In Bricks->Settings->builder access, role is set to “No access”
When I create new user (with that custom role) it has access to builder on user level.
Every time new user is created I have to manually disable access. I think for new users it should be default to whatever is set in bricks global settings.
I am able to get both results and I am able to reproduce the issue.
We are using plugin called “admin menu editor” (Admin Menu Editor – WordPress plugin | WordPress.org) I have the pro version of it. It has feature to register new roles. It should use add_role(). I havent tested to register new roles manually (custom function etc.).
New roles are visible in bricks settings (test role, test role 2):
To reproduce this issue we need to create a role that copies capabilities from administrator. (test role 2). It should be one time copy only, not “sync”. Should be doable with custom function too?
I contacted the author of plugin he replied with following:
Have you ruled out the possibility that bricks always gives access to
roles that have certain admin capabilities, regardless of “builder
access” settings? Try the same thing with a more limited role like
“Author” and see if the problem still happens.
If bricks looks for a specific capability, and that capability is also
used for an admin menu item, enabling that item for the custom role
would give them the capability even if it’s not enabled in the “Roles” tab.
Does the problem persist if you temporarily deactivate Admin Menu
Editor Pro? This would at least rule out issues with the admin menu
configuration and the “editable roles” feature. If the same thing still
happens when AME is inactive, it’s most likely related to role capabilities. Tested: user still gets access to bricks
Not to hijack the thread, but I have the same problem using the Members plugin. Setting the new role to no access in the Bricks builder access menu, the role still has full Bricks access and capabilities.
Update: when I disable the edit posts permission for the user role in the Members plugin, the Bricks permissions are revoked. However, that role then can’t edit normal posts either, which is no good. Seems the Bricks permissions are somehow coupled to the edit post permissions, shouldn’t this be decoupled?
Update 2: I think I narrowed it down to the ‘remove user’ permission in the Members plugin. Strangely there are two permissions named ‘remove user’. Enabling one of them doesn’t seem to do anything at all, it doesn’t actually give remove user permissions to the role. Neither does it give Bricks access.
Enabling the other ‘remove user’, does give permission to remove a user as well as full Bricks access. I think this ‘remove user’ setting, is the one that should be decoupled from enabling Bricks access.
BTW I’m using a role that is cloned from the default WP ‘Author’ role.
I appreciate your efforts in exploring this issue further. The behavior you’re observing with the manage_options capability is consistent with WordPress’s core design. In WordPress, the manage_options capability is a powerful permission typically reserved for administrators. Users with this capability have access to administrative features, including the ability to modify most aspects of a site, such as themes and plugin settings.
Since Bricks is a WordPress theme and follows WordPress standards, users with manage_options capability inherently gain access to a wide range of settings, including those of Bricks builder access. Therefore, it’s advisable to assign the manage_options capability only to roles that require full administrative access.
In your case, for roles not intended to have administrative-level access, it would be best to avoid assigning the manage_options capability. This approach aligns with the principle of least privilege, ensuring users have only the permissions necessary for their role.
We have plugins that our clients needs to have access to. These plugins can require manage_options capability. So its definately needed in some cases.
We are using admin menu editor to hide or deny access to certain parts of WordPress.
In current state I think builder access page can be a quite missleading since its clearly saying “No access” even for roles that has manage_options capability.
Hmm yeah, you have a point, it could be confusing if it says “No access” in Bricks setting but you’re still able to access it. I created a ticket for this