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
