#3. rename to Preferences with a TypeID added. However use the logniID to find the Preference with the type Party. since we now have the login tied to the partryID already.
Hans Bakker sent the following on 9/29/2011 3:11 AM: > 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 >>> >>> >>> >
