Conflict with Login Tobaggon
affinitymc - January 21, 2009 - 15:17
| Project: | Registration role |
| Version: | 5.x-1.2 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed |
Description
It seems that Login Toboggan, when assigning a TEMPORARY role, overwrites RR role assignment. Then when the user clicks on the link in the confirmation email, it resets their status to Authenticated User, without the role assigned through RR being maintained or restored.
A previous issue mistakenly set this as 'by design', when it in fact is a conflict between the two modules.
#1
It's actually not a conflict with Logintoboggan specifically, it is a conflict with user_save and the regsitration_role module not properly setting a new role.
user_save(http://api.drupal.org/api/function/user_save/5) calls the insert hook expecting modules that want to alter a user insert to use the $edit array to set new variables, after the hook is called is when the roles are updated, and if there exists any new roles in the $edit array, all old roles are dropped, and since registration_role is using a direct SQL statement to alter the users roles the user_save is pretty much immediately deleting that change. Any module that alters user roles will break registration_role.
Attached is a fix to use the $edit array to properly set the role at registration.
#2
status update
#3
That hardcodes the role ID as role 1. Also has anyone tested this approach?
#4
Thanks to a patch supplied by abhaga and christefano in issue http://drupal.org/node/320087 this was in fact fixed long ago, but i failed to create a release. New release now, 5.x-1.3. My apologies.
benjamin, Agaric Design Collective
#5
> That hardcodes the role ID as role 1. Also has anyone tested this approach?
No, the "1" is a truth(boolean) value, not an RID, print_r() a user object and look at the format of the roles array. The value of [$rid] makes no difference, I put up the link to the api documetation for reference, all that matters is that the $user[roles] array exists and has a list of keys that represent the RIDs you want to add/modify.
<?php// Save user roles (delete just to be safe).
if (is_array($array['roles'])) {
db_query('DELETE FROM {users_roles} WHERE uid = %d', $array['uid']);
foreach (array_keys($array['roles']) as $rid) {
if (!in_array($rid, array(DRUPAL_ANONYMOUS_RID, DRUPAL_AUTHENTICATED_RID))) {
db_query('INSERT INTO {users_roles} (uid, rid) VALUES (%d, %d)', $array['uid'], $rid);
}
}
}
?>
The other patch does the job just fine except for instantiating an empty array for no reason, but I don't see a use-case where the difference would be noticeable.
#6
Yup, my bad– as noted, this was fixed in head a good while ago, and a new release has been made now.
#7
Automatically closed -- issue fixed for 2 weeks with no activity.