This can then be used by a privileged action to verify that packages
requested for installation are in fact valid. This slightly improves
security of those privileged actions.
Currently menu items are shown in alphabetical order in applications and
no clear order in system configuration. This is done using static
weights for menu items based on English names that does not work for
other locales.
Sorting can't be done at the time of adding menu items as users of
multiple locales may use the interface at the same time.
Implement a sorting mechanism based on existing order as well as labels
of menu item. This allows the flexiblity of grouping menu items in
future as it may be need for system configuration. In case of help menu
Remove sort order for all modules except for help menu as here we want
that specific order.
wget does not seem to support interface scoping for IPv6 addresses. For
example, http_proxy=http://[fe80::babe:ff:ffff:babe%eth0]:8118/ . Curl
supports this.
This fixes most of the failures for IPv6 related addresses. Hide the
last failure as there does not seem to be a proper fix from OS level:
when using link local addresses, if a hostname is resolved to IPv6 link
local address, it is not scoped to that interface. It can't properly be
used by any tool then.
It has been decided that FreedomBox will no longer support ownCloud due
it's removal from Debian. To deal with this:
- Don't show ownCloud in Plinth any more for new users.
- For users who have already installed ownCloud, show a warning message
that they need to migrate away from ownCloud or need to manage it
manually.
The Service object now offers handling services on a system level,
and gathering information whether it's enabled or running.
New methods: enable, disable, is_enabled, is_running;
For this it needs the correct (system-level) service name.
All of the methods can be overridden/customized.
This changes all modules to the new Service object and deletes
action scripts that are not required anymore.
- The last part of the module import path is the module name. This also
becomes the Django app name. Apps names have to be unique. Hence,
there is no scope for two different modules with same name but
different load path to exist in the project.
- Most uses of list of loaded modules are dealing with app names instead
of full module load path. This is due to the fact that Django deals
with app names and not module paths.
- It is also somewhat clumsy to access a loaded module as we are
re-importing every time to get access module.
- Simplify all of the above by using app names are module identifiers
and maintaing an ordered dictionary of app names to loadded modules.
- Remove unused imports.
- Minor styling fixes.
