WIP
OVERVIEW
...
The config.json file stores the full set of settings in the system settings that - they roughly map to the same System Console sections/sub-sections, but is are a superset of the settings exposed in the System Consolesurfaced by these sections/subsections.
API methods
There are mainly two categories of API calls : get and create, patch and update. The get calls are gated by the READ permissions and the create, patch and update are gated by the WRITE permissions.
...
There is a set of permissions that are used to gate specific tasks in the API and not covered by the MANAGE_SYSTEM permission, like PERMISSION_MANAGE_JOBS, PERMISSION_LIST_PRIVATE_TEAMS PERMISSION_JOIN_PRIVATE_TEAMS, PERMISSION_MANAGE_TEAM, etc.. These will be assigned to the new roles, depending on their specific requirements.
Note that not all of them are system level permissions.
...
Note: For User Manager role above, for the “User Management” section we could have had only the PERMISSION_READ_SYSCONSOLE_USERMANAGEMENT and PERMISSION_WRITE_SYSCONSOLE_USERMANAGEMENT permissions. The reason we have more permissions , assigned to subsections, is that in the future we project to have variants of this role that will have some of their subsections WRITE permissions removed.
...
Since the newly-added permissions are by definition linked to the System Console sections, we need to map them to the config.json settings. To do that, we have reviewed the existing System Console settings and mapped them to the corresponding config.json fields:
an excerpt of a snippet from the sectionToPermission struct:
...
The goal is to maintain parity between the set of permission needed to gate a System Console section/sub-section and the equivalent set needed to gate the corresponding set of `configconfig.json`json settings + API calls.
Access to a section/subsection of the System Console
...
Most API calls that were previously gated by the MANAGE_SYSTEM permission are now gated by the READ_* permissions for the get() calls and WRITE_* permission for the create, patch and update calls.
If we need to have more granular access to an API method that corresponds to the functionality of a sub-section in the System Console (like in the User Manager case), we will gate those calls on a case by case (a single panel functionality in the System Console panel can map to one or more API calls).
Permissions
See changes detailed above
Schema
No schema changes
REST API
The following API methods will have their gating functionality changes, as follows:
Performance
No performance degradation expected.
Plugins
CREDITS
Thanks to