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 example, web links and sub-sections that have the current user’s role has 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(s) tree shown in the next page is disabled.
write - the section (and its subsections) are fully accessible

...

About - none
Reporting - none
User Management - read+write
Users - read+write (with the exception of not being able to reset other admin passwords)
Site Configuration - none
Authentication - read
Plugins - none
Integrations - none
Compliance - none
Experimental - none

...

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