WIP

OVERVIEW

...

The new roles can have the following levels of access to these sections (and in some instances to some of their subsections) - none, read, write, where:
none - the section is not displayed to the User
read - the section is displayed but all of its components are disabled. For , with exceptions given by the type of component (for example, web links and search boxes are not disabled) and by the permissions on the sub-sections that - if the current user’s role has WRITE permissions on are a subsection, it is 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(s) tree shown in the next page is disabled.
write - the section (and its subsections) are fully accessible

...

There are mainly two categories of API calls : get or and create, patch and update. The get calls are gated by the READ permissions and the create, patch and update are gated by the WRITE permissions.

...

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 can map to one or more API 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