I'm not sure whether this is a bug, or by design, but I find it puzzling either way:

I have a Drupal 5.15 site with logintoboggan 5.x-1.3 installed. On the admin/user/settings screen, if I choose the registration option:

* Visitors can create accounts and no administrator approval is required.

and leave the

"Require e-mail verification when a visitor creates an account"

box UNchecked,

I find on the /admin/user/logintoboggan form that "Set password & Immediate login" is checked; the user gets logged in immediately, but they still have to verify their email address, which is clearly not what I want if I unchecked the e-mail verification box on the User Settings form.

The inverse is also true; if I uncheck "set password and immediate login" box on the Logintoboggan form and switch back to the user settings form, I find that the "Require e-mail verification" box is checked again.

Is this by design? Does logintoboggan completely remove the ability to allow users to register and set their own passwords without e-mail verification?


tbartels’s picture

The description under the Logintoboggan "Set Password & Immediate Login" tells you that the checkbox is merely a mirror of the email verification box on the User Settings form. So yes, checking one is going to alter the other.

This will allow users to choose their initial password when registering (note that this setting is merely a mirror of the Require e-mail verification when a visitor creates an account setting, and is merely here for convenience). If 'Set password & Immediate login' is selected, users will be assigned to the role below and logged in immediately. They will not be assigned to the "authenticated user" role until they confirm their e-mail address by following the link in their registration e-mail. It is HIGHLY recommended that you set up a "pre-authorized" role with limited permissions for this purpose.
NOTE: If you enable this feature, you should edit the user e-mail welcome message--more help in writing the e-mail message can be found at LoginToboggan help.

I believe what you are looking for is just underneath where it says: Non-authenticated Role. If you set the non-authenticated role to "authenticated user" you essentially bypass the verification process, I guess you would still have to deal with the welcome email not being sent(if that's what you want), but that shouldn't be too hard.

nextpulse’s picture

I had the same issue on D6. I think this is actually a bug.

If the email verification box is unchecked for registration - it means NO verification is needed.
The role in Logintoboggan is set to 'authenticated'.
BUT Logintoboggan still displays the re-send validation-email info on the my account page: this is incorrect - since the user is already verified/activated and has the role 'authenticated'.

the offending piece of code:

if (!variable_get('user_email_verification', TRUE) && array_key_exists(logintoboggan_validating_id(), $user_edit->roles) && variable_get('user_register', 1) == 1) {

I changed the:
if (!variable_get('user_email_verification', TRUE)
if (variable_get('user_email_verification', TRUE) //so if email verification is needed - then display the links

tbartels’s picture

Yah, I actually have a fix for that:

line 891:

    // User is editing their own account settings, or user admin
    // is editing their account.
    if (!variable_get('user_email_verification', TRUE) && array_key_exists(logintoboggan_validating_id(), $user_edit->roles) &&
        !array_key_exists(DRUPAL_AUTHENTICATED_RID, $user_edit->roles) && variable_get('user_register', 1) == 1) { 
      // User is still in pre-authorized role; display link to re-send e-mail.
      $form['revalidate'] = array(
        '#type' => 'fieldset',
        '#title' => t('Account validation'),
        '#weight' => -10, 
      $form['revalidate']['revalidate_link'] = array(
        '#value' => l(t('re-send validation e-mail'), 'toboggan/revalidate/'. $user_edit->uid),
      return $form;

and if you are picky you may want to set the perms on the re-send url as well

line 469:

    //callback for re-sending validation e-mail
    $items[] = array('path' => 'toboggan/revalidate',
      'title' => t('Re-send validation e-mail'),
      'callback' => 'logintoboggan_resend_validation',
      'callback arguments' => array(arg(2)),
      'access' => ($user->uid == arg(2) && !array_key_exists(DRUPAL_AUTHENTICATED_RID, $user->roles)) || user_access('administer users') ,
      'type' => MENU_CALLBACK,

I can make a patch if anybody really wants it, but you can just as easily hide it in your theme as I'm not really sure Logintoboggan was intended to be used in this fashion. /shrug

SocialNicheGuru’s picture

a patch would be great.

are #2 and #3 needed to solve this issue or either or?


nextpulse’s picture

mine (#2) was a quick and simple one line fix - it resolved the issue for me - not sure if there are side effects.

hunmonk’s picture

Component: Miscellaneous » Code
Category: support » bug

i though the logic there was ok, but i'll have another look at it.

hunmonk’s picture

Title: Unchecking "Set Password & Immediate Login" checks "Require E-mail verification" on user settings screen, vice versa » re-send validation link always appears if non-authenticated role is set to auth user
Priority: Normal » Minor

I changed the:
if (!variable_get('user_email_verification', TRUE)
if (variable_get('user_email_verification', TRUE)

this is not the correct fix -- we want to display the re-send validation link if that variable is set to false. false means no core email verification, which means they're setting their own password and receiving a validation email. confusing, i know... ;) core's idea of email verification and LT's idea of email validation are very different, but because we leverage the core user login block, we have to use that setting so we know what's going on.

the real problem here is that we should also be checking to make to see if the non-auth role is set to authenticated user, and skipping the link display if so.

hunmonk’s picture

Status: Active » Fixed

committed a fix to 5.x-1.x-dev, 6.x-1.x-dev, and HEAD.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.