- 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.
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.
- πΊπΈ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'