Jacques From: "David E Jones" <[email protected]>
Those sound more like PartyGroups (related using PartyRelationship) than PartyClassifications. A party classification is used for usually "sensitive" data like race, income, etc and usually for marketing purposes.
Yes, that was also my feeling, but you know... client is king...
As for the group hierarchy thing, I think that may already be supported for group-based pricing,
Yes, it is.
and I know there is already code to walk up relationships to expand a set of group partyIds.
Good to be known, anyway it's was not long to create this recursive custom method, the parentId in PartyClassificationGroup was useful.
I could commit but this woul dimply to have another choice (Recursive Party Classification) and I guess it's a bit specific. Thanks Jacques
-David On Jan 29, 2009, at 2:23 PM, Jacques Le Roux wrote:A client of mine needed to have a price rule on a party classification also working on children of a classification (using parentId) His use case was agent agent partner agent partner fix agent partner performer agent not partner ... and he wanted that if he defines a rule on agent it also apply on all children (this generalized at any level of the hierarchy, of course, ie a rule on agent partner would only apply to agent partner, agent partner fix and agent partner performer) I created a little recursive method, do you think this could be useful OOTB ? Jacques
