role doesn't get automatically assigned

Any chance you could install the devel module and activate the 'backtrace' mode of error reporting? It should backtrace to the line of code in my module that is the problem and/or give you the sql query that is the problem if sql is to blame.

That line of code you listed could point to a number of possibilities.

P.S. Don't leave the backtrace mode on after you find the info, I think your users would see that instead of a Drupal message. Check the docs to be sure. I could be wrong and backtrace could be permissions based.

Nothing is pointing to my module huh? That's strange. To make sure we're on the same page: when the backtrace fires, it creates a table (though it can be pretty wild looking) with the offending line of code on the left and the argument data that goes with it to the right. That data can sometimes be quite long resulting in a very long, vertical page with the offending lines of code spaced far apart. So if that's what you're seeing, and none of the functions on the left are from my module, then what you could do is list what IS in that column. If it repeats (due to multiple page loads or whatever), don't bother with that; the first run through is enough. From top to bottom, what you've got it the last function called down to the first function called. So if one of my functions calls one that's in your list, I'll know where to look. Does that make sense?

I'm having the same problem and I also noticed that when you try to sign up a second user with the same role, the following error occurs:

user warning: Duplicate entry '0-4' for key 1 query: INSERT INTO users_roles (uid, rid) VALUES (0, 4) in /path/to/htdocs/includes/database.mysql.inc on line 172.

What's in the database for users_role is a row with 0 as the uid and 4 as the rid. It appears that the uid never gets saved to the database correctly when the user registers.

Not sure if it's related.

@smooshy, I fixed that error the other day and just need to release it. The error can actually be ignored because the database is updated correctly. Basically, I accidentally tried to INSERT the same values twice. So although the error is certainly annoying and will confuse users, it is innocent enough.

As for the other issue, I'll review the above attachment at the first chance I get.

I can confirm experiencing both issues.

In terms of fixing it, I suspect this is part of the the problem :

// nf_registration_mod.module
$current_role[$name] = variable_get('nf_registration_mod_enhance_roles', array());  // line 441
$current_role = $current_role[$name];  // line 442

Looks like a typo...I suspect it should actually be this:

$current_role = variable_get('nf_registration_mod_enhance_roles', array());  // line 441
$current_role = $current_role[$name];  // line 442

Making that change eliminated the errors on the admin side for me. Note that this does not fix the actual *assignment* of roles upon login. That is probably addressed in the fix rconstantine referenced above.

Hrm, turns out I needed the role-assignment after all, so the fact that it didn't work was problematic. Here's the fix to make the role assignment happen properly: change $user->uid to $account->uid in the following snippet.

// file: nf_registration_mod.module
db_query('INSERT INTO {users_roles} (uid, rid) VALUES (%d, %d)', $user->uid, $edit['mem_choice_role']);  // line 916

This fix eliminates the error that users would see during the registration process and also correctly assigns new users to roles.

I don't recall whether I fixed this or not. Could you tell me if this is still broken in the 1.2 version? If so, update this issue's version.

The version I was working against was v1.2 -- 1.2.2.3 (Sept. 17th 2007 to be exact). Sorry I didn't update the version earlier!

Try modifying the function you're talking about to look like this:

if (!module_exists('accounttypes')) {//accounttypes implements auto-roll assign; don't step on toes
        $roles = user_roles(TRUE);
        unset($roles['2']);
        $current_role[$name] = variable_get('nf_registration_mod_enhance_roles', array());
        //$current_role = $current_role[$name];
        $form['nf_registration_mod_enhance_roles'] = array(
          '#type' => 'radios',
          '#title' => t('Select role to automatically assign to new users'),
          '#options' => $roles,
          '#default_value' => $current_role[$name],
          '#description' => t('The selected role will be assigned to new registrants from now on.  Be sure this role does not have any privileges you fear giving out without reviewing who receives it.'),
        );
      }

The problem I have in testing this is that I've had my accounttypes module installed which allows you to assign multiple roles, not just one. And that feature works fine. The above function, obviously, tests to see if the accounttypes module exists, and if not, allows you to assign one role.

I'm not sure if that will work -- I think the issue is that when you execute variable_get('nf_registration_mod_enhance_roles', array()), a keyed array is returned and what is really needed is the RID, so you need to use the value of $name as a key to that array to indicate the currently-selected RID. At least, I think that is the case. In any case, the fix I posted above appears to be working OK (no accounttypes needed for me).

So let me see if I understand.

First, (although I don't recall exactly) let's look at what is/should be stored in the variable "nf_registration_mod_enhance_roles"; is the structure something like "membership name => RID"? That's what I would expect it to be.

If so, then looking at the submit function, only the RID is needed from that form variable. In other words, your mod at #8 is correct.

Next, are you checking $user->uid vs $account->uid? Is that how you came to that conclusion in #9? If so, was this signing up as the new user, or as an admin creating the new user? Did you try both ways? I suppose it should work both ways. Using the accounttypes module does work both ways if I recall correctly.

Let me know. I've added your change from #8 already to my code. Thanks.

Well with the $account vs. $user issue, since this is an implementation of hook_user, I think you should *always* be using $account (or whatever you name the 3rd parameter being passed into the function) because the function is supposed to operate on the account in question, not the current user. It solved the problem of the role not being assigned when a new user signed up, at least.

Now, I don't think the section that I was talking about ever gets executed when an admin creates a user because there's the check for whether or not $edit[mem_choice_roles'] is empty immediately previous to that and I don't think that will get populated when an admin creates a user. There appear to be a few extraneous global $user; in the other sections of that switch statement too ($user doesn't get used in 'em in other words).

BTW -- despite all my nit-picking I really like the module and I've used it with great success on one project and am just starting another in which it will be invaluable :)

I don't mind nit-picking at all. Especially since you haven't "sounded" like a big complainer. I will change $user to $account as you suggest and look for the extra global $user lines.
Notice the new release. It fixes the problem of users not being able to edit their pageroute-related account data.