Not that rare, our employees(customer service) routinely update accounts for people.
Our "Turbine" deployment is 7(8?) years old now. It's been sliced and diced and probably doesn't even look like Turbine any more. We really only use the core services anymore. We have customized everything for account maintenance. The conversation just reminded me of when we made our account update section years ago. I just remember spending quite a bit a time tracking down why changes were getting reverted when we updated peoples email addresses for them. So really the only thing the save on session unbind does for us now is tell us when the last time they were on was. Could probably clean it up and just update the object directly. Oh well, tangental to the original discussion. Sheldon > Date: Thu, 12 Jan 2012 19:13:19 +0100 > From: [email protected] > To: [email protected] > Subject: Re: TorqueUser synchronization problem > > On 12.01.12 16:11, Sheldon Ross wrote: > > In order to get around this, we actually update TurbineSecurity (Turbine > > 2.3) and made the save on session unbind look like this. > > IMO it's probably easier to modify the > SecurityService.saveOnSessionUnbind() method as this is meant to be > pluggable in Turbine. > > > public static void saveOnSessionUnbind(User user) > > throws UnknownEntityException, DataBackendException > > { > > //Get a fresh copy in case user was updated during session > > User fresh = getUser(user.getName()); > > fresh.setHasLoggedIn(user.hasLoggedIn()); > > fresh.setLastLogin(user.getLastLogin()); > > if(fresh != null) getService().saveOnSessionUnbind(fresh); > > } > > > > Makes sure a fresh copy of user data is pulled in before saving, so it > > doesn't overwrite a password/email update on logout. > > ... but throws away all modifications the user may have done himself. > Especially those in PermStorage which we for example use for preferences > storage. Do you want this? > > A clean solution to handle this correctly needs to cover all conflict > situations and probably has to use some sort of locking within the > database. Although all of this is absolutely possible, it's a lot of > effort for a (IMO) rare use case. > > Bye, Thomas. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
