Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hello,
When "Define password" is enabled in LT and admin approval is required in Core, new user status should be "blocked" before approval by admin.
If there are not in "blocked" status, it means new users (even if assigned a pre-authorized role) can log into the website without admin approval.
Comments
Comment #1
hunmonk CreditAttribution: hunmonk commentedthere'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.
Comment #2
syldes CreditAttribution: syldes commentedHi,
I found a workaround, in my case new user status is set to "blocked" when I set $status to 0 instead of 1 in this part of logintoboggan.module file:
In fact I don't get these lines:
Could you please tell me what are the settings leading to $reg_pass_set == 1, thus overriding site default ?
Comment #3
hunmonk CreditAttribution: hunmonk commentedyou'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.Comment #4
syldes CreditAttribution: syldes commentedHello,
I'm sure you'll agree with my description of 2 typical registering worflows over websites :
It is fine having LoginToboggan having more registering features than described previously, but I expect also LoginToboggan to be able to reproduce workflow number 2, which is currently not possible without manual patching.
In my opinion the current LT registration behaviour is flawed when approval is required :
- When drupal core option "admin approval required" is checked, new users should be blocked (this is the normal drupal behavior), whatever configuration LoginToboggan has. At this time this modification of default drupal behavior is not explained anywhere in LoginToboggan UI. In my opinion you should not change the default drupal core's assigned status, or at least describe this change somewhere in the UI.
- The only thing administrators want from non-yet approved users is that they can't login. This is a duplication of effort to have a "pre-authorized" role which mimics an anonymous or blocked user, and this can be tricky (Organic Groups may be hidden to prevent membership requests, and so on...).
A workaround would be the possibility to select "Anonymous" as the "Pre-authorized" role. Or simply leave the default $status untouched.
Thanks for this module and please consider those feature requests.
Comment #5
hunmonk CreditAttribution: hunmonk commentedif 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... ;)
Comment #6
capellicI 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.
Comment #7
hunmonk CreditAttribution: hunmonk commentedso 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.
Comment #8
centas CreditAttribution: centas commentedNeeded 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.
Comment #9
jm.federico CreditAttribution: jm.federico commented#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.
Comment #10
franfran CreditAttribution: franfran commentedI 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.
Comment #11
a.siebel CreditAttribution: a.siebel commentedI 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).
Comment #12
jbova CreditAttribution: jbova commentedI 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.
Comment #13
scor CreditAttribution: scor commentedEverytime 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.
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.
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.
Comment #14
stevecowie CreditAttribution: stevecowie commentedThe 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.
Comment #15
scor CreditAttribution: scor commentedfor 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.
Comment #16
kle CreditAttribution: kle commented@scor: thank you very much. Your combination is the seamless solution for me !
Comment #17
dilanke.kumara CreditAttribution: dilanke.kumara commented@ scor ,
Your solution is the ideal solution for my issue also. Thanks a lot.
Comment #18
stomerfull CreditAttribution: stomerfull commented@scor
:) thank you very much
it works very well
thank a lot
Comment #19
infojunkieDropping this module due to this "feature".
Comment #20
func0der CreditAttribution: func0der commented@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?
Comment #21
helmo CreditAttribution: helmo at Initfour websolutions commentedThere is a sort of duplicate issue of this one ... #1773424: Logintoboggan breaks user_registrationpassword use cases with a patch.
Comment #22
tanius CreditAttribution: tanius commentedSmall improvement on the wordaround / patch from #2: in file
logintoboggan.module
, functionlogintoboggan_user_register_submit()
, I changed the following statement:into this:
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.
Comment #23
Rob C CreditAttribution: Rob C commentedWhile 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.