[BlueOnyx:00880] Re: Feature Requests

[Greg O'Lone]

On Mar 27, 2009, at 10:03 am, Michael Stauber wrote:

> Hi Greg,
>
>> Oops, right. I'm guessing we'd have to turn off the suggestion code  
>> if
>> the userPrefix was defined for a site.
>
> Depends. I'd prefer to adjust it to get it working for both scenarios.
>
>> I've been playing around with
>> this on my test environment... trying to get it just right, but
>> haven't even approached the scenario of an existing user that already
>> fits the bill. I probably should look at the usernames of every user
>> on the box to check for duplicates (what a pain).
>
> The existing code already handles cases such as "username already  
> taken", so
> that should be no big deal.


Michael.

I wasn't thinking that the VSite administrator would have the ability  
to edit the usernames if a prefix was set, but that's an interesting  
point. I guess it could allow just about any suffix to be used,  
although my original plan was to make it so conflicts did not happen  
by assigning usernames numerically (SOS_001, SOS_002, SOS_003).

The problem I see with allowing the admins to change usernames is that  
they could create their own conflicts (which is what I'm trying to  
avoid). Imagine two sites, one with a prefix of SOS and one with SOST.  
The first admin makes a user SOSTREBECA for a user named Tom Rebeca.  
The second admin tries to create the same user SOSTREBECA for a user  
named Rob Ebeca. It's not likely, but I'm all about idiot proofing.

There was a time when I "suggested" to admins that they use the first  
8 characters of their domains and a 3 or 4 digit number to assign  
usernames. Most of them were okay with the idea. The troublemakers are  
the casual hosting customers who all want the "info" username...

I know that the current interface limits usernames to 12 characters  
(or something like that). Do you know if this is a limitation of Linux  
or Sausalito?

Greg