I was more showing how this model would allow easier expansion. was not suggesting that preferences were to be proliferated.
Jacques Le Roux sent the following on 9/29/2011 11:57 PM: > I don't see anyh other types of preferences, but I'm sure reality can > come with few. So yes, it looks like a good idea to me to have that > > Jacques > > From: "BJ Freeman" <bjf...@free-man.net> >> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>> >>> >
