UserLogin.userLoginId primary key, why!?!?!

[Adam Heath-2]

Why oh why does the primary key for UserLogin get used as the actual
username during login?  This makes it *very* difficult for users to
change their username.  Even more confusing when the email address is
used for login, but then the user changes their email address, and
wants to change their login name too.

Since all security is attached to userLoginId, and all the
modified-by/created-by stuff is also attached to that, it makes it
difficult to change that kind of schema.

However, what should be possible, is that a new field is added to
UserLogin, that specifies the name to use.  Or possibly a whole new
entity that only relates to UserLogin, and leave the rest of the
system alone.

Does anyone else agree?  We won't have time to work on this right now,
but we are interested in working on this with someone else now, or, in
the future, when we are less busy, doing it ourselves.

[David E. Jones-2]

A couple of questions for you:

1. when a user "changes" their username what should happen with the old one? should it be available for another user to pick up?

2. should it be possible for a single person to have more than one username?

-David


On Apr 6, 2010, at 10:43 AM, Adam Heath wrote:

> Why oh why does the primary key for UserLogin get used as the actual
> username during login?  This makes it *very* difficult for users to
> change their username.  Even more confusing when the email address is
> used for login, but then the user changes their email address, and
> wants to change their login name too.
>
> Since all security is attached to userLoginId, and all the
> modified-by/created-by stuff is also attached to that, it makes it
> difficult to change that kind of schema.
>
> However, what should be possible, is that a new field is added to
> UserLogin, that specifies the name to use.  Or possibly a whole new
> entity that only relates to UserLogin, and leave the rest of the
> system alone.
>
> Does anyone else agree?  We won't have time to work on this right now,
> but we are interested in working on this with someone else now, or, in
> the future, when we are less busy, doing it ourselves.

[Scott Gray-2]

It can certainly make life difficult at times and I'd be in favor of the discussion continuing although I have no time to be very involved myself right now.

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 6/04/2010, at 9:43 AM, Adam Heath wrote:

> Why oh why does the primary key for UserLogin get used as the actual
> username during login?  This makes it *very* difficult for users to
> change their username.  Even more confusing when the email address is
> used for login, but then the user changes their email address, and
> wants to change their login name too.
>
> Since all security is attached to userLoginId, and all the
> modified-by/created-by stuff is also attached to that, it makes it
> difficult to change that kind of schema.
>
> However, what should be possible, is that a new field is added to
> UserLogin, that specifies the name to use.  Or possibly a whole new
> entity that only relates to UserLogin, and leave the rest of the
> system alone.
>
> Does anyone else agree?  We won't have time to work on this right now,
> but we are interested in working on this with someone else now, or, in
> the future, when we are less busy, doing it ourselves.

[Adrian Crum]

I agree that it is inconvenient. Either solution will take a lot of work.

-Adrian

Adam Heath wrote:

> Why oh why does the primary key for UserLogin get used as the actual
> username during login?  This makes it *very* difficult for users to
> change their username.  Even more confusing when the email address is
> used for login, but then the user changes their email address, and
> wants to change their login name too.
>
> Since all security is attached to userLoginId, and all the
> modified-by/created-by stuff is also attached to that, it makes it
> difficult to change that kind of schema.
>
> However, what should be possible, is that a new field is added to
> UserLogin, that specifies the name to use.  Or possibly a whole new
> entity that only relates to UserLogin, and leave the rest of the
> system alone.
>
> Does anyone else agree?  We won't have time to work on this right now,
> but we are interested in working on this with someone else now, or, in
> the future, when we are less busy, doing it ourselves.
>

[Adam Heath-2]

David E Jones wrote:
> A couple of questions for you:
>
> 1. when a user "changes" their username what should happen with the old one? should it be available for another user to pick up?

If username is disconnected from the item that maintains security,
then old usernames won't exist at all, or maybe have a
fromDate/thruDate filter.  New users should be able to reuse old
usernames, but *not* get any of the previous user's security roles.

> 2. should it be possible for a single person to have more than one username?

More than one, absolutely.

Another issue we have add over the years, is the need for a 'realm'
key for usernames.  So with a shared database, different frontends
could have overlapping usernames, but with the realm key, still be
able to differeniate.

If a sub-table is used to map actual login names to UserLogin, then
existing could should still function, and it's only the login
services/events/pages that have to be updated.  Old code should still
work, in theory, I think.

>
> -David
>
>
> On Apr 6, 2010, at 10:43 AM, Adam Heath wrote:
>
>> Why oh why does the primary key for UserLogin get used as the actual
>> username during login?  This makes it *very* difficult for users to
>> change their username.  Even more confusing when the email address is
>> used for login, but then the user changes their email address, and
>> wants to change their login name too.
>>
>> Since all security is attached to userLoginId, and all the
>> modified-by/created-by stuff is also attached to that, it makes it
>> difficult to change that kind of schema.
>>
>> However, what should be possible, is that a new field is added to
>> UserLogin, that specifies the name to use.  Or possibly a whole new
>> entity that only relates to UserLogin, and leave the rest of the
>> system alone.
>>
>> Does anyone else agree?  We won't have time to work on this right now,
>> but we are interested in working on this with someone else now, or, in
>> the future, when we are less busy, doing it ourselves.
>

[Jacopo Cappellato-4]

Wouldn't be easier to create a new UserLogin, associate it to the same Person and expire the old one?

Jacopo


On Apr 6, 2010, at 5:43 PM, Adam Heath wrote:

> Why oh why does the primary key for UserLogin get used as the actual
> username during login?  This makes it *very* difficult for users to
> change their username.  Even more confusing when the email address is
> used for login, but then the user changes their email address, and
> wants to change their login name too.
>
> Since all security is attached to userLoginId, and all the
> modified-by/created-by stuff is also attached to that, it makes it
> difficult to change that kind of schema.
>
> However, what should be possible, is that a new field is added to
> UserLogin, that specifies the name to use.  Or possibly a whole new
> entity that only relates to UserLogin, and leave the rest of the
> system alone.
>
> Does anyone else agree?  We won't have time to work on this right now,
> but we are interested in working on this with someone else now, or, in
> the future, when we are less busy, doing it ourselves.

[Ruth Hoffman-2]

Hi Adam:
I thought that was the idea behind having a PARTY entity and a partyId.
When you use the PARTY as the unique user identifier, a user may have
any number of user logins, email addresses etc.

Regards,
Ruth

Adam Heath wrote:

> Why oh why does the primary key for UserLogin get used as the actual
> username during login?  This makes it *very* difficult for users to
> change their username.  Even more confusing when the email address is
> used for login, but then the user changes their email address, and
> wants to change their login name too.
>
> Since all security is attached to userLoginId, and all the
> modified-by/created-by stuff is also attached to that, it makes it
> difficult to change that kind of schema.
>
> However, what should be possible, is that a new field is added to
> UserLogin, that specifies the name to use.  Or possibly a whole new
> entity that only relates to UserLogin, and leave the rest of the
> system alone.
>
> Does anyone else agree?  We won't have time to work on this right now,
> but we are interested in working on this with someone else now, or, in
> the future, when we are less busy, doing it ourselves.
>
>  

[Adam Heath-2]

Jacopo Cappellato wrote:
> Wouldn't be easier to create a new UserLogin, associate it to the same Person and expire the old one?

No.  Tons of entities have a createdByUserLogin,
lastModifiedByUserLogin, there's UserLoginHistory,
UserLoginSecurityGroup, etc.

You'd have to modify *all* those entities, expiring/updating them all.

>
> Jacopo
>
>
> On Apr 6, 2010, at 5:43 PM, Adam Heath wrote:
>
>> Why oh why does the primary key for UserLogin get used as the actual
>> username during login?  This makes it *very* difficult for users to
>> change their username.  Even more confusing when the email address is
>> used for login, but then the user changes their email address, and
>> wants to change their login name too.
>>
>> Since all security is attached to userLoginId, and all the
>> modified-by/created-by stuff is also attached to that, it makes it
>> difficult to change that kind of schema.
>>
>> However, what should be possible, is that a new field is added to
>> UserLogin, that specifies the name to use.  Or possibly a whole new
>> entity that only relates to UserLogin, and leave the rest of the
>> system alone.
>>
>> Does anyone else agree?  We won't have time to work on this right now,
>> but we are interested in working on this with someone else now, or, in
>> the future, when we are less busy, doing it ourselves.
>

[Adam Heath-2]

Ruth Hoffman wrote:
> Hi Adam:
> I thought that was the idea behind having a PARTY entity and a partyId.
> When you use the PARTY as the unique user identifier, a user may have
> any number of user logins, email addresses etc.

But you can't reuse old logins for anyone else.  And security is
attached to the login, not the party.  And logins can exist without
parties.

>
> Regards,
> Ruth
>
> Adam Heath wrote:
>> Why oh why does the primary key for UserLogin get used as the actual
>> username during login?  This makes it *very* difficult for users to
>> change their username.  Even more confusing when the email address is
>> used for login, but then the user changes their email address, and
>> wants to change their login name too.
>>
>> Since all security is attached to userLoginId, and all the
>> modified-by/created-by stuff is also attached to that, it makes it
>> difficult to change that kind of schema.
>>
>> However, what should be possible, is that a new field is added to
>> UserLogin, that specifies the name to use.  Or possibly a whole new
>> entity that only relates to UserLogin, and leave the rest of the
>> system alone.
>>
>> Does anyone else agree?  We won't have time to work on this right now,
>> but we are interested in working on this with someone else now, or, in
>> the future, when we are less busy, doing it ourselves.
>>
>>  

[Malin Nicolas]

I've the same idea.
+1

Jacopo Cappellato wrote:

> Wouldn't be easier to create a new UserLogin, associate it to the same Person and expire the old one?
>
> Jacopo
>
>
> On Apr 6, 2010, at 5:43 PM, Adam Heath wrote:
>
>  
>> Why oh why does the primary key for UserLogin get used as the actual
>> username during login?  This makes it *very* difficult for users to
>> change their username.  Even more confusing when the email address is
>> used for login, but then the user changes their email address, and
>> wants to change their login name too.
>>
>> Since all security is attached to userLoginId, and all the
>> modified-by/created-by stuff is also attached to that, it makes it
>> difficult to change that kind of schema.
>>
>> However, what should be possible, is that a new field is added to
>> UserLogin, that specifies the name to use.  Or possibly a whole new
>> entity that only relates to UserLogin, and leave the rest of the
>> system alone.
>>
>> Does anyone else agree?  We won't have time to work on this right now,
>> but we are interested in working on this with someone else now, or, in
>> the future, when we are less busy, doing it ourselves.
>>    
>
>  

--
Nicolas MALIN
Consultant
Tél : [phone]
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : [phone]
Site : http://www.librenberry.net/

[Jacopo Cappellato-4]

On Apr 6, 2010, at 5:56 PM, Adam Heath wrote:

> Jacopo Cappellato wrote:
>> Wouldn't be easier to create a new UserLogin, associate it to the same Person and expire the old one?
>
> No.  Tons of entities have a createdByUserLogin,
> lastModifiedByUserLogin, there's UserLoginHistory,
> UserLoginSecurityGroup, etc.
>
> You'd have to modify *all* those entities, expiring/updating them all.

You don't have to change any values. This is historic information that cannot change.

Jacopo

>
>>
>> Jacopo
>>
>>
>> On Apr 6, 2010, at 5:43 PM, Adam Heath wrote:
>>
>>> Why oh why does the primary key for UserLogin get used as the actual
>>> username during login?  This makes it *very* difficult for users to
>>> change their username.  Even more confusing when the email address is
>>> used for login, but then the user changes their email address, and
>>> wants to change their login name too.
>>>
>>> Since all security is attached to userLoginId, and all the
>>> modified-by/created-by stuff is also attached to that, it makes it
>>> difficult to change that kind of schema.
>>>
>>> However, what should be possible, is that a new field is added to
>>> UserLogin, that specifies the name to use.  Or possibly a whole new
>>> entity that only relates to UserLogin, and leave the rest of the
>>> system alone.
>>>
>>> Does anyone else agree?  We won't have time to work on this right now,
>>> but we are interested in working on this with someone else now, or, in
>>> the future, when we are less busy, doing it ourselves.
>>
>

[Jacopo Cappellato-4]

On Apr 6, 2010, at 5:57 PM, Adam Heath wrote:

> But you can't reuse old logins for anyone else.

This requirement (reusing expired user logins for new parties) is the only reason (together with the realm thing mentioned in another way) I see for modifying the UserLogin entity.
If this is what you need we can discuss the data model change, but we have to be careful about reusing user logins.

Jacopo

[Scott Gray-2]

On 6/04/2010, at 10:16 AM, Jacopo Cappellato wrote:

> On Apr 6, 2010, at 5:57 PM, Adam Heath wrote:
>
>> But you can't reuse old logins for anyone else.
>
> This requirement (reusing expired user logins for new parties) is the only reason (together with the realm thing mentioned in another way) I see for modifying the UserLogin entity.
> If this is what you need we can discuss the data model change, but we have to be careful about reusing user logins.
>
> Jacopo

Agreed

[BJ Freeman]

once coded to do all that is not going to be hard.
it would run up the cpu usage and database activity but on a dedicated
server that should not be a problem.

Plus I think it is good for audit to keep all the records synced to the
current lognin

========================

BJ Freeman
http://bjfreeman.elance.com
Strategic Power Office with Supplier Automation <http://www.businessesnetwork.com/automation/viewforum.php?f=93>
Specialtymarket.com <http://www.specialtymarket.com/>

Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man
Linkedin
<http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro>


Adam Heath sent the following on 4/6/2010 8:56 AM:

> Jacopo Cappellato wrote:
>> Wouldn't be easier to create a new UserLogin, associate it to the same Person and expire the old one?
>
> No.  Tons of entities have a createdByUserLogin,
> lastModifiedByUserLogin, there's UserLoginHistory,
> UserLoginSecurityGroup, etc.
>
> You'd have to modify *all* those entities, expiring/updating them all.
>
>> Jacopo
>>
>>
>> On Apr 6, 2010, at 5:43 PM, Adam Heath wrote:
>>
>>> Why oh why does the primary key for UserLogin get used as the actual
>>> username during login?  This makes it *very* difficult for users to
>>> change their username.  Even more confusing when the email address is
>>> used for login, but then the user changes their email address, and
>>> wants to change their login name too.
>>>
>>> Since all security is attached to userLoginId, and all the
>>> modified-by/created-by stuff is also attached to that, it makes it
>>> difficult to change that kind of schema.
>>>
>>> However, what should be possible, is that a new field is added to
>>> UserLogin, that specifies the name to use.  Or possibly a whole new
>>> entity that only relates to UserLogin, and leave the rest of the
>>> system alone.
>>>
>>> Does anyone else agree?  We won't have time to work on this right now,
>>> but we are interested in working on this with someone else now, or, in
>>> the future, when we are less busy, doing it ourselves.
>
>

[Adam Heath-2]

BJ Freeman wrote:
> once coded to do all that is not going to be hard.
> it would run up the cpu usage and database activity but on a dedicated
> server that should not be a problem.
>
> Plus I think it is good for audit to keep all the records synced to the
> current lognin

My recommendation wouldn't require that.  The username used to log in
with would not be tied to the userLoginId field, so there wouldn't be
a need to change any other fields.

[Adam Heath-2]

Jacopo Cappellato wrote:

> On Apr 6, 2010, at 5:56 PM, Adam Heath wrote:
>
>> Jacopo Cappellato wrote:
>>> Wouldn't be easier to create a new UserLogin, associate it to the same Person and expire the old one?
>> No.  Tons of entities have a createdByUserLogin,
>> lastModifiedByUserLogin, there's UserLoginHistory,
>> UserLoginSecurityGroup, etc.
>>
>> You'd have to modify *all* those entities, expiring/updating them all.
>
> You don't have to change any values. This is historic information that cannot change.

If the username gets reused, then all the existing records that map to
that userLoginId would point to the new user.  There are security
checks that allow the current user to modify the record if they are
the creater or modifier.  Since the UserLogin entity is now attached
to a new partyId, this is actually a security problem.

[Jacopo Cappellato-4]

On Apr 6, 2010, at 7:02 PM, Adam Heath wrote:

> Jacopo Cappellato wrote:
>> On Apr 6, 2010, at 5:56 PM, Adam Heath wrote:
>>
>>> Jacopo Cappellato wrote:
>>>> Wouldn't be easier to create a new UserLogin, associate it to the same Person and expire the old one?
>>> No.  Tons of entities have a createdByUserLogin,
>>> lastModifiedByUserLogin, there's UserLoginHistory,
>>> UserLoginSecurityGroup, etc.
>>>
>>> You'd have to modify *all* those entities, expiring/updating them all.
>>
>> You don't have to change any values. This is historic information that cannot change.
>
> If the username gets reused, then all the existing records that map to
> that userLoginId would point to the new user.

As I have written in another post, reusing usernames is one of the very few requirements that would require such a change.
However, it may be arguable if reusing userlogins is a good practice (for example you would never reuse usernames if they are email addresses).

Jacopo


>  There are security
> checks that allow the current user to modify the record if they are
> the creater or modifier.  Since the UserLogin entity is now attached
> to a new partyId, this is actually a security problem.

[Adam Heath-2]

Jacopo Cappellato wrote:

> On Apr 6, 2010, at 7:02 PM, Adam Heath wrote:
>
>> Jacopo Cappellato wrote:
>>> On Apr 6, 2010, at 5:56 PM, Adam Heath wrote:
>>>
>>>> Jacopo Cappellato wrote:
>>>>> Wouldn't be easier to create a new UserLogin, associate it to the same Person and expire the old one?
>>>> No.  Tons of entities have a createdByUserLogin,
>>>> lastModifiedByUserLogin, there's UserLoginHistory,
>>>> UserLoginSecurityGroup, etc.
>>>>
>>>> You'd have to modify *all* those entities, expiring/updating them all.
>>> You don't have to change any values. This is historic information that cannot change.
>> If the username gets reused, then all the existing records that map to
>> that userLoginId would point to the new user.
>
> As I have written in another post, reusing usernames is one of the very few requirements that would require such a change.
> However, it may be arguable if reusing userlogins is a good practice (for example you would never reuse usernames if they are email addresses).

[hidden email] used to point to someone else.  It now points to me.

[Jacopo Cappellato-4]

On Apr 6, 2010, at 7:49 PM, Adam Heath wrote:

> Jacopo Cappellato wrote:
>> On Apr 6, 2010, at 7:02 PM, Adam Heath wrote:
>>
>>> Jacopo Cappellato wrote:
>>>> On Apr 6, 2010, at 5:56 PM, Adam Heath wrote:
>>>>
>>>>> Jacopo Cappellato wrote:
>>>>>> Wouldn't be easier to create a new UserLogin, associate it to the same Person and expire the old one?
>>>>> No.  Tons of entities have a createdByUserLogin,
>>>>> lastModifiedByUserLogin, there's UserLoginHistory,
>>>>> UserLoginSecurityGroup, etc.
>>>>>
>>>>> You'd have to modify *all* those entities, expiring/updating them all.
>>>> You don't have to change any values. This is historic information that cannot change.
>>> If the username gets reused, then all the existing records that map to
>>> that userLoginId would point to the new user.
>>
>> As I have written in another post, reusing usernames is one of the very few requirements that would require such a change.
>> However, it may be arguable if reusing userlogins is a good practice (for example you would never reuse usernames if they are email addresses).
>
> [hidden email] used to point to someone else.  It now points to me.
>

Very good!

Jacopo

[Ean Schuessler]

Well, Adam Keys isn't such a bad guy... even if he does like Ruby on Rails more than Java.

Though I'm afraid, Mr. Heath, that he has trumped you in the domain name department: http://therealadam.com/ 

----- "Jacopo Cappellato" wrote:
> Very good!
> Jacopo

--
Ean Schuessler, CTO Brainfood.com
[hidden email] - http://www.brainfood.com - 214-720-0700 x 315