Notify administrator of new users awaiting approval, too!
| Project: | User registration notification |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Your code goes like this
<?php
function user_register_notify_user($op, &$edit, &$account, $category = NULL) {
switch ($op) {
case 'insert':
// Notify administrator of new user only if this is not first user and
// if visitors can create accounts without administrator's approval.
// In case when accounts must be created with administrator's approval
// there is already a 'pending approval' e-mail notification.
if ($account->uid != 1 && $account->status) {
...
?>This is fine for a site that is running with Visitors can create accounts and no administrator approval is required (although it also sends a notification when an administrator creates an account, which may or may not be desired).
However, IMO, this module is much more useful for a site that is running with Visitors can create accounts but administrator approval is required. It's true that there is a "'pending approval' e-mail notification," as stated in your comment, but that notification goes to the new user, not to the administrator! The administrator has to check regularly whether there are any new users waiting to be approved. Here's where this module could really shine, because we want to approve new users as quickly as possible, and for that we need an e-mail notification to the administrator!
For this usage, the condition has to be reversed. I'd suggest the following code to cover both cases:
<?php
function user_register_notify_user($op, &$edit, &$account, $category = NULL) {
switch ($op) {
case 'insert':
// Notify administrator of new user only if this is not the first user and
// if visitors can create accounts without administrator's approval
// or if the new account needs approval.
if ($account->uid != 1 && (variable_get('user_register', 1) == 1 ? $account->status : !$account->status)) {
...
?>
#1
I have checked Drupal 5.1 user module:
<?phpdrupal_mail('user-register-approval-user', $mail, $subject, $body, $from);
drupal_mail('user-register-approval-admin', $from, $subject, t("!username has applied for an account.\n\n!edit_uri", $variables), $from);
?>
So, user and administrator receive notifications. Am I right?
#2
Oh, yes, you're right. The site email address does receive a notification, so your comment in the code is correct.
However, I still think this module would be useful in the new-users-require-approval case because it allows specifying a different email address and a message title and body with additional fields. Supporting this case would add value to user_register_notify.
#3
salvis,
If you can give me a real world example of were this is useful I will include but to me it sounds like the admin would get 2 copies of every email that would be a pain.
thanks
Robert
#4
Here's a real world example:
Most sites use a NON-replying (:blackhole:) email address to send out notices --i.e. use an email that gets tossed away if replied to.
for example.
examplesite.com, in drupal, would have its "Site Information --> email address" set to: no-reply@examplesite.com
meaning, any email sent to this address will NOT be RECEIVED by anyone... hence, USERS WAITING APPROVAL emails will not be recieved (which gets sent out by drupal's user module to the "Site Information --> email address" )...
So as you can see, with the above scenerio, you'd have to use the "User registration notification" module to receive an email notification. (CVS; which currently is the only one that lets you customize the recipient email)
So please implement this functionality. Thanks a bunch.
-ali
#5
Prior to 5.1 release this module sent to that same address. I have added support for customizing the reply address in 5.1 and 6.0 so I can see your use I will look at incorporating that into the next release.
Thanks
Robert
#6
Well, it's been a while since I wrote that...
If I remember right, your messages are better (e.g. a mailto link). That makes your notifications much more useful than the ones from core.
#7
salvis & duntuk
I just took over the project and was cleaning up the queue I intend to make it even more useful.
Thanks
Robert
#8
I realize that I made some customizations (customizable subject and body, with a few useful variables) that I never got around to posting, because I never received a reply. Patch for D5 attached. Some points worth noting:
— condition as mentioned above
— define's compatible with D5 and D6
— $from should be sendmail_from
— drupal_mail() should be on a single line for Mail Editor compatibility
Finally, it's nice to have a Reply-To header that goes to the $to address. That way, if $to goes to multiple people (a mail group), then the first person who takes care of the registration can simply hit [Reply] to let the others know.
EDIT: There's more to Mail Editor compatibility, and it doesn't really matter here, because the patch provides its own editing, so maybe it's even an advantage to break the drupal_mail() call into multiple lines.
#9
BTW, you should have branched DRUPAL-5 from MAIN (1.4) and not branched DRUPAL-6--1 at all. Instead you should have used MAIN for D6 and only branch to get ready for porting to D7.
There's no going back now, and it's not a catastrophe, but you might do better with your next module...
#10
salvis,
I will check out your patch. As for the branch info I am really new to CVS. The quickstart guide covering CVS is what I used to get though the process. I am getting ready to do a 2.x version that integrates with actions/triggers to replace the current code base. That will be 6.x only though.
Thanks
Robert
#11
OK Patch from #8 committed to CVS. I am going to hold off since I am making so many changes until things slow down before I release.
Thanks
Robert
#12
To work on 6.x-2.x, you should copy the latest 6.x-1.x to MAIN
(this means: check out MAIN into one directory, check out 6.x-1.x into another, copy the files from the latter to the former, and commit the former)
and from that develop 6.x-2.x in MAIN, setting 6.x-2.N tags in MAIN as long as you can — essentially until you must branch away again because you want to start either 6.x-3.x or 7.x-1.x in MAIN.
Please read http://drupal.org/node/17570, too. Before you create a new branch, you must make sure that you're in the directory that has the one version checked out, from which you want to branch.
#13
(oops, sorry, our posts crossed)
Thanks for committing.
#14
salvis,
That I do. It took me a few try to get right but I have Diff. folders for D5 and D6 and D6 Version 2. I have read that section as well. I am getting used to CVS. It is good at telling you how to create a project not good at how to take over an existing project or managing a project with a simple cheat sheet. Were is cover the how not so much as the why.
Thanks
Robert
#15
I hope you don't mind that I've used your example to try to improve the CVS Quickstart Guide at #267327: CVS Quickstart Addendum. Please comment there if you can add something.
#16
anything that makes it easier for me in the end and other is always good.
Thanks
Robert
#17
Automatically closed -- issue fixed for two weeks with no activity.