Allow logged in users to validate their email address and be removed from the temporary role

Hello elliottf,

Thanks very much for submitting a patch along with your request, that's always much appreciated!

I've just attempted to review it, but it seems you've rolled the patch against the 6.x codebase rather than the 7.x codebase.

Please would you re-roll the patch against 7.x-1.x-dev and resubmit? (or correct me if I'm wrong)

Thanks
Steve

Any update on this issue? Seems like an issue with many folks potentially...

Hey Elliotf, the patch in #1 is indeed for <= the 6.x branch as there is no logintoboggan_block() method in 7.x, tho if locally you have it somewhere in 7.x I'd love to see how you did it.

I'll post a patch later today that works in hook_init() to ride along with (and duplicates logic of) user_pass_reset() which cannot be form altered for logged in users....it's not beautiful cause user_pass_reset() has some drupal_goto() going on which we can't control afaik

Here it is, seems to work, would be good to get more eyes/hands on it tho.

Applying this patch threw the following error:

Parse error: syntax error, unexpected $end in sites/all/modules/contrib/logintoboggan/logintoboggan.module on line 1334

Checking this.

Ooooops, I forgot to fix that in the patch, thanks....reattached...

Also, I'm now trying to make this usable and there are some challenges, it seems that because a user is logged in immediately when using this setup the welcome email contains an invalid reset link, this may be mitigated partially by the fact that two emails get sent out (I believe the second email contains a link with the login time after immediate login, tho I need to do more testing), this creates a problem in that a user may never understand that the first email is invalid...it's a bug, maybe we need to do a hook_mail_alter on the welcome authorized mail?

OK, this is a documentation issue...i found out while searching for another problem I encountered along the way (duplicate registration welcome emails)

I'm going to put this in big text so it is not missed feel free to correct me but I'm pretty sure this is the deal:

the user "Welcome (no approval required)" email MUST have the [user:validate-url] token for email validation to work for logged in users

Logintoboggan supplies it's own validation method for the link created for this token, bypassing limitations imposed in drupals user_pass_reset()

Cheers,
JP

The patch from #9 is not the right approach. If a single page needs to be altered it is not a good idea to use hook_init() for this, since this fires on each request. Using arg() is not advisable either, the documentation for arg() mentions "Avoid use of this function where possible, as resulting code is hard to read".

The patch from #1 looks much better. I will review it and make sure it applies properly to the latest 7.x-1.x if any problems should arise.

This is not a feature request but a bug, and a serious one. When users follow the 'pre-authorized' registration procedure they are logged in immediately after registering, so it is fair to assume that most users that click the validation link are logged in when they do so. This means that this functionality is broken in the typical use case.

Patch #1 still applies to 7.x-1.x but with some fuzz. Here is a straight reroll of the patch from #1 against the latest 7.x-1.x-dev.

Hey pfrenson just wondering, did you see what I wrote in #11? I thought it was well broken as well but then found I just needed to replace the token with the right one... Does that apply to your scenario as well?

@jpstrikesback, you're right! I was totally on the wrong track with this. I did read your comment but for some reason I thought this did not apply to my situation. But yes it makes sense, by default the [user:one-time-login-url] token is used in the message, but it needs to be the [user:validate-url] token. It is also mentioned very prominently on the settings page, with a link to the help page with the full explanation.

I'm going to set this to "Works as designed" because it is basically a case of RTFM :)