WIP

OVERVIEW

...

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 `config.json` settings + API calls.

...

Access to a section/subsection of the System Console

First, the user needs to be in a role that gives them access to the System Console from the chat-facing side (READ_SETTINGS). Then, depending on the role, the user could have read-only access (no WRITE_SETTINGS permission)TBD - maybe check in chat facing if one has READ_SETTINGS or WRITE_SETTINGS access and then only assign READ_SETTINGS or WRITE_SETTINGS to a role. Or maybe we need READ permission for the API calls to populate the read-only sections (?) - we should not be able to read

The algorithm is as follows:
- if the current user's system role does not have READ or WRITE permission on the resource, the section is hidden for the user.
Example: User Manager does not have PERMISSION_READ_SYSCONSOLE_PLUGINS or PERMISSION_WRITE_SYSCONSOLE_PLUGINS so the Plugins section is hidden from view for a user in a User Manager role.
- if the current user's system role only has READ permission on the resource the resource(section) is disabled
Example: User Manager has PERMISSION_READ_SYSCONSOLE_AUTHENTICATION so the Authentication section is disabled for a user.
- if the current user's system role has a WRITE permission on a sub-section, then irrespective if he has READ or WRITE permission on the parent section, the resulting permission on the subsection is WRITE
Example: User Manager has PERMISSION_WRITE_SYSCONSOLE_USERMANAGEMENT_USERS on the Users sub-section but also PERMISSION_READ_SYSCONSOLE_USERMANAGEMENT on the entire section, the resulting permission is WRITE on the sub-section.

Note, by design we will not define a case in which a role has WRITE access on a section and READ on a sub-section (the opposite can happen, see above).

...

Access to a setting in the config.json

Similar to the System Console, a user will need to be in a role that has the global READ_SETTINGS to fetch the settings and WRITE_SETTINGS to patch/update a setting. Beyond that, if the user only has READ access to a section setting, we are restricting update access to that setting. For example, since User Manager has only PERMISSION_READ_SYSCONSOLE_AUTHENTICATION, the user in this system role will not be able to update the config.json fields mapped to the settings.

...

Access to the various API methods

Each API call that was previously gated by the MANAGE_SYSTEM permission is now gated by the READ_* permission for the get() calls and WRITE_* permission for the create/patch/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 (one panel functionality in the System Console panel can map to more than one API call).

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