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? 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? 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. 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 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 > >> > > >
