I have this module enabled, and am assigning a specific role to new users. However, I have another module that implements hook_user, and the new role assigned to the user is not appearing in the user object.

I believe that the user object should be modified after the new role has been assigned:


// Add the auto-assigned role to the user object so that it can be accessed by other hooks
$user->roles[$objRole->rid] = $objRole->name;

Any thoughts?

CommentFileSizeAuthor
#7 autoassignrole.021908.patch1.44 KBebeyrent

Comments

cyberswat’s picture

Assigned: Unassigned » cyberswat
Status: Active » Postponed (maintainer needs more info)

ebeyrent: could you check to see if this issue has been resolved by http://drupal.org/cvs?commit=98222 ... I believe it has been. If not, could you identify the module you are using so I can test?

ebeyrent’s picture

I don't see where in this patch you are updating the reference to the user object. If you fail to modify the user object, the other modules with hook_user that get executed after your module will not be able to make decisions based on the auto-assigned role.

Case in point - you want your new users to be automatically assigned a badge for a specific role. So, when the new account is created, you auto-assign a role of 'Newbie', but when the User Badges module fires its hook_user, it's looking at $user->roles and the auto-assigned role is not there, because you did not modify the $user reference in your hook. Therefore, the badge for that role cannot be assigned to the user.

Does this make sense?

cyberswat’s picture

"I believe it has been. If not, could you identify the module you are using so I can test?"

ebeyrent’s picture

Did you miss the part where I talked about the User Badges module??

To test:

1. Create new role "newbie"
2. Configure Auto Assign role to assign newbie to all new users
3. Configure User Badges module to assign badge to newbie role
4. Register a new user

The result I am seeing is that the new user does not get the badge.

cyberswat’s picture

I didn't miss anything .. I'm busy and do this as I can ... Please evaluate http://ftp.drupal.org/files/projects/autoassignrole-5.x-1.x-dev.tar.gz ... the original module has some very bad code in it that is no longer there. If this is still a problem I'll fix it but I don't have the time to approach this unless it is still an issue and I don't have the time resources to determine that myself ... so your help and understanding is appreciated considering I just took this project over to clean it up and provide you a solution that works.

cyberswat’s picture

Status: Postponed (maintainer needs more info) » Closed (fixed)

Assuming this is closed.

ebeyrent’s picture

Status: Closed (fixed) » Active
StatusFileSize
new1.44 KB

This is not solved. You are still not modifying the $user object. You are updating the role in the database, which is great, but you also have to update $user.

After each role is inserted into the database, you have to:

// Add the auto-assigned role to the user object so that it can be accessed by other hooks
$user->roles[$role->rid] = $role->name;

You do this so that any other module that implements hook_user will have the updated user object without reloading it from the database.

To be more explicit, here is some code from user_badges.module:

function user_badges_user($op, &$edit, &$user, $category = 'account') {
  switch ($op) {
    case 'insert':
      if (is_array($user->roles)){
        // get the list of role badges
        $roles = user_badges_get_roles();
        $badges = user_badges_get_badges('select');
        $message = user_access('manage badges');
        $rids = array_keys($user->roles);
        ...
  }
}

This code executes at some point after your hook_user call on insert. If you dump the $user->roles array, you will not see the auto-assigned role. The reason you don't see the auto-assigned roles is because your code never updates the $user object that's in memory.

Does this make sense?

To fix the problem, I have attached a patch based off the code you instructed me to download.

introfini’s picture

Hi,

There's something wrong with the $user object, because theme_username($user) isn't working when the user has just registered.

http://api.drupal.org/api/function/theme_username/5

Your patch didn't fix that issue, but I think you are on the right track…

introfini

lauscherli’s picture

I'm having the same problem; badges don't apply for roles created by the auto assign role module.

I just came across a similar discussion here http://drupal.org/node/161825.
There the badges didn't show up when a user was promoted to a new role by a userpoint module promote mechanism (don't know that module), and they seem to have found a fix. I don't know if these promoting-mechanism work similar, but maybe...

Would be nice to have the badges working together with auto assign module, anyway :-)

ebeyrent’s picture

lauscherli - that was my patch, and I can verify that it works as it's supposed to. My patch on this thread works as well. Feel free to try it and let me know if there are any issues...

lauscherli’s picture

Just tried it - but it didn't help the badges... But maybe it was my fault, as i'm not experienced in applying patches yet. I will give it a second try tomorrow :-) I'll let you know.

There's several patches around that i tried, they fix the automatic role assignment, but don't help the batches...

UPDATE: I tried out your patch a second time: The roles are getting assigned, but still the badges are not being assigned to the roles; in order that they show up i first need to resave the badget-roles... Just to inform you: I am NOT using LoginToboggan. I mention this, because others guess that it's a problem related to that module.

cyberswat’s picture

Version: » 5.x-1.1
Status: Active » Fixed
cyberswat’s picture

Version: 5.x-1.1 » 6.x-1.0-beta1

Make sure this is in place for D6

cyberswat’s picture

Status: Fixed » Active

changing status to active for D6

cyberswat’s picture

Status: Active » Fixed
Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.