WIP
OVERVIEW
Add three new System-scoped roles to the product: Junior Admin, User Manager and Console Viewer.
GOALS
-
-
-
SCOPE
In:
gate System Console sections and subsections access
gate
config.json
settings managementgate API methods.
Out:
defining define custom roles
support plugins permissions
TERMINOLOGY
resources - they can be System Console sections/subsections, config.json
settings, API methods.
SPECIFICATIONS
Requirements
...
Code Block |
---|
PERMISSION_READ_SETTINGS PERMISSION_WRITE_SETTINGS PERMISSION_CREATE_USER_ACCESS_TOKEN PERMISSION_READ_USER_ACCESS_TOKEN PERMISSION_REVOKE_USER_ACCESS_TOKEN PERMISSION_EDIT_OTHER_USERS PERMISSION_GET_PUBLIC_LINK PERMISSION_LIST_USERS_WITHOUT_TEAM PERMISSION_MANAGE_JOBS PERMISSION_MANAGE_OAUTH PERMISSION_LIST_PUBLIC_TEAMS PERMISSION_LIST_PRIVATE_TEAMS PERMISSION_READ_SYSCONSOLE_USERMANAGEMENT PERMISSION_READ_SYSCONSOLE_USERMANAGEMENT_USERS PERMISSION_WRITE_SYSCONSOLE_USERMANAGEMENT_USERS PERMISSION_READ_SYSCONSOLE_USERMANAGEMENT_GROUPS PERMISSION_WRITE_SYSCONSOLE_USERMANAGEMENT_GROUPS PERMISSION_READ_SYSCONSOLE_USERMANAGEMENT_TEAMS PERMISSION_WRITE_SYSCONSOLE_USERMANAGEMENT_TEAMS PERMISSION_READ_SYSCONSOLE_USERMANAGEMENT_CHANNELS PERMISSION_WRITE_SYSCONSOLE_USERMANAGEMENT_CHANNELS PERMISSION_READ_SYSCONSOLE_USERMANAGEMENT_PERMISSIONS PERMISSION_WRITE_SYSCONSOLE_USERMANAGEMENT_PERMISSIONS PERMISSION_READ_SYSCONSOLE_AUTHENTICATION |
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 mapped 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:
...
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 to the sections (READ_*no WRITE_SETTINGS
permission).
...
if the current user's system role does not have
READ
orWRITE
permission on the resource, the section is hidden for the user. Example: User Manager does not havePERMISSION_READ_SYSCONSOLE_PLUGINS
orPERMISSION_WRITE_SYSCONSOLE_PLUGINS
so the Plugins section is hidden from view for a user in a User Manager roleif the current user's system role only has
READ
permission on the resource, the resource(section) is disabled. Example: User Manager hasPERMISSION_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 subsection, then no matter if he hasREAD
orWRITE
permission on the parent section, the resulting permission on the subsection isWRITE
Example: User Manager hasPERMISSION_WRITE_SYSCONSOLE_USERMANAGEMENT_USERS
on the Users sub-section but alsoPERMISSION_READ_SYSCONSOLE_USERMANAGEMENT
on the entire section, the resulting permission isWRITE
on the sub-section.
...
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 section/subsection can map to one or more API methods 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