i'm planning to add a setting to this module so that it resets the password and sends either the new temporary password (or better yet, a one-time login link) in the email notifying the user that their account is now active. on my sites that require admin approval of account requests, i found my users were confused by the initial email telling them their account exists and what password to use, even if the account was still blocked (not yet approved) and that password didn't work. i'd like to make it possible/easy for admins to setup their site such that end-users never even see a temporary password or login link until a user's account has been activated. this will prevent all sorts of end-user confusion.

Comments

lanesharon’s picture

Thank you!

lanesharon’s picture

Why not let them set the password at registration and never use a temporary password. Use the user status code, which is currently set to 0 when the user is not activated. I am totally not understanding the purpose of the temporary password!

dww’s picture

lanesharon’s picture

See my suggestions in that same node.

drupal777’s picture

I must not understand something, because I inserted the following single line after line 214

$user_status_loginurl = url("user/reset/$user->uid/$user->created/".user_pass_rehash($user->pass, $user->created, $user->login), NULL, NULL, TRUE);

and changed the line that previously read:

array($notify_site, $user->name, $notify_loginurl),

so that it now reads:

array($notify_site, $user->name, $user_status_loginurl),

and I was then able to use the %loginurl substitution in the "Activate status" body to display the one-time login link. Is it really that simple? Something must be wrong. Nothing is ever that simple.

To recap, the code now looks like this after line 212:

        case 1:
          if (variable_get('user_status_activated_enable', FALSE)) {
			$user_status_loginurl = url("user/reset/$user->uid/$user->created/".user_pass_rehash($user->pass, $user->created, $user->login), NULL, NULL, TRUE);
			return user_mail($user->mail,
                             str_replace(array('%site', '%user'),
                                          array($notify_site, $user->name),
                                          variable_get('user_status_activated_subject', user_status_activated_subject())),
                             str_replace(array('%site', '%user', '%loginurl'),
                                       array($notify_site, $user->name, $user_status_loginurl),
                                       variable_get('user_status_activated_body', user_status_activated_body())),
                             $headers);
		 }

Does this rise to the level of a patch? If so, does anybody want to give me a quick lesson on how to submit one? As you can tell, I've never submitted a patch before.

dww’s picture

see http://drupal.org/patch or
http://drupal.org/diffandpatch for info on how to generate and submit a patch. what you've got here isn't yet a patch, but the code is certainly on the right track...

and yes, it probably is that simple. :) i just never had any time to work on this at all. i'm currently on vacation and unable to apply, test and commit changes, but if you follow the instructions above and attach a real patch to this issue, i'll certainly review and apply it as soon as i get home.

thanks,
-derek

drupal777’s picture

The more I look at what I've done so far, the less I like it. I need to add a variable to restore the ability to generate a link to the user's login screen (I had hijacked that variable for the one time login and that can't be right - that is just making one thing available at the expense of the other).

Also, I think the explanatory text that displays in the Administer->Settings->User_Status->Activate Status under the Body textarea needs to be expanded to reference the newly available variable.

I'll try to do this over the weekend, but I'm running out of time so if somebody else wants to do this, I won't complain.

drupal777’s picture

And to add a little feature creep.... at this point, the routine does not hook into watchdog so the acts of sending the emails on Activation, Blocking and Deleting are not being recorded in the watchdog log. Something else I'll try to figure out.

dww’s picture

Status: Active » Fixed

since i couldn't stand it anymore and finally needed this for one of my own sites, i just committed a bunch of changes into the DRUPAL-4-7 branch to implement this feature along with providing all the same placeholders that core does (see http://drupal.org/node/66936), clean up the settings page, update the README.txt and INSTALL.txt, etc. All of this will be available in the forthcoming 4.7.x-1.1 release (or right now from the end of the DRUPAL-4-7 branch if you're so inclined).

enjoy,
-derek

Anonymous’s picture

Status: Fixed » Closed (fixed)