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
