1st propostion seems more powerful and especially less constrained
Jacques
Hans Bakker wrote:
or, just add the preferenceId to party and userLogin and not create the
two new entities..
On 11/02/2011 01:13 PM, Hans Bakker wrote:
After the discussion in this mailing list we had, the followi
or, just add the preferenceId to party and userLogin and not create the
two new entities..
On 11/02/2011 01:13 PM, Hans Bakker wrote:
After the discussion in this mailing list we had, the following is
proposed:
1. rename the UserPreference entity to Preference
2. rename the userLoginId in
After the discussion in this mailing list we had, the following is proposed:
1. rename the UserPreference entity to Preference
2. rename the userLoginId in this entity to preferenceId
3. create a UserLoginPreference entity to link the preference to the
userLoginId
4. create a PartyPreference en
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 go
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"
sorry if I was not clear
add preferenceID to Party, partyGroup, and change the userlogin to
preferenceID. this is a one to one.
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
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 ty
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 Preferen
I like to see the item model used in orders and agreements.
this lets preferences to expand in the futures without redesign
Nicolas Malin sent the following on 9/29/2011 4:21 AM:
> I also agree with Adrian, on beautyfull world PartyPreference just
> contains only functionnal preference while UserP
#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
I also agree with Adrian, on beautyfull world PartyPreference just
contains only functionnal preference while UserPreference embeds
navigation information (or useful information) to work with OFBiz IHM
Nicolas
Jacques Le Roux a écrit :
I agree with Adrian. But then we will not have the possibi
I agree with Adrian. But then we will not have the possibility to have preferences by logins, only parties. Not sure it's a big
deal, maybe should be considered? (Why it was done that way...?)
Jacques
From: "Adrian Crum"
I would prefer #2.
The distinction between users and parties is already
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 part
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 Use
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
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
16 matches
Mail list logo
