Allowing groups (roles) to be a sub-member of another group and inherit all such permissions allows for a much more hierarchical system. If you have many groups it can become a pain to issue the same permissions to all the relevant ones.

Comments

jstoller’s picture

I've been dying to see this functionality in Drupal, but I think we need to go beyond just sub groups and really overhaul the user access management system. I submitted a feature request here with some suggestions on a possible implementation.

pancho’s picture

Title: Sub groups (roles) » Introduce sub-roles inheriting permissions

I agree with jstoller that we need to overhaul the whole permissions system, and in the end we will see if we need subroles or not.
Still I'm giving this issue a name that better reflects what it is about.

ultimateboy’s picture

Priority: Critical » Normal

While this is would be a nice feature, I think there are bigger fish to fry in regards to the permissions system. I see no reason for this to be "critical".

mr.baileys’s picture

Marked #279153: Role inheritance as a duplicate of this. Note that there is also a module in contrib (still in dev, needs some tlc) which has the same goal, see http://drupal.org/project/role_inheritance

aren cambre’s picture

subscribe (from #279153: Role inheritance)

sun.core’s picture

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

Tracking.

aren cambre’s picture

Were 7.x's permission API changes architected anticipating this?

mxt’s picture

Tracking.

lpalgarvio’s picture

andypost’s picture

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

Status: Active » Closed (duplicate)

Users can be added to more than one role already.

Also #1200572: Concept of a hierarchical permission system would mean less granting of individual permissions.

Not sure what else there is here, so closing as duplicate - needs an issue summary if not.

Version: 9.x-dev » 9.0.x-dev

The 9.0.x branch will open for development soon, and the placeholder 9.x branch should no longer be used. Only issues that require a new major version should be filed against 9.0.x (for example, removing deprecated code or updating dependency major versions). New developments and disruptive changes that are allowed in a minor version should be filed against 8.9.x, and significant new features will be moved to 9.1.x at committer discretion. For more information see the Allowed changes during the Drupal 8 and 9 release cycles and the Drupal 9.0.0 release plan.