Hi Jacques, All, I have taken your summation, Jacques, and poured it into a page in confluence (see [1]).
Can we say that there is consensus regarding the definition? [1] https://cwiki.apache.org/confluence/display/OFBIZ/EntityNameRole 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 4:48 PM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Thanks Gil, > > I now get the ideas and I agree with them. > > Le 15/11/2021 à 15:37, gil a écrit : > > I will try to explain better > > > > With OFBiz you could create minimalistic application where you could > define roles to a party to make them appear in one dropdown for a specific > > purpose. > > What I wanted to show is that through pragmatism, basic usage of > PartyRole can exist and be sufficient. > > > > But whereas a business need indicates that there is retirement of an > actor from a particular role, for me, then context "EntityNameRole" fits > for > > this. Thus I agree with PartyRelationship usage. > > > > In partyMgr component, when managing party relationships and party role, > since it is more like a technical component, I do not see how we can > > improve the screens and avoid having technical error like partyRole FK > constraint. And moreover, it is nice like this to me. > > > > For business oriented component, like HR, the choice of roles > managements process should be made, and if I understand well that the goal > of OFBIZ-5827. > > > > I hope it is clear > > > > Gil > > > > > > > > Le lun. 15 nov. 2021 à 1:25 pm, Jacques Le Roux < > jacques.le.r...@les7arts.com> a écrit : > >> 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 <mailto: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 > >>>> > >>> > > > > Le lun. 15 nov. 2021 à 1:25 pm, Jacques Le Roux < > jacques.le.r...@les7arts.com> a écrit : > >> 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 <mailto: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 > >>>> > >>> > > >
