Hi Michael, All,

The reason why we have the partyIdFrom and partyIdTo fields (and the
associated roleTypeIdFrom and roleTypeIdTo fields)  is that the project
started out following the Unified Data Model (UDM) by Len Silverton.

And then we digressed from that.
Were each of those digressions carefully thought through and the impact
thoroughly discussed before they went into the code base?

The reason why these are in several entities in the UDM is that the values
of these fields (relating to these principal parties) are regarded as
immutable when the object reaches a certain state (the *_APPROVED or
similar)[1].

The various associated *Role entities are intended to capture:
1. additional roles for the principal parties
2. additionally involved parties (both internal and external) in their
respective roles, per [2]

If we were to only use *Role entities we are creating a more complex
problem to solve the immutability issue.

As an example:

The OFBiz operator needs to have the ability to add parties (and a role of
the party) and expire existing *Role records associated to the principal
object (agreement, invoice, order, project, employment contract, etc.).


With this function the operator can add a new party as the customer (and
expire the original) to e.g. the sales order after the order has been
approved.



In order to prevent this from happening, we would need to have a mechanism
to ensure that the principal parties (and their principal role regarding
the object) don't change during the lifespan of the object. IMO this will
be a complex solution given all permutations possible.



[1] We're not talking about what can be done at database level (or via
WebTools) by SystemAdmins.
[2] https://en.wikipedia.org/wiki/Responsibility_assignment_matrix

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


>

Reply via email to