Design a better model for managing permissions

Thanks for creating this issue @yoroy. I have been working on solving some of these problems at https://www.drupal.org/project/permission_ui. It hasn't got the grouping part yet, but we can go towards there once we make the core permission API more generic (config entity) instead of "special" component.

One thing that would open a door to making this enormously simpler is role dependencies. If you can only have the "editor" role if you already have the "authenticated user" role, then there's a whole lot less permissions we have to show if we're summarising or removing permissions for "editor". You only have to show that "editors" are always "authenticated users" and have the extra permissions x, y, z.

I'm just talking about simple role dependency, don't allow people to have role A unless they also have role B, a far simpler proposition than the kind of inheriting hierarchy discussed in #1200572: Concept of a hierarchical permission system, and and inherently backwards compatible.

We should have a look at other similar interface outside of Drupal. I thought google for that would be easy, but it turns out, the systems I googled (joomla/typo3 have permissions on a per site category level) or simply look basically as boring as Drupal itself.

#2934995: Add a "Manage permissions" tab for each bundle that has associated permissions is a proposal to handle the per-bundle types generically, probably including UI support. So that could provide an iterative improvement by making the longest permission subsets (node, etc.) more manageable.

Not really better, but a possibly fairly simple improvement for many use cases would be to have a per-module page, I think there are contrib modules doing the same.

We already have per-module direct-links on the modules page as well as admin/index, those could then directly link to a page with just the permission of that module, which would obviously by way faster to load than the whole page. The problem with proposed filters in the whole list is that we still have to load everything before we can start to filter and will still submit everything.

Let's add the JS initiative tag.

We discussed the problem of the Permissions page at #3214045: Drupal Usability Meeting 2021-05-21.

One idea that came up is related to the suggestion in #6.

Example: starting with the Standard profile, I enable Content Moderation and Layout Builder. I am presented with a confirmation form:

Some required modules must be enabled

You must enable the Workflows module to install Content Moderation.
You must enable the Layout Discovery module to install Layout Builder.

Would you like to continue with the above?

Continue Cancel

The standard advice, after enabling any module (core or contrib) is to configure permissions for the module. We should make it easy to follow that advice! After I submit the confirmation form, why not load a page with just the permissions for the modules I am enabling? (In this example: Workflows, Content Moderation, Layout Discovery, Layout Builder. Well, LD does not have any permissions.) Or at least, in the status message, provide a link to such a page.

First step: implement #6, and do it in a way that works for one module or several modules.

I'd like to echo and support Benji's recommendation. This would go a long way towards syncing the action of enabling one or more modules with their followup action of configuring related permissions that many/most modules require to be functional in a predictable way.

Following on from what @benjifisher and @worldlinemine said.

One idea that I had during #3214045: Drupal Usability Meeting 2021-05-21 was the idea of a module being able to suggest recommended configuration (including permissions). So for instance, as Benji described: "After I submit the confirmation form, why not load a page with just the permissions for the modules I am enabling?; This screen could have some permissions pre-selected for some roles as "suggestions" and a "apply suggestions" button. Perhaps the screen could even suggest creating one or more roles (if they don't exist), for example Content Moderation could also suggest creating the Content Editor and Content Manager roles in addition to a suggested set of permissions.

In any case, I think this screen should be accessible using the existing "Permissions" link that modules provide (in the same way that the "Configure" link takes you to that modules configuration screen).

Additionally, when a module is enabled, even if some of its dependencies are already installed, those should be shown on this screen as well, for example enabling Content Moderation enables Workflow, and the bulk of Content Moderation permissions sit under Workflows; So when enabling a contrib module that also depends on Workflow, even if Workflow is already enabled, on this screen we would still want to show permissions for Workflow because there may be new permissions that didn't exist before.

I just added #3216341: Provide a module-specific permissions form, responding to #6, #8-10. I have already started implementing it.

@AaronMcHale, I think you mis-remember the permissions for Content Moderation (#10). They mostly appear under that module, with just one permission under Workflows. But maybe there are other examples where one module should have a link to permissions for more than just its own permissions.

If a module wants to recommend a set of permissions, then it can provide one or more user roles under config/install/. The site administrator can copy those permissions to existing roles and delete the module-provided roles, or simply keep them. I am not sure we need a new way for a module to provide suggestions like this.

Re @benjifisher

@AaronMcHale, I think you mis-remember the permissions for Content Moderation (#10). They mostly appear under that module, with just one permission under Workflows.

Oh okay that's good then. field_ui is probably a better example then, as I know that field_ui permissions appear under field_ui, even though they directly relate to the entity types in other module (e.g. permissions for manage fields, manage display, etc). The fact those permissions show under field_ui instead of the module that I'm working with (or working on), mean that I more often than not completely forget these permissions exist.

We reviewed this issue, and some related issues, at #3241573: Drupal Usability Meeting 2021-10-15. We agreed that we have made enough progress that it is time to update the issue summary.

After #3216341: Provide a module-specific permissions form (Fixed) and #2934995: Add a "Manage permissions" tab for each bundle that has associated permissions (getting close) we have made a lot of progress. Assuming that #2934995 and some related issues get fixed, we have the following improvements:

• There are Permissions forms for each module, or list of modules.
• The links on /admin/modules now go to these new pages.
• When one or more module is enabled, the confirmation message includes a link to one of these new pages.
• Links in the help pages go to these new pages instead of the main Permissions form.
• Each bundle type that has permissions (such as a content type or a vocabulary) has a "Manage Permissions" tab.

In short, the old Permissions form is still there, but a lot of the time (most of the time?) we can manage permissions without using it.

Reminder: we already have the role-specific Permissions forms such as /admin/people/permissions/authenticated.

At this point, it seems right to give people time to get used to these changes. Then start some user interviews before deciding what to do next.

The following issues are mentioned in the current issue summary. These have all been fixed, so I will remove them from the summary:

• #3216341: Provide a module-specific permissions form
• #2862422: Add per-media type creation permissions for media
• #1848686: Add a dedicated permission to access the term overview page (without 'administer taxonomy' permission)
• #2892821: Core modules check node module's "access content" permission for displaying things that have nothing to do with nodes