BTW, the seed data that prompted me to start thinking on these lines is below
<PartyType description="Informal Group" hasTable="N"
parentTypeId="PARTY_GROUP" partyTypeId="INFORMAL_GROUP"/>
<PartyType description="Family" hasTable="N"
parentTypeId="INFORMAL_GROUP" partyTypeId="FAMILY"/>
<PartyType description="Team" hasTable="N" parentTypeId="INFORMAL_GROUP"
partyTypeId="TEAM"/>
<PartyType description="Legal Organization" hasTable="N"
parentTypeId="PARTY_GROUP" partyTypeId="LEGAL_ORGANIZATION"/>
<PartyType description="Corporation" hasTable="N"
parentTypeId="LEGAL_ORGANIZATION" partyTypeId="CORPORATION"/>
<PartyType description="Government Agency" hasTable="N"
parentTypeId="LEGAL_ORGANIZATION" partyTypeId="GOVERNMENT_AGENCY"/>
I am still searching if some of the sub types are used in some ways in
ofbiz.
- Arays
ARays wrote:
>
> ah! there definitely is a catch. However, if one were to have a
> base/principal role/purpose (sort of their primary which is not expected
> to change) then one can base some workflows on that.. To share my
> scenario, I am looking to use ofbiz for back office use where the workflow
> changes quite dramatically for employees vs contractors. They can
> obviously play different roles such as sales clerk, manager, accountant
> etc, but the way they are compensated for example is different. Not sure
> if that makes sense in the context of ofbiz, but I am looking at ways to
> support such a scenario. For example in PartyMgr Orders makes sense for
> customers, but may not as much for employees and my intent is to have
> context specific (primary purpose of their engagement) viewprofiles and be
> able to extend the datamodel appropriately for each segment of user.
>
> As I mentioned I did consider using roles to differentiate, but then the
> challenge may be that down the line someone might change or drop roles
> which can complicate matters. The idea is to treat the primary purpose
> much like the 'sex of a person' which is not expected to change in most
> cases if not all ;-)
>
> - Arays
>
>
>
> David E Jones-4 wrote:
>>
>>
>> How would this handle a Party that is in multiple roles, as the current
>> model does?
>>
>> -David
>>
>>
>> On Saturday, October 03, 2009, at 12:03PM, "ARays" <[email protected]>
>> wrote:
>>>
>>>Hi,
>>>
>>>I am trying to get party entries to be a little more fine grained. For
now
>>>it seems like there are only two types in use 'person' & 'partygroup'.
The
>>>view profile reflects this difference. However, I would like to control
it
>>>some more based on whether the party person is primarily an employee or
>>>contractor etc. Which is a better option to go about the same?
>>>a) Use roles to distinguish between different types. This may cause
>>>integrity problems since any workflow based on roles may break if the
roles
>>>are changed down the line.
>>>b) Use the partyTypeId to distinguish. This seems like a cleaner
approach.
>>>However, I am unable to find out how and where partyTypeId is set. I
would
>>>expect to extend person with sub types as employee, contractor etc, say
as
>>>below
>>>
>>> <PartyType description="Employee" hasTable="N" parentTypeId="PERSON"
>>>partyTypeId="EMPLOYEE"/>
>>> <PartyType description="Contractor" hasTable="N"
>>> parentTypeId="PERSON"
>>>partyTypeId="CONTRACTOR"/>
>>>
>>>Looking for some inputs/suggestions.
>>>
>>>Thanks
>>>Arays
>>>--
>>>View this message in context:
http://www.nabble.com/fine-grained-party-tp25731734p25731734.html
>>>Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>
>>>
>>>
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/fine-grained-party-tp25731734p25734852.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
