This is a user interface proposal for hierarchical permissions, a concept aims to make it possible to have modules with hierarchically structured, accurately regulable permissions.
Permission rules
If you have ever worked on a bigger Drupal project, you know that the permission admin page can go crazy. Many modules provide many permissions. Introducing a hierarchical permission system on its own will not help. Moreover, if we will take advantage of effectively having more granularity in our permissions, the situation will become worse. But do we use all the permissions which are available? No, we don't -- most of the time. So what if we have to deal with only those permissions what we actually use in our website? It sounds better, doesn't it? Let's have a possibility to choose a permission, and right away define the roles which we would like to grant that certain permission to. This is how a permission rule can be created. The idea is to provide separated functionality to quickly create permission rules (more than one at the same time), and then present these in a clear way, and make it possible to edit the roles in a permission rule. It also makes sense to have the top-level permissions as default permission rules -- with the permission granted to the administrator role. Installation profiles could provide more deafults.
Propoposal for the UI
During my Google Summer of Code project last year I was working together with my mentor, Károly (chx) Négyesi and we came up with a plan which was reviewed by Bojhan Somers. At last I have implemented it as a working prototype:
Here comes some explanation about what you can see.
Creating permission rules
The interface consists of two parts. The first section makes it possible to discover the permission tree (in the prototype you can see more or less the permission tree described in this issue) in an easy way. Besides discovering the most important is that you can create your own permission rules. Choose and combine permissions from different levels (make sure that you don't skip choosing also from the parent level, if it exists). Select one or more roles, and then click on Create. Then you have a (few) new permission rule(s).
Displaying permission rules
If you scroll down, you can see the second component of the UI. The list of permission rules. First of all, without doing anything, you have a few defaults. As I mentioned, the top-level permissions with the Administrator role are here by default.
If you have created your own permission rules, you can see them here in the list. You can remove them with the small X icon on the left. Note that you don't have the possibility to delete default permission rules. In the end of each row, you can see the list of the roles for the permission. The roles can be modified, just hover them, and select or deselect items in the appearing list. You can never deselect the Administrator role.
Needs improvement
The way how the list of permission rules is displayed should be improved visually, and maybe even functionally (we could use e.g. different filters for quickly filter the list).
My goal with this proposal is to see whether you like the idea of permission rules, and having separated UI component for creating them. And if you do so, we could discuss the further improvements.
| Attachment | Size |
|---|---|
| Creating permission rules | 46.28 KB |
| Displaying permission rules | 33.42 KB |
Comments
This is a great start
My thoughts on permissions I like the style you first laid out. One thing that drives me nuts is modules that do not set the admin permissions to on when a module is installed. Plus I found out that a module did not work because of that I could not use the browsers find feature to find the program by name as scrolling I had missed it several times up and down the list.
Faster Permissions is not a solution if you don't know what category that module stuck it's permissions into.
Head Dragon Kid Stevens
Of Web-DrupalDesign .com
"Superuser" role, expanding all sections
If we consider the current behavior, yes, this is a problem. However, I hope this issue will end up introducing a superuser role, which means, that we will constantly have a role with all the permissions granted. That would solve this issue.
Good point. I have used the Accordion plugin in jQuery UI, which doesn't support multiple sections open at once. But if we use another solution which does, we could have an Expand all link at the top, so you can open all sections with one click, and then you're able to use the browser's find feature.
Approach looks great! Example data needs work
This approach looks great! That said, I think your case is going to be undermined by your examples not making a whole lot of sense. Why would "Edit specific fields" live under "Access user profiles"? The example doesn't make sense. "Edit" would be an entirely separate hierarchical group from "View". Even within a discrete operation (view/edit/delete) I'm sure you'll find a lot of room for hierarchy.
Rather than checkboxes, we'll likely also see a lot of radio buttons for the top-level permission. Say you had "Edit content" as a top-level category, you'd want to first select a radio button of which content type you want to grant edit to (possibly including "all" as the first option). Then under that single radio button, list all the fields within that type (with an "all" option as the default selected option). While checkboxes could be used to edit multiple content types at the same time, I think conceptually users would grasp editing one type at a time more easily.
Here's an example that I think would work. I made a few adjustments to the order of things, like I put the list of roles first, since you'll always need to choose the roles for any permissions, it'd be nice if it were always located in the same place (the left-most position), rather than jumping a variable amount of distance to the right. Not sure it's the "right" approach since it doesn't make the permission configuration "read" as easily and the listing of permissions would be the other way around.
User module, UI consistency
My example uses the permissions described in this issue. So they're built around User module (or we should call the grouping People), and when you read fields, they mean the fields on the user entity. It does make more sense having this in mind, I think.
Yes, this is a tough one. I can see it's confusing, but if you think about it, it's logical (kind of), since if you can edit something, you can also view it. So this is a hierarchy. But if we separate the "View" from "Edit", the UI won't reflect this. But I can agree, in my example, handling the permissions around "View" would be really hard, because you can only operate on field level. So in my opinion, the decision is, either we want a more usable, but in some way logically inconsistent UI, or we accept that it won't be convenient for every purpose, but at least it fully supports the hierarchical logic. Or we find a third way, which fulfill both requirements.
At first sight, I find it
At first sight, I find it pretty impressive, especially compared to what we have now. I can't imagine a drupal site where this approach would increase the complexity. It'd do just the opposite.
I have two points, hopefully constructive ones:
- I'd keep the ability to do a direct search in the hierarchy if i know what i look for!
An example, hierarchical settings implemented in Eclipse-based IDEs, with ability of quick search. Browsers don't find in the hidden parts of the page, and so on. http://drupal.org/project/drush_role is nice, but still.
Also is it an open question that how this UI would show the description of permissions and other extra stuff what hook_permission allow?
Grouping permissions
Thank you, I like the idea of having an instant search field at the top, it would improve the usability.
A previous discussion made it clear, that we should stop assembling our permissions around modules. Instead, we should switch to a more natural grouping, similarly how the configuration actions are separated now in Drupal, e.g.: People, Content authoring, Media, Search and metadata, Regional and language etc. What I showed in this example could be the People group. In my opinion the best approach would be to list these categories on a page (similarly like the /admin/structure page now), so we could have separated permission admin pages for the different groups. With this separation the structure is more clear, and we don't have the issue, when we try to show every permission on the same page, and the browser crashes. But still, the stress-test is not a bad idea, if we are in that stage.
Yes, it's totally open. :)
Nice idea, but it seems a tad
Nice idea, but it seems a tad more confusing to me than what is currently available in Drupal.
Would it be possible to set permissions "per role" instead? I kind of feel that we will have a lot of overlap when creating permissions if we use the setup proposed.
Thomas Hambach, Web developer
Wildcard vs. granularity
Where is the "I don't fucking care, grant all?" checkbox in this design? :)
(for one permission, to be granted to a certain role)
We absolutely need to make sure to not make the most simple use-case a horrible experience while introducing more granularity to permissions.
Daniel F. Kudwien
unleashed mind
Default permission rules
The top level permissions are available by default granted to the Administrator role, so you find these below, if you don't fucking care about creating custom permission rules. :) So, skip the permission rule creation, scroll down, hover the role name on the right, next to the permission rule, and add new roles as you like. This is the required action, if you want to grant all the permissions to a role which are structured under the particular top level one.
Annotated review
Basically in line with some of what @quicksketch already mentioned:
Daniel F. Kudwien
unleashed mind
"Please choose permissions from the parent level(s) as well"
First of all, I really like where this is going, let's do our best...! I can't wait to get this working. It might be my fault/misunderstanding, but...
With this UI prototype my biggest concern is that users aren't "forced enough" to fill the form in the right way. Choosing from the parent level can be missed easily for those who don't know how this works. This can be quite confusing for those Drupal users who know how the current system works, because they're used to the "one-click-on-a-checkbox-and-save"-style permission UI.
This could be improved with something like a sliding form implemented in a way which would force the user to select the parent level permission before even showing the alternative permissions under the parent. (Or temporarily disable the checkboxes which should not be filled yet. Etc.)
Another thing which is not clear for me:
if I select the Edit own profile permission from Edit all field in specific user roles, the all field part in the text suggest that the permissions from Edit specific fields are all allowed automatically if I doesn't alter it with a selection. Why is this invisible in those checkboxes? There should be some clarification.
The above two summarized in a quick and dirty mockup:
New example permission tree
Here is a more simple and better example (based on quicksketch's comment) for the permissions, so that we could use this when we continue the discussion.
So forget about the permissions around people, they are obviously confusing, and it seems everyone likes to think about content first.
Thank you for the great feedback so far, I'm working on the prototype based on your comments, and will post it soon.
Quickly add permission rules
We had a discussion with Aron Novak about his idea of having a search field for those who already know what permissions they are looking for. The following mockup has been born:
I would consider this as an alternative for the existing permission rule creation UI, and we could place this search field above the accordion. This idea is quickly resulted by our brainstorming, obviously not perfect, but we want your feedback. Is this a thing what we should work on?