Recently dynamic DNS module was fixed to use root ownership and limited
permissions for configuration and status files to avoid other users
reading dynmaic DNS account details. This caused a regression when
Plinth is being run as non-root user. This patch runs the commands to
read the current configuration as root user.
When invoking actions, invoke them using sudo so that Plinth itself can
run as non-root. Most operations require superuser previlage. Those
that don't require superuser should not be part of the action script and
can be moved to Plinth main.
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.
This app rightfully belongs in system configuration section instead of
the application section. It is setup once and not used regularly. It
is not service but enabler for other services. Closes: #441.
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.
- adapted all modules to not use views.ConfigurationView anymore
- removed templates that are not needed anymore
- no more implicit 'enabled' and 'get_status' functions in __init__.py files
- (more coherent/explicit use of Django functionality)
- 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.
- For each application, add ./tests directory and __init__.py file
within it.
- Modify test controllers (coverage.py, runtests.py) to find the new
test directories for testing and coverage analysis.
- Move existing application-specific test modules (test_pagekite.py) to
the newly created directories.
- Don't allow strings to be sent as arguments. The mixup with
lists/tuples could be dangerous.
- Don't escape arguments. subprocess.Popen takes care that arguments
are passed on nicely to the actions.
- Update tests.
