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]
