just to mention it, this may be just another alternative to what is said (a little bit hidden) about additional columns in
http://turbine.apache.org/turbine/turbine-4.0-M2/howto/extend-user-howto.html . I think, although the text is very insightful and mostly correct and helpful, it should be reviewed before releasing the final version. Best, Georg Von: "Georg Kallidis" <[email protected]> An: "Turbine Developers List" <[email protected]> Datum: 11.08.2016 15:16 Betreff: Turbine 4 Final: How to save additional attributes into turbine_user, removed in M2 Hi, in the case, you need to save some more attributes as defined in TurbineUser interface into turbine_user table - e.g. confirm_value, last_login, created, password_changed (which were removed in Turbine M2), I could find no other (easy)? way to get it to work but to - extend org.apache.fulcrum.security.model.turbine.entity.impl.TurbineUserImpl into a new class (and interface), set/get required properties and - declare it in services.SecurityService.user.class=<extended class> This class is set as userDelegate (of the hard coded reference org.apache.turbine.om.security.DefaultUserImpl, see below), which defines similar setters/getter (confirmed, createDate, lastLogin, but backed by permstorage. It´s created in org.apache.turbine.services.security.DefaultUserManager wrap method, e.g. when a user instance is created. By default DefaultUserManager.store(User) just retrieves the perm storage and saves it, which is correct, if you have no colums for its own in turbine_user table - which IS indeed the case in the new Fulcrum security torque context, but is NOT the case for Turbine M1 and older/other. To get it to work you also have to - extend/override methods in DefaultUserImpl and set the required attributes into the user delegate instead perm storage - most easily by implementing the new interface. To get the pieces work together you have to - extend org.apache.turbine.services.security.DefaultUserManager overriding the wrap method (setting DefaultUserImpl to appropriate class) and declare the class in TR.properties services.SecurityService.user.manager = Is this the way to go in this case? Do other/better solutions exist? Any other ideas? I would indeed suggest to make DefaultUserImpl configurable, you haven´t then to redefine SecurityService.user.manager and it would be more intuitive IMO.. Best regards, Georg --------------------------------------------------------------------- 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]
