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" <[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-tp25731734p25734851.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
