Dev - right way to set up party relationship

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Dev - right way to set up party relationship

Si Chen-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Dev - right way to set up party relationship

David E. Jones

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

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dev - right way to set up party relationship

Si Chen-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Dev - right way to set up party relationship

David E. Jones

The problem is in that example that the relationship type description  
does not imply which is the customer and which is the vendor.

There is quite a bit that is setup properly as described by the  
comment, including the promo and price rules and some permissions  
stuff for billing accounts and various other things.

I don't know that the data model resource book defines which way the  
relationship goes, so this was introduced as implementation was done  
on this.

-David


On Dec 21, 2005, at 4:18 PM, 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

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dev - right way to set up party relationship

Si Chen-2
In reply to this post by Si Chen-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Dev - right way to set up party relationship

David E. Jones

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

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dev - right way to set up party relationship

Si Chen-2
David,

I don't think much code needs to be changed.  I think the current code
checks for a rollup of partyIdFrom to partyIdTo, and that's all
correct.  Only the edit party relationship page and the descriptive name
of "GROUP_ROLLUP" need  to be modified.

The reason for doing is:
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?  :)

Thanks,

Si

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
>
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Dev - right way to set up party relationship

David E. Jones

On Dec 21, 2005, at 5:19 PM, Si Chen wrote:

> David,
>
> I don't think much code needs to be changed.  I think the current  
> code checks for a rollup of partyIdFrom to partyIdTo, and that's  
> all correct.  Only the edit party relationship page and the  
> descriptive name of "GROUP_ROLLUP" need  to be modified.

I'll just say this one more time: much more than this has to be  
changed. I've already listed a number of places and there are others  
that may need to be changed. Finding and assuring they are all  
changed is not easy and quite error-prone.

> The reason for doing is:
> 1.  To conform to the standard in the Data Model Resources Book

What exactly in the data model resource book implies this sort of order?

> 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?  :)

Perhaps it is more intuitive, perhaps not. Of course, in things like  
this intuition might be somewhat dangerous. It hasn't been a problem  
in the past except for cases where the definition was not looked  
into. Even in the accounting extensions you setup the internal  
organization rollup demo data just fine...

-David
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Dev - right way to set up party relationship

Si Chen-2
David,

It's on page 45 of the Data Model Resource Book, Volume 1.

Si

David E. Jones wrote:

>
> On Dec 21, 2005, at 5:19 PM, Si Chen wrote:
>
>> David,
>>
>> I don't think much code needs to be changed.  I think the current  
>> code checks for a rollup of partyIdFrom to partyIdTo, and that's  all
>> correct.  Only the edit party relationship page and the  descriptive
>> name of "GROUP_ROLLUP" need  to be modified.
>
>
> I'll just say this one more time: much more than this has to be  
> changed. I've already listed a number of places and there are others  
> that may need to be changed. Finding and assuring they are all  
> changed is not easy and quite error-prone.
>
>> The reason for doing is:
>> 1.  To conform to the standard in the Data Model Resources Book
>
>
> What exactly in the data model resource book implies this sort of order?
>
>> 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?  :)
>
>
> Perhaps it is more intuitive, perhaps not. Of course, in things like  
> this intuition might be somewhat dangerous. It hasn't been a problem  
> in the past except for cases where the definition was not looked  
> into. Even in the accounting extensions you setup the internal  
> organization rollup demo data just fine...
>
> -David
>
>------------------------------------------------------------------------
>
>
>_______________________________________________
>Dev mailing list
>[hidden email]
>http://lists.ofbiz.org/mailman/listinfo/dev
>
 
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: Dev - right way to set up party relationship

Si Chen-2
But you're right, it's probably better just to stay with the way it is
for consistency's sake.  Thanks for looking at this.

Si

Si Chen wrote:

> David,
>
> It's on page 45 of the Data Model Resource Book, Volume 1.
>
> Si
>
> David E. Jones wrote:
>
>>
>> On Dec 21, 2005, at 5:19 PM, Si Chen wrote:
>>
>>> David,
>>>
>>> I don't think much code needs to be changed.  I think the current  
>>> code checks for a rollup of partyIdFrom to partyIdTo, and that's  
>>> all correct.  Only the edit party relationship page and the  
>>> descriptive name of "GROUP_ROLLUP" need  to be modified.
>>
>>
>>
>> I'll just say this one more time: much more than this has to be  
>> changed. I've already listed a number of places and there are others  
>> that may need to be changed. Finding and assuring they are all  
>> changed is not easy and quite error-prone.
>>
>>> The reason for doing is:
>>> 1.  To conform to the standard in the Data Model Resources Book
>>
>>
>>
>> What exactly in the data model resource book implies this sort of order?
>>
>>> 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?  :)
>>
>>
>>
>> Perhaps it is more intuitive, perhaps not. Of course, in things like  
>> this intuition might be somewhat dangerous. It hasn't been a problem  
>> in the past except for cases where the definition was not looked  
>> into. Even in the accounting extensions you setup the internal  
>> organization rollup demo data just fine...
>>
>> -David
>>
>> ------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> 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