This simplifies the UI, as nobody really understood the difference
between ‘Restrict Application Installation’ and ‘Restrict Application
Installation for Others’. Now there’s just a ‘Restrict Application
Installation’ checkbox, which controls application installation in the
home and system flatpak repos.
The underlying app-filter representation in libmalcontent still supports
restricting installation to them separately, but the UI will always set
them to the same value.
There is a suggestion that we may want to support user repos again in
future iff the user has added a remote to their user repo. However,
figuring that out for other users (which is what the admin would have to
do when setting this all up) starts to get tricky with permissions for
reading other users’ home directories. Skip that for the moment — we can
reconsider adding that option in future if someone argues a case for it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #30
This documents some development principles which should be borne in mind
when working on new malcontent features.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This prevents a polkit authentication prompt popping up unexpectedly if,
for example, a non-privileged user has opened and immediately closed
malcontent-control.
Spotted by Andre Moreira Magalhaes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
While the label for the OARS pseudo-combobox was updated when loading a
user’s app filter, the internal state (`self->selected_age`) was not.
Similarly, the set of restricted apps wasn’t loaded until the restricted
apps dialog was opened.
This caused problems when loading a user’s parental controls and then
editing a control which *wasn’t* restricted apps or the OARS level. The
resulting app filter would be built using default values for those two
controls, overwriting and losing their previous values when it was
saved.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Since the changes to avoid reloading the app list entirely when loading
an app filter (commit 9d4639cf49), the switch states haven’t been set
properly when loading a new app filter, since the app rows already
exist, and the switch states were only set on creation.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Rather than waiting until an app filter is set on the application
selector, load the app list immediately at construction time. This is
now possible because it can be diffed easily when the app filter is set.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #28
Instead of removing all the entries in the list store when the set of
installed apps is updated, diff the old and new lists so that removed
apps can be selectively removed from the list store, and added apps can
be selectively added.
This means that we can (in subsequent commits) reload the app list less
conservatively, as doing so will no longer remove in-progress user
modifications to the set of blocked apps. Modifications are still only
saved when the restrict applications dialogue is closed.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #18, #28
This is handled on the primary instance, and causes the tab to be
switched to show the given username (if possible).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #19
This doesn’t achieve anything by itself, but makes some upcoming commits
to diff the new/old app lists work properly.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #18, #28
Following on from commit b5b1ac2, change a couple of other strings to be
the same to reduce the number of translatable strings. These strings are
unlikely to ever be seen by the user, so it’s not an issue that they’re
becoming a little less specific.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Philip Withnall pointed out that if mct_manager_get_session_limits()
fails with G_DBUS_ERROR_ACCESS_DENIED or
org.freedesktop.Accounts.Error.PermissionDenied, the error message
will wrongly refer to app filter data. Make it more generally applicable.
Signed-off-by: Simon McVittie <smcv@debian.org>
In distributions that package shared libraries and daemons separately,
it's possible to have the shared library (because it's required to run
something like Flatpak) but not the accountsservice daemon or its
malcontent extension (because the administrator of this particular
installation has no interest in parental controls, and their choice of
desktop environment is such that nothing else depends on accountsservice
either). This minimizes the memory and disk space cost of enabling the
libmalcontent feature in Flatpak for those who do not need it, while
keeping it available for those that do.
Treat this the same as if accountsservice is available but the
malcontent extension is not: fail open, by returning
MCT_MANAGER_ERROR_DISABLED.
Resolves: https://gitlab.freedesktop.org/pwithnall/malcontent/-/issues/27
Bug-Debian: https://bugs.debian.org/972145
Signed-off-by: Simon McVittie <smcv@debian.org>
Philip Withnall
Yuri Chornoivan
scootergrisen
Philip Withnall
Piotr Drąg
Yuri Chornoivan
Simon McVittie
Anders Jonsson
Milo Casagrande
Philip Withnall