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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |