if your solution is fine, that's ok of course! The TurbineUser class has to implement org.apache.fulcrum.security.model.turbine.entity.TurbineUser, which may be the reason, that it fails - and it must be set in the xml file, which is, where the Fulcrum configuration is done.
But you are right, what does not work in Torque 4.0 is adding the appropriate peer class management in the Torque schema. Anyhow, the current state (how to handle custom columns) could be showcased more precisely in the Turbine webapp archetype. I'll check this as soon as possible .. Best regards, Georg -----Jeffery Painter <[email protected]> schrieb: ----- An: [email protected] Von: Jeffery Painter <[email protected]> Datum: 16.11.2017 13:58 Betreff: Re: Turbine 4.0 extended user howto Hi Georg, I tried to subclass the user, but I wasn't getting anywhere trying to do that. When I inspected the user manager, the delegate was still referencing the default TurbineUser om and refused to accept my new class as a substitute when I defined it in TR.props but I don't think I tried overriding in the componentConfiguration.xml since I read the comments that said it wasn't working. Anyway - I like actually keeping the user class very simple and will use the one provided. My work around to place a CustomUser object in the user's temp space is working nicely, and even if I were to switch out the authentication mechanism, this way I keep a reference object in the database that won't break if a user model is changed out down the road. I also don't have to worry about having to get rid of user history when removing a user this way either, as the system needs to preserve all transactions even if an employee leaves, so this way it is easier to clean up the security object and still maintain all the data in the background. Thanks for the pointer to the Wiki though. If I see anything else during the migration, I will make a note of it. Once I get everything working, I may go back and see if I can get the old ExtendedUser stuff working and write up something on how to do it. -- Jeff On 11/16/2017 05:51 AM, Georg Kallidis wrote: > Hi Jeff, > > I could think of that you may use a wrapper class to access your custom > fields as explained in > > https://wiki.apache.org/turbine/Turbine4/Turbine4.0M1/Diff ("How to handle > extra columns in Turbine user table with Fulcrum Security", T U R B I N E > 4.0). > > - The wrapper class (set services.SecurityService.wrapper.class in > TR.properties) may just need to extend o.a.t.om.security.DefaultUserImpl. You > then should have access to your custom fields there (check that TurbineUser > class is correctly defined in userManager/className in > componentConfiguration.xml). If you need custom initialization you might > override the DefaultUserImpl(TurbineUser user) constructor. > > Does it work like this? > > > Best regards, Georg > > -----Jeffery Painter <[email protected]> schrieb: ----- > An: [email protected] > Von: Jeffery Painter <[email protected]> > Datum: 14.11.2017 19:36 > Betreff: Re: Turbine 4.0 extended user howto > > Answering for benefit of others. > > I saw in the comments for componentConfiguration.xml the following lines > which I take to mean that implementing a custom extended user under > Turbine 4.0 is not an option. > > <!-- > Custom Turbine ORM Torque classes could not yet be used: > - requires Torque 4.1 or if using Torque 4.0 reqires manually > adding the interfaces in T-classes > - requires attribute baseClass in fulcrum-turbine-schema.xml table > elements set to appropriate > org.apache.fulcrum.security.model.turbine.entity interfaces > - requires attribute peerClass in fulcrum-turbine-schema.xml table > elements set to org.apache.fulcrum.security.torque.peer.TorqueTurbinePeer > --> > > > I ended up creating an object in my application schema called something > like "CustomUser" table that I have used to replace references to my old > extended user in the foreign key of those tables that needed them, and > created a USER_ID in this CustomUser table that I manually map from a > new user entry when it is recorded in the TURBINE_USER table. > > Upon user login, I look up the corresponding CustomUser object and stick > that in my TurbineUser's temp storage so it is available throughout > their session while logged in, and then I can still link actions and > events in the database to the CustomUser object rather than the old > ExtendedUser. > > Not a perfect solution, but it is working and seems to keep me in line > with the new fulcrum security. If you have any better recommendations, > please let me know! > > Thanks, > Jeff > > > On 11/13/2017 03:47 PM, Jeffery Painter wrote: >> Hi guys, >> >> I am posting this here to capture any response on the mail archives. >> >> I know that the security management has been moved to the >> fulcrum-security service for Turbine 4.0 and I am digging deep into >> learning how this works versus the old way in Turbine 2.3.x >> >> Georg or Thomas, do you have any advice on how to migrate my extended >> user classes to continue to work in Turbine 4.0? I only have a few >> additional fields, but I really depend heavily on linking the primary >> key from my custom user table into other tables within my Turbine >> application. >> >> If it is possible to do the foreign key maps for the default >> TURBINE_USER in an easy way, I would be happy to just create an >> additional table to store all the old "extended info" but I like the >> way torque handles the foreign key enforcement. >> >> Here is an example of my app's customer user and a logging table for >> transactions. How would I do this now using Turbine 4.0? Thanks for >> any advice or pointers to where this might already be documented. >> >> >> I was used to doing the following and it worked nicely through turbine >> 2.3.3. >> >> ExtendedUser eu = (ExtendedUser) data.getUser(); >> MyappUser user = (MyappUser) eu.getPersistentObj(); >> >> // Log the event >> EventLog eLog = new EventLog(); >> eLog.setMyappUser(user); >> eLog.setTransactionType(25); >> eLog.setMessage("Updated vendor access to file"); >> eLog.setTxDate(new Date()); >> eLog.setNew(true); >> eLog.save(); >> >> >> In my torque application schema XML I had.... >> >> <!-- extend the base user --> >> <table name="MYAPP_USER" idMethod="native"> >> <!-- default turbine/torque user fields :: DO NOT CHANGE --> >> <column name="USER_ID" required="true" primaryKey="true" >> type="INTEGER"/> >> <column name="LOGIN_NAME" required="true" size="64" type="VARCHAR" >> javaName="UserName"/> >> <column name="PASSWORD_VALUE" required="true" size="64" >> type="VARCHAR" javaName="Password"/> >> <column name="FIRST_NAME" required="true" size="64" type="VARCHAR"/> >> <column name="LAST_NAME" required="true" size="64" type="VARCHAR"/> >> <column name="EMAIL" size="64" type="VARCHAR"/> >> <column name="PHONE" size="64" type="VARCHAR"/> >> <column name="CONFIRM_VALUE" size="128" type="VARCHAR" >> javaName="Confirmed"/> >> <column name="MODIFIED" type="TIMESTAMP" javaName="ModifiedDate"/> >> <column name="CREATED" type="TIMESTAMP" javaName="CreateDate"/> >> <column name="LAST_LOGIN" type="TIMESTAMP"/> >> <column name="OBJECTDATA" type="VARBINARY"/> >> >> <!-- custom fields --> >> <column name="VENDOR" type="BOOLEANINT" default="0"/> >> <column name="ENABLED" type="BOOLEANINT" default="1" >> javaName="Enabled"/> >> <column name="LOGIN_ATTEMPT" type="INTEGER" default="1" >> javaName="LoginAttempts"/> >> <unique> >> <unique-column name="LOGIN_NAME"/> >> </unique> >> </table> >> >> <!-- transaction log --> >> <table name="EVENT_LOG" idMethod="native"> >> <column name="LOG_ID" required="true" >> primaryKey="true" type="INTEGER" autoIncrement="true"/> >> <column name="USER_ID" required="true" type="INTEGER"/> >> <column name="TRANSACTION_TYPE" type="INTEGER"/> >> <column name="MESSAGE" type="VARCHAR" size="500"/> >> <column name="TX_DATE" type="TIMESTAMP"/> >> <foreign-key foreignTable="MYAPP_USER"> >> <reference local="USER_ID" foreign="USER_ID"></reference> >> </foreign-key> >> </table> >> >> >> -- Jeff Painter CEO and Founder of JiveCast Software and analytics, made together http://jivecast.com 301 Fayetteville St. Unit 2301, Raleigh, NC 27601 (919) 533-9024 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
