On the /admin/people/permissions page, when a permission is checked for the "Authenticated user" role, that permission is inherited by all custom roles, and the checkbox becomes disabled and grayed out in the UI.
However, on /admin/people/permissions/{user_role}, there's no indication that a permission has already been inherited from the "Authenticated user" role. Admins can still check these boxes, which creates redundant permissions and complicates the permission structure. Using the role-specific permissions pages, admins can easily miss inherited permissions, leading to confusion.
This issue is particularly glaring on larger or enterprise sites with many user roles and contrib modules, where the main permissions page (/admin/people/permissions) is slow to load.
/admin/people/permissions and see that "Content editor" role inherits access to the "Basic HTML" text filter. The checkbox is disabled and checked.admin/people/permissions/content_editor and see that the checkbox for "Basic HTML" text filter is enabled and unchecked.Discuss UX implications and settle on an implementation approach.
Write patch.
Role-specific permissions pages will show inherited permissions as "enabled" and "uneditable", consistent with the main permissions matrix behavior.
Site admins will now be able to see when a user role has been granted permission to do something via an inherited permission. This will provide necessary in-page context to make better decisions when modifying other permissions.
It will no longer be possible to store redundant permissions from the Role-specific permission pages.
Active
11.0 🔥
Last updated
While looking into this issue I also realized there is opportunity to take things a step further and reduce those redundant permissions.
I filed a sister ticket and follow-up ✨ Tree shake permissions matrix upon save Active .
Changes are made on on 11.x (our main development branch) first, and are then back ported as needed according to our policies.