I am building a website that requires a UserA to be able create UserB, UserC, etc...and have whatever content they create to be managed by UserA (edit, delete, update, etc...)

However I don't think role based permissions are the way to go. I only want UserA to be able to manage those subusers, not assign them a "manager" role where another manager (say, UserX) has created UserZ and if both UserA and UserX are "managers", UserX can change UserB's content.

It looks like the Subuser module is the way to go, however, it is hardly updated and seems to be incomplete. Is there another module or set of modules that can do the same thing?

Organic groups also gives me the access control I need, however, the content that all users should be site-wide and not actually tied to any group. I don't need a container to keep nodes, just the access control for users to manage other users within their own sphere.

Does any one have any other way in which this can be accomplished?

3 Answers 3


This could be convoluted but this is how I would do it.

To start with, I would use rules and have either entity reference fields or integer fields for the users and content.

With rules, when the new users are created, USER A is referenced (or their UID in the integer field) using rules.

Then, using rules, every node the new users create have this entity reference (or UID integer) applied to it automatically.

For editing, I would give USER A's role editing permissions and then write a custom module that redirects users from the node edit page if the node's field doesn't match the user's field. (And allow certain roles like admin and also allow the node author).

One benefit of this is that you could create a view for USERS A that only shows nodes they can edit and provide a link per node. And I'd use an intreger field as a preference.

Edit: You could do all of this without any extant contrib modules or rules and just custom code. But I always have rules so it's an obvious go to for me.


I have not used it myself. But I attended a DrupalCON where this module was presented for HigherEd usage and the maintainer swore by its usage. This is similar, but different from say the Workbench Suite of modules.

Give Monster Menus a try out in a sandbox or something and see if it meets your needs, or as detailed in the project page try out the demonstration site provided by the institution that created this project.


Have a look at the (fairly new) alternative for the Organic groups module, which is the Group module. Some more details about it (from its project page):

Organic Groups allows content itself to be groups, which isn't always what people want. It relies on an entity reference field to keep track of the ties between a group (node, term, ...) and its content (node, term, user, ...).

Groups instead creates groups as entities, making them fully fieldable, extensible and exportable. Every group can have users, roles and permissions attached to it. Groups can also act as a parent of any type of entity. Seeing as a group itself is also an entity, creating subgroups is very easy.

Even though it only has a beta release for D7 so far, its Usage statistics seem to indicate it is like a "rising star". And I've heard it mentioned recently in various occasions as a valid alternative for the "heavy" OG module.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.