In config.xml, change default to 0.

		<field
			name="sendpassword"
			type="radio"
			label="COM_USERS_CONFIG_FIELD_SENDPASSWORD_LABEL"
			description="COM_USERS_CONFIG_FIELD_SENDPASSWORD_DESC"
			class="btn-group btn-group-yesno"
			default="1"
			>
			<option value="1">JYES</option>
			<option value="0">JNO</option>
		</field>

Update the sample data: "sendpassword":"1"

Done thanks @Quy

Afaik, currently passwords are always sent when the user is created by the admin in backend, no matter what the setting is. Currently if the password is empty a random password is generated and sent to the user. The admin has no knowledge of the generated password and the password itself isn't a "default" password the admin always uses for new users.
So making the password required in the backend could actually be less secure in the end. :)

Similar too all services out there not sending the PW out too.

Changing the default to not send the password if the user has self-registered in frontend is fine and is the use case of most services out there.
The creation in the backend however isn't comparable to those services because I doubt Facebook does create many accounts themself for the users (yet g). And if they do they would need a way to let the user know which password they defined. I doubt they're phoning you or sending a letter. They would send it by email as well.

So keep that in mind 😄

Afaik, currently passwords are always sent when the user is created by the admin in backend, no matter what the setting is.

Fixed with the last commit. Thanks for the hint.

The creation in the backend however isn't comparable to those services because I doubt Facebook does create many accounts themself for the users (yet g).

Sure FB don't do this and also for Joomla this should be not the normal use case. If that is required the user can still enable that option in the backend. As i have not removed it completely. But I guess we agree to not send the plain PW via a mail should be the default. So this just protect any new installation.

And if they do they would need a way to let the user know which password they defined. I doubt they're phoning you or sending a letter. They would send it by email as well.

They would tell me please reset the PW via the PW reset feature. Done.

I am 100% in favour of this for signups from the front-end
I am 100% against applying this to the back end

Applying it to the backend will men that either people will disable this functionality completely and/or they will send the password by other plain text methods. So instead of hardening the system you would be weakening it.

Just reverted the last change. Thanks for your suggestion.

I'm with Brian here. When a user is created from backend, the PW has to be sent with the email always. Every other option is either less secure (eg admin sets password manually always to "summer") or awkward (eg having to use reset password feature).
What I usually do is let Joomla generate a random password that gets mailed to the user, but I also set the account so it needs a password change on first login. So even in case the email is intercepted, the password would be either useless (since user already changed it) or worst case the user is locked out and contacts admin (if account already compromised and PW got changed).

Pushed thanks @Bakual I'm going to prepare a PR against 4.0-dev when this got merged. I think we are good to get some testes here now? Would be great 👍

I have tested this item ✅ successfully on 66c03f1

I have tested this item ✅ successfully on 66c03f1

The only thing I've found while testing is description for "Notification Mail to User" in plugin "User - Joomla!" which is not always correct:

"When an administrator creates a user account, this determines if an email, which has their username and password, is sent to the user."

Should be another PR if wanted to clarify the description!

"When an administrator creates a user account, this determines if an email, which has their username and password, is sent to the user."

This is still correct for the backend. The option here only affects the frontend for now. Thanks for testing!

Ready to Commit after two successful tests.