Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

WIP

OVERVIEW

...

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).

The algorithm is rules are as follows:-

  1. if the current user's system role does not have READ or WRITE permission on the resource, the section is hidden for the user.

...

  1. 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

...

...

  1. if the current user's system role only has READ permission on the resource the resource(section) is disabled

...

  1. . Example: User Manager has PERMISSION_READ_SYSCONSOLE_AUTHENTICATION so the Authentication section is disabled for a user.

...

  1. if the current user's system role has a WRITE permission on a

...

  1. subsection, then

...

  1. no matter if he has READ or WRITE permission on the parent section, the resulting permission on the subsection is WRITE

...

  1. 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).

...

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