sorry if I was not clear add preferenceID to Party, partyGroup, and change the userlogin to preferenceID. this is a one to one. So each one can have preference independent and specific to that level. So the Party Group would be first, then add the Party that is Associated then lookup the userlogin if there is one logged in, but this is not reqired, just one way to structure veiws and code. if you access a party then you can find the preferences by looking up the Preferennce through preferenceID or do a view PartyPreference. for migration you can have a view UserPreference for userlogin
you can further have preferences with partyreltionship and roles. By Just Adding a preferenceID Hans Bakker sent the following on 9/29/2011 6:27 AM: > Hi BJ, > Is an interesting solution, however only one problem...how about a party > without a userlogin? > > Regards,Hans > > On Thu, 2011-09-29 at 05:53 -0700, BJ Freeman wrote: >> guess I should address you orginal requirement. >> you would link to preference from party or login with either Pary or >> user type. So add the preference ID to party. >> then have a preference Item with one to many to preference >> >> BJ Freeman sent the following on 9/29/2011 4:54 AM: >>> #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 >>>>>> >>>>>> >>>>>> >>>> >>> >
