discussion: party preference and user(loginId) preference

[hans_bakker]

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



--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Alternative ofbiz website: http://www.ofbiz.info
http://www.antwebsystems.com : Quality services for competitive rates.

[BJ Freeman]

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
>
>
>

[hans_bakker]

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
> >
> >
> >

--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Alternative ofbiz website: http://www.ofbiz.info
http://www.antwebsystems.com : Quality services for competitive rates.

[Adrian Crum-3]

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
>>>
>>>
>>>

[Jacques Le Roux]

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" <[hidden email]>

>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
>>>>
>>>>
>>>>

[Malin Nicolas]

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 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" <[hidden email]>
>> 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
>>>>>
>>>>>
>>>>>

[BJ Freeman]

#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
>>>
>>>
>>>
>

[BJ Freeman]

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 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 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" <[hidden email]>
>>> 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
>>>>>>
>>>>>>
>>>>>>
>
>

[BJ Freeman]

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
>>>>
>>>>
>>>>
>>
>

[hans_bakker]

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
> >>>>
> >>>>
> >>>>
> >>
> >

--
Ofbiz on twitter: http://twitter.com/apache_ofbiz
Alternative ofbiz website: http://www.ofbiz.info
http://www.antwebsystems.com : Quality services for competitive rates.

[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. 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
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>

[Jacques Le Roux]

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" <[hidden email]>

> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>

[BJ Freeman]

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" <[hidden email]>
>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>
>