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


Reply via email to