You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adam Heath <do...@brainfood.com> on 2010/04/06 17:43:34 UTC
UserLogin.userLoginId primary key, why!?!?!
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.
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Adam Heath <do...@brainfood.com>.
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.
>>
>>
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Ruth Hoffman <rh...@aesolves.com>.
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.
>
>
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Scott Gray <sc...@hotwaxmedia.com>.
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.
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Adrian Crum <ad...@hlmksw.com>.
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.
>
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
:-)
On Apr 7, 2010, at 3:19 PM, Ean Schuessler wrote:
> 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
> ean@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Jacques Le Roux <ja...@les7arts.com>.
:D
Jacques
From: "Adrian Crum" <ad...@yahoo.com>
> Another Mac OSX user?
>
>
> --- On Wed, 4/7/10, Kishor Kumar Das <ki...@connectix.net> wrote:
>
>> From: Kishor Kumar Das <ki...@connectix.net>
>> Subject: Re: UserLogin.userLoginId primary key, why!?!?!
>> To: dev@ofbiz.apache.org, dev-unsubscribe@ofbiz.apache.org
>> Date: Wednesday, April 7, 2010, 9:34 PM
>>
>>
>> --- On Thu, 8/4/10, Adam Heath <do...@brainfood.com>
>> wrote:
>>
>> From: Adam Heath <do...@brainfood.com>
>> Subject: Re: UserLogin.userLoginId primary key, why!?!?!
>> To: dev@ofbiz.apache.org
>> Date: Thursday, 8 April, 2010, 10:02 AM
>>
>> Scott Gray wrote:
>> > badcommit.com is also available but unfortunately
>> nononono.com is taken.
>>
>> itsfunnybecauseyourright.com is not taken, and neither is
>> neinneinneinnein.com.
>>
>
>
>
>
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Adrian Crum <ad...@yahoo.com>.
Another Mac OSX user?
--- On Wed, 4/7/10, Kishor Kumar Das <ki...@connectix.net> wrote:
> From: Kishor Kumar Das <ki...@connectix.net>
> Subject: Re: UserLogin.userLoginId primary key, why!?!?!
> To: dev@ofbiz.apache.org, dev-unsubscribe@ofbiz.apache.org
> Date: Wednesday, April 7, 2010, 9:34 PM
>
>
> --- On Thu, 8/4/10, Adam Heath <do...@brainfood.com>
> wrote:
>
> From: Adam Heath <do...@brainfood.com>
> Subject: Re: UserLogin.userLoginId primary key, why!?!?!
> To: dev@ofbiz.apache.org
> Date: Thursday, 8 April, 2010, 10:02 AM
>
> Scott Gray wrote:
> > badcommit.com is also available but unfortunately
> nononono.com is taken.
>
> itsfunnybecauseyourright.com is not taken, and neither is
> neinneinneinnein.com.
>
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Kishor Kumar Das <ki...@connectix.net>.
--- On Thu, 8/4/10, Adam Heath <do...@brainfood.com> wrote:
From: Adam Heath <do...@brainfood.com>
Subject: Re: UserLogin.userLoginId primary key, why!?!?!
To: dev@ofbiz.apache.org
Date: Thursday, 8 April, 2010, 10:02 AM
Scott Gray wrote:
> badcommit.com is also available but unfortunately nononono.com is taken.
itsfunnybecauseyourright.com is not taken, and neither is
neinneinneinnein.com.
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Adam Heath <do...@brainfood.com>.
Scott Gray wrote:
> badcommit.com is also available but unfortunately nononono.com is taken.
itsfunnybecauseyourright.com is not taken, and neither is
neinneinneinnein.com.
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Scott Gray <sc...@hotwaxmedia.com>.
badcommit.com is also available but unfortunately nononono.com is taken.
On 7/04/2010, at 5:40 PM, Adrian Crum wrote:
> So is theonlyadamthatcounts, theoneandonlyadam, and mynameisadamworshipme.
>
> -Adrian
>
> Scott Gray wrote:
>> adamforreals.com is still available.
>> Regards
>> Scott
>> On 7/04/2010, at 7:19 AM, Ean Schuessler wrote:
>>> 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 ean@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Adrian Crum <ad...@hlmksw.com>.
So is theonlyadamthatcounts, theoneandonlyadam, and mynameisadamworshipme.
-Adrian
Scott Gray wrote:
> adamforreals.com is still available.
>
> Regards
> Scott
>
> On 7/04/2010, at 7:19 AM, Ean Schuessler wrote:
>
>> 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
>> ean@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315
>
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Scott Gray <sc...@hotwaxmedia.com>.
adamforreals.com is still available.
Regards
Scott
On 7/04/2010, at 7:19 AM, Ean Schuessler wrote:
> 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
> ean@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Ean Schuessler <ea...@brainfood.com>.
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
ean@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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).
>
> adam@brainfood.com used to point to someone else. It now points to me.
>
Very good!
Jacopo
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Adam Heath <do...@brainfood.com>.
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).
adam@brainfood.com used to point to someone else. It now points to me.
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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.
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Adam Heath <do...@brainfood.com>.
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.
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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.
>>
>
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Adam Heath <do...@brainfood.com>.
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.
>
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Nicolas Malin <ma...@librenberry.net>.
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 : 06.17.66.40.06
Site projet : http://www.neogia.org/
-------
Société LibrenBerry
Tél : 02.48.02.56.12
Site : http://www.librenberry.net/
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Adam Heath <do...@brainfood.com>.
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.
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by BJ Freeman <bj...@free-man.net>.
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.
>
>
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
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.
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by Adam Heath <do...@brainfood.com>.
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.
>
Re: UserLogin.userLoginId primary key, why!?!?!
Posted by David E Jones <de...@me.com>.
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.