You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by ARays <ar...@kenfuse.com> on 2009/10/03 21:03:33 UTC
fine grained party
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.
Re: fine grained party
Posted by Adrian Crum <ad...@hlmksw.com>.
Before you get too far into this, you should get The Data Model Resource
Book - which explains in great detail why the Party entities are set up
the way they are. Once you have a clear understanding of why it is
designed that way, you will have a clearer picture of how to reach your
goals.
For instance, you would know that contractor is not a subtype of person.
It is a role. A contractor could be a person (freelance contractor) or a
party group (contracting company).
Also keep in mind that a person could be an employee AND a contractor.
Where I work we have people like that. As an employee, they punch a time
clock and get paid a wage. During their "off time" they do side work for
the company and bill the company as a contractor.
-Adrian
ARays wrote:
> Agreed roles should be configurable describing the roles party would play
> within the system. However, my requirement is more closer to Identity of the
> person and an implied role (cannot be changed). To pick on the same
> contractor example, a subtype of person, the compensation of the person is
> very different from employees another subtype. Assumption, contractor cannot
> become employee. They both can play the same roles which makes it hard to
> distinguish workflows based on roles alone. Some more researching and I find
> party classification could be a way besides party types and I am wondering
> which is one is better suited. Differentiation is not just in workflow but
> presentation as well. Since fundamentally as I mentioned it is part of
> identity of the person, a subtype seemed appropriate. Looking for
> suggestions. I am looking at the same reasons which led to having 'party
> group' and 'person' as types within partymgr.
>
> - Arays
>
>
> David E Jones-4 wrote:
>>
>> Some more food for thought: not only should you not have a primary
>> role for a user, you should never even look at the role of a user on
>> its own... roles should be used to describe a relationship between a
>> party and something else in the system (another party, a product, a
>> task, an order, etc, etc).
>>
>> That should solve your workflow problem...
>>
>> -David
>>
>>
>> On Oct 3, 2009, at 10:59 PM, 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" <ar...@kenfuse.com>
>>>> 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-tp25731734p25734851.html
>>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>>
>>
>>
>
Re: fine grained party
Posted by ARays <ar...@kenfuse.com>.
Agreed roles should be configurable describing the roles party would play
within the system. However, my requirement is more closer to Identity of the
person and an implied role (cannot be changed). To pick on the same
contractor example, a subtype of person, the compensation of the person is
very different from employees another subtype. Assumption, contractor cannot
become employee. They both can play the same roles which makes it hard to
distinguish workflows based on roles alone. Some more researching and I find
party classification could be a way besides party types and I am wondering
which is one is better suited. Differentiation is not just in workflow but
presentation as well. Since fundamentally as I mentioned it is part of
identity of the person, a subtype seemed appropriate. Looking for
suggestions. I am looking at the same reasons which led to having 'party
group' and 'person' as types within partymgr.
- Arays
David E Jones-4 wrote:
>
>
> Some more food for thought: not only should you not have a primary
> role for a user, you should never even look at the role of a user on
> its own... roles should be used to describe a relationship between a
> party and something else in the system (another party, a product, a
> task, an order, etc, etc).
>
> That should solve your workflow problem...
>
> -David
>
>
> On Oct 3, 2009, at 10:59 PM, 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" <ar...@kenfuse.com>
>>> 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-tp25731734p25734851.html
>> Sent from the OFBiz - User mailing list archive at Nabble.com.
>>
>
>
>
--
View this message in context: http://www.nabble.com/fine-grained-party-tp25731734p25744976.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: fine grained party
Posted by David E Jones <de...@me.com>.
Some more food for thought: not only should you not have a primary
role for a user, you should never even look at the role of a user on
its own... roles should be used to describe a relationship between a
party and something else in the system (another party, a product, a
task, an order, etc, etc).
That should solve your workflow problem...
-David
On Oct 3, 2009, at 10:59 PM, 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" <ar...@kenfuse.com>
>> 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-tp25731734p25734851.html
> Sent from the OFBiz - User mailing list archive at Nabble.com.
>
Re: fine grained party
Posted by ARays <ar...@kenfuse.com>.
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" <ar...@kenfuse.com>
>> 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.
Re: fine grained party
Posted by ARays <ar...@kenfuse.com>.
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" <ar...@kenfuse.com>
> 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-tp25731734p25734851.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
Re: fine grained party
Posted by "David E. Jones" <de...@me.com>.
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" <ar...@kenfuse.com> 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.
>
>
>