ReSend confirmation e-mail

Seriously.

I don't think this is going to be a feature in the user registration password module itself, but yeah it's on a list somewhere. So marking as 'won't fix', with a small comment:

I am creating a separate module for this, also to get some more 'actions' from other mods in there. The idea: the ability to re-send:
- almost all types of mail drupal can send that are defined on the accounts config page.

That new module can call all existing functions in contrib modules to send out emails, it's basically just a small wrapper module that looks if module x,y,z is installed and if so, renders an action that you can select at admin/people onder 'Update options'. (guess that's what you want, i want that too!) (where x can be user registration password, y can be logintoboggan, and so on.)

So we don't actually need to do anything to our module, or any other contrib mod, if the module is created this way. Currently it's at draft / concept stage.

I had the same idea couple of weeks ago, code will be available at some point, but... funding... Also have to pay the rent n such ;-)

And thanks, i'll pass it on ;)

Update:

https://drupal.org/sandbox/ClusterFCK/1819072
Check this sandbox, it contains the base basics for the module. Still needs work, but it can be as simple as that.

Grtz!

Love the module, but I needed this feature, so wrote a patch for it.

Also I believe this feature is actually needed for this module to function well. As it stands the module redirects to 'user/pass' if you use an expired one-time login. Problem is that 'user/pass' won't generate a one-time login mail for blocked users, so there is no way for users to unblock their account or get a new one-time login.
So I would say that this is actually a bug fix, not a feature request.

I added a menu entry to send a new one-time login (borrowing heavily from user_pass), that checks if the user is blocked and has never logged in (otherwise this could be used to always unblock your account, not just accounts blocked at registration), then sends a new activation email.

Len

Lendude, thanks for the patch. I do have some additional questions, like how and what to do for limiting the re-requesting, like Drupal core does. (see the flood_control module to see what flood is) (else we'll create a new bug while fixing this one.)

Maybe we can even do a couple neat things, like check if a user tries to re-register with the same info, and if so, redirect to 'user/resendregistrationpassword'.

And about that project i listed previous, we could create an admin action to re-send the user_registrationpassword confirmation mail. This way, if users have trouble, admin's can step in and assist.

I'll try and properly review the patch in a couple of days, because this #115801: Allow password on registration without disabling e-mail verification is taking a bit more time. Yes that is the D8 patch! We'r trying to get our functionality in core.

1 free tip: next time, put the issue 'Status' to 'Needs review' next time. The only reason it got my attention, is because i'm still subscribed to this issue. (if i wasn't, i never would have seen your patch.)

Thanks!

Lendude, did you ever try to wait 24 hours? Aka did you experienced a link not working after 24 hours?

Rob,

at the moment, flood control is done the same way that Drupal core does it for password resets, namely, not at all (just tested this on one of my live sites and I can spam myself silly with password reset mails). I fully agree that it would be good to do this, how would you test if something is a valid request? how much time would need to pass? pick a timespan? wait atleast 30 minutes for the mail to arrive? admin interface to set the waiting period? hardcode it? Ideas?
All sounds easy enough to implement. Would need a database table to keep track of send mails or just do a variable_set() and dump an array into it with UID => timestamp pairs (might be a problem with a HUGE number of users registering at the same time, but probably not a problem in real life)

I didn't look at you sandbox project to be honest, didn't feel that this warrented another module (we usually have more than enough modules enabled in our projects as it is ;-), but felt it should be part of this module.

About the 24 hours, my bad, didn't read the code right. So no bug. Silly me. Rerolled the patch to not include that change.

That does mean that there is no reference to the resend URL anywhere in the module right now, so if you would decide to add this, it would probably be a good idea to put a reference to it in the drupal_set_message after registering or something (my current project redirects to a specific 'what to do after registering' page using the login_destination module, so that's how I handled that, but that doesn't sound like an acceptable standard workflow for people that just want to use this module).

and gratz on the D8 to core thing! Keep up the great work.

Len

'how would you test if something is a valid request?'

Simple. Log attempts to the 'flood' table and then check for them during the function that deals with the request.

The 'flood' table IS that table your talking about and it's in core. pass reset just doesn't use it, see: #1681832: Password reset form has no flood protection
That should really get into D8 if you ask me.

Resending a pass reset if a user is blocked:

  $users = entity_load_multiple_by_properties('user', array('mail' => $name, 'status' => '1'));

is used in core to verify the user's status, and we use status for our functionality. I just uploaded a new D8 core patch that solves this issue In core. (or at least tries to) So if you want to test that, to see if that fits your case (think it does), download D8 core and my patch and give it a go. (could also really use some feedback on that patch)

Thanks!

Thanks for pointing out the flood functions in core, never ran into those before, nice to know.

I put some flood control into the 'resend activation email' function, now capped at once every 30 minutes (time limit now set with a define() so no admin control over that at the moment)

Len

Everybody. I am working on the next version of this module.

See user_registrationpassword for a big time code cleanup + small tweaks + TESTS!

And ... see user_registrationpassword_extra for a new idea, to expand this module a bit.

The idea is to merge back those new features, but we don't need all of them, some of it will be fixed in core at some point.

Let me know what you guys think about this! Thanks.

Question: Does the 7.x-1.x-dev version contain the patch from above?

Also: Will user reg pwd extra have a Drupal project page soon? Have to document usage statistics for our client and am interested in trying it out, but can't if it's not officially Drupalled.

Hey prairiebean,

In short: not 100%. The github page (also GPLed) is more up to date. I'll merge back the code very soon. (working on a couple media projects that take up all my time)

I'll check if i have some spare time to do some more work on 1.4 end of the week, maybe get parts of the extra module in the existing module, or start a separate project for it. Not sure yet, cause it doesn't look like the issues the extra module tries to fix will be fixed for D7 any time soon, so i might just start that new project.

As a side note: I'm trying to get 1.4 compatible with the commerce checkout redirect.
More info on this:
#1825448: Support for User Registration Password (and possibly others)
And more people have issues, so this patch needs testing with our version on github: #1881972: Rewrite module (that i'll be merging soon)

As soon as i have a working dev version on d.o. i'll update this post.

I have merged user_registrationpassword_extra into user_registrationpassword. The files are now available via git, wait 24 hours to download the development release.

Included:
- Resend confirmation mail from admin users page. < need serious testing.
- Resend confirmation mail from password reset form for new users. < need serious testing.
- Password reset form flood limits. (and control)
- Privacy mode for password reset.
- Lots of minor tweaks and fixes, see the changelog and readme for more info.

The tests still need work, they need to be updated to include all new functionality and changes, i'll see if i can update them next week. And support for commerce checkout redirect is untested and still needs work (i bet). Hope i can get some time to work on these last 2 points, if that's fixed, we'r close to a 1.4 release.

The files on git could use some testing. If you try them, please report back the results, thanks!

Using the 7.x-1.x, 2013-Apr-07 version

I was able to:
- resend the confirmation email from the password reset form.
- enable privacy enhancements

I was not able to:
- See any way to resend the confirmation email from admin users page.
- See any way to turn on flood limits/control

ADrupalUser, thanks for testing!

When you visit admin/people you will get a new option in the dropdown box to resend to selected users.
And to edit flood limits you need to install flood_control.

I'm currently axing a couple of these new features, i'm creating a new module that includes the privacy and flood bits, had a quick chat about this with a couple people - and this seems like the best thing to do / keep user_registrationpassword as clean and simple as possible, i will update this issue when i've synced my repo to d.o. and created the new module, so stay tuned.

OK, but FYI with the 7.x-1.x, 2013-Apr-07 version, I don't see this:

- When you visit admin/people you will get a new option in the dropdown box to resend to selected users.

Indeed true, i did already removed this due to user_mail_actions.

To wrap this up:

Fixed in dev, sync from git to test this please.

- See any way to resend the confirmation email from admin users page.

The user mail actions module offers this already. Not a real project yet, but it does work already. (i'll see if i can update it to a real project soon)

- See any way to turn on flood limits/control

This is going to be part of a new module i'm working on. More info soon.

For those looking for the D6 patch of #3, find it attached.

Hi,

I'm trying to implement my own function to do this but from what I can see the following code doesn't work as the email it needs to send "Welcome (no approval required)" is disable by this module. How can I re-send the verification email?

Looking at the custom module it also uses _user_mail_notify() so I am not sure how that can work either.

$uid = 42861;
$account = user_load($uid);
$op = 'register_no_approval_required';
$status = _user_mail_notify($op, $account);

Cheers Dan

@danharper
Maybe this comment may be useful

@toemaz next time plz reopen the issue / put it on needs backport. I missed your comment about the d6 patch cause i closed the issue and hit unfollow...