Opened 3 years ago

Last modified 2 years ago

#11297 new enhancement

Don't email the admin when he creates a user from the backend

Reported by: caesarsgrunt Owned by:
Priority: low Milestone: Future Release
Component: Users Version: 2.9
Severity: minor Keywords:
Cc:

Description

I just created the user myself. I already know I did it. I don't need to be told again.

Emails should only be sent to the admin when a user registers themselves (if that is enabled). They shouldn't be sent when the admin manually creates a new user.

Attachments (1)

11297_wp_new_user_notif-context.patch (1.5 KB) - added by nacin 3 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 follow-up: ↓ 7   nacin3 years ago

What about a site with multiple admins? More importantly, the admin_email isn't tied directly to a user account, so you'd have to compare the admin_email with the current user email, that way if the admin_email isn't the current user's, it can still be sent.

Perhaps wp_new_user_notification, as a pluggable function, could use an extra parameter specifying whether it came from wp-login.php or wp-admin?

See also #11210.

  • Keywords reporter-feedback added
  • Type changed from defect (bug) to enhancement

Recommend closing as won't fix at this time.

Consistent, low friction... also as nacin describes "multiple admins" -- blog owner/admin is weak concept in WordPress. I don't think we should tweak it.

Functions are already pluggable.

PS. caesarsgrunt, please always include your specific build when setting the version to the current trunk version.

comment:3 follow-up: ↓ 4   nacin3 years ago

Seems like wontfix, though the attached patch might not be a bad idea.

comment:4 in reply to: ↑ 3 ; follow-up: ↓ 5   lloydbudd3 years ago

  • Priority changed from normal to low
  • Severity changed from normal to minor

Replying to nacin:

Seems like wontfix, though the attached patch might not be a bad idea.

nacin, maybe throw the patch in it's own ticket, describing that solves the problem of being able to filter based on $context.

comment:5 in reply to: ↑ 4 ; follow-up: ↓ 6   nacin3 years ago

Replying to lloydbudd:

nacin, maybe throw the patch in it's own ticket, describing that solves the problem of being able to filter based on $context.

I could, but this patch would directly facilitate a solution for this via a plugin. A new ticket here just bloats Trac IMHO.

comment:6 in reply to: ↑ 5   lloydbudd3 years ago

Replying to nacin:

Replying to lloydbudd:

nacin, maybe throw the patch in it's own ticket, describing that solves the problem of being able to filter based on $context.

I could, but this patch would directly facilitate a solution for this via a plugin. A new ticket here just bloats Trac IMHO.

Which ever you prefer.

A concise problem + solution makes it easier for other to find, and encourages by example well written ticket submission.

comment:7 in reply to: ↑ 1   caesarsgrunt3 years ago

Replying to nacin:

What about a site with multiple admins? More importantly, the admin_email isn't tied directly to a user account, so you'd have to compare the admin_email with the current user email, that way if the admin_email isn't the current user's, it can still be sent.

Well, perhaps we'd also have to change that to fix this (and #11277).

I'm not sure if the email needs sending even in the event of multiple admins, but i it does then perhaps we could do it by either (a) checking the addresses and not sending to the address of the current user, or (b) removing the admin email field in Settings and emailing each admin instead using their profile email address. This is tidier anyway; having the same data in two places is redundant.

Replying to lloydbudd:

PS. caesarsgrunt, please always include your specific build when setting the version to the current trunk version.

I do when it's relevant, but in this case it isn't really. I can anyway if you like... (FWIW, this still applies in 12312.)

  • Keywords reporter-feedback removed
Note: See TracTickets for help on using tickets.