Send New User Approval Email After Approval

I think thats a great contrabution, simply a better system. Is there any chance this will work with 4.6.6?

Thanks

There is already a module that handles this situation and does it in a more general way - i.e. it notifies the user after any change in status:

http://cvs.drupal.org/viewcvs/drupal/contributions/modules/user_status/

alans - does your patch/module behave differently enough that you think it should be included in core instead of just using user_status

alans,

Thanks for the thorough explanation and, of course, for the ideas you have and the code you have written.

I definitely agree with you that a "pending" status is a good idea. I would like to see that added to core. When a new user signs up they get added to "pending" and then can be moved to "active" or "blocked" after that, but "pending" is the initial state that users get into when they first sign up and are waiting for approval. That makes sense to me.

I think that the best way to progress at this point is as you have described

1. create a patch against CVS-HEAD that will create the pending status and attach it to a new issue that is related solely to that
2. create a patch against user_status to implement any features you see that are lacking from it
3. close this issue

Again, I think your ideas are good and (for what it's worth) I will +1 them when I see the separate issues.

This is exactly the functionality that I am looking for. Is there a version of this that works with 4.7.2?

This patch needs to be updated to cvs because 4.7 branch is now closed to new features.

anupam96 - the module you desire is here: http://drupal.org/project/user_status

I'm tempted to call this a bug. If Drupal is misleading users into thinking they have an approved accound when they don't, then this would be a bug and we shouldn't depend on some contributed module to do it.

The user_status module is a nice to have and does not satisfy my need. This module is exactly what I'm looking for.

Does anybody have this working in 4.7?

i've never had a need to use the admin approval feature for registrations until now.
and upon realizing how drupal handles this, i was not happy.

so i agree and also would call it a bug, albeit a bugfix that will result in a new feature ;)

side note:
i am experimenting with the invite module.
so i am also going to want to revise that module (and prob a bit of core) so drupal can optionally have registrations disabled *unless* it is by invite.... and not needing admin approval if invited.
this allows for a trusted ecosystem.

Here's a rerolled version of the patch. This patch was badly out of date and I don't think it would have worked for the version it was intended to patch.

I've changed that status to bug, since I agree that it is a bug. Sending an email containing a username and password to a user very poor user design and will confuse users, even sophisticated ones who are in a hurry. On top of that, if the admin doesn't get around to approving the account for a couple days, the email that contained the username and password will be hopelessly buried.

Can this patch also handle better the problem of spam registration?

Spam Robots register fake accounts everywhere they can, using fake emails. They crawl the net looking for registration forms. Spammers don't care if 99% of accounts created by their robots lead to nowhere, as long as 1% (or 0.1%) of the accounts are properly created with their spam links.

This is relevant to this patch, because it is crazy to ask the admin to guess whether the user accounts created are fake or bona fide: the admin shouldn't have to make a decision to authorize users until the user has confirmed that the email is valid.

So, the workflow should be this way:
1) user (spammer?) creates account.
2) email is sent to verify that their email is not fake.
3) user reply, thereby proving s/he's not a robot :) AND that the user didn't make a mistake/typo when entering their email.
4) Only now does the admin become aware of the new account. She can decide to approve the account or not.
5) if approved, the welcome email is sent.

I am tempted to mark Patch needs work for that.

Head has this problem, too: I would have preferred a patch against cvs first.

@beginner

I think a captcha would better filter out users as you suggest. After all, it's not difficult for a spam robot to "reply" to an email sent.

Also, if the administrator is going to be screening incoming user accounts, he is probably only going to allow specific or particular kinds of individuals in. His criteria is not "is this a real person?" His criteria is, "Do I know this person?" or "Do I want this kind of person in?" The administrator would probably use profile data filled out at the time of registration to make his decision.

It probably would be a good idea, however, to at least send some kind of confirmation email to the person to let them know that their account is awaiting approval. That will also give them some positive confirmation that the email address they supplied is valid. That said, I think it's somewhat unlikely that a user who enters their email address incorrectly and then does not receive the confirmation email will put 2 and 2 together and figure out they entered their wrong email address. Most will not realize they were supposed to get an email (because they ignored the message posted to the screen) or they will think that the technical problem is on the server's end, not theirs.

I found a few issues with the latest patch posted here. Here are my patches since applying that patch:

We want to send the text and subject from the 'Approved' template, not the 'Welcome' template, otherwise the user module settings page is misleading regarding the 'Approved' template:

-      $subject = _user_mail_text('welcome_subject', $variables);
-      $body = _user_mail_text('welcome_body', $variables);
+      $subject = _user_mail_text('approval_subject', $variables);
+      $body = _user_mail_text('approval_body', $variables);

For some reason I don't yet understand, user_register global was not set. I'm not sure if defaulting to two is right either, but it was the only way I could get the patch to work in 4.7.2:

-    $status = variable_get('user_register', 1);
+    $status = variable_get('user_register', 2);

Also the subject of the email sent notifying the administrator that she has a new pending user needs fixing. While I agree it should be settable in the user.module settings, using one of the existing template subjects is misleading...

-      $subject = _user_mail_text('approval_subject', $variables);
-      user_mail(variable_get('site_mail', ini_get('sendmail_from')), $subject, t("%u has applied for an account.\n\n%uri", array('%u' => $account->name, '%uri' => url("user/$account->uid/edit", NULL, NULL, TRUE))), "From: $from\nReply-to: $from\nX-Mailer: Drupal\nReturn-path: $from\nErrors-to: $from");
+      user_mail(variable_get('site_mail', ini_get('sendmail_from')), t("New pending user needs your approval"), t("%u has applied for an account.\n\n%uri", array('%u' => $account->name, '%uri' => url("user/$account->uid/edit", NULL, NULL, TRUE))), "From: $from\nReply-to: $from\nX-Mailer: Drupal\nReturn-path: $from\nErrors-to: $from");

I think you are on the right path with your proposed changes and that they will make drupal's user experience even more friendly and intuitive. Thanks!

Oops my secondary patch file wasn't attached to my message. If anyone is interested you can apply this after applying the previously attached patch. This has been tested on 4.7.2...

This is cool, and has long been a pet peeve of mine that Drupal doesn't work this way. Unfortunately, however, it's a new feature, and features only go into the CVS version. Any chance you could do a re-roll for HEAD?

@webchick - fwiw, steve dondley marked it as a bug and aimed it at 4.7.

I would love this patch ported to 5.1. The behavior is still wrong and the user registration notify module does not fix it. Users should NOT get an email with their password until AFTER an administrator has approved the account (if that is the way it is set up).

I agree this is a bug, but with my lack of php knowledge cannot fix, is anyone working on this for 5.x?

In #12, beginner wrote:

Can this patch also handle better the problem of spam registration?
...it is crazy to ask the admin to guess whether the user accounts created are fake or bona fide: the admin shouldn't have to make a decision to authorize users until the user has confirmed that the email is valid.

So, the workflow should be this way:
1) user (spammer?) creates account.
2) email is sent to verify that their email is not fake.
3) user reply, thereby proving s/he's not a robot :) AND that the user didn't make a mistake/typo when entering their email.
4) Only now does the admin become aware of the new account. She can decide to approve the account or not.
5) if approved, the welcome email is sent.

In #13, Steve Dondley wrote:

@beginner

I think a captcha would better filter out users as you suggest. After all, it's not difficult for a spam robot to "reply" to an email sent.

How about using a clickable link in the initial email to confirm that the user's email account is real. That would prevent bots from simply being able to send a reply and fake their way in. Of course, that first email should not contain a username and password, nor a one-time login link. Just a "Please confirm that you're a human by clicking this randomly-generated link, and we'll approve your new account for you". I would rework Beginner's flowchart like this:

1) user (spammer?) creates account.
2) server generates an email containing a random hyperlink to verify user's email address is not fake.
3) user clicks the random link, thereby proving s/he's not a robot, and is shown a "Your account is now pending" page on the originating website.
4) now that the account is in Pending status, the admin is notified and approves it.
5) once approved, a welcome email is sent that contains the user's minty fresh password.
6) if the account is not approved within a preset timeframe of 48 (or ??) hours, another email is generated for the expectant user that informs them they've been denied and must re-apply if so desired.

The most important thing to consider from a new user's perspective is that they're already jaded, they half-expect your registration process to screw them over somehow, and since they've already confirmed to this bloody website that they have a valid email addy, they're expecting a password email or a denial email within about 6 minutes. Making them wait for an eternity and never hearing anything good or bad from that website is bad business.

Senpai, the whole purpose of having an administrator approve accounts is to weed out unwanted users. There is no need to have a computer send any kind of link at all.

Steve, the point is to lessen the administrator's work load by letting the system and the user perform a basic email check first.

@beginner, I offer the following reasons for voting against the proposed challenge emails:

1) A bot can register for a Drupal account using a valid, working email address acquired from some fly-by-night email operation which gives them out for next to nothing. It's then a trivial matter to program the bots to visit the link in the challenge email. So, the challenge emails are easily circumvented and don't really solve anything.

2) I don't think of it as helping the administrator, I think of it as placing more burden on the user. This feature would create an extra step for users. Why bother the user with unnecessary hassle and complication?

3) If you really want to block out bots, captchas are a more user-friendly way of screening them out. Perfect, no. Better than email confirmation? IMO, yes. They work great for me, particularly my own custom questions using the "riddler" module.

4) Many more things can go wrong using an email challenge than with a captcha. For example, the email can get caught up in spam filters, or the email just plain getting lost in the cloud or missed by the user.

5) If an administrator chooses to review accounts before making them active, they already know they are getting themselves into some administrative overhead. Besides, how much work are you really saving administrators? Screening out bots isn't very time consuming, maybe 5 min. per day at most.

6) A human will do a far superior job of determining who is real than a challenge email can. For example, what if a user makes a typo in their email address, let's say email@yagoo.com. The challenge email will never be seen by the user in this case. But a human could recognize that the user is valid from other hints in the registration form.

So, for now, I remain staunchly against any use of challenge emails.

Then the question is why is that a core option (to approve accounts) in drupal.

Some people use their drupal system for friends and family. That way, people can choose to sign up. If you recognize them, then you approve. I do this with our cub scout pack.

to #21 I agree a captcha would be the best spammer filter, however the current system can also work if admin approval is required to access anything meaningful. For example

new user could register and be verified (either by e-mail or with a captcha --preferred). the user is blocked until admin review, or assigned to a very limited/ restricted role.

The problem comes when admin assigns a role or activates an account, there is no option to send (resend) any welcomer e-mail.

A patch was developed (see http://drupal.org/node/76150) for 4.x but it hasn't been ported to 5.x.

I've made the changes necessary to Drupal 5.1 user module so that if admin approval is required for new users then:

1. Admin is sent a mail when a user registers
2. User is sent a mail when the admin approves (using the welcome email template)

Additionally the changes include:

1. Bulk user acount activation in the user admin screen
2. Bulk block works with both active and pending accounts
3. Bulk unblock only works with block accounts

All the changes I've made are marked with a //UP comment.

A) Feature requests aren't going to go into 5.x or 4.7.x, so you can give up on that.

B) In 5.x and 4.7.x, this problem is solved via the User status contrib module, which allows you to configure automated emails when an account is approved.

C) User status already moved into core for 6.x and beyond, so this is no longer a problem (http://drupal.org/node/144859).

Hence, won't fix.

Cheers,
-Derek

My question is why is this patched version is not on applied to the user modul page?
1. The regular version is missleading, the admin only finds this bug upon testing. On the settings page there is a text box for the Subject of welcome e-mail (user created by administrator) so it is very logic to think that it works correctly.
2. I had to look for this solution for more than 1 hour.

Anyway thanks for the contribution Alex!

Regards,
Gabor

Because these are new features that might break existing sites, hence, Drupal core won't see them in the stable versions (5.x and 4.7.x). Futhermore, because the problem is already solved in 6.x in core, and in 5.x and 4.7.x via the contrib module I mentioned above in comment #28. Yes, it's too bad it's not as easy to find http://drupal.org/project/user_status for sites requiring admin approval, but there's not a whole lot we can do about that. Sorry.

and see http://drupal.org/project/user_register_notify

And http://drupal.org/node/195581