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. >
