Assign a specific role upon confirmation

i have no interest in coding this right now, but i would be willing to review a patch for it if it shows up in this thread, and commit it to the module if i think the implementation is quality.

I have found this same issue. It seems like logintoboggan may be even more powerful if it integrated the auto assign role function into the registration confirmation phase (step 2). Alternatively, if there was a way to hook the selected user role, per auto assign role, into the users role that would be assigned upon confirmation that would also be great. However, it really seems like these modules should be combined in some fashion.

Thanks for another great contribution to the Drupal community.

from function logintoboggan_validate_email():

      // Remove the pre-auth role from the user, unless they haven't been approved yet.
      if ($account->status) {
        if ($pre_auth) {
          db_query("DELETE FROM {users_roles} WHERE uid = %d AND rid = %d", $account->uid, logintoboggan_validating_id());
        }
        // Allow other modules to react to email validation by invoking the user update hook.
        $edit = array();
        $account->logintoboggan_email_validated = TRUE;
        user_module_invoke('update', $edit, $account);
      }

this functionality is in both 5.x and 6.x -- it's been around awhile. what that means is that any other module can look for $account->logintoboggan_email_validated in the 'update' op of hook_user(), and determine if the account has just been validated.

if other modules want to extend functionality to the validation process, they should leverage this method. i'm not going to add special cases to the module when this method exists.

reassigning to Auto Assign Role, as the request is more appropriate for that queue.

Holy *crap*, it took me forever to track this issue down to this particular post! Tons of threads out there, none of them with a working solution. Anyway, of course the fix turns out to be two lines of code... in function autoassignrole_user(), I added an "update" case and a conditional break to the "op" switch:

function autoassignrole_user($type, &$edit, &$user, $category = NULL) {                                                                     
  switch ($type) {                                                                                                                          
    case 'insert':                                                                                                                          
    case 'update':                                                                                                                          
      if ($type == 'update' && $user->logintoboggan_email_validated != TRUE) break;                                                         
      if (variable_get('AUTOASSIGNROLE_ROLE_ACTIVE', AUTOASSIGNROLE_ROLE_ACTIVE) == 1) {                                                    

I don't know if this causes other issues. I don't know if making the autoassignrole module aware of logintoboggan is any better than the reverse (an idea that has been shot down in other threads). I don't even know how to roll this into a proper patch, being a bit of a drupal noob. However, I do know that the two modules are now working for me, so I'm happy.

EDIT: not sure why drupal seems to be inserting newlines into the code above.

Update to my fix in #6 above: note that this only seems to work for "AUTO" role assignment, not "USER" role assignment. The problem is that user's role choice happens on the registration page (hook_user 'insert'), but the 'update' call to hook_user doesn't happen until the logintoboggan email verification. At that point, the info from the AUTOASSIGNROLE_ROLE_USER form is gone.

I think what's needed is for autoassignrole to save the AUTOASSIGNROLE_ROLE_USER form info into a table during registration (insert), then pull it back out again on update. Or - logintoboggan needs to save any pre-assigned roles during the 'insert' phase, and re-apply them upon verification.

Still trying to figure out how to implement this. Suggestions or tips welcome.

Further update. I've got a fix that works for me - though I feel that it may not be "correct" implementation. Basically, I discovered that the AUTOASSIGNROLE_ROLE_USER form value was getting stuffed into the user table "data" row. Therefore, changing references to

$edit['AUTOASSIGNROLE_ROLE_USER']

in autoassignrole_user to

$user->AUTOASSIGNROLE_ROLE_USER

seems to do the trick. During the 'update' phase, the form values that were saved during registration are pulled out & the users_roles table is updated with the correct role.

This all smells sort of hacky to me - particularly since I'm too new at this to know why the registration form values are saved to the user object, or if that's a "legal" thing to do. There seems to be at least one place in the core user_register_submit() function where this is explicitly avoided: http://api.drupal.org/api/function/user_register_submit/5 (search for "unset"). So any words of wisdom from someone who knows better are welcome.

To summarize - in autoassignrole_module:
1) add "update" case, and logintoboggan_email_validated check
2) change $edit['AUTOASSIGNROLE_ROLE_USER'] to $user->AUTOASSIGNROLE_ROLE_USER

This has only been tested with *single* user roles. Don't know if it works with multiple roles. I've got to catch a plane in about six hours, or I'd spend more time testing this & turning it into a patch.

Thanks for posting this fix. However, I can't get it to work for me. I suspect I'm doing something wrong.

First, do you apply the latest patch (from here: http://drupal.org/node/235707) to the module before making this change?

Second, I'm a bit thrown because the syntax I see in the module doesn't match your final line above. Are you leaving out all the code for the insert case above, or should the modification go above it?

Please take a look at this and tell me where I went wrong.

It would be great if you added a few lines above and below your code so it was clear to coding novices like me exactly what is being replaced and where.

function autoassignrole_user($type, &$edit, &$user, $category = NULL) {
  switch ($type) {
    case 'insert':
    case 'update': 
               if ($type == 'update' && $user->logintoboggan_email_validated != TRUE) break; 
            if(variable_get('AUTOASSIGNROLE_ROLE_ACTIVE','0') == 1) {
        $roles = variable_get('AUTOASSIGNROLE_ROLE','0');
        if(is_array($roles)) {
          $sql = 'INSERT INTO {users_roles} (uid, rid) values (%d, %d)';
          foreach($roles as $key => $value) {
            if($value > 0) {
              db_query($sql, $user->uid, $value);
            }
          }
        }
      }
      if(variable_get('AUTOASSIGNROLE_ROLE_USER_ACTIVE','0') == 1) {
        $sql = 'INSERT INTO {users_roles} (uid, rid) values (%d, %d)';
        if(is_array($edit['AUTOASSIGNROLE_ROLE_USER'])) {
          foreach($edit['AUTOASSIGNROLE_ROLE_USER'] as $key => $value) {
            if($value > 0) {
              db_query($sql, $user->uid, $value);
            }
          }
        } else {
          db_query($sql, $user->uid, $edit['AUTOASSIGNROLE_ROLE_USER']);
        }
      }
     break;
  

  }
}

function autoassignrole_form_alter($form_id, &$form) {
...

Thanks,
Ben

As far as the patch you reference - there's a note in that thread indicating that the patch in question is superseded by the one in this thread: http://drupal.org/node/228774#comment-781025 I believe that I did apply the latter patch.

Your "update" case seems correct, except that, as you noted, the syntax of the next couple of lines is different. I have:

      if (variable_get('AUTOASSIGNROLE_ROLE_ACTIVE', AUTOASSIGNROLE_ROLE_ACTIVE) == 1) {
        $roles = variable_get('AUTOASSIGNROLE_ROLE', AUTOASSIGNROLE_ROLE);

This could be a result of the patch mentioned above - I'm not sure. However, note that you can open up a patch file and read it as text to find out what changed. (Sorry if that's obvious. I didn't know it myself at first.)

All of the above pertains to the first "if" clause in autoassignrole_user(). That's the case that handles "AUTO" role assignment (i.e., non-user-selected roles).

With respect to the "$edit" change I listed in my most recent post: There are two instances of "$edit['AUTOASSIGNROLE_ROLE_USER']" - both are in the second "if" clause of that same function, which is the case that handles "USER" role selection. The first one relates to the case where there are multiple roles, and the second one relates to the case where there's just one role selected. I have only tested the second case. My entire function looks like this:

function autoassignrole_user($type, &$edit, &$account, $category = NULL) {
  switch ($type) {
    case 'insert':
    case 'update':
      if ($type == 'update' && $account->logintoboggan_email_validated != TRUE) break;
      if (variable_get('AUTOASSIGNROLE_ROLE_ACTIVE', AUTOASSIGNROLE_ROLE_ACTIVE) == 1) {
        $roles = variable_get('AUTOASSIGNROLE_ROLE', AUTOASSIGNROLE_ROLE);
        if (is_array($roles)) {
          $sql = 'INSERT INTO {users_roles} (uid, rid) VALUES (%d, %d)';
          foreach ($roles as $key => $value) {
            if ($value > 0) {
              db_query($sql, $account->uid, $value);
            }
          }
        }
      }
      if (variable_get('AUTOASSIGNROLE_ROLE_USER_ACTIVE', AUTOASSIGNROLE_ROLE_USER_ACTIVE) == 1) {
        $sql = 'INSERT INTO {users_roles} (uid, rid) VALUES (%d, %d)';
        if (is_array($edit['AUTOASSIGNROLE_ROLE_USER'])) {
          foreach ($account->AUTOASSIGNROLE_ROLE_USER as $key => $value) {
            if ($value > 0) {
              db_query($sql, $account->uid, $value);
            }
          }
        }
        else {
          db_query($sql, $account->uid, $account->AUTOASSIGNROLE_ROLE_USER);
        }
      }
      break;
  }
}

Note two things: 1) I changed the "$user" variable to "$account", because this seemed to be consistent with other uses I've seen elsewhere, and I think there's a global $user variable, so I thought this was clearer. 2) All of this could be a complete hack - I'm not really familiar enough with the way things are "supposed" to work to say.

subscribing

Hello all.

I'm subscribing to this issue, but at the same time offering a solution to this problem

The attached patch does a few things, and I say upfront that this is NOT the total solution, but it's a working one.

First, it implements the hook_user as described in post #11.

Second, it bugfixes that implementation; During the registration process, there is no $account->AUTOASSIGNROLE_ROLE_USER. There is a test for $edit['blabla'] and that one should be used. (so in my opinion, the original code is correct in that part)

Third, and as I see it the biggest problem, is that the roles are placed in an array, given to the form_api (as they should be), trouble is, there is a problem with the contents of that array.

To function with this code

  $sql = 'INSERT INTO {users_roles} (uid, rid) VALUES (%d, %d)';
  db_query($sql, $account->uid, $edit['AUTOASSIGNROLE_ROLE_USER']);

the delivered value must be a role-id (rid).
To get that, the array for the forms-api must be in the form rid => 'role description'
Unfortunately the function _autoassignrole_intersect creates a non-associative array (the keys are lost) so where the example role 'Site tester' used to have role-id 4, it now has role-id 0 (if its the first in line). I traced the problem to the use of the array_multisort call.

I took the fastest and most logical way to solve this; array_multisort for sorting a single array? no need for that, use asort and arsort. Also I replaced a foreach loop to cleanup the array with a call to array_filter. (I used to do it with a foreach myself until I discoverred array_filter and found that it's much faster :) )

I hope you don't mind me altering your code, the only reason that I do is; I like the module and I like for it to get as optimal as possible.

Remon

p.s.
I took the liberty of including a few lines of comment for the function _autoassignrole_array_intersect_key so that people reading the code don't have to figure out what this function does :P

@rmpel - I tried your patch (against the stock 5.x-1.1 release from the main page), and it doesn't seem to fix the original issue. That is, when using "user role assignment" (user-selected roles at registration), when the user verifies his account (via LoginToboggan verification), his selected roles aren't being set. At least, it's not working for me.

You noted that during registration, there is no $account->AUTOASSIGNROLE_ROLE_USER, and therefore $edit['AUTOASSIGNROLE_ROLE_USER'] should be used... If my memory is correct, when I looked into it I discovered that during loginToboggan verification, there is no form information in $edit['AUTOASSIGNROLE_ROLE_USER']. (It's not the registration form - it's the verification form that is calling hook_user.) Could this be the reason I haven't gotten your patch to work?

Hmmmm, perhaps we have been talking about similar but different problems.

I had the problem that roles weren't set correctly and my patch fixes that, but, I must admit, I'm not using LoginToboggan. (I assumed this module would pass the information to the hooks correctly)

Your remark suggests that LoginToboggan sends the info to the hook in a different format than should be. (difference between $account-> and $edit[])
According to drupal code; $account should be used for identifying the user to edit and $edit should hold the altered information.

As I'm not using LoginToboggan, I can only guess here, but I think the rest of this problem is caused by a bug in LoginToboggan.

I'm kinda low on spare time atm, so I cant look into the details atm (of LoginToboggan), I hope someone else will take that upon him/her.
I'll check back soon and hope to have more time next month, in case there is no fix yet.

Your remark suggests that LoginToboggan sends the info to the hook in a different format than should be. (difference between $account-> and $edit[]) According to drupal code; $account should be used for identifying the user to edit and $edit should hold the altered information.

I think the issue is that at the time LoginToboggan calls hook_user(), there's no information for it to pass, through either mechanism. I believe LT hijacks the registration page & user roles, giving new users its own "pending" role until they use the link in their verification mail to verify their account. It calls hook_user() with type "update" during verification, but doesn't pass any info (because the user-selected roles are never saved during registration). My fix above was taking advantage of the fact that these selected roles seemed to be ending up in $account, and so could be retrieved from there - but I admit that this feels like a hack.

As I'm not using LoginToboggan, I can only guess here, but I think the rest of this problem is caused by a bug in LoginToboggan.

That's definitely an arguable position. Anyway, as you can see from the first post, this incompatibility is what this bug refers to. The "correct" way to fix it would probably be either:

1) autoassignrole stuffs the selected roles into a table somewhere on registration (hook_user("insert")), then retrieves them at verification (hook_user("update")). Or...

2) logintoboggan calls hook_user() at registration to allow the roles to be set, then removes them and stores them somewhere, then retrieves them and sets them again at verification time.

#2 feels better to me - but if you search the database, there are a number of other bug entries related to this, and the maintainer of Logintoboggan has basically refused to "make a special case" for autoassignrole. He might be willing to change the code if someone wrote the patch for him, and made an argument that it's the "correct" way for LT to behave. Unfortunately, I don't think I'm knowledgeable enough to be that person.

A thought just struck

As i see it this is the requested functionality;

Open site:
1. User registers on site
2. User is activated with roles of choice

Semi-open (admin must approve)
1. User registers on site
2. user is stored ' inactive ' with roles of choice
3. Admin activates user

User-activated (and correct me if im misinterpreting)
1. User registers on site
2. user is stored ' inactive ' with roles of choice
3. User activates himself by clicking a link

(from here on it's just thinking on virtual-paper)

Now, the logintoboggan module tries to implement this.
If I were to make such a module, i would let the registration play out completely with one alteration; set the user->active to 0 (a.k.a. inactive user)

As I'm typing im grabbing the latest version of LT to see what it's doing.

[moment of silence]

/gasp

A lot of code for a seamingly simple task.

LT is hijacking form submit functions (as well as doing a lot of other stuff) of (among others) the user_register form.

at line 282 the user is saved the same way the user_register_submit function does ( user_save(empty variable in place of object, array with values to save)

after clicking the link the user info is loaded and stored again correctly (function logintoboggan_validate_email)

All seems ok here

the module invokes the hook_user with $op = update, $edit being an empty array and $account being a valid user object.

And then it confuses me;

Why request other modules to perform the operation 'update' but not saving the user afterwards?

      // Remove the pre-auth role from the user, unless they haven't been approved yet.
      if ($account->status) {
        if ($pre_auth) {
          db_query("DELETE FROM {users_roles} WHERE uid = %d AND rid = %d", $account->uid, logintoboggan_validating_id());
        }
        // Allow other modules to react to email validation by invoking the user update hook.
        $edit = array();
        $account->logintoboggan_email_validated = TRUE;
        user_module_invoke('update', $edit, $account);
      }

I would add a user_save($account, $edit); here, making the code:

      // Remove the pre-auth role from the user, unless they haven't been approved yet.
      if ($account->status) {
        if ($pre_auth) {
          db_query("DELETE FROM {users_roles} WHERE uid = %d AND rid = %d", $account->uid, logintoboggan_validating_id());
        }
        // Allow other modules to react to email validation by invoking the user update hook.
        $edit = array();
        $account->logintoboggan_email_validated = TRUE;
        user_module_invoke('update', $edit, $account);
        user_save($account, $edit);
      }

Perhaps that would solve all your troubles.

Perhaps the line user_module_invoke('update', $edit, $account); shouldn't even be here...

Again, just thinking aloud here ...

Tried the change that you suggested, but it didn't seem to work for me. In debugging it, it appears that the "INSERT INTO" query in autoassignrole is getting called at registration time, as it should be - but nothing ever shows up in my "user_roles" table. Is it possible that LT (or some other piece of code) is DELETEing the roles immediately afterwards? (Sadly, I don't have access to mysql logs on my host in order to check this.)

Has ay further progress been made around meeotch's issue? I've had the same problem.

The workarounds I posted are working for me. However, you should note that they probably aren't "correct". It feels like the "correct" fix would be for LoginToboggan to remember the roles that other modules assign at registration time, and re-apply them at confirmation time.

It works fine with autoassignrole and logintoboggan... big THX!

I think this has been fixed by http://drupal.org/cvs?commit=135899 ... let me know if it's still a problem.