Jump to:
| Project: | Register Pre-approved |
| Version: | 6.x-1.1 |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
Hi- This module fits the bill for me perfectly-- thanks for sharing: I am changing a site to whitelist some emails on registration (pass through), blacklist other specific ones (prevent registration), and hold all other non-matches for administrator approval.
However, when I register with a whitelisted email, I see the message:
You have been pre-approved and granted access to SITENAME.
Thank you for applying for an account. Your account is currently pending approval by the site administrator.
Once it has been approved, you will receive an e-mail containing further instructions.
on screen, the admin gets a notification, and the email registered gets a "pending admin approval" message. Clicking in to edit the user does in fact show Status: Active.
My settings under Public Registrations (admin/user/settings) is Visitors can create, but admin approval required and Require email verification is checked.
Did I miss something?
Comments
#1
Register Pre-approved is primarily designed to automatically assign roles for white-listed email addresses and domains with registration settings "Visitors can create accounts and no administrator approval is required." and "Require e-mail verification when a visitor creates an account." This way, once the user verifies their email address, they're free to login with whichever pre-assigned roles.
The setting "Visitors can create accounts but administrator approval is required." kind of defeats the purpose of the module because the admin is forced to manually approve the accounts and optionally assign roles. However, I understand why you would assume it should work the same way with this setting.
I'm willing to consider ways to make it more flexible. Thoughts?
#2
Well, I was banging my head wondering why there were both DENY and ALLOW rules under Access Rules if they didn't fit _my_ desired use case :) Before I found your module, I thought about going down the route of writing this little interpretation of mine as a module: perhaps, to make it clearer, even adding an additional Public Registrations option "Administrator approval required when Access Rule not matched" or something.
On the surface, I think that's as plain jane simple as I require, but whether it's an appropriate ship's course change for your module or whether I would know how to hook into what to make it happen, I don't know. Of course _I_ find it relevant, but whether it would either make sense or be of use to anyone else, I dunno. I imagine it would.
#3
John-
I am looking for a place to "hook in" to disable the admin authentication when, using your Register Pre-Approved module, a registrant's email address matches the pre-approved. Looks like the check is performed in user.module:user_register_submit():2417, as an else fallthru case:
<?php
else {
// Create new user account, administrator approval required.
_user_mail_notify('register_pending_approval', $account);
drupal_set_message(t('Thank you for applying for an account. Your account is currently pending approval by the site administrator.<br />In the meantime, a welcome message with further instructions has been sent to your e-mail address.'));
$form_state['redirect'] = '';
return;
}
?>
This If's are all based on the various settings on the page.
Only thing I can think is to perhaps temporarily override the user_register to 1 ("Visitors can create accounts and no administrator approval is required."), let user_register_submit happen, and then immediately set it back to whatever it was.
It's a conceptual hack, but if it can be done outside user.module, it at least wouldn't be a core hack! :) Any thoughts on this?
#4
..and I've reread your original reply above again: Is there any purpose of Register Pre-Approved other than to automatically apply a role to pre-approved accounts with matching emails?
#5
John-
I've made a couple changes to your module to suit my needs and will upload a patch for your consideration once it's made a little friendlier. It hurts to go making cvs patches with git so close on the horizon, eh? ;)
-Bronius
#6
@Bronius,
Thanks for taking the time. I'm curious to see what you've done.
Thanks,
John
#7
Gladly-- but please stand by.. Turns out a lot of my theory was working well until I realized that Logintoboggan was actually replacing the core user_register_submit handler (which is pretty cool that we can do so), and I have slipped further back into the rabbit hole. I don't want to post anything until it is known to work as intended, probably both with Core and Logintoboggan.
-Bronius
#8
John (and anyone else)-
I abandoned looking for an elegant solution to meet everyone's needs (based on my use case). If you are interested in hearing more, feel free to comment here if it's relevant or hit me with a direct message. I would, however, like a quick code review if you have any better ways to achieve my heinous hack, whether I'm introducing session mem leak or..?
The Problem: I needed to be able to whitelist/automatically activate some emails and queue others for admin approval. Unfortunately, core user_register_submit (user.module) relies on specific User Settings in its conditional logic as to when it will send email notifications, and LoginToboggan completely replaces the user_register_submit and exhibits the same rigid (and just as confusing!) logic.
The Solution: Set a flag when register_preapprove performs a pre-approval and check for it in account registration process. I hacked two modules in a most tiny, innocent manner:
register_preapproved.module:register_preapproved_user:~513:
append
$_SESSION['whitelisted'] = $account->uid;flag to make:<?php// grant access regardless of user registration settings (admin/user/settings)
// forcibly set account status to active because it's not possible in user_save()
db_query("UPDATE {users} SET status = 1 WHERE uid = %d", $account->uid);
$_SESSION['whitelisted'] = $account->uid;
?>
logintoboggan.module:logintoboggan_user_register_submit:~380:
<?phpif (variable_get('user_register', 1) == 1) {
?>
becomes
<?phpif (variable_get('user_register', 1) == 1 || ($_SESSION['whitelisted'] == $account->uid)) {
?>
This flag is set per registration session and is checked in the registration portion that determines whether or not the system preference variable (user_register) is set to "Allow Users to Create Accounts and no admin approval is required."
Conclusion: Don't do this. Not only is it reckless to hack contrib modules, in this case, it's even worse bc the hack has a two-module dependency, both otherwise unrelated to each other. Probably the best solution is to develop a hybrid new module, clutter contrib, and buy these real superstars some beers.
-Bronius
#9
Hi Bronius,
I haven't closely looked at the user registration related code since releasing this module over a year and a half ago, but I seem to remember it being pretty rigid and not easy to override.
Let's backup and reiterate your objective: to grant instant access to white-listed email addresses when using the user setting "Visitors can create accounts but administrator approval is required." therefore skipping manual approval. Is this correct?
If so, is this something that can be accomplished with a subsequent call to user_save in hook_user? Or perhaps with another "forcible" database update?
John
#10
John-
Yes, you've got that part of the objective correctly stated.
The problem I encountered using any core (or logintoboggan-overridden) functionality is that once core thought it should notify admin for approval, admin was already notified: I couldn't pop the stack of notifications nor unsend emails. These things happened because they fell through the rigid conditional logic as in #3 above. I would like to have created (and in fact tried this too) a simple 4th option: "Administrator approval required for valid emails not whitelisted", but again, core logic falls through to the "else" case and doesn't allow for a test of that 4th radio button for user_register on the User Prefs page. Once it hits that part of user_register_submit (or the equiv in LT), the system has already sent out the Admin Approval email(s) and drupal_set_message notified the user onscreen.
That wasn't a really clear reply-- sorry :) For now I am going with the hack: it's a simple <5 line diff in all, and it appears to be working. The developer in me wants to derive a better solution, but I just can't see it.. And certainly not an encompassing solution for both core user.module and overridden logintoboggan.module.
-Bronius
#11
Sorry for the delayed response.
I'm glad you got it working the way you needed. I think for your particular requirement you don't have any other choice than to modify the modules to suit your need.