Your understanding of the data model is not correct. The PartyClassification entity is just a join entity between Party and PartyClassificationGroup. The entity definition itself can help clarify this because it follows the same pattern as join entities in general in OFBiz, ie the fields are (the first 3 are pks):
partyId* partyClassificationGroupId* fromDate* thruDate This is the basic pattern for join entities. Other example include PartyContent, ProductContent, ProductCategoryMember, and dozens (hundreds?) of others. Any time two entities have a many-to-many relationship a join entity is needed to go between them. For PartyClassificationGroup note that it has a "parentGroupId" field making the structure hierarchical (like many other *Type and other entities that need a simple hierarchy). In your example Hispanic would be a PartyClassificationGroup that is a child of the US Minorities group. Note that the current structure is a pure hierarchy, ie it is not a graph, and each node can only have a single parent. If you want a PartyClassificationGroup to have multiple parents then you'll need another join entity to model that many-to-many relationship (much like ProductCategoryRollup). -David On Jan 10, 2011, at 4:27 PM, Adrian Crum wrote: > I spent some time in Party Manager trying to make sense of the Party > Classification feature, and I can't seem to make it do anything meaningful. > Maybe I'm not understanding something, so I'll provide an example and see if > anyone knows how to implement it in the current code. > > In table 2.3 of the Data Model Resource Book, there is a party named Marc > Martinez who has been classified as Hispanic. I will use him for my example. > > In Party Manager I create a person named Marc Martinez and I want to classify > him as Hispanic. I would also like to include the Hispanic classification in > two classification groups: US Minorities and Non-White. I go to the > Classifications tab - where I can create classification groups from a list of > pre-defined group types. I choose the Minority type, type "US Minorities" in > the Description field, and save the group. I want to add the Hispanic > classification to this group, but I don't see any way to add classifications. > I go to Marc's profile page and try to assign him a classification, but I can > only assign him to a classification group. If I assign him to the "US > Minorities" group that still doesn't classify him as Hispanic. > > As far as I can tell, Party Classification doesn't work. > > Any ideas? > > -Adrian > > > --- On Mon, 1/3/11, Adrian Crum <adrian.c...@yahoo.com> wrote: >> Understood. If we wanted to create >> entities to avoid the sub-types mentioned in the book >> (Organization Classification, Person Classisfication, etc) >> then I think we could have done that in a simpler way and >> still keep the book's model: >> >> PartyClassificationGroupType >> ---------------------------- >> *groupTypeId >> description >> parentGroupTypeId >> >> PartyClassificationGroup >> ------------------------ >> *groupTypeId >> *partyTypeId >> >> Anyways, I have come up with a workaround. I'll just use >> the existing PartyClassificationGroup the way the book uses >> PartyType. >> >> -Adrian >> >> >> --- On Mon, 1/3/11, David E Jones <d...@me.com> >> wrote: >>> Every single *Type entity in OFBiz is a deviation from >> the >>> book (ie the *Type entities are an OFBiz pattern to >> avoid >>> redundant entities and keep track of entity extensions >> like >>> the Party -> PartyGroup,Person thingy), as are >> dozens of >>> other entities and hundreds of fields. That book is >> valuable >>> for general concepts and patterns, and is not an >> actual data >>> model to be used as-is. >>> >>> -David >>> >>> >>> On Jan 3, 2011, at 5:57 PM, Adrian Crum wrote: >>> >>>> I don't think I'm generalizing anything. The book >> is >>> pretty specific and clear: Party Classification is an >>> intersection entity that sets up a many-to-many >> relationship >>> between the Party entity and the Party Type entity. >>>> >>>> I understand OFBiz deviates from the book here >> and >>> there, and if this is one of those cases, then I'll >> ask >>> again: Why was it done that way? >>>> >>>> I'm trying to make sense of the OFBiz Party >>> Classification model, and so far it doesn't make >> sense. The >>> way it is set up, I can't give a party a >> classification >>> without first creating a classification group, assign >> a >>> classification type to it, and then assign the party >> to the >>> classification group using party classification. >>>> >>>> In the book it's much simpler - I just assign a >> party >>> type to a party using a party classification. >> Classification >>> groups are Party Classification sub-types and they >> aren't >>> necessary unless I want to group things a certain >> way. >>>> >>>> -Adrian >>>> >>>> --- On Mon, 1/3/11, David E Jones <d...@me.com> >>> wrote: >>>>> I think you may be taking the specific term >> "type" >>> and >>>>> generalizing it. Consider that *Type entities >> in >>> OFBiz mean >>>>> something very specific, and it is different >> from >>> the more >>>>> general use of the term in the book. >>>>> >>>>> -David >>>>> >>>>> >>>>> On Jan 3, 2011, at 3:24 PM, Adrian Crum >> wrote: >>>>> >>>>>> That's not what the book shows. There is >> a >>> simple >>>>> relationship: >>>>>> >>>>>> Party -> PartyClassification -> >>> PartyType >>>>>> >>>>>> If you want to group classifications, >> give >>> them >>>>> parent/child relationships, etc then you do >> it >>> with >>>>> PartyType, not PartyClassification. Look at >> table >>> 2.3 on >>>>> page 32. >>>>>> >>>>>> -Adrian >>>>>> >>>>>> --- On Mon, 1/3/11, BJ Freeman <bjf...@free-man.net> >>>>> wrote: >>>>>>> how about a pattern of parent child >>>>>>> for PartyClassification of supertype >> >>>>>>> and the sub types then use a >>>>> table for the >>>>>>> attributess of the subtype. >>>>>>> this would allow walking the parnent >>> child >>>>> relationships. >>>>>>> PartyClassification >>>>>>> >>>>> >>> >> --->organizationClassification---->minorityClassification >>>>>>> >>> >>>>> >>>>>>> >>> >>>>>>> >>> ---->industryclassification >>>>>>> >>>>>>> ========================= >>>>>>> BJ Freeman >>>>>>> Strategic Power Office with Supplier >>> Automation >>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52> >>>>>>> Specialtymarket.com <http://www.specialtymarket.com/> >>>>>>> Systems Integrator-- Glad to Assist >>>>>>> >>>>>>> Chat Y! messenger: bjfr33man >>>>>>> >>>>>>> >>>>>>> Adrian Crum sent the following on >> 1/3/2011 >>> 2:46 >>>>> PM: >>>>>>>> PartyClassificationGroup should >> have >>> a >>>>> one-to-one >>>>>>> relationship with an entity called >>>>>>> PartyClassificationGroupType. >>>>>>>> >>>>>>>> -Adrian >>>>>>>> >>>>>>>> --- On Mon, 1/3/11, BJ >> Freeman<bjf...@free-man.net> >>>>> >>>>>>> wrote: >>>>>>>>> so the Party Classification >> Group >>>>>>>>> table would have a one to >> one >>> with >>>>>>>>> Classification Types >>>>>>>>> or vica versa. >>>>>>>>> >>>>>>>>> >>>>>>>>> ========================= >>>>>>>>> BJ Freeman >>>>>>>>> Strategic Power Office with >>> Supplier >>>>> Automation >>>>>>>>> <http://www.businessesnetwork.com/automation/viewforum.php?f=52> >>>>>>>>> Specialtymarket.com<http://www.specialtymarket.com/> >>>>>>>>> Systems Integrator-- Glad to >>> Assist >>>>>>>>> >>>>>>>>> Chat Y! messenger: >>> bjfr33man >>>>>>>>> >>>>>>>>> >>>>>>>>> Adrian Crum sent the >> following on >>> 1/3/2011 >>>>> 1:41 >>>>>>> PM: >>>>>>>>>> Looking into this more, >> The >>> Data >>>>> Model >>>>>>> Resource Book >>>>>>>>> mentions classification >> groups - >>> but I >>>>> believe the >>>>>>> author >>>>>>>>> meant that Party Types could >> be >>> grouped >>>>> together >>>>>>> in >>>>>>>>> classification groups. In >> other >>> words, >>>>> the >>>>>>> classification >>>>>>>>> groups are defined by the >> data >>> contained >>>>> in the >>>>>>> Party Type >>>>>>>>> table - not in a separate >> "Party >>>>> Classification >>>>>>> Group" >>>>>>>>> table. There is nothing >> stopping >>> us from >>>>> having a >>>>>>> Party >>>>>>>>> Classification Group table, >> but it >>> should >>>>> group >>>>>>> Party Types, >>>>>>>>> not "Classification Types." >>>>>>>>>> >>>>>>>>>> -Adrian >>>>>>>>>> >>>>>>>>>> --- On Mon, 1/3/11, >> Adrian >>> Crum<adrian.c...@yahoo.com> >>>>>>>>> wrote: >>>>>>>>>>> Looking at The Data >> Model >>>>> Resource >>>>>>>>>>> Book and the way >> OFBiz >>> models >>>>> Party >>>>>>>>> Classification, it >>>>>>>>>>> appears to me OFBiz >> models >>> it >>>>> wrong. >>>>>>>>>>> >>>>>>>>>>> According to the >> book, the >>> Party >>>>>>> Classification >>>>>>>>> entity ties >>>>>>>>>>> a Party to a Party >> Type >>> with a >>>>> from and >>>>>>> thru >>>>>>>>> date. >>>>>>>>>>> >>>>>>>>>>> In OFBiz, the Party >>> Classification >>>>> entity >>>>>>> ties a >>>>>>>>> Party to a >>>>>>>>>>> Party Classification >> Group >>> with a >>>>> from and >>>>>>> thru >>>>>>>>> date. The >>>>>>>>>>> Party Type is tied >>> directly to >>>>> Party with >>>>>>> no from >>>>>>>>> and thru >>>>>>>>>>> date. >>>>>>>>>>> >>>>>>>>>>> Was that intentional? >> Why >>> was it >>>>> done that >>>>>>> way? >>>>>>>>>>> >>>>>>>>>>> -Adrian >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> >> > > >
