[
https://issues.apache.org/jira/browse/OFBIZ-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282534#comment-14282534
]
Pierre Smits commented on OFBIZ-5959:
-------------------------------------
I can follow the reasoning and would be inclined to share your viewpoint, if we
would not follow the 'Universal Data Model' as the guiding aspect regarding
entity models. And guess what: it is in the UDM.
See following articles (and incorporated diagrams):
*
[http://www.universaldatamodels.com/Portals/9/udm_Publication_Articles_11_05_Models_Patterns.pdf]
*
[http://www.universaldatamodels.com/Portals/9/Publication_Articles_5_02_Healthcare.pdf]
*
[http://www.universaldatamodels.com/Portals/9/Publication_Articles_7_02_Financial_Serv.pdf]
*
[http://www.universaldatamodels.com/Portals/9/Publication_Articles_3_02_Relationship_Dev.pdf]
To name but a few.
And the reason why it is in the UDM is simple. It all has to do with the aspect
of being able to track and trace changes (as part of GCR). Not having the
fromDate and thruDate fields in that entity makes it harder to track changes.
Apart from the aspect above, it has additional benefits, as it ensures that
only those persons are shown in drop down fields and other selection mechanism
in derivative functions. Not the persons who had the role in the past and are
not in that role anymore, and potentially not those persons who have the role
in the future and not now (although the latter is debatable - depending on
requirements). Having the right set of people, based on the attribute
filter-by-date, available for selection reduces data traffic and improves user
experience.
Let me outline briefly two scenarios of what might happen without PartyRoles
and the assignment to persons as prerequisite for dependent functionalities
(forgoing the aspect that current functionality throughout the entire feature
set doesn't factor in PartyRelationship in any person selection, see issue
[https://issues.apache.org/jira/browse/OFBIZ-5827] or Employment with respect
to internal persons, see issue
[https://issues.apache.org/jira/browse/OFBIZ-5832]).
Scenario
{quote}
Have a look at the following screen:
[http://demo-trunk-ofbiz.apache.org/accounting/control/EditAgreementRoles?agreementId=8000]
In current feature set of OFBiz the search for the right person can be long,
type ahead only delivers a specific number of hits and then you have to go
through the list of all the roles available to find the right one. Our current
demo data set is limited, but imagine how that will be experienced in a real
life scenario, when multiple parties need to be added to a specific agreement
and over and over again for each new agreement. Not very user friendly, I would
say.
Now imagine the following, in the screen above you find the person and the drop
down field were to show only the roles he has. You would instantly know whether
that person has the right role (as intended with issue:
[https://issues.apache.org/jira/browse/OFBIZ-5990]. Or another potential
improvement inclusion: you type the role and you get the appropriate persons.
{quote}
{quote}
Scenario two:
Suppose that all agreements registered in a real life scenario and all
agreements have parties been assigned to various roles. Suppose also that a
internal person has left the company and all agreements needs to be revisited
to evaluate whether the assignment needs to be adjusted.
Evaluation and maintainability of the validity of the records regarding the
other <entity>Role entities is much more cumbersome without automation (again
not user friendly) and/or more complex to achieve with automation. Or there is
no uniformity.
{quote}
For sure, if we were to question the people considering OFBiz these the
majority is either investigating it for a small setup (the person in the small
organisation)or considering it as a setup for small users (the system
integrator). But always have to keep in mind that OFBiz is not just for the
smaller organisation (where shortcuts are applied visavis compexity), but also
the larger/more complex organisations. These larger organisations have a lot
more data to manage and/or complex organisational setups to delegate authority
(to central back offices, or a multitude of persons in middle mgt). Think of
Stannah (see this testimonial:
[http://ofbiz.markmail.org/message/phwl43o5vzwvfwmc?q=stannah]) as such an
OFBiz user.
OFbiz is a suite of generic solutions intended for all kinds of organisational
setups and this kind of refactoring (improvement) of business functionality not
only ensures that it stays in the top bracket functionality wise. It also keeps
us in the position to promote it with the slogan 'Yes, it works for you too'
and drive adoption. Not only of users, but also with respect to a diversity in
contributors.
> Add lifespan fields to PartyRole
> --------------------------------
>
> Key: OFBIZ-5959
> URL: https://issues.apache.org/jira/browse/OFBIZ-5959
> Project: OFBiz
> Issue Type: Improvement
> Components: party
> Affects Versions: Trunk
> Reporter: Pierre Smits
> Labels: role, roles
>
> Currently the assignments of roles to parties are boolean (there or not
> there).
> However, these role assignments also have a lifespan. This can be achieved by
> adding fromDate and thruDate fields.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
