Don't generate username if the account->user is already set

I think the second patch is missing most of the content from the original patch.

However, I think this could be solved a lot more generically. Basically I don't think the email_registration should not generate a username if the account object already has one set. There are other modules besides the migrate module that create / import users and set a user name with them.

This patch just does a simple check to determine if the username is already set, and if so then it does nothing. This also means that you don't really even need hook_email_registration_name() as any other modules that wish to override the account name can just do so in their on hook_user insert.

Forgot that /this/ module sets a random username on registration :). Here's a new patch that accounts for that.

Tested (with User Import) and works fine!
This patch fixes my #981772: Conflict with User Import issue.

Also, fyi #657472: Add setting to allow users to login with email address or username depends on this patch
Thanks!

Feeds.module imports are also affected by this problem. Any remote login system or social network would probably be affected as well, Facebook connect, Google, etc. There is no check on the hook_user_insert() before it rewrites and updates the username. Basically anywhere you are creating users programatically.

The Drupal 6 version was marked RTBC more than a year ago, can we get these committed? Especially since that other issue depends on it.

I updated this patch to work with Drupal 7.

I'd be happy to co-maintain this module!

marking needs review

Works for me (D7 version from #6).

After applying the patch at #6 my new users are being created with the username set as the random password that's generated :S

bump.

I think this should be implemented by different way. the module require a flag set into a property of account, this will allow ordering of the modules that affects username, email and other properties

I'd like to see the patch in #6 committed. It resolves the conflict with numerous other modules that set user name (for example fboauth).

This isn't to suggest that andypost is wrong in wanting a more formal system for modules to deal with making these changes and interacting with one another, but to my mind, that is a separate issue working on a different scope of problems.

I visually reviewed the 6.x and 7.x patches and think they are ready to go.

I agree with leeomara's perspective in #13 that we shouldn't hold back progress in the name of perfection.

@andypost, maybe create a new issue for the feature you mention in #12 so that people who need it can work on it?

I think yes #6 solves the problem so needs to be commited. Also I not sure that it's possible to find a universal way to fix this among all user-name related modules

Commited and pushed to 6.x and 7.x

+++ email_registration.module.new	2010-07-17 20:16:20.000000000 +0200
@@ -14,6 +14,11 @@
+      ¶

D6 #3 fixed trailing white-space

Hello Jon!

We would like to use Email Registration and LDAP modules together. Furthermore we would like usernames generated from the email address even when user is *imported from LDAP database*.

Since your patch accepted, Email registration only generates the username if the user is created via the registration form (and username is temporarily set to 'email_registration_' . user_password()). I see your point, and understand that often this is what users want. But I think there are other cases (like ours) when the former way of username generation would be preferred.

I'd like to see a configuration option for this. Something like "always generate username from email".

What do you think about it?

Best regards, Peter

Hi riskop,

It's possible to do that in a custom module. See hook_email_registration_name.