tags:

views:

356

answers:

3

I need to automatically apply a role, Role X, to all Drupal users that have been granted a separate role, Role Y. In other words, I wish for Role X to be a subset of Role Y. How can I do this?

A: 

The LDAP module allows you to dynamically assign roles based on DN. I actually had to write my own module that is tailored specifically to our system, otherwise I would be more than happy to share it.

link text

lilott8
I've worked with the LDAP module before, but only for the purpose of user authentication. Would I have to set up a separate authentication system to be able to model sub-roles correctly with the LDAP module? My experience with it is quite limited, I am probably misunderstanding. Please elucidate.
Reynolds
I don't think LDAP has anything to do with this. The poster would have to set up a separate LDAP server, which seems like all kinds of overkill.
theunraveler
+4  A: 

You could implement hook_user() in a custom module. On the 'insert' and/or 'update' action, you'd check for role Y in the $account->roles array. If present, add role X if not already there. This would ensure that your rule gets applied every time a user account gets created and/or changed.

For a bootstrapping/one time operation, take a look at user_multiple_role_edit(). It lets you add or remove roles for an array of user ids. Alternatively, you could do it directly in the database:

INSERT INTO users_roles (uid, rid)
  SELECT uid, [roleX_ID] AS rid FROM users_roles
    WHERE uid IN
      (SELECT uid FROM users_roles WHERE rid = [roleY_ID])
    AND uid NOT IN
      (SELECT uid FROM users_roles WHERE rid = [roleX_ID])
;
Henrik Opel
This sounds like it will work great. Thank you very much!
Reynolds
+1  A: 

I agree with Henrik Opel on using hook_user in a custom module would be a good solution to maintain the users and make sure they are up to date all the time.

Normally I wouldn't mind writing SQL or something alike, but in this case, since it's on a production site, I would prefer a different route, since if something can easily go wrong when writing raw SQL, a little typo can cause big troubles. Another good point is that you can run into problems as drupal wont be aware of what raw SQL you run on your database and might get out of sync with some processes, hooks and other processes that's normally run when you do things through the Drupal API.

Instead you can use the drupal user admin interface. I actually think that in this case, it is the easiest way to do what you want. Simply filter all users that are students. Click all the users and give them the member role. This is done with a few clicks in no time, and is very secure since Drupal will handle all the SQL for you.

Updated
With that many users, I'm surprised that you don't have a custom user and content managing page setup using views_bulk_operations. Using a few minutes, you can setup a admin page which you can use to preform bulk operations like changing user status, roles, or perform similar tasks for nodes. You can create your own filters using exposed views filters. So with a few clicks you can select all the users with role of student and that isn't member, select them all and add the member roll to them. The advantage doing this is not only that it's quick and safe, but you can create some nice managing pages for your site administrators, content creators etc. You should consider looking into this module.

googletorp
This is a good idea, and I would use this solution, but our active member numbers are in the five-digit range and it would take me many days.
Reynolds
+1 - I totally agree on avoiding direct DB manipulation whenever possible - although less because of the risk of typos (rigorous testing of the change script on a stage instance should prevent those) but mainly because of the implied circumvention of hooks that would get fired when changing things via API calls.
Henrik Opel
That's a good point with the hooks, added. I haven't tried any problems due to typos etc, my point was just that it's risky in that sense that only a few chars need to change to mess things up. So a lot of care = testing = time is needed for things like this.
googletorp

related questions