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.
