Sometimes there is a need to give access for other, non-administrator users to manage access to certain website resources likes posts, pages, metaboxes, widgets or API endpoints. You also do not necessarily what to give too many privileges like changing capabilities or creating new roles. That is why AAM provides the flexibility to define very granular access also to the AAM page and its services.
Prior to AAM 4.7.0, most of the access management to AAM functionality was managed with ConfigPress configurations however we figured that it probably will be a little bit more transparent and intuitive if access control to AAM services can be accomplished with custom capabilities.
By default, access to AAM functionality is granted only for users that have administrator capability (technically only users with the Administrator role). However, in order for other non-administrator users to use AAM services, you can redefine this behavior with a few simple steps.
Step 1. Redefine capability to AAM itself.
The first step is to redefine the default access capability. This is the first authorization layer that AAM uses to verify that user can work with AAM services. Create custom capability aam_manager. Go to the Capabilities tab and on the top right corner click + Create button. From this point only users with aam_manager capability checked, will have access to the AAM functionality.
Note! Make sure that you do not misspell aam_manager capability. “R” in the end!
Step 2. Define what type of subjects can be managed.
All users, roles, visitors, and default settings, collectively are called subjects. So basically the subject is who you are managing access for. Because the majority of access settings are defined for a very specific subject (e.g. role or visitors), you have to be very explicit about what particular subjects are allowed to be managed.
The core AAM functionality supports four different types of subjects: Role, User, Visitor, and Default. So aam_manage_roles, aam_manage_users, aam_manage_visitors, and aam_manage_default are capabilities that grant access to respective subject.
Note! If you do not grant one of the four mentioned above capabilities, a user just with aam_manager capability will see only “You are not allowed to manage AAM subjects” message.
It is strongly discouraged to give the ability for other users to manage the “Default” subject as this may affect your administrator user permissions.
Step 3. Define access to AAM services.
The next step is to define what actually user can do within AAM and below is the list of all available capabilities with a detailed description.
Note! AAM has integrated users/roles filtering that is based on user levels so you should not worry that user with lower user level will be able to manager users and roles with higher user level. For more information about this feature please refer to the WordPress Users and Roles Filter article.
Grant access to the Backend Menu service.
Grant access to the Toolbar service.
Grant access to the Metaboxes & Widgets service
Grant access to the Capabilities service. Note! Be extra careful with giving access for other users to manage list of capabilities. For more information check aam_manage_capabilities reference page.
Grant access to the Posts & Terms service.
Grant access to the API Routes service.
Grant access to the Access Denied Redirect service.
Grant access to the Login Redirect service.
Grant access to the Logout Redirect service.
Grant access to the 404 Redirect service.
Grant access to the Settings area.
Grant access to the Add-Ons area.
Allow user to see Notification Manager.