[jira] [Comment Edited] (OFBIZ-5959) Add lifespan fields to PartyRole and dependency refactoring

["Jacques Le Roux (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OFBIZ-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282534#comment-14282534 ] 

Jacques Le Roux edited comment on OFBIZ-5959 at 8/28/15 12:02 PM:
------------------------------------------------------------------

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 OFBIZ-5827]or Employment with respect to internal persons, see issue 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: OFBIZ-5990. Or another potential improvement inclusion: you type the role and you get the appropriate persons.
{quote}

Another scenario
{quote}
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 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 we 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.




was (Author: pfm.smits):
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}

Another scenario
{quote}
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 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 we 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 and dependency refactoring
> -----------------------------------------------------------
>
>                 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)