Thanks once i get some other stuff out of the way will try to evaluate what this means.
Adrian Crum sent the following on 9/4/2011 11:54 AM: > The marketing department will want to group party classifications one > way. The human resources department will want to group party > classifications another way. A department head might want to group > subordinates a certain way. How is each party classification grouping > handled without redundant and potentially stale data? By grouping party > classifications instead of grouping parties. When a party's > classification changes, their membership in the various party > classification groups changes automatically. > > It's simple and flexible. > > -Adrian > > > On 9/4/2011 7:47 PM, BJ Freeman wrote: >> Looks like I missed an important part of you thinking. >> >> Adrian Crum sent the following on 9/4/2011 11:36 AM: >>> No, I want Hispanic to be a member of an arbitrary number of groups. >>> >>> -Adrian >>> >>> On 9/4/2011 7:34 PM, BJ Freeman wrote: >>>> Parent child is the same as grouping in my view. >>>> it even gives you a hierarchy >>>> so if you point to Hispanic you can find it under Minorities. >>>> if you want to further define Hispanic, Like Castillian or Mexican they >>>> can be child of Hispanic >>>> >>>> Adrian Crum sent the following on 9/4/2011 11:10 AM: >>>>> And your point is? That doesn't assign Hispanic to a classification >>>>> group, it only makes Hispanic a child classification of the Minority >>>>> Classification. >>>>> >>>>> At any rate, I have implemented the pattern I needed locally, and I >>>>> have >>>>> given up trying to make the case for an improved Party Classification >>>>> data model. >>>>> >>>>> -Adrian >>>>> >>>>> On 9/4/2011 7:04 PM, BJ Freeman wrote: >>>>>> <PartyClassificationType description="Minority" hasTable="N" >>>>>> parentTypeId="" partyClassificationTypeId="MINORITY_CLASSIFICAT"/> >>>>>> <PartyClassificationType description="Hispanic" hasTable="N" >>>>>> parentTypeId="MINORITY_CLASSIFICA" >>>>>> partyClassificationTypeId="HISPANIC_CLASSIFICAT"/> >>>>>> >>>>>> >>>>>> Adrian Crum sent the following on 1/10/2011 4:27 PM: >>>>>>> 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<[email protected]> 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<[email protected]> >>>>>>>> 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<[email protected]> >>>>>>>>> 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<[email protected]> >>>>>>>>>>> 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<[email protected]> >>>>>>>>>>>>> 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<[email protected]> >>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>> >>>>>>> >
