Client is King... well, yes, but Kings need advisors.
In this case if they refuse to use call a group a group, and instead
want to call a group a classification then they cannot use existing
functionality in OFBiz, and as in this case there is less of a chance
that whatever is developed for them will make it back into the project.
Often Kings don't realize such things, hence their need for advisors.
And if they choose not to listen to their advisors (if their advisors
are good ;) ), they typically pay more and/or fail.
-David
On Jan 30, 2009, at 2:16 PM, Jacques Le Roux wrote:
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
