[GSoC Proposal] Hierarchical permissions for Drupal 8

The basic idea has more than 2 years of history. In 2009 Larry Garfield wrote a blogpost about more flexible rights management. His concept has two important parts: we need a much more fine-grained permission system, and we need the ability to organize permissions into a hierarchical, unambiguous, logical system.

This was welcomed by the community, and an issue has been created. Thinking about the possibilities of implementation and changes took a few months. Plenty of suggestions came, but there weren't any actual progress in implementation before the release of Drupal 7. I would like to take the challenge. During Summer of Code, I would be implementing the ideas of Larry and the community. Then prepare the final code for integration into Drupal 8 core.

A better permission system

The current permission system has troublesome elements. Rights, that when enabled, cover several other rights too. Those covered rights are still going to be available and this situation confuses inexperienced users. The 'administer xy' rights, according to their names, grant the user a huge pool of rights. In some cases, these can be considered security holes. The biggest problem is, however, that a lot of rights are only available if the 'administer xy' is granted. Accessibility cannot be properly fine-tuned and instead there are workarounds or contrib modules used.

The formerly mentioned cases are resolvable with the introduction of a hierarchical rights management system. A giant step can be taken forward in better usability if we require modules to define logically built, nested levels of rights. Accessiblity provided by rights would compose a more clear, transparent system. This by itself wouldn't make accessiblity fine-tuned, but would give modules a great option to do so. It would depend on module maintainers if and how they choose to use it. Given the approach and method, properly documented and communicated, the maintainers would be more inclined to design well-defined, conscious rights tree(s) for their modules.

A possible permission structure (borrowed from Larry's blogpost):
- User.Accounts.EditAccounts
- User.Accounts.ChangeAnyPassword
- User.Accounts.ProcessApplications
- User.Accounts.ViewBlockedAccounts
- User.Permissions.ConfigurePermissions
- User.Permissions.ConfigureRoles

Organize, organize...

This new view requires a different approach from us in certain things. The reorganization of Drupal 7's configuration menus helped a lot with usability, since its structure is more humanized and names were established, which are more closely related to natural logical thinking. Perhaps the time has come to abandon the grouping by modules on the rights management site and change it into a logical grouping by rights. We should consider switching from rights worded with natural-language terms to paraphrased technical terms. We get a more transparent interface by doing this.

The new permission UI

We have been struggling with the 'field of checkboxes' for years, so maybe it's time to say goodbye. This is the right time do this with introducing this new approach. During my project, because this is a vital part of working with a Drupal site, I'm going to work with the permission configuration UI, design and implement a brand new one, of course in co-operation with the UX- Team and the community. If there is a chance, a solution based on Hierarchical Select would be preferred.

Under the hood

We have to work out a new way of implementing hook_permission() to achieve these plans .
We should provide the simplest option for modules defining their permission tree(s). The user_access() function must be really fast.

The new system offers us usage of wildcards in the user_access() calls. Primarily we are talking of suffix wildcards here, so according to the example above, this is a possible call:
user_access('User.Account');
In this case, all permissions aligned under User.Accounts would be checked (like User.Accounts.EditAccounts, User.Accounts.ChangeAnyPassword, etc.)

The user_access() function currently is composed of an isset() call, among other things. We obviously can't compete with the speed of that, the introduction of suffix wildcards shouldn't be increasing the run time too much. I would also provide the option of using infix wildcards. This, however, raises questions about performance. We'll get a clear view of what are the real odds of introducing this method after benchmarking.