Thanks BJ for the comment. In order to keep the framework (login preference) and party preference separated i would like to suggest to either:
1. extend the UserPreference entity and adding the field partyId to the key, override the related services and make the PartyId mandatory. 2. copy the UserPreference and call it PartyPreference and replace the userLogin with the partyId and create similar services in the party component. anybody any comments? Regards, Hans On Mon, 2011-09-26 at 21:24 -0700, BJ Freeman wrote: > I can see the case for both > I have taken the approach to start with partyrelations.rollup.roles (not > as defined by ofbiz, but the datamodel book) that a userloginId has, > against the PartyID info available. > that is a lot more detailed than I think you looking for. > > > Hans Bakker sent the following on 9/26/2011 7:12 PM: > > Currently we have a userLoginId preference. What is fine for preferences > > in screens etc. > > > > However we would would like to have preferences on a party level, like > > email notification preferences. This is rather difficult at the moment > > because if you specify these at the userLogin level and there are 5 > > userlogins for a user what to do? If you only know the partyId? > > > > System messages or orders are an example, there only partyId is known > > and not the specific userloginId. We would also like to send > > notifications when an email comes is, where also only partyId is known. > > > > Any opinions here? > > > > Regards, > > Hans > > > > > > -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Alternative ofbiz website: http://www.ofbiz.info http://www.antwebsystems.com : Quality services for competitive rates.
