Re: PartyRole usage in OFBiz

[Jacques Le Roux]

Le 15/11/2021 à 14:39, Pierre Smits a écrit :
Hi Jacques, All,

You asked earlier in this thread what I meant with 'erroneous record going
into the PartyRole table'. My apologies for not addressing this earlier.

What I meant with that is this: any record that goes into the PartyRole
table (or any other table) that either intentionally or unintentionally can
be defined in any OFBiz component due to 'features' in that component while
at the same time going against policies and procedures of the OFBiz-using
organisation.

Does that mean that there is something wrong with the ensurePartyRole
request and underying service (when talking about PartyRole)? No. the
request takes the parameters as defined by the underlying service, and the
service applies those parameters in line with the entity definition.

As for your proposal to circumvent current issues by having the community
to prefer the service(s) under the createPartyRelationshipAndRoles request
over any other solution is in essence the combination of invoking the
ensurePartyRole service and the createPartyRelationship service under a
request?

I was wrong it's
createPartyRelationshipAndRole
not
createPartyRelationshipAndRoles
and 3 cases of use OOTB.

Actually createPartyRelationshipAndRole  uses ensurePartyRole since OFBIZ-5905.
Both can and should be used in different situations

. One worry less.


There is technically nothing wrong with  a) the services ensurePartyRole
and create PartyRelationship (invoked by a triggered request or call
service) or createPartyRelationshipAndRoles. Works as designed, any
developer will say. But there is a functional issue . Which is: who in what
capacity is permitted to invoke this service and given the specific OFBiz
application what are the - functional - limits to the field/value
combinations (for Party AND RoleType) that can be provided as required
input parameters to the service?

Yes, as Gil said, it's up to the developer. We would need to analyse more to make you a complete answer. I'm not sure it's necessary. For me that's OK 
as is and I even don't know how we could enforce that, because it's contextual.


As for those claiming that the PartyRole definition lacks context in OFBiz
and therefore should not exist: this is a wrong presumption/conclusion. The
context of a PartyRole record is the relationship shared between 2 other
records: a Party record and a RoleType record.  Like any other new
<entityName>Role record creates/shows the context shared between 3 other
entity records. As an example:
https://demo-trunk.ofbiz.apache.org/webtools/control/entity/find/ProductRole/DEMO-PRODUCT-1/DemoCustomer-1/PRODUCT_OWNER/2010-11-18%2014:50:01.259
shows the context shared between a Product record, a Party and a RoleType.
I personally don't question the need of PartyRole. What I question is the need to the one (hence with PKs) in the relations from other 
EntityNameRoles. Hopefully A one-nofk would do the job, even with legacy. Just a bet for now...



Functionally (and technically per current design), you can not have the
existence of a PartyRelationship record without the context of the Party
and the RoleType record (a PartyRole record) for both to and from

You are mistaken about "(a PartyRole record)".  PartyRole has nothing to do 
there, RoleType and Party only.

Jacques


Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory <https://directory.apache.org>, PMC Member*


On Mon, Nov 15, 2021 at 1:26 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Hi Gil,

Inline...

Le 15/11/2021 à 10:36, gil a écrit :
Hello,

The current applications IMO are not meant to be used as it, but are
presenting existing features.
So there are many design flaws that exists in the current states of the
application (leads to fk constraint error messages when deleting partyRole
or creating partyRel).

The example of having only a partyRole defined  for an actor to be
selected can be *sufficient* in one implementation

Sorry, I'm not sure what that means, could you explain a bit more? TIA


Having the need to expire role association implies, for me,  to have it
associated within a context (WorkEffort, PartyRel, etc.) which OFBIZ-5827
is
one possibility.
That makes sense and would prevent to remove PKs to PartyRole from
EntityNameRole relations. But do we really need that? Should we not rather
concentrate on PartyRelationShip. For instance we can't assign a role to a
party with a relation to an organisation (for OFBIz implementation where
there is several organisations). PartyRelationShip allows that.


It is our choices as Integrators to decide and customize application to
use `ensurePartRole` when it is needed, or to lookup for the good
configured
party the way it is the best for our case.
Sure, but what do you mean by that? To not remove things in model,
services, UI, etc?


In other word, Jacques I second your proposal, that seems the consensus
we could agree on.

Thanks, but it's a bit confuse to me, detailing your proposition would
help.

TIA

Jacques

Thanks,

Gil

Le lun. 15 nov. 2021 à 8:04 am, Jacques Le Roux <
jacques.le.r...@les7arts.com> a écrit :
Le 13/11/2021 à 19:26, Jacques Le Roux a écrit :
Jacopo made an interesting comment at: <https://s.apache.org/6s8lr>
that:
    <<There are pros and cons, or rather scenarios that are facilitated
by one approach and made more difficult by the other, to both ways of
    interpreting PartyRole records.
    The current approach, implemented in many ootb applications, as
Michael Brohl has pointed out, is to interpret the PartyRole records as all
the
    roles the party actually plays.
    The other approach, that is the one advocated by Pierre Smits, is
to interpret the PartyRole records as the roles the party can play.>>
Hi Jacopo, All,

Thinking about it, is there not a contradiction between Michael's
vision (actually also how it was also historically envisioned by the
founders)
and the fact that we are able to create/edit PartyRoles in party
component?
Hence the creation of OFBIZ-5980 "Have the ability to revoke (expire)
roles of a party", OFBIZ-12370 "InvoiceRole: impossible combination of
party
and role selectable: leads to error" and all related issues,

It seems to me that OFBIZ-5827 "Have party selection in screens based
on relation(s) in stead of role" and all related issues fits more.
Note that all is Pierre's work. That's the Gordian node I speak about.
I think we have already almost decided how to cut it: OFBIZ-5827 way rather
than OFBIZ-5980 one.

So we should tackle OFBIZ-5827 and all related issues and close
OFBIZ-5980 and all related issue after carefully reviewing them
Nobody objects?

Jacques