In the function logintoboggan_form_user_pass_reset_alter(), we use the following code to display a message on password reset:

_logintoboggan_process_validation($account);
drupal_set_message(t('You have successfully validated your e-mail address.'));

_logintoboggan_process_validation() properly checks that the non-authenticated role is not "authenticated user" before doing any processing. The message though, is outside of this logic and will always be dispalyed, even if I'm not making use of an unauthenticated role.

I think the message should either be wrapped in a similar check, or moved inside _logintoboggan_process_validation().

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

EAnushan’s picture

Status: Active » Needs review
FileSize
722 bytes

Attached patch.

GuyPaddock’s picture

Title: Successfully Validated E-mail Address Message when "set password" is set to FALSE » Logic for the Successfully Validated E-mail Address Message needs clarification

The reason why the message should be displayed regardless is because the user is still confirming their e-mail address by clicking the link, regardless of whether or not the site is using the pre-auth role.

You want to tell the user that they have successfully confirmed their email address.

If I am wrong about that, then you are indeed correct that the same check should be applied here. But, if I am correct, then the message should be pulled out of being wrapped by the conditional for pre-auth entirely.

On a related note, though, the way that the pre-auth is handled actually causes the success message to appear on multiple pages when LoginToboggan is used in conjunction with the Password Reset Landing Page (PRLP) module.

GuyPaddock’s picture

I think I see what the OP was talking about -- the user always gets the message, even when resetting their password, no?

In any event, the attached patch reworks a lot of the logic in logintoboggan_form_user_pass_reset_alter(), as follows:

  • Rely on form build args instead of path arguments: The form builder signature is more reliable than the path, especially if the site uses a third-party module that could invoke the form from a different path.
  • Prevent doing any actions if we're not on the log-in form or in the middle of handling form submission: It's usually a bad idea to do any actions with side-effects in a form build function, since Drupal will call the build function and alter hooks a second time to re-build the form during form submission. Unfortunately, it doesn't seem like it's avoidable in this case since LT wants to act on the user password reset page. So, at least now there's a check for whether or not the log-in form is loading for the first time.
  • Ensure that no message is displayed for normal password resets: I did incorporate EAnushan's patch in the check for whether the user is in the pre-auth role or not, so that should prevent the success message from appearing except for first-login, where we always want to show it.
MrPeanut’s picture

@GuyPaddock — Your patch didn't apply anymore, but I applied it manually. It fixed my issue with PRLP which I was having (like you mentioned in #2). I could then manually add info to the PRLP page. Thank you!

lukedekker’s picture

Status: Needs review » Reviewed & tested by the community

Patch from #3 applies cleanly against 7.x-1.5.

Definitely a better way of doing things and makes a lot more sense for it to work this way.

  • GuyPaddock authored 072a35e on 7.x-1.x
    Issue #2144901 by EAnushan, GuyPaddock: Logic for the Successfully...
stevecowie’s picture

Status: Reviewed & tested by the community » Fixed

This is now pushed to dev. Sorry it's taken so long.

stevecowie’s picture

Status: Fixed » Closed (fixed)