I am just going to point a few more things: - The SecurityService interface already has a renamePermission(), renameGroup() and renameRole() methods. Having a renameUser() seems consistent to me.
- In database theory, fields that are part of a primary key are not supposed to be changed. - If we allow the primary key to be changed, we need to make sure that the new user name is not taken and we may need to throw an EntityExistsException which may seem odd in a save() method. I am going to vote +0 on Quinton's proposal meaning that eventhough I am not quite convinced I recognize that we need to move a head. -- Humberto ------------------- > I had this working in turbine 2.1 using just the regular > TurbineSecurity.saveUser(). I haven't bothered going back to see what has > changed to stop it from working now as this seems like a waste of time. > > Originally I was inclined to just fix the problem so it would work the same > as it did before, but then I cam across Humberto's comments and I could see > some logic in having a special method for this since some underlying > implementations (e.g. LDAP) do not maintain UserId primary key. > > However, Quinton's comments have struck a chord with me and I am inclined to > agree that we should attempt to keep the DB security service as simple and > as close to regular torque as possible. For my applications I often create > records related to a user I am creating at the same time. With the existing > turbine 2.2 implementation it is impossible to combine these into a single > DB transaction. With turbine 2.3 however it should be easier (though I > haven't investigated it yet) to treat a TurbineUser record as a regular om > object, enabling the inclusion of changes to this record type in > transactions (assuming I code around TurbineSecurity). > > As for LDAP, if necessary, TurbineUser could be updated to maintain a > userNameRetrieved field (and accessor method) that is only initialised when > setUserName() is invoked. The save() method can then use this to determine > that a combination delete-add operation is required in order to handle the > change in the primary key. > > For DBUserManager, I am inclined to think that since many of the UserManager > methods rely on accountExists(userName), we should perhaps implement the > TurbineUser.userNameRetrieved field/accessor now and have > accountExists(user) use userNameRetrieved rather than userName when > userNameRetrieved != null. > > getUserNameRetrieved() would be added to the interface > o.a.t.om.security.User. > > I don't have anything running 2.3-dev here, so it is possible that I am way > off track - let me know if you think this is the case. > > I need this working pretty much now and I will need this in 2.2.1. Can we > please agree on the approach so that I can get the change in ASAP. > > Effectively I am saying +1 to Quinton's approach. But please also comment > if you feel the implementation I am suggesting above is off the rails. > > Cheers, > > Scott > -- > Scott Eade > Backstage Technologies Pty. Ltd. > http://www.backstagetech.com.au > .Mac Chat/AIM: seade at mac dot com > > > On 15/02/2003 6:09 AM, "Quinton McCombs" <[EMAIL PROTECTED]> wrote: > > > Here is my _opinion_ on this issue: > > > > Most of our users will use the DB security service. It should be as > > painless as possible for as many people as possible. I know that the > > security service can easily be changed to allow a simple user.save() to > > update the username for the DB version. > > > > On LDAP, if the PK can not be changed to a surrogate key, the method > > used to save the user inside of the LDAP UserManager implementation > > should do a remove and add if the username has changed. If this is not > > possible, throw an exception. > > > > I think this way would be the simplest to understand for anyone using > > Turbine. > > > > For this approach: +1 > > > >> -----Original Message----- > >> From: Humberto Hernandez Torres [mailto:[EMAIL PROTECTED]] > >> Sent: Thursday, February 13, 2003 4:10 PM > >> To: Turbine Developers List > >> Subject: RE: Changing the username in SecurityService > >> > >> > >> The purpose of my mail was to discuss what should be done > >> about this. I was making > >> the case that even in DBSecurityService we should use a > >> different method. I could make > >> the change but I don't think we have an agreement. What do > >> you guys suggest? > >> > >> I should have commented the issue in directly in scarab but I > >> am only an observer and I cannot request a role. What can I do? > >> > >>> -----Original Message----- > >>> From: Quinton McCombs [mailto:[EMAIL PROTECTED]] > >>> Sent: Thursday, February 13, 2003 9:31 AM > >>> To: Turbine Developers List > >>> Subject: RE: Changing the username in SecurityService > >>> > >>> > >>> I think that generally when people use the security service > >>> they regard > >>> the limitation of not being able to change the user name as a > >>> defect. > >> > >> I understand. > >> > >>> I > >>> think that we should allow the users to simply update the > >> username and > >>> call the save() method. If this can not be implemented in the LDAP > >>> model, then I suppose that we really don't have much of a choice. > >>> However, if LDAP can use a surrogate key instead of > >> username, then I > >>> think it should be changed. > >> > >> Yeah, one possibility may be to use a user_id. But still, I > >> don't like the idea of changing a primary_key. > >> > >>> > >>>> -----Original Message----- > >>>> From: Humberto Hernandez Torres [mailto:[EMAIL PROTECTED]] > >>>> Sent: Wednesday, February 12, 2003 5:11 PM > >>>> To: Turbine Developers List > >>>> Subject: RE: Changing the username in SecurityService > >>>> > >>>> > >>>> > >>>> Just some more thoughts on this subject. > >>>> > >>>> In the DBSecurityService there are two primary keys. The user > >>>> id and the username (login name). The user id is the primary > >>>> key for all database purposes but the username is the primary > >>>> for the SecurityService interface since all methods use this > >>>> field to identify users. For this reason I think that > >>>> username should be treated as a primary key and if it needs > >>>> to be changed it has to be done using an explicit method > >>>> like 'void renameUser(Usert user, String name)'. Within > >>>> DBSecurityService would be very easy to change that field. In > >>>> LDAPSecurityService a new entry con be created with all the > >>>> same values and the old entry can be deleted. > >>>> > >>>> Any thoughts? > >>>> > >>>> -- > >>>> Humberto > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Humberto Hernandez Torres > >>>>> Sent: Tuesday, February 11, 2003 6:28 PM > >>>>> To: 'Turbine Developers List' > >>>>> Subject: Changing the username in SecurityService > >>>>> > >>>>> > >>>>> Hey guys, In regards of this defect: > >>>>> http://scarab.werken.com/scarab/issues/id/TTWS44 > >>>>> > >>>>> The username cannot be changed in the LDAPSecurityService > >>>> because it > >>>>> is the primary_key for the Users. Neither I think it is a > >>>> good idea to > >>>>> change it in DBSecurirtyService using the > >>>> DBSecurityService:store(User > >>>>> user) method. However, I understand the need to change the > >>>> username, > >>>>> but I would suggest to have a different method 'void > >>>> renameUser(Usert > >>>>> user, String name)'. This is consistent with the way many > >>> Web pages > >>>>> operate, they let you change your information in one page > >>>> but if you > >>>>> want to change your account name you have to go to a > >>>> diffferent page. > >>>>> > >>>>> The alternative is to restructure the LDAPSecurityService > >>> to use a > >>>>> unique integer id. At this moment I don't know what the > >>>> implications > >>>>> would be. I will think about it tonight. > >>>>> > >>>>> -- > >>>>> Humberto > >>>>> > >>>>> > >>>> > >>>> > >>> > >> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>> For additional commands, e-mail: > >> [EMAIL PROTECTED] > >>>> > >>>> > >>> > >>> > >> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
