Make the user permissions page less daunting for new users

Created on 20 December 2024, 3 months ago

Problem/Motivation

If you aren't very familiar with Drupal, the permissions page (admin/people/permissions) is going to be confusing at best. What does "Content block: Administer display" mean anyway?

I propose extending *.permissions.yml files to add help text. They currently have descriptions, but the help text would be for a longer explanation that would include possible use cases, side-effects, the roles that the permission might be appropriate for, etc. The help text would be conversational and designed for beginners.

I also propose adding sections to each module's permissions. E.g., "Delete own files" could be put in a "user" section, while the much more consequential "Delete any file" could be put in an "advanced" or "admin" section.

There would be a multiselect filter at the top of the page listing the sections and the user could choose which sections they want to see.

Steps to reproduce

I don't know if Drupal CMS is being tested with non-Drupal users, but if so ask them what they think of the permissions page.

Proposed resolution

I posted a module with a proof of concept. See this page for the changes to *.permissions.yml files and see the image on this page for what it looks like.

See https://www.drupal.org/project/permissions_repository β†’

Remaining tasks

If there's interest, I'll clean up the module code and implement the missing parts. I'll also resolve issues with the tooltip module; maybe a variant of that module could be put into core too since it seems like it would get a lot of use.

User interface changes

See the image for what it looks like now. I'm more than willing to defer to others on how these new features appear in the UI.

API changes

TBD. The service I created could just be used by the permissions page, or it could replace the existing service.

✨ Feature request
Status

Active

Version

11.1 πŸ”₯

Component

user system

Created by

πŸ‡ΊπŸ‡ΈUnited States TolstoyDotCom L.A.

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @TolstoyDotCom
  • πŸ‡¦πŸ‡ΊAustralia larowlan πŸ‡¦πŸ‡ΊπŸ.au GMT+10

    I also wonder if we could do some route lookups and list paths the permission would grant you access to

  • πŸ‡³πŸ‡ΏNew Zealand quietone

    @tolstoydotcom, I think this is a duplicate of #1765576: Redesign Permissions Page β†’ . Can you confirm?

  • In the least it should be part of that issue or incorporated into it.

  • πŸ‡ΊπŸ‡ΈUnited States TolstoyDotCom L.A.

    The two issues are related, but I don't think this is a duplicate: the other issue is about how to present the info, this issue is about giving more info. As with art, I know what UX I like but I can't draw a crooked line so I'm perfectly willing to let others handle that aspect of things. No matter what it ends up looking like, the permissions page is going to need more info if anyone expects regular users to use it. Regular users are going to need much more detailed explanations of what various things do.

    And, there needs to be some sort of structure rather than confronting them with dozens of permissions from one module. Field UI has 28 permissions and Node has 42. That's going to overwhelm people and dividing the permissions into sections would make it easier for newer users. One of the node permissions is "Bypass content access control"; regular users aren't going to understand what that means, the side-effects, etc etc without a detailed explanation and examples.

  • In that case I think this issue needs a title update to more clearly indicate its scope. Additionally, you should comment at #1765576: Redesign Permissions Page β†’ to alert the followers of that issue of the existence of this issue.

  • πŸ‡ΊπŸ‡ΈUnited States TolstoyDotCom L.A.
  • πŸ‡ΊπŸ‡ΈUnited States TolstoyDotCom L.A.

    I did as #6 suggests.

    No matter how it's presented, augmenting permissions files seems like it's going to be necessary for new users. Should I create a patch? If so, should it be based on the current module, or based on using plugins for each of the additions to the permissions files. Those plugins would have a weight so the heaviest plugin would do what currently happens: everything is assumed to be a permission. Each plugin would get an array derived from the permissions file and the plugin would indicate in that array if what it's processed.

  • You may as well try. But, create merge request instead of a patch.

  • πŸ‡ΊπŸ‡ΈUnited States TolstoyDotCom L.A.

    I pushed the changes/additions if anyone wants to review them. I made a minor change to the existing file core/modules/user/src/PermissionHandler.php and a few changes to core/modules/user/user.services.yml (I added comments for those).

    There are now three ways to get permissions:
    - the 'user.legacy_permissions' service. This is the current way.
    - the 'user.permissions' service. This is a replacement for the former way.
    - the 'user_permissions_parser.repository_factory' service. This is what new code should use, it returns an object with all of the permissions.

    There are differences in the sorting between the first two services above. If that's an issue I can change it. However, both get the same permissions.

    I can add tests if this looks OK.

  • πŸ‡³πŸ‡ΏNew Zealand quietone

    Found some more related issues. I did not review them to determine how they relate to this.

  • πŸ‡ΊπŸ‡ΈUnited States TolstoyDotCom L.A.

    If you use section names like "admin >> editing" and "admin >> deleting", it will look like a hierarchy.

    Or, sections can be nested (the client would have to be aware of that of course):

    sections:
      - title: users
        weight: 1
        extended_help: 'permissions for regular users'
      - title: admin
        weight: 2
        extended_help: 'permissions for admins'
        sections:
          - title: editing
            weight: 1
            extended_help: 'permissions for admins editing items'
          - title: deleting
            weight: 2
            extended_help: 'permissions for admins deleting items'
    
Production build 0.71.5 2024