New users are not in "blocked" status even with admin approval required

there's a very good chance this is being caused by a bug in another module. please disable all other contribs except LT and try to reproduce the problem. if it goes away, then you'll need to start enabling the other modules one at a time to find the problem one, and report the bug there.

you're assuming a workflow which does not exist. Pre-auth users *are* allowed to log into the site before they get admin approval, but they do so with the restricted permissions of the pre-auth role. This makes sense, as the access control to the site is provided at the permissions level in this case, since the user already has their password (they created it).

$reg_pass_set = !variable_get('user_email_verification', TRUE); merely checks core's email verification setting, and determines if the user is setting their own password.

When drupal core option "admin approval required" is checked, new users should be blocked (this is the normal drupal behavior),

if modules did not alter core's workflow at times, what would be the point of writing them? ;)

the entire point of admin approval in the LT workflow is removing the user from the pre-authorized role -- the pre-authorized role IS the access control in the LT workflow. if you want the user to have no more permissions than an anonymous user, set the pre-auth perms to match the anon perms. please explain to me what is gained by messing with status at this point and not allowing the user to log in. afraid your users will get confused? then put something in the admin approval email to clarify how you handle things on your site.

"everybody else does it this way" as an argument, by itself, it not enough to convince me that a change is needed here. with that logic alone, nothing new would ever happen... ;)

I also need workflow #2 in #4 above. One problem with making the assumption that a user should be Active just because they are supplying their password upfront is that the approval process gets wonky. As the site owner, when I approve someone by changing their status to a "member" role, that doesn't trigger an email to the user that they have now been accepted. Sure, I could potentially write a Rule to do that, but there are caveats with that as well and it doesn't feel right to have to use another module to makeup for this.

I would think that adding a new field to the configuration form for LT to provide an option would be the right way to go.

Sure, I could potentially write a Rule to do that, but there are caveats with that as well and it doesn't feel right to have to use another module to makeup for this.

so it's a solvable problem, great. ;)

logintoboggan has long been the default receptacle for everybody's all in one solution for core's user registration woes. as such i've become quite particular about what new features i will accept. i'm still not convinced this adjustment is needed.

Needed this functionality as well, imlpemented it as per comment #2, all works as wanted.
I mean, if this is the only fix required to do so (do not have a chance to take a look at the whole modue at the moment) why just not add cewckbox in module and check in that line if the option is selected, just set status to 0, instead of 1.

I might repeat what is already told here, but really I think this might be a very handy feature. I mean, this module is great, and thank you for all the hard work you have put into it, it adds a lot of flexibility to the drupal registration/login functionality, but if I have an option to select the "Administrator approval required" and an option "Allow user to set password during registration", I might as well have an option to not make the user active and log them in straight away.

#1178138: LoginToboggan breaks "approval is required" marked as dup of this

Sorry to be insistent

Thing is, it should not be necessary to create module that re-implements a core future. I understand the use of this feature, and it can be quite useful in plenty of cases where you want users to have immediate acces to certain aspects of the site, but you still want them to confirm the e-mail. My point is, it leaves the user/admin with no option but to deal with the fact that that is the way LT works, instead of letting you choose.

Don't get me wrong, the module is very useful, I just think it should respect the original workflow and give us the option to change it, instead of just enforcing it.

I would like to know how to deal with the following case:

- For user default settings, "Approval is required" is enabled
- Enable "Notify user when account is activated" under the "Account activation email"
- We follow the LoginToboggan practice, create a "Pending" role
- In the LoginToboggan setting, for newly created account with password, assign the default user role to "Pending"

So for any newly created account, they are in the "Pending" role. And according to "LoginToboggan practice", we restrict this user's action within the "Pending" permission. User can still login, but cannot do anything(maybe not, up to your site requirement).

However, even we change the user's role from "Pending" to "normal", this user won't receive any activation email. Because role has nothing to do with account status.

Yes, I can see there is rule for "Send a mail to a user" under the Rules' action. We may set a rule and send user's email after changing their role? But at the end we will be putting our email body under the Rule section instead of the default core section.

From comment#5, "then put something in the admin approval email". May I know how the system send approval email? Or we send it manually?

Thanks.

I find this behaviour of logintobbogan very annoying. It took me quite a time to realize, that new users aren't blocked after login, when i enable the "set password" option in logintobbogan.

It makes logintobbogan quite useless for me.

I enabled it, because I want my users to login using their email adresses and a unified login/registration form. But I also want them to set their passwort on registration (because it is a user-friendly way) and I want new users to be blocked by default (because they get a notification, that they can use their account, when I set the status from blocked to active).

I agree with the previous comments. The following scenario should be possible:

1) User may set a password during registration
2) User must confirm valid e-mail address by clicking link
3) Administrator may approve or deny account

Currently, having 1 & 3 do not allow for 2. Therefore, a user could create an account, and the administrator must choose to approve or deny the account without knowing whether or not the visitor supplied a valid e-mail address.

I don't see why setting the password on registration must result in the account being marked as active. It should certainly honor the setting in the following option:
Who can register accounts?
* Administrators only
* Visitors
* Visitors, but administrator approval is required

Whereby, selecting "Visitors, but administrator approval is required" should require both an e-mail verification, and a subsequent administrator approval.

Everytime I have to look at the logintoboggan config page, the "set password" section makes my head spin. Like @Gaara and others have said, I find it utterly confusing that site admins who want to allow people to set a password during registration have to deal with the pre-auth role feature if they do not want people to log in in the interim.

if you want the user to have no more permissions than an anonymous user, set the pre-auth perms to match the anon perms. please explain to me what is gained by messing with status at this point and not allowing the user to log in.

sorry, but this is just needless burden for site admins who have to go through all permissions, uncheck all the auth role perms because of the js script that assigns each perm of auth to all roles. This is also error prone, when there is a status flag active/blocked that just does that for you.

afraid your users will get confused? then put something in the admin approval email to clarify how you handle things on your site.

People don't necessarily think to check their email once they're browsed away from the page saying they have to check their email. They are logged in, browsing away, without knowing they are supposed to verify their mailbox.

I just don't get why a feature allowing to set a password during registration forces site admins to deal with a pre-auth role, and then have to find work arounds to prevent that feature like http://drupal.org/project/logintoboggan_prevent. IMO, there should be an option to just block the user after their register, and optionally use the pre-auth if and only if it makes sense.

The logic of LT is that if you give users the power to add their own password then there is no purpose in having administrators approve accounts. It is done simply to speed up the email verifications process like so:
1) Set your password
2) Get a temporary role
3) Confirm your email is valid
4) Become an authenticated user

If you have concerns about an authenticated user not having been approved then you could just remove most permissions from authenticated user and have a trusted user role that administrators can assign to users where a human check is needed.

So that's the current position. However, it does seem that a few people have a use case where they want a new user to be able to set his/her own password but still be blocked, so we might look at implementing that.

for the records and for anyone looking to achieve something similar: I managed to get the password on registration form + email as username but without the trouble of the pre-auth setup by getting rid of LT and simply using http://drupal.org/project/email_registration and http://drupal.org/project/user_registrationpassword.

@scor: thank you very much. Your combination is the seamless solution for me !

@ scor ,
Your solution is the ideal solution for my issue also. Thanks a lot.

@scor

:) thank you very much

it works very well

thank a lot

Dropping this module due to this "feature".

@hunmonk
Your way of changing the core's 'user_email_verfication' setting just because admins want a password to be set on registration is plain wrong.
This behavior is not a feature it is simply a bug. Let me explain why:

The whole Drupal process of registering is odd. Sending an email to the user with a link for a one time login to change a password on a page that might be stuffed with endless profile fields is not only uncommon, but also creates the need for modules like yours or the once mentioned in #15, that would get around this stupidity.

A common flow for a registration would be, to supply your user name and your email address and get send a password via email.
That way not only your email address is verified, but also you got your password.
A big but about this is, that this is not enough in some countries. You need to OPT-IN via a link in your email, which by clicking you confirm that you really WANT to have an account with the page that sent your that email.

'Til then the account is basically dead to the system, because it HAS to wait for approval to be properly used.
Since you can not prohibit the user from logging into a site from just being a special group, because there is no permission for that, you would need to handle something like that over the `status` property of the users.

Because your are overwriting the 'user_email_verification' setting, this whole process can not happen as planned, because the Drupal settings are ignored by the code that was mentioned here in #2.

I am convinced that there are use cases for both and I like your way of putting the users in another user group, too.
It is great for some communities, where you should read, but not write.
As great as it is, it is not sufficient enough to please every law in every country.

So, to prevent the pile of modules that could mess up the system from growin, I would like you to ask you to implement the following:

1. Provide an option to either let the user have a "pre-authenticated group" or to just set the status of the new user (value of 'user_register' as default). I could supply a patch for that, but since I think this should go closely with number 2, I would rather have you doing it, because you are much deeper in your code and though easily ten times faster than me.

2. Please detach your code from the core variable 'user_email_verification' and build your code upon 'logintoboggan_user_email_verification', where needed. I am not sure if this is at all possible without the help of number 1, but anyway.

What do you say?
Are you convinced now?

There is a sort of duplicate issue of this one ... #1773424: Logintoboggan breaks user_registrationpassword use cases with a patch.

Small improvement on the wordaround / patch from #2: in file logintoboggan.module, function logintoboggan_user_register_submit(), I changed the following statement:

if ($reg_pass_set) {
    $pass = $form_state['values']['pass'];
    $status = 1;
  }
  else {
    $pass = user_password();
    $status = variable_get('user_register', USER_REGISTER_VISITORS_ADMINISTRATIVE_APPROVAL) == USER_REGISTER_VISITORS;
  }

into this:

if ($reg_pass_set) {
    $pass = $form_state['values']['pass'];
  }
  else {
    $pass = user_password();
  }
  $status = variable_get('user_register', USER_REGISTER_VISITORS_ADMINISTRATIVE_APPROVAL) == USER_REGISTER_VISITORS;

The improvement over #2 is, it always honors the Drupal Core setting of who can register accounts (visitors, or visitors with admin approval). Works nicely so far, incl. an on-screen message after registration that the account is under review, and an e-mail when the account has been unblocked by an admin.

I do not require e-mail verification, so my Logintoboggan pre-auth role is simply "authenticated user". If set to something else, there would be first unblocking, then a round of acquiring more privileges by confirming your e-mail address. Should work too.

While this issue has more followers and is a bit older, #1773424: Logintoboggan breaks user_registrationpassword use cases has a patch available. The comment in #22 does almost the same thing as this patch in #1773424. Please review the patch in the related issue.

Maybe we can close this issue or close the other and upload that patch here.