Change #value for #default_value on email_registration_form_user_register_form_alter()

Hi greggles

Here is the patch.

The problem is that right now the module uses hook_user_insert() to change the username. First it does this check:

  if (!empty($account->name) && strpos($account->name, 'email_registration_') !== 0) {
    return;
  }

So if you provide a different account name from the create user page (with jquery since the field is hidden) then you skip this hook, that further down the line does this inside that same hook_user_insert:

  // Replace with generated username.
  db_update('users')
    ->fields(array('name' => $new_name))
    ->condition('uid', $account->uid)
    ->execute();

The problem is that you can't know the email of the new user before generating the create user form. So you have this code that I'm proposing to change:

/**
 * Implements hook_form_FORM_ID_alter().
 */
function email_registration_form_user_register_form_alter(&$form, &$form_state) {
  $form['account']['name']['#type'] = 'hidden';
  $form['account']['name']['#value'] = 'email_registration_' . user_password();
  $form['account']['mail']['#title'] = t('E-mail');
}

That provides a __#value__ for the account->name. I'm suggesting changing that to __#default_value__. And I have this jQuery code in my theme:

    // set username to email of the user from JS (using hook_email_registration_name didn't work for LDAP)
    if($('#user-register-form').length > 0 ){
      $('#edit-mail').change(function() {
        $('input.username').val(this.value);
      });
    }

I'm not sure if we could add this jQuery code to a behaviour inside the module instead. But at least providing the opportunity to use this solution by using __#default_value__ sounds like a good alternative right? =).

Ups, forgot to add the patch

It doesn't sound like a big issue to me. Specially considering that after login, the user is allowed to change his "Display name" (account name).

The issue I have is when integrating with https://www.drupal.org/project/ldap. The LDAP module creates a user in my ldap server before the insert. And then creates a second one when the update runs.

So, what I'm saying is that the risk is already there, since the user already has permission to modify his username. So this saves a few milliseconds by not calling the update query, which seems to also call other hooks as well. For example in my case, the update query seems to call an update hook for the ldap module that creates two ldap users with two different account names, one for the email_registration_XXXXX user and another for the updated account name user.

@agerson are you also using the email_registration module? What issue are you seeing?

That sounds strange..... email registration module should allow that. Anyway, the way we do it is we set the LDAP module configuration so that synced users have their email used as account name. That's how we do it and it is working on two sites.

Their email becomes their username.