Yes, mojoPortal tries to avoid any duplicate login names even if using email for login because you could always change that at any time.
By default users choose their own login name and the registration page will tell them if the one they chose is already in use.
The only case where we auto generate one is if you have added the config setting AutoGenerateAndHideUserNamesWhenUsingEmailForLogin as true.
In that case we take the part of the email before the @ sign and try to use it but if it exists we do keep appending 1 until it is not a duplicate in SiteUtils.SuggestLoginNameFromEmail
public static string SuggestLoginNameFromEmail(int siteId, string email)
{
string login = email.Substring(0, email.IndexOf("@"));
int offset = 1;
while (SiteUser.LoginExistsInDB(siteId, login))
{
login = login + offset.ToInvariantString();
offset += 1;
}
return login;
}
I guess this logic is not perfect and if the same one keeps coming up then eventually it outgrows the allowed size for the loginname field.
I did not anticipate there being that many duplicates from the part of a unique email address before the @ sign. In order to have this problem you must have lots of users with the email address administrator@someuniquedomain
I just changed the logic like this:
public static string SuggestLoginNameFromEmail(int siteId, string email)
{
string login = email.Substring(0, email.IndexOf("@"));
int offset = 1;
while (SiteUser.LoginExistsInDB(siteId, login))
{
offset += 1;
login = email.Substring(0, email.IndexOf("@")) + offset.ToInvariantString();
}
return login;
}
which should take much longer to run out of unique variants
This change is in the source code repository now.
Only workarounds I can think of are to update to a build of the latest code, or update existing rows to change/remove "administrator" portion of the data to avoid future collisions until the next release of mojoPortal.
Hope that helps,
Joe