I wrote a module in Drupal 4.7 for the web development company I work for to solve a user administration issue for a client we were creating a web site for.

The idea is, we create websites for our clients and set up the Drupal CMS in a way that is as user friendly as possible (i.e. strip out all the features that allow them to break stuff and cause havoc) so that they're able to administrate the various features and content on their website simply and without being confused (a common problem for most clients). The problem is, when it comes to user administration, we generally don't trust our clients enough to give them the rights to mess with any user in the system, yet there is only one permission we can provide them with for this task: "Administer Users". Further, the particular project I'm referring to had a need to set up a sort of hierarchy of user administration access rights to the various users.

My solution was to develop a module that provided a matrix of dynamically generated user permissions based on each role in the system (modifiable in the user access section) for the task of administrating users.

The result was that there was an 'Administer users' permission OF every role in the system, FOR every role in the system.
In other words, the permissions for the role CEO might be 'Adminster users of role Director', 'Administer Users of role Manager', 'Administer Users of Role Employee'. Of course the role "Director" had all these permissions, but with one less check box checked -they could not administer CEO's, but could for managers and employees. Managers could administer employees, but no one else, and so forth. This matrix allowed us to give each role exactly the permissions they needed to fit their respective roles in their organization, as well as the restrictions that were required.

I developed the same sort of matrix for the purposes of assigning roles as well; when Directors create/edit users, they can't assign that user to the role of CEO, but could assign that user to any role "below" them. I've since learned that other modules exist which handle the latter part of my module's functionality, such as RoleAssign and Role Delegate (which I have yet to try out, but they sound like they fit the bill.)

Unless I'm quite out of the loop (which is likely) this sort of thing seems like a much needed addition to any Drupal site with any sort of hierarchical user system or a need to set some restrictions to user administration. It's been very necessary for a company like ours, where we want to give our clients user administration privileges yet allow our development teams user accounts to stay out of the way and behind the scenes where they should be - yet we still need them to help support and administer the site. It was also perfect for my aforementioned example, and I'm certain there are many more scenarios where the same logic could apply.

Anyways, my question is this:
Is this sort of functionality something that another module/Drupal feature is already capable of? If not, does it seem like something desired or needed by the drupal community?

Thanks for reading,

-Justin

Comments

justindodge’s picture

Anyone?

stevecowie’s picture

This may not help much but I'm grappling with a similar problem. I'm working on a site where there is a central administrator but also administrators of local projects, who need the capacity to administer their own users without having any access to other local projects' users. I've looked at various approaches but found nothing that fully addresses the problem. In fact, I'm currently thinking about using CCK to create a content type 'person' that would be relatively easy to control using og_groups adn/or taxonomy access control. However, going down this route means I lose all the functionality that is associated with users such as using usernode or profile. I also thought about writing a module - let's call it userowner - which would add an extra permission to the user permissions of 'administer own users'. The idea would be that if you had this permission the system would check a table of parent-child users and provided you were the parent of a given user you would be able to administer, but otherwise not. however, i'm a bit reluctant to do something that starts hacking about with a core module like user.
Sorry I haven't provided a solution but since you took the trouble to detail your problem I thought it made sense to flag that I've come up with a vaguely similar issue.