http://ofbiz.116.s1.nabble.com/Dev-right-way-to-set-up-party-relationship-tp166405p166410.html
I don't think much code needs to be changed. I think the current code
correct. Only the edit party relationship page and the descriptive name
1. To conform to the standard in the Data Model Resources Book
2. I really think the other way is more intuitive. GROUP_ROLLUP can
really go either way in meaning, but CUSTOMER, AGENT, etc. has strong
implications. At least I think it's more intuitive. If you disagree,
then we're stuck at 50:50. Maybe we should do a poll on the list? :)
David E. Jones wrote:
>
> Okay, and what would be the reason for changing this convention that
> has been there for years?
>
> There are many more than you list here. The promo code is in a worker
> and not a service as it is primarily used by the shopping cart object.
>
> Even the accounting extensions use this order for group members and
> such.
>
> It is true that some code doesn't care about the order, but there is
> quite a bit of code that does.
>
> So, the question is why would be want to change it so that the
> relationship description describes the from instead of the to?
>
> -David
>
>
> On Dec 21, 2005, at 4:41 PM, Si Chen wrote:
>
>> So just some further thoughts about this one
>>
>> 1. The PartyRelationship services can go either way. They make no
>> judgement about the meaning of a relationship.
>>
>> 2. The only relationship that is actually used in the system right
>> now seems to be "GROUP_ROLLUP" and it is named "Group Member" It
>> appears that the edit party relationship screens are written in the
>> "${partyIdTo} is ${partyRelationshipName} for ${partyIdFrom}" so
>> that the GROUP_ROLLUP relationships are displayed correctly.
>>
>> 3. I've found that PriceServices use GROUP_ROLLUP relationship
>> only. I did not find any PromoServices using PartyRelationship.
>>
>> I think the solution is really to:
>> 1. Change the descriptive name of "GROUP_ROLLUP" to "Group with
>> Member"
>>
>> 2. Alter the party relationship screen to "${partyIdFrom} is $
>> {partyRelationshipName} for ${partyIdTo}"
>>
>> 3. I don't think it would affect PriceServices either way. If
>> there are other parts of the code that it would affect, I'd be happy
>> to take a look at them.
>>
>> I think it would be nice if we could conform to the data model
>> resource book standard, as it would be more intuitively sensible for
>> the future when there are different types of relationships.
>>
>> Thanks,
>>
>> Si
>>
>> Si Chen wrote:
>>
>>> David,
>>>
>>> I just checked the Data Model and Resources Book, and they have it
>>> the way our seed data is set up as well:
>>>
>>> Volume 1, page 45 -
>>> Relationship Type name = Customer relationship
>>> From Party = ACME Company
>>> From Role = Customer
>>> To Party = ABC Subsidiary
>>> To Role = Internal Organization
>>>
>>> So I still think that the comment is the one that must be wrong.
>>> I'll take a look at the createPartyRelationship service and see if
>>> I find anything there.
>>>
>>> Si
>>>
>>> David E. Jones wrote:
>>>
>>>>
>>>> Si,
>>>>
>>>> I think that comment is correct and consistent with what is coded
>>>> in the edit party relationships page in the party manager.
>>>>
>>>> The problem is most likely that the seed data for the agent is
>>>> wrong... I think this has actually been brought up before, so
>>>> I'll fix it real quick...
>>>>
>>>> -David
>>>>
>>>>
>>>> On Dec 21, 2005, at 2:22 PM, Si Chen wrote:
>>>>
>>>>> Hi. I'm just trying to confirm the right way to set up party
>>>>> relationships in the system, because I think this comment in
>>>>> PartyTypeData.xml might be wrong:
>>>>>
>>>>> <!-- NOTE: The partyRelationshipName describes the TO party, ie
>>>>> A is a customer of B, so A is the partyTo and B is the partyFrom
>>>>> -->
>>>>> The existing seed data for PartyRelationship, however, show
>>>>> partyIdFrom = DemoCustAgent
>>>>> partyIdTo = DemoCustCompany
>>>>> partyRelationshipTypeId = AGENT
>>>>>
>>>>> when DemoCustAgent (partyIdFrom) is an AGENT of DemoCustCompany
>>>>> (partyIdTo)
>>>>>
>>>>> The seed data seems to be more intuitive anyway, but I just
>>>>> wanted to confirm. I can change the incorrect comment in the
>>>>> PartyTypeData.xml
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Si
>>>>> _______________________________________________
>>>>> Dev mailing list
>>>>>
[hidden email]
>>>>>
http://lists.ofbiz.org/mailman/listinfo/dev>>>>
>>>>
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> ----
>>>>
>>>>
>>>> _______________________________________________
>>>> Dev mailing list
>>>>
[hidden email]
>>>>
http://lists.ofbiz.org/mailman/listinfo/dev>>>>
>>>
>>> _______________________________________________
>>> Dev mailing list
>>>
[hidden email]
>>>
http://lists.ofbiz.org/mailman/listinfo/dev>>>
>> _______________________________________________
>> Dev mailing list
>>
[hidden email]
>>
http://lists.ofbiz.org/mailman/listinfo/dev>
>
>------------------------------------------------------------------------
>
>
>_______________________________________________
>Dev mailing list
>
[hidden email]
>
http://lists.ofbiz.org/mailman/listinfo/dev>