This PR adapts the /grass_modules and /modules endpoint such that only those grass modules which are permitted to be used by the authenticated user are listed. The permitted grass modules are stored in the redis db as accessible_modules and are saved when a user is created (by default from the whitelisted modules from the config) or updated. In this PR, they are compared against the "complete" grass module list that is generated in core.modules.grass.createModuleList.
However this only applies to non-admin users. admin and superadmin users effectively have access to the complete range of grass modules, even though they may have only a limited list in their accessible_modules stored in redis.
Tests are adapted and added accordingly.
Following PRs could work on:
The inconsistency of admin and superadmin users having an accessible_modules list which seems to be effectively ignored.
Check whether PC-templates contain grass-modules that are not permitted to the user. Currently, all PC-templates are permitted to the users, but they may fail if certain grass-modules within cannot be used.
This PR adapts the
/grass_modules
and/modules
endpoint such that only those grass modules which are permitted to be used by the authenticated user are listed. The permitted grass modules are stored in the redis db asaccessible_modules
and are saved when a user is created (by default from the whitelisted modules from the config) or updated. In this PR, they are compared against the "complete" grass module list that is generated incore.modules.grass.createModuleList
. However this only applies to non-admin users. admin and superadmin users effectively have access to the complete range of grass modules, even though they may have only a limited list in theiraccessible_modules
stored in redis. Tests are adapted and added accordingly.Following PRs could work on:
accessible_modules
list which seems to be effectively ignored.