I have been frustrated by the limitations of Drupal's user management. I would love to see Drupal adopt a more sophisticated access control system, with groups and permission inheritance (perhaps along the lines of PEAR::LiveUser). I see something like the following...

Areas
Each site is broken up into functional areas, typically associated with an individual module or group of related modules.
Roles
Each area has one or more roles associated with it. A role is granted a specific set of user rights. Roles can be implied, so someone in Role-A may automatically gain the rights of Role-B, even though those rights have not been explicitly defined for Role-A. In this case, having Role-A implies that you also have Role-B. By default, every area will include an area admin role that automatically gains all rights associated with every role in that area.
Rights
A right is a specific privilege that can be granted to a user. As with roles, rights can also be implied by other rights.
Groups
A group is a container for users. Individual Groups can be assigned any combination of roles and rights from any area. Sub-groups can also be defined. For instance, if Group-B is a sub-group of Group-A, then its members are automatically assigned all the rights and roles of Group-A, but they can be assigned additional rights and roles as well that are not shared by the containing group. Site Admin is a special group that automatically gains all rights and roles associated with all areas of the site. Other special groups might include Guest and New User.
Users
A user represents an individual person. Users can be put in any number of groups. Users can also be granted rights and roles directly.

This feature would allow for amazing flexibility and power in Drupal's user management, with fine grain control available to those who need it. Some other feature requests, like this one, would become trivial to implement.

The addition of groups and implied rights would allow for a much cleaner, more user friendly, administration interface when managing complex sites with lots of users. It would also allow site administrators to be more creative in the way they use various modules. Module developers would set the area, roles and rights associated with their modules, but the site admin gets to create groups with any combination of rights and roles (across multiple modules) that that they see fit. A site with dozens of modules could be managed simply by assigning users to one of a handful of groups. And the odd user who needs "special" privileges could get them without much trouble.

Comments

jstoller’s picture

Title: sophisticated user access management » expanded user access management

It occurs to me that this system should include a mechanism to order roles and groups in strict hierarchies. That way rights granted to an administrator role can be given more weight than an authenticated user role.

This is especially important if the system not only allows for rights to be granted or denied (i.e. not granted), but also for rights to be forbidden (as discussed in this feature request). A forbidden right is denied even if the user was granted that right by another role. However, in this case that would only hold true if the other role is lower down on the totem poll than the role forbidding said right.

The logic would be something like this...
If none of the user's roles explicitly define access to Right-A, then they are denied access to Right-A.
If one or more of the user's roles define access to Right-A, then whatever is defined by the highest ranked role sets the user's access to Right-A.
Defining access to a right means either granting or forbidding that right. All rights not granted or forbidden are considered denied by default.

garthee’s picture

exactly this is what I am looking forward to handle here [1], and my road map is
1. implement it as a separate module providing necessary functions (other modules have to call these api /hooks to use them)
2. patch to user module, to effect that and enforce it for all modules with in D6
3. Integration with core in D7, such that user.module will be used for creation and user management (profile and other stuff), and possibly authentication integrated (but with expanding authentication options I hope this is handled separately) and this permission.module to oversee all authorization, role, permission management and policy management related tasks with hooks to implement policies

jstoller’s picture

garthee, your link didn't come through.

For anyone interested, here is the link to garthee's SoC proposal: http://groups.drupal.org/node/9584

mdupont’s picture

Version: 7.x-dev » 8.x-dev
mdupont’s picture

See also #1200572: Concept of a hierarchical permission system as a step in this direction.

lpalgarvio’s picture

Version: 8.0.x-dev » 9.x-dev
Issue summary: View changes
lpalgarvio’s picture

catch’s picture

Version: 9.x-dev » 8.2.x-dev
Status: Active » Postponed (maintainer needs more info)
Issue tags: +Needs issue summary update

Moving back to a minor release since this is a feature request.

However also tagging for an issue summary update since this could at least use some comparisons to contrib concepts (organic groups, og_roles, spaces etc.).

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

Going to close as outdated since this has been in PNMI for 6 years without an update

If you feel this is still an issue please reopen. After searching for any duplicates