It is currently possible to store redundant permissions whereby custom user roles can be granted a specific user role, and then later the permission granted to the Authenticated user role, allowing all custom roles to inherit this permission, but the permission is not removed from the individual roles. This can result in confusion and complexities when auditing a site's permissions via Configuration Management or via the UI.
/admin/people/permissions
and add the "Use help pages" permission to the "Content editor" role, save the page./admin/people/permissions/content_editor
and confirm that the checkbox for the role is checked./admin/people/permissions
and add the "Use help pages" permission to the "Authenticated user" role. The checkbox for the same permission under the "Content editor" role becomes grayed out. Save the page./admin/people/permissions/content_editor
and confirm that the checkbox for the role is still checked. Uncheck the checkbox and save the page. Confirm that the checkbox for the role is no longer checked./admin/people/permissions
and confirm that there is no visual change on the permissions matrix and the permission is still granted to the role via the checked and disabled checkbox.See also related issue β¨ disable checkboxes inherited from authenticated user role on role-specific permissions page Active .
Any time a permissions form is submitted, ensure all permissions that are granted to the Authenticated user role are pruned from other custom roles.
Note: under the current behavior of Drupal 10 and 11, this resolution will create a head scratcher on role-specific permissions forms /admin/people/permissions/{user_role}
because users will try to check a permission that they've already been granted and not see the permission actually being saved. Therefore this solution should be built and released side-by-side with
β¨
disable checkboxes inherited from authenticated user role on role-specific permissions page
Active
.
For this reason, perhaps it is better to eventually combine these two, but for now will leave them separate so that the merits of the bug/improvement can be discussed indepently.
Identify any caveats of preventing redundant permissions. Are there any?
Write patch.
None.
None.
A new function or method is introduced to prune redundant permissions from custom user roles. It would act on all user roles except for Authenticated user and Anonymous user. The function should be marked for internal use and only executed upon form submit from one of the permissions forms.
A hook_update_N should be introduced to run the permissions pruning function once the code has landed and included in a core release.
Any redundant permissions will be removed from active configuration after saving the permissions forms. Websites utilizing configuration management may also see redundant permissions removed from several user role yaml files after upgrading to the latest core release containing this fix and running database updates.
Active
11.0 π₯
Last updated