During my Google Summer of Code project I am implementing hierarchical permissions and I hope my work will become a part of Drupal 8 core. We have started the work with my mentor, Károly ‘chx’ Négyesi one month ago.
http://chalcedony.co.nz/gemsofwisdom/permissions
Introduction of a hierarchical rights management system could be a solution for the formerly mentioned cases.
The current permission system is hard to understand for inexperienced Drupalers.
In many cases we get the clear picture of what a permission means only if we try out things, or read the code itself.
Let’s imagine that modules describe trees instead of simple lists when they determine their permissions. Leaves of these trees can be very specific about what rights and functionalities the users get if we grant that certain permission for them. Without a tree, this would mean an unmanagable number of permissions but with the hierarchy, users can be as specific or generic as necessary when granting permissions. There is no more situation like enable the permission where we have no idea what power we give our users, unless we have experience of that certain topic and module. A well-structured permission tree could be a huge help for everyone.
Permissions often overlap with others (e.g., ), but administrators doesn’t noticed about this.
If the permission tree has been built in a proper way, the overlap is not an issue anymore. It’s up to the maintainers who design the tree of course. You will see examples for this.
Managing permissions is difficult, and could become hard when we work on a larger website. The user interface isn’t transparent enough, and sometimes it needs serious concentration to work with.
One of the most interesting part of my project is the design of the new user interface. Representing the hierarchical structure is an objective which offers itself. It’s also an important objective to work out an approach which allows us to come along from simple to difficult. So, if someone doesn’t want to fine-tune their permissions, then we don’t let the interface to distract her/him with unnecessary elements. I imagine a minimalist UI which can become more complex only if the task requires.
Let’s say someone writes a blog with her/his friends, and would like to allow those beloved friends to edit all of the fields of their profiles. There should be an easy way to achieve this with a minimum effort without constantly seeing the options to define the rights at field level. In short: the interface must be “good enough”.
With creating the proper UI we can simplify our administrators’ life. But maintainers will face a good achievement when they design permission trees for their modules. This will be a serious responsibility in the future for them.
In every cases our most important goal is simplicity. The purpose of introducing hierarchy is distinctness, so don’t ruin this with designing permission trees which are too difficult.
Permissions can be interpreted by leaves of the permission tree. At upper levels, the nodes should only be “containers”, they shouldn’t cover real functionalities. Their purpose should be to summarize the subtree rooted at that node. We can have exceptions to this rule in reasonable cases, there will be an example for this.
I’d like to share some of my thoughts on the designing procedure of this tree. The first part of the work was outlining the current permission list of the User module:
Some of these permissions are overly broad. The is especially problematic, but we can say in general that the -type permissions will cause real headache for us. So we created a first draft for the list of permissions. Then we started to think about real-life problems.
The first branch of the tree is , all of the profile editing related options are structured under this node. Interesting detail is that the view permissions are under the edit permissions. This is a logical decision; if we want to retain the hierarchy, this structure is necessary. This solution is one of that extraordinary cases, where the parent node means real functionality, and not just acts as a container. But it seems reasonable, doesn’t it? We can see divisions into user roles, and additionally the own profile option. We can meet this structure in other cases as well, towards dealing as much use cases as possible.
is a branch itself. It cannot be placed under somewhere else, and doesn’t worth to divide further parts. is also a separated branch, but you can refine whether a user can access a certain setting. For instance we can grant the ability for editing text of various e-mails to our trusted editors. Isn’t it convenient that we can delegate this, and we don’t need to take care of this anymore?
is an adventurous story. Here we can see the importance of handling visibility of UI elements, because we will list all of the permissions under this node. We can define which permissions can be administered by users. A further option for refining this, that users can delegate permissions only if they have it.
On one hand, yes. If we define complexity that we have to deal with more options, than yes, it’s more complicated. But let’s think about the advantages of the formerly outlined implementation. With well defined permission trees we can help our users, because we can show them all of their possibilities in a structured, clear system. Everyone can decide on which level (s)he wants to use this feature. If someone wants to refine permissions substantially, it would be much more difficult without this approach, needs a lot of knowledge, contrib modules etc. So this system will be auspicious for them. But what if someone wishes pure simplicity? Well, the new user interface will help. Anyway, they can check checkboxes with fearlessness and confidence in the future. Exactly what they need.
When we check a permission, we can refer any node in a permission tree, due to the hierarchical structure, the whole subtree rooted at that node will be checked. What does it mean? Let’s see some examples using the User module’s permission tree above.
user_access examplesAny of the following strings could be an argument for the user_access method. In their decriptions I’ll explain what rights the user has, if the method returns TRUE.
User module.User profiles
Our first example is an extensive permission. If we look at the tree, we can easily understand how the example can be interpreted: in this case, users can do anything with profiles in any role: they can edit and view all of the fields, and grant any role for other users. We can check this with one simple query, it’s not necessary to list all the child permissions. In every case we should find the corresponding node in the permission tree, and examine the subtree rooted at that node. With analyzing the nodes of the subtree we could get the functions and rights which are covered by the permission.
User module.User profiles.Own profile
Adding narrows down the generic permission to the user's own profile. The user can see an edit everything (s)he wants.
User module.User profiles.Own profile.Edit property X
The user can view and edit only the field inside her/his own profile. As you can see, it's similar to the previous one, but the permissions is restricted to the field.
User module.User profiles.Own profile.Edit property X.View property X
The user can view the field inside her/his own profile, but (s)he can’t edit it. Now we are in the lowest level in the tree, and narrows the previous permission, just like in every other cases. E.g. this permission could be useful when we don’t want to let our users to edit their username.
If we look through the permission tree, we can notice a simple and important rule: each node narrows its parent permission.
When we administer permissions, sometimes we should click a lot to accomplish a given situation. Staying in example above, let’s say we’d like to grant someone the right to administer all of the permissions, but only if (s)he has that certain permission. We can use wildcards when we adjust permissions for that role, which looks like this: . It will be the goal of the UI to provide the possibility for this operation.
User module.Cancel profiles.*.Delete the account and its content
Permission for delete all of the accounts and their contents.
User profiles.Role X.*.*
Permission for view all of the profile fields in Role X.
Using wildcards could be a convenient way to handle certain cases. But we won’t introduce wildcards on the query side in user_access calls, because this feature would have performance issues. When an administrator grants permissions, it doesn’t matter how quick it is, and how much time it takes to save, but the query side is critical, the user_access is used frequently in every page load. So it's worth to make this decision.
Needs work
11.0 🔥
user system
The issue is available for high level reviews only. If there is a patch or MR it is not to be set to 'Needs work' for coding standards, minor or nit-pick changes.
Issue summaries save everyone time if they are kept up-to-date. See Update issue summary task instructions.
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
The Ideas project is being deprecated. This issue is moved to the Drupal project. Check that the selected component is correct. Also, add the relevant tags, especially any 'needs manager review' tags.
Changing to the standard issue template → would also help other contributors.