I would prefer #2.
The distinction between users and parties is already blurred enough, and
relating User Preferences to a party will just make that worse.
-Adrian
On 9/29/2011 11:11 AM, Hans Bakker wrote:
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
