add --notify option to user-create

Good concept. I think that the main flag should be --notify to enable sending email. The --message flag should allow the specific message to be selected, but should default to register_admin_created, which is almost always what you are going to want.

Follow the convention return drush_set_error(....

It is odd to see the convention where if ($message_valid) { is TRUE when $message is FALSE. The logic reads better if you just abort out with a return drush_set_error(... on invalid messages as suggested above so that you do not need to predicate user_save on $message_valid.

Oh, another thought: optional, but it might be nifty to have an option to allow the user to select which message to send via a drush_choice menu.

user-login may also have a --notify-user option.

remove various trailing whitespaces.

it looks odd to me to have both --notify and --message. it should be just one of those. if user provides no value, then we use a default. we can distinguish that from the option not being there at all (don't send any email).

the values of --message should use dashes instead of underscores. convert the supplied value to underscores in the code. this is the cli convention.

looks ok to me. anyone care to review?

Code looks good to me, although I did not test.

Regarding drush_get_option, I think that cancel should always be an option when presented a choice, and it should actually cancel the operation if selected. If your option is screwed up and you get the choice prompt, you should have the option to say "that's not what I meant at all." (Hm, current patch does not cancel -- setting to 'needs work' for that minor addition.)

If you actually want to have "no message" as an option to the call to drush_choice, just add it to the end of the drush_choice options (or maybe add it to the beginning if you want it to always have the same number). I don't think that's necessary, but it would probably be a useful enhancement.

This would be really useful for us to automate creating a standard set of users across corporate sites without having to send them a second email. :)

Could someone please test this?

Does not apply anymore.

rerolled.

I applied the patch, ran the testUser test and it passed.

I then made this change to testUser.php:

-    $this->drush('user-create', array($name), $options + array('password' => 'password', 'mail' => "example@example.com"));
+    $this->drush('user-create', array($name), $options + array('password' => 'password', 'mail' => "example@example.com", 'notify' => "register-pending-approval"));

And the test passed.

It might be my test environment, but I get an email sent to example@example.com with the status-activated email when the testUser test is run.

After applying this patch I also get another email that contains whatever the notify option is set.

Leaving at needs review.

I would rather that tests not actually generate emails. Can we add a --simulate and check the logs that the email went out. Not perfect, but better than leaving cruft in a spool somewhere.

#15 described a temporary measure done by hand to test the feature; there is no unit test code in the patch. #17 is probably the best way to create a test for this.

This issue was marked closed (won't fix) because Drush has moved to Github.

If this feature is still desired, you may copy it to our Github project. For best results, create a Pull Request that has been updated for the master branch. Post a link here to the PR, and please also change the status of this issue to closed (duplicate).

Please ask support questions on Drupal Answers.