Versions Compared

Key

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

WIP

OVERVIEW

...

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

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

  3. if the current user's system role has a WRITE permission on a subsection, then no matter if he has READ or WRITE permission on the parent section, the resulting permission on the subsection is WRITEExample: 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.

(TBD) 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 subsection (the opposite can happen, see above).

...

Similar to the System Console, a user will need to be in a role that has the global READ_SETTINGS permission to fetch the settings a setting 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 Authentication settings (see table above).

Access to the various API methods

Each Most API call calls that was were previously gated by the MANAGE_SYSTEM permission is are now gated by the READ_* permission 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 (one a single panel functionality in the System Console panel can map to one or more than one API callcalls).


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