Allow Admin-users set username while user creation

I agree this would be a helpful, but minor option.

Still, I think there should be a description letting the (admin) user know about this behavior. And please provide the changes as MR.

This also needs to be described in the description of the field, I think!

So needs work and needs tests. Happy to review a complete MR.

I am not entirely sure, why we even have this logic in place... doesn't make sense to me. We have two different logics for generating the username:

• The one mentioned in this issue executed through "email_registration_form_user_form_alter()", which will generate the username through 'email_registration_' . \Drupal::service('password_generator')->generate();.
• The one executed through email_registration_user_insert() run through "email_registration_strip_mail_and_cleanup()" which will generate a unique username from the user mail provided.

The main problem with "email_registration_form_user_form_alter" is, that it will only get called through "/admin/people/create", but not through "/user/register", meaning a "normal" registration will always lead to the username being generated through "email_registration_user_insert".
The benefit of the username generation logic in "email_registration_form_user_form_alter" is, that it is easily identifiable, meaning, the module would be a bit more performant. BUT, the username is very cryptic.

Here is an example of a user with the Mail-address "mail@mail.com":

• Generated Username through logic 1.: 'email_registration_awnFqFb6af'
• Generated Username through logic 2.: 'mail' (or mail_1, mail_2, etc. if mail is already taken)

@Anybody, what do you think about this? In my opinion, we should settle on one generation logic, where logic 1 is generally better performing but more cryptic.

@Grevil: I agree it doesn't make sense to have two logics in place here and I agree the admin should always be able to override / set the username with priority.

So from my perspective we need a 2.x meta issue to rework these points, combining issues like

• 🐛 Switch to hook_user_presave() for setting username Needs work
• ✨ Allow Admin-users set username while user creation Needs work (this)
• ✨ Update username when updating user entity Needs review (here we should decide, if a setting to update the username on email change should be discussed)

and possible others combined for a clear and safe functionality.

@Grevil could you prepare such a meta issue?
I think the listed issues (and this one) should be subtasks then.

Ok, let's settle on one username scheme and set that value as the "default value" on "admin/people/create" IF the value is empty. 👍

OK, my bad,
'email_registration_' . \Drupal::service('password_generator')->generate(); is just used temporarily and overwritten through the insert hook. I just read the first if case in the insert hook wrong.

So we do not need to settle on anything. We can simply use the existing logic.

Back to the original issue:

When Admin-user goes to admin/people/create page, he is not able to set username, it's always filled with "email_registration_{generated_string}"

I agree, we should never prefill the username anyway. The admin should decide what the username should be and if he leaves the username empty, we use the generation logic from the module.

This won't be fixed. "email_registration_{generated_string}" is only set as the default value and can be changed at will. Unfortunately it is not (easily) possible, to make the username field not required, as core will still throw an error.

So we will simply adjust the description for an admin user, so he knows if he leaves the default value ("email_registration_{generated_string}"), this username is simply just temporary and will be overwritten, through the module's presave hook.

@Grevil: I'd suggest creating a follow-up feature request then with the planned (leave empty vs. fill) functionality. I guess it is possible, but not easy and perhaps not worth it. Having this documented below the field (and setting the field disabled?) should be an appropriate improvement for now!

Having this documented below the field (and setting the field disabled?) should be an appropriate improvement for now!

Almost, we should only disable the field on specific permissions. Admin user shouldn't have the field disabled, also not a user who has the "change own username" permission, who is on his edit user page.

I don't think a follow-up issue would be worth it.

Alright, we found a nice workaround for this in 🌱 [2.x] Rework username generation save logic Active ! "email_registration_{generated_string}" won't be seen by any user any more, instead it will be temporarily set through the validation. We can't leave it entirely due to core validations.

FIXED!

Automatically closed - issue fixed for 2 weeks with no activity.