Allow per-site configuration of 'Notify user of new account' default setting

@lauriii raised the question of whether this could be tied to the dev/prod toggle. I don't think it should be, because the usecase @pameeela has raised is to notify real new users via email when an account is created, but mine (from my own site-building days) is always to not notify users created by admin.

We could also use the dev/prod toggle to not send any emails from dev ever, but that's its own separate followup issue.

If anything (if we want fewer settings in the UI), I would almost make it only a site-wide checkbox, rather than a checkbox on every user creation form. That would more align with core-as-framework IMO. But that also seems like followup material to me.

@lauriii raised the question of whether this could be tied to the dev/prod toggle. I don't think it should be, because the usecase @pameeela has raised is to notify real new users via email when an account is created, but mine (from my own site-building days) is always to not notify users created by admin.

We could also use the dev/prod toggle to not send any emails from dev ever, but that's its own separate followup issue.

The email based workflow for adding new users is increasingly common nowadays. I do think we should default to that, given that how common it is. I don't even remember when was the last time I was passed a password to a product manually. I understand that some organizations may have a different workflow, but we should set the default based on what we think is the 80% use case. I don't really understand how this default would be different for Drupal CMS vs Drupal Core.

The dev/prod toggle idea I had, was to not check this automatically when working in a dev environment. That way you could still choose to sent an email in dev environment if you want to test this (or some other reason).

This could be a separate issue, but as a UX enhancement, I think we should be also be generating the password automatically.

If anything (if we want fewer settings in the UI), I would almost make it only a site-wide checkbox, rather than a checkbox on every user creation form. That would more align with core-as-framework IMO. But that also seems like followup material to me.

If we make this a site wide setting, it almost seems something that should be managed by ECA → . However, that's something for future because that would require having ECA in core.

I'm more open to that instead of a site-wide setting to control what the default value should be. That said, if we remove the checkbox, we need to make changes to this page to make it clear that an email will be sent or not depending on what the setting is.

To me, changing the default value seems like the least disruptive way forward. I'd recommend we do that and open a follow-up to move this to a global setting. Based on that, the next steps would be:

1. Change the default value to checked (this issue)
2. Add an automatic password generation (follow-up)
3. Move this to a global setting for configuring the registration flow (follow-up)

Release management hat on: Changing the default value on the form would be too disruptive. I would say that's a major-only behavior change.

I think Starshot can flip the default value from core's, and which way the default behavior goes can at least be added as a site-wide config setting. That way, Starshot and site owners could override it. I think this is potentially something where the Starshot and core framework 80% case differ.

I'd still also lean toward exposing the site-wide default in the user settings admin UI, but we can separate out that decision to a followup as well if we want. That also would give us the opportunity to deprecate a checkbox on a more frequently used form, if we want.

Release management hat on: Changing the default value on the form would be too disruptive. I would say that's a major-only behavior change.

Would it be possible to document what the expected disruption would be to see if we could find ways to address those?

I think this is potentially something where the Starshot and core framework 80% case differ.

I don't really understand how this would be different between the two? Email based sign-offs are used commonly in both, consumer and enterprise products. For sites using SSO, this would be different, but in this case humans wouldn't be even accessing this form.

This could be a separate issue, but as a UX enhancement, I think we should be also be generating the password automatically.

I'm planning to add this in Drupal CMS using https://www.drupal.org/project/genpass → for now, I tested it last week and it works well, I actually made a minor UX suggestion as a result and it's already fixed. I have a tab open for creating the issue but never managed to finish it.

This was the reason I revisited this, I felt that we should sort this out first since it doesn't make sense to generate the password and NOT send an email.

The dev/prod toggle idea I had, was to not check this automatically when working in a dev environment.

I don't necessarily think dev/prod is that relevant, if I'm making someone an account on dev I would want them to get an email too. But that's only on manual creation, not sure if we should distinguish? Meaning, if I'm manually creating an account for someone on dev, why would I NOT want them to be notified? If it's a test account I'd use my own email. If I'm making an account with someone else's email address, how would they access it without getting an email?

The main exception for me when creating accounts is that very rarely I might be setting up accounts for training or something at the end of a build, and I don't want them to get an email because I don't want them to be confused and try to log in before the training. But this is a real edge case and not a dev/prod distinction.

I don't necessarily think dev/prod is that relevant, if I'm making someone an account on dev I would want them to get an email too. But that's only on manual creation, not sure if we should distinguish? Meaning, if I'm manually creating an account for someone on dev, why would I NOT want them to be notified? If it's a test account I'd use my own email. If I'm making an account with someone else's email address, how would they access it without getting an email?

This is mainly because the emails may not be all that useful given that the user may not be able to access the site when it's in dev environment (e.g., localhost). I don't think this is that important use case at all to consider, just something that came to my mind.

I didn't really say clearly but my overwhelming preference is to change the default to on. I don't think it is very disruptive, because although it is a change, it is clearly visible on the form. I think removing the per-user option and making a sitewide setting only would be much more disruptive.

To me it clearly meets the criteria for a minor release which allows "changes to behavior that existing sites might rely on" but this is just a change of behaviour, I don't think you could say a site "relies" on this since you can select it every time.

I think maybe it isn't totally clear that this setting only applies to users created via this form, where it is presented as an option. There is no hidden or assumed behaviour change to users created via any other method, e.g. user creation from an external system (this was mentioned in a separate conversation about this).

but mine (from my own site-building days) is always to not notify users created by admin.

This definitely is an outlier for me, and if this is the case you could change the default with a few lines of code.

From my experience , when creating an account manually, it is probably 50:50 between situations, where notification email is desired and when it is not desired. I think the default off is reasonable there. The primary way to register on the site is by users themselves and there the emails are sent.

This was the reason I revisited this, I felt that we should sort this out first since it doesn't make sense to generate the password and NOT send an email.

There is a reason. Sending plaintext passwords in emails is not a good idea from the security point of view and that was a reason why core is not doing this anymore from 2010 ( #660302-64: Migration path for changed user email tokens; don't complicate translation of default messages → ). I am strongly against the idea of sending plaintext password in emails again.

Nothing about this proposal would result in passwords being sent in plain text. Not sure where you got that idea.

The email sent is a login link where you can set your own password. That would remain the same.

@pameeela Sorry I was not clear enough, but my second part of the comment was a reaction to the quoted text, but that is related mostly to a separate issue @lauriii mentioned earlier, not this change itself. It was not really clear to me, what other benefits (except that admin would not have to enter a random password) can be achieved by generating a password and sending the email vs generating and not sending it (with regards to the generation itself), if the notification email will be still the same in both cases (when password will be generated, or manually entered) - it will just contain a link to reset the password. But yes, this question belongs to a separate issue (or probably also here 📌 Automatically generate a password on user creation Active ). This issue is just about the checkbox/configuration setting.

Fair enough, to clarify, the only reason that I’m proposing generating the password automatically is that it’s required. In my proposal it would happen behind the scenes and never be available, the user would receive an email with a login link. This is what I do now, I create a random password that I never save or share with the person, they log in via the link in the email and set it themselves.

The eventual ideal for me in this scenario would be that setting a password isn’t required on account creation, if you are using this workflow.

I am not sure this is also what Lauri meant but that is what I assumed.

The eventual ideal for me in this scenario would be that setting a password isn’t required on account creation, if you are using this workflow.

This was the intention. Many platforms only ask for email (and sometimes for name) when inviting new users to the platform and expect the user themselves to fill in all required information like password when they use their one time login link. If you are using this email based registration flow, it seems completely unnecessary for the person creating the user to have to enter a password, because it would be changed by the owner of the user on their first login.

There is an older related issue which proposes to make the password field optional (when creating an account for another user) - #397846: When creating an account for another user, make password field optional → .

This is what I had in mind for the UX:

I'm thinking we could hide the status too when the user is invited to set their password. It doesn't make sense to notify the user that an account was created if the account is blocked.

Yes, this looks perfect, I think it neatly solves both use cases.

I'm thinking we could hide the status too when the user is invited to set their password.

Great idea!

I don't think this would be too disruptive for a minor release - it's only changing the default value of a checkbox on a form, not changing any other behaviour such as when users are saved programmatically. We can put it in the highlights post as a user facing change (albeit a small one) and in the release notes. We've changed significantly more in minor releases like adding publishing status to entity types etc.

Also if we look at project usage, there are only 7,000 sites on 11.0.x and 150,000 sites on 10.3.x, and 85,000 sites on 10.2.x. All of those sites are more likely to update to 11.1 than 11.0 (I know this will be what my 10.x sites do). So in practice it will be part of a major upgrade for more than 300,000 sites and part of a minor upgrade for less than 15,000.

Adding a configuration option is extra config + config schema + upgrade path etc. then maintenance over time.

I don't really understand the dev/prod toggle discussion here - sites in dev will either have broken email sending (on local) or they should be configured not to send emails at all (maillog or one of the other approaches). I do, out of paranoia, uncheck this box even if I have maillog or similar installed but that is years of superstition and past bad local development practices (and memories of before email spam checks were stricter and you could successfully deliver emails from postfix running on localhost with phpmail).

There isn't really much into it. 😅 I'm doing the exact same out of paranoia (unchecking email checkboxes on dev regardless of using MailHog), which was why I was thinking that we could consider changing the default value depending on this setting. This isn't a critical part of the issue and I think we can discuss this in a follow-up if we want to.

Thanks @catch I've updated the issue to reflect the consensus around not having a new config option for this.

And extra issue with flipping the default depending on dev/prod is that if you actually wanted to form alter to change the default, it could be very confusing that it's behaving differently on dev and prod and hard to test that the form alter worked. Given both me and @lauriii are paranoid about emails going out from localhost, maybe we should open a general issue for some minimal dev/prod email support, like config somewhere for 'don't send any emails in dev mode' which people could set in lieu of one of the other email catching solutions.

On the release management side I agree with @catch here; this is admin UI and we've made bigger changes in other areas of the admin UI in minor releases. BC policy allows us to "change [form] structures where necessary to make usability improvements or add features in minor versions" and "form classes [...] are not part of the API [...] unless specifically marked with an @api tag" - in fact Drupal\user\ProfileForm is explicitly tagged @internal.

I also would like to not add yet another config option that will rarely be changed on most sites; I think core can be opinionated here on UX and if anyone wants to change the behaviour then contrib or custom code can provide their own form or alter the existing form as they could before.

I think it would be even better if we can implement #18 here (including #19, as I thought the same when I saw the animation before I read the comment), instead of just changing the default value of the checkbox; even if the code is @internal if we can make the changes we want in one step instead of two then it will be better for anyone who is affected.

@longwave you make a very good point :) I certainly would prefer that, it would avoid a lot of other messing around, which would be a stopgap anyway. So updating the scope of this once again!

I'm thinking about the wording for the checkbox, not sure about the word "invite" because it seems vague, but this isn't needed to progress. It will always be an email so I think we can say "Email user to set a password"? ("Send user a one-time login link to set a password" is yet more descriptive, but a bit wordy.)

Thanks @catch I've updated the issue to reflect the consensus around not having a new config option for this.

Huh? When did that get consensus? I still don't agree. I suggested a config-only option, not adding it to the UI. And I still feel this is too disruptive for a minor release because your sites start freaking sending real people emails when you create accounts. Spam by accident is much worse than no spam by accident.

a form structure change that suddenly starts sending emails without warning

The form itself gives a very clear indication that an email will be sent. How could this be described as without warning?

I completely understand that people may use this form and not want to send an email. I noted a use case for this myself, but it's rare (well below 20%, using the 80% use case threshold that lauriii mentioned earlier). That's what the checkbox is for. In fact, the change to hide the password field makes it *much more obvious* that is what's happening.

I don't understand the risk aspect myself, and @catch and @longwave agree, and @lauriii agrees with the change and has proposed the UX. This seems like consensus to me, although I acknowledge I posted that before longwave replied.

For my part, it would be really helpful to understand the common use case for creating accounts this way where you would *never* want to send an email. How are folks accessing their accounts in this scenario? Is the password being shared with them by some other means? Why would this be preferred? Not saying that it's impossible or wrong in any way, I just do not have this experience so I'm not able to consider the implications.

The default state of the checkbox is not really a blocker to progressing with this issue.