Versions Compared

Key

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

WIP

OVERVIEW

Add three new System-scoped roles to the product: Junior Admin, User Manager and Console Viewer.

GOALS

  1. -

  2. -

  3. -

SCOPE

In:

Out:

  • defining custom roles

  • plugins permissions

SPECIFICATIONS

Requirements

  • the goal is to add at least three new roles: User Manager, Console Viewer and Junior Admin (see https://www.notion.so/New-System-Roles-Special-Admins-be514029606545e3be3aa3e8c8ba507e
    for current requirements). These new roles will be defined at System scope. They will have access to the System Console - like the System Admin

  • these new roles will have specific rights on the following resources:

    • System Console sections and subsections.

    • config.json settings (through the API config.goget/update set endpoints).

    • various API methods that support functionalities that are being exposed in the System Console (e.g. display analytics, link, sync groups) - separate from config settings.

High-level Architecture

Resources

...

About
Reporting
User Management
Environment
Site Configuration
Authentication
Plugins
Integrations
Compliance
Experimental

The new roles can have level the following levels of access to these sections (and in some instances to some of their subsections) :
- none, read, write, where their semantics is:
none - the section is not displayed to the User
read - the section is displayed but all of its components are disabled. For example, web links and sub-sections that have WRITE permissions on are not disabled. In some cases the page needed to access the main functionality is not disabled but the landing page components are - example: Edit Scheme is enabled, but the permission tree shown in the next page is disabled.
write - the section (and its subsections) are fully accessible

...

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