An alternative method to role management in #drupal

Posted by Craig Aschbrenner

 
 
I'm putting together a small drupal site for a group of very non-technical users.  There are three departments that together make up the whole team.  Each department has different responsibilities (i.e. roles / permissions) on the site.  I needed to find an easy way for this role management to be handled by department heads and not the site administrator (user #1).  

A couple of modules exist that provide role management capabilities / permissions.  These include the RoleAssign and Roll Delegation modules.  These modules were not ideal however.  

The RollAssign module required the administer users permission which gave too much power.  They would be able to modify users and roles outside of their department.  The Role Delegation module creates a hierarchy (of sorts) where we can configure (by role) what roles can assign other roles.  But then I would have to create a role for each department head just so they could add their department role.  

Luckily one of the other requirements for the site was that each department would have their own group with the department head owner of those groups.  The department heads were already adding / removing users to those groups so let's trigger off of those events to assign roles.  This turned out to be a lot easier than I thought!!

So as it turned out, I used the organic groups module with the rules module to handle role management for these departments. Here's how we accomplished this.

Step 1 - Create each role and assign the permissions
There was nothing out of the ordinary with creating the roles so not much to explain here.

Step 2 - Create each department group
I had already created out department group node type so all we had to do was actually create the groups themselves.  The one thing to note however is that I did write down the node ID for each group.  This will become important later on. 

Step 3 - Setup department heads
This simply was editing the group and changing the authored by field to the username of the department head.  I also manually added their department roles to them.

Step 4 - Create the rules
This isn't as difficult as it may sound but it does make use of the group node IDs we wrote down from step #2.  

Triggered Rule - Add Department Role (repeat this for each department)
  1. Create a rule to trigger off of the event: User approved to group by admin.  The department groups used membership moderation so this event made sense.  

  2. Add the condition: Execute custom PHP code.  We use this condition to check and see if the user is joining a particular department.  In the text box labeled PHP Code I entered the following:

    return (module_exists('og') && og_is_group_member(INSERT_GROUP_NODE_ID_HERE, FALSE, $acount->uid));

    This code first checks to make sure the organic groups module exists.  If we forget this check and the module is removed from the system for some reason, bad things happen.  The second part of the code uses a function provided by the group module to check if a user (based on user ID) is a member of a group (based on node ID).  You'll notice where we need to insert the group node IDs we wrote down from the earlier step.

  3. Add the action: Modify user roles.  For the arguments configuration of this action we want to make sure we select User that subscribed to the group and not the active user.  Select the department role we want to add and save the rule.
Triggered Rule - Remove Department Role (repeat this for each department)
  1. Create a rule to trigger off of the event: User unsubscribes from group.  I tested and verified that this event is triggered when a user manually leaves a group or if the group admin removes them.

  2. Add the condition: Execute custom PHP code and enter the following into the PHP code section:

    return (module_exists('og') && $group->nid == INSERT_GROUP_NODE_ID_HERE);

    This code first checks to make sure the organic groups module exists.  The second part verifies that the group this code is triggering off of is the group we want.  Remember we're removing one role for each rule.

  3. Add the action: Remove user role.  Select the role to remove and also don't forget to set the argument configuration to User that subscribed to the group.  Save the rule.

Step 5 - Drink Beer!
This is the most important step in the whole tutorial.  Let's not forget to follow it.

So what we're left with now are departmental groups that are managed by the department leads.  Simply by managing those groups the group members are assigned the appropriate roles to perform their duties throughout the rest of the site.  After this initial setup, at most the site admin (user #1) will only need to change the group owners should the dept. lead change.  

So there we have it, a nice clean way to manage roles using activities that the users were already doing.  I like that!

Comments [3]

Jun 24, 2010
MXT said...
I think this architectural approach is very interesting. Thank you very much for sharing!

Do you have an alternative based on rules to reach a configuration like described here: http://drupal.org/node/711246 and here: http://drupal.org/node/742676#comment-2855062 ?

Best results I've reached is using OG + OGUR + WORKFLOW, but actually I have serious problem due to OGUR lack integration with Views (see: http://drupal.org/node/737292 ).

So I'm really interested in look for alternatives. Can you help me? A tutorial like the others you wrote would be very appreciated.

Thank you very much

MXT

Jun 24, 2010
Craig Aschbrenner said...
Hey MXT.... I took a brief look at your problem and I believe we can solve through a variety of modules. Let me think on it some and I'll see if I can create a tutorial for you.

I love solving problems like this so hopefully we can get it to work. :-)

Sep 01, 2010
MXT said...
Thank you!!! Can't wait to see the tutorial!!! THANK YOU!!!
 
 
?