Provide a mechanism for other modules to indicate an account is already validated [#463654]

If a user accepts an invitation, they have already confirmed their email address, and should not go into the non-authenticated role.

I'm working on a patch for this on our site, but wanted to post here early in case anybody had thoughts, objections, or had done this already. I'll post the patch when I have something working.

Comment	File	Size	Author
#3	logintoboggan_pre_validated.patch	2.81 KB	scottgifford

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

scottgifford CreditAttribution: scottgifford commented 15 May 2009 at 14:02

The tricky bit of this is that it sits between the Invite module and LoginToboggan. If anybody has any suggestions about the right things to hook, please let me know.

Comment #2

hunmonk CreditAttribution: hunmonk commented 15 May 2009 at 14:21

please note that i will not commit any module-specific integration patches to LT. i'm happy to adjust the API so that other modules can leverage it, but i really don't want a bunch of if (module_exists('blah')) checks in LT.

Comment #3

scottgifford CreditAttribution: scottgifford commented 6 June 2009 at 04:49

Title:	Invited users should not be put in unconfirmed role	» Provide a mechanism for other modules to indicate an account is already validated
Status:	Active	» Needs review

File	Size
logintoboggan_pre_validated.patch	2.81 KB

OK, how about this as a general mechanism?

If logintoboggan requires that the account be validated (for example because the user has already set their password), in logintoboggan_user_register_submit it will set the key need_validated in the new user's fields, and clear the field pre_validated. Other modules can set pre_validated in hook_user('insert',...) if they have already verified the user. Finally, when logintoboggan_user runs, if need_validated is set but pre_validated is not, it will add the user to the pre-authenticated role.

Once the user is created, logintoboggan_user_register_submit will check if the user already entered a password but did not end up in the pre-authenticated role, and if so will not send an email.

Here is a patch that does this. Feedback is welcome.

For this scheme to work, logintoboggan will also need to have its weight increased to be sure its hook_user runs last. This can be done in the install file, I can provide a patch if you'd like.

Comment #4

mrfelton CreditAttribution: mrfelton commented 29 September 2009 at 15:26

I have hit upon an issue that I think is related. If you are requiring that a user enter the password on the registration page, they get added in to the pre_authenticated role, and they get an email with the validation link.

If the user follows the link in the email all is cool and they get logged in and removed from the pre auth role.

However, if the user uses the 'reset password' form, they get send a one-time login link by user.module. When they click on the link, they are logged in to their account and they can change their password etc. But, they are not removed from the pre authenticated role, even though they have effectively just verified their email by clicking the login link that was sent to them by user.module.

Comment #5

hunmonk CreditAttribution: hunmonk commented 9 October 2009 at 00:19

@mrfelton: the issue you raise is a separate issue -- please open a new issue for it.

@scottgifford: couple of things:

i think i'd rather officially handle this in the Drupal 6 branch -- i have a feeling it will be easier with the FormAPI upgrades there.
the current solution you provide feels overly complicated to me. can't we just provide some override flags for LT to look for, and then make sure the overriding module is weighted before LT? a 'skip_validation_role' flag and a 'skip_mail' flag would do, yes?

Comment #6

hunmonk CreditAttribution: hunmonk commented 9 October 2009 at 00:28

Status:

Needs review

» Postponed (maintainer needs more info)

Comment #7

scottgifford CreditAttribution: scottgifford commented 12 October 2009 at 16:13

@hunmonk, you'rs suggesting some global variables to indicate this, rather than passing around the information in the form? That seems like it would be fine to me, though the current solution doesn't seem that complicated to me.

I am currently running a Drupal 5 installation, and would be happy to roll up a new patch using global variables if it's likely to be accepted. Unfortunately I do not have a Drupal 6 installation handy, so I'm not able to easily port my changes to that version.

Comment #8

hunmonk CreditAttribution: hunmonk commented 12 October 2009 at 16:46

@scottgifford: no, i was meaning just those two flags as part of either form data or user/account object data -- i believe that would work ok as long as the module in question ran before LT and was able to insert them for LT to discover.

Comment #9

hunmonk CreditAttribution: hunmonk commented 6 January 2011 at 01:34

Version:

5.x-1.5

» 7.x-1.x-dev

please see http://drupal.org/project/logintoboggan#commitment for more information on how feature requests are handled in the module.

Comment #10

steveparks CreditAttribution: steveparks commented 30 April 2011 at 09:58

Hi scottgifford,

Are you still interested in working on this functionality? If so it would be great if you could submit a patch against master, so it can be considered for the D7 branch. Otherwise can we close the ticket?

Thanks
Steve