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 > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>> > > >>>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>> > > >>>> > > >>> > > >>> > > >>> > > >> > > >> > > > > > > > > > > > > > > > > >
