Bring back set password only option

after a lengthy discussion in IRC with webchick, i concluded that the 'set password' without automatic login option is rather useless (either don't log the user in and force them to get a pass from email, which is standard drupal login, or log them in and force them to check email to get 'normal' privs), and needs to be eliminated, so this patch will no longer apply. feel free to submit a patch to this thread which accomplishes that goal, or unassign yourself from the task and i'll take care of it. :)

i'm undecided whether i want a constant message on the user view page--i think that a drupal_set_message may be enough. in either case, that should be a seperate issue/patch.

set password only option has been removed from both 4.7 and HEAD versions of the module.

We use the set password w/o auto login, I think its useful. Our site users are regular people - non-techies. The drupal password that's sent out is difficult to use and I'm not sure how many people change their passwords after they log-in for the first time. Maybe if drupal sent people straight to the change password section the first time they log-in, it might work. On the other hand, I don't want to grant anybody any privledges until they validate themselves.

Please consider adding it back in, other folks may want to use it. I'd prefer to see the patch that allows me to re-send validation e-mails to folks who've never logged in.

it seems that the main issue being raised here is the desire for users to set their own password combined with the limited access prior to email validation. to be clear: that feature is already present--no changes are required in the code, just set up a proper pre-authorized role and it will work fine.

@aaron: i would need a valid use case for the password only option--picky clients aren't enough to get it in... ;)

my current logic is: it seems useless to make users go through the extra step of manually logging in when they will already be restricted by a properly set up pre-authorized role. if the goal of validation is to prevent bot registration, then we've already got that covered with the email validation step.

also note that the password only option is available in the 4.6 version (as i will neither add nor remove features in older versions of the module) if you're desperate for it.

marking as "won't fix" for now, but feel free to reopen if you can list some valid use cases for me to consider...

Apologize for resurrecting an old post. I have two good reasons for dis-allowing login prior to authentications.
1. I do not wish logintoboggan to touch my roles at all. I have set them up carefully using "Registration Modifier" module. This allows roles to be auto-assigned based on a "type of user" choice made prior to registration. (e.g. member or advertiser). I would prefer to simply block logins than create an extra role and try to manage which role gets set after activation.
2. (Less Importance) If a user enters the wrong email address, etc. as they go through the site it is quite possible they will not understand that they must validate, and will either receive 403 errors or think that the site is quite lacking in functionality.
As it seems that the Drupal community does not consider this to be a pressing need, I will go ahead and hack/write my own module.
Cheers.

@thekeyper:

1. what exactly are you using LT for? if all you care about is allowing users to set their own password, that functionality is already provided by Drupal core.

2. if a user enters a wrong email addy, they are screwed in a number of ways regarding site access, regardless of using this module. in all cases of user registration, a message clearly states than an email was sent to their address, so they should know something is wrong if they don't get it. furthermore, in the case of immediate login the user also sees: "In order to gain full access to the site, you will need to follow the instructions in that message." this all seems quite clear to me.

Thanks for response.

1: My reason for looking into this module was solely for the "activation link" email. Nothing else.

2. This point is not very important, and could be easily worked-around by checking for a "non-activated" user, and displaying a message at the top of every page as they browse, reminding them to login.

Looking at it, I guess this all falls a bit outside of the targeted functionality of this module. I will go ahead and do it myself. Apologies for waste of time. Marking as won't fix.

i'm still considering this request. because of the redesign of the submit handler, it might not be that hard to implement. to be clear: even if this feature is revived, the only thing it does differently is to not log the user in as part of the registration process -- everything else in the workflow remains the same.

@thekeyper: i think you might be a bit confused about how the module functions. if you want LT's validation link feature, LT _must_ touch the user's roles -- that's how it works :)

i did however recently arrange things so that the registration/confirmation redirects work even when there's no immediate login set: http://drupal.org/node/179512

combined w/ core's built in 'set own password' functionality, this gets you very close to what you're looking for, i think. what you lose is LT's pre-auth role protection against spammers, etc.

barring difficulties with the re-implementation, i've decided to revive this feature in 6.x. i won't be making any changes to either of the stable branches, so everybody is going to have to be patient. :)

1. what exactly are you using LT for? if all you care about is allowing users to set their own password, that functionality is already provided by Drupal core.

I've heard this before.

But as I understand it, users can create their own password (good) but then they're automatically considered "authenticated" (very very bad).

You'd think none of the people designing this kind of log-on process had ever used the standard procedure used on 5 million other sites: create account/choose password and then email authenticate.

This is the procedure again used on 5 million other sites.

You'd think none of the people designing this kind of log-on process had every used the standard procedure used on 5 million other sites

you have two choices here:

1. engage the code as it is now, and offer productive criticism/feedback.
2. keep comments like that to yourself, and stay out of my issue queue

Actually, bringing attention to the fact that the default sign-up procedure is completely non-standard is the very definition of "productive criticism/feedback".

P.S. Since when do people "own" issue queues?

1. what exactly are you using LT for? if all you care about is allowing users to set their own password, that functionality is already provided by Drupal core.

To take the most charitable assumption, this was at least inaccurate. Far more candid (and helpful) would have been:

1. what exactly are you using LT for? if all you care about is allowing users to set their own password [and authentication doesn't matter to you], that functionality is already provided by Drupal core.

i don't own the issue queue, but i do maintain the project.

i understand your point -- i just think you could have done a more effective job of communicating it. it bothers me when people criticize the work of the drupal volunteer community, and i believe your comment was in that vein. if you don't think it's done right in core, then write a friggin' patch, get others interested, and make the change happen.

To take the most charitable assumption, this was at least inaccurate.

try reading that sentence again. it is accurate. "and authentication doesn't matter to you" means you _don't_ care. it's actually implied by the sentence itself.

at any rate, i've already decided to re-implement the feature that is the subject of this issue queue, as i posted above.

hunmonk, please no lessons in communication. Your initial statement was incomplete and inaccurate.

End of story.

patachon: well, i've provided a valid explanation of my statement, so i'm hardly moved by the finality of your conclusion.

perhaps we should take this conversion in another direction: i'd be happy to review any patch that you write which adds logintoboggan's email validation functionality to core. i originally pushed for this when the user-generated password code went in, but it didn't make it.

you're clearly not happy with the overall way drupal's login functionality works. drupal is a community-driven project -- as such, you are one "of the people designing this kind of log-on process", as you put it. so i'm asking you to put your money (or your time) where your mouth is, and do something about it. talk is cheap, code is gold...

http://drupal.org/cvs?commit=89031

please note that i will _not_ backport this feature. it will be available from 6.x forward.

hunkmonk,

drupal 5x head patch attached.

the problem I am having with this fix is that although the user does not get logged in immediately - the account is active and the user can login to the system subsequently without the admin having to unblock them.

in the logintoboggan_user_register_submit() function. I replace.

  if ($reg_pass_set) {
    $pass = $form_values['pass'];
    $status = 1;
  }

with

  if ($reg_pass_set) {
    $pass = $form_values['pass'];
    $status = variable_get('user_register',1) == 1;
  }

i stated clearly in #20 that i will not backport this feature.

This issue touches a nerve eh ? ;-).

That is fine. I am not asking you to backport it. My comment was intended to do the following:

- the patch is here for those who may wish to patch their 5.x files
- notify you that the patch to 6.x may not be working as needed because the user can still login without needing to have their account activated - your patch only disables the automatic login but does not address the need that the user must have their account activated before logging in.

notify you that the patch to 6.x may not be working as needed

if you have discovered a bug, please open another issue, and include exact steps to reproduce it.

Actually I have the same problem, which is the user status should not be active unless he activated the account via the confirmation email.

Thanks in advance,