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
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.
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.
In other word, Jacques I second your proposal, that seems the consensus
we could agree on.
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
