subject:"PartyRole usage in OFBiz"

Re: [Conclusion] PartyRole usage in OFBiz

2021-11-20 Thread Michael Brohl


+1

Thanks Scott,

Michael


Am 20.11.21 um 02:47 schrieb Scott Gray:

(Removing the private list since the discussion has no place there)

I don't think this topic needs any further debate at this stage.  Pierre
objects to having the tickets closed, so we can leave them open since that
is the easiest path and doesn't really come at any cost.

We don't need to resolve this disagreement until someone is ready to move
forward on an alternative solution that the community will accept.

Regards
Scott

On Sat, 20 Nov 2021, 09:35 Gil Portenseigne, 
wrote:


Hello Pierre,

Inline,

On Fri, Nov 19, 2021 at 06:48:40PM +0100, Pierre Smits wrote:

Hi Gil, All,

My apologies, but I have to object to this and for the following

reasoning:

Objections to pursuing improvements to the entity definition (for
PartyRole) and subsequent addressing front-end issues (screens/forms,
requests, services etc) for that and other entities impacted were raised,
before https://cwiki.apache.org/confluence/display/OFBIZ/EntityNameRole

was

brought forward now 4 days ago.

I'm aware about this page and discussion, if i'm not wrong, it is not
about adding lifespan into PartyRole entity. That is the point I wanted
to clarify. I'm not contesting this improvement, that can continue in a
dedicated thread.

If you think that subject is common please clarify to let us take
position on the PartyRole case (the only one I want to tackle at the
moment)


That page defines the requirements for any and all EntityNameRole entity,
including PartyRole. And the validity of what was stated there has not

been

contested up to now. Not even by those objecting to changes to PartyRole
(as it is included in the page) before the date/time of the page, and who
have remained silent since the availability of the page. I wanted to

wait a

bit longer, so that every contributor (and other readers of the dev ml)
could have an informed opinion, before suggesting to claim consensus on
that. But alas...

I did not gave date on purpose, there is no hurry, it was a way to
recenter the discussion about this specific case.

So it stands to reason that getting current existing and failing
EntityNameRole entities (including the PartyRole entity) compliant is
implied and thus warranted. And thus tickets can stay as they are. Just

the

order of improvements coming in is a concern that needs to be addressed
when they come in. And if such concerns can be addressed and eliminated
beforehand, so much the better.

Furthermore, one key aspect I would like to mention here. You mentioned

in

your comment (see [1]): 'The current applications IMO are not meant to be
used as is'.
This is a very wrong point of view, as the many users/contributors in

user

ml see differently.

That is mine, and claiming it is wrong because others see it differently
is not a valid argument to me.

Claiming that in webtools and partymgr there can be FK errors while
deleting PartyRole, is IMO not a good argument since those component are
*technical* ones that should not be used by *non technical* end users.

The idea is not the same for more business component like HR for
example, where I agree should be more usable for business end user.


Otherwise they would not raise a thread about the
workings of OFBiz, about functionalities not being good enough. Or a

ticket

in JIRA. They expect OFBiz as a business solutions to be usable as is,

as a

minimal viable product (MVP). They don't expect it to be perfect when

they

start using it. They'll trust that it will come along in due time.  And
they also don't expect it to have all the bells and whistles a particular
developer thinks necessary (while adding no value to the user). But, any
improvement brought forward to benefit all can/should go in. That is what
they expect.
And integrators downstream can take that and enhance for their own

audience

(current and future) as they see fit. It is not up to the integrators (as
you proclaimed in the same posting: 'It is our choices as Integrators to
decide') to decide what goes into OFBiz that works for all users, not

just

their own clients. System integrators don't contribute to an project to

the

ASF. Even if they would be able to do so, at the end the using company
decides).

You are interpreting my words. I was not talking about contribution, but
about integrators using Apache OFBiz for their customer. The decision I
was mentioning was about how they design their product to fill the need
for their customer, where there is not truth but choice to be made.

I remember discussion with you and others in Budapest (old good time)
that the applications are too big, present many features that
demonstrate the power of OFBiz, and this fact leads to being hardly
usable without customization.
In my experience, anytime I redevelop specific plugins for my end user
to simplify to their needs, that is the choice I made as an integrator
human being (not my company).


We need to work on that perception of contributors with

Re: [Conclusion] PartyRole usage in OFBiz

2021-11-19 Thread Scott Gray

(Removing the private list since the discussion has no place there)

I don't think this topic needs any further debate at this stage.  Pierre
objects to having the tickets closed, so we can leave them open since that
is the easiest path and doesn't really come at any cost.

We don't need to resolve this disagreement until someone is ready to move
forward on an alternative solution that the community will accept.

Regards
Scott

On Sat, 20 Nov 2021, 09:35 Gil Portenseigne, 
wrote:

> Hello Pierre,
>
> Inline,
>
> On Fri, Nov 19, 2021 at 06:48:40PM +0100, Pierre Smits wrote:
> > Hi Gil, All,
> >
> > My apologies, but I have to object to this and for the following
> reasoning:
> > Objections to pursuing improvements to the entity definition (for
> > PartyRole) and subsequent addressing front-end issues (screens/forms,
> > requests, services etc) for that and other entities impacted were raised,
> > before https://cwiki.apache.org/confluence/display/OFBIZ/EntityNameRole
> was
> > brought forward now 4 days ago.
>
> I'm aware about this page and discussion, if i'm not wrong, it is not
> about adding lifespan into PartyRole entity. That is the point I wanted
> to clarify. I'm not contesting this improvement, that can continue in a
> dedicated thread.
>
> If you think that subject is common please clarify to let us take
> position on the PartyRole case (the only one I want to tackle at the
> moment)
>
> >
> > That page defines the requirements for any and all EntityNameRole entity,
> > including PartyRole. And the validity of what was stated there has not
> been
> > contested up to now. Not even by those objecting to changes to PartyRole
> > (as it is included in the page) before the date/time of the page, and who
> > have remained silent since the availability of the page. I wanted to
> wait a
> > bit longer, so that every contributor (and other readers of the dev ml)
> > could have an informed opinion, before suggesting to claim consensus on
> > that. But alas...
>
> I did not gave date on purpose, there is no hurry, it was a way to
> recenter the discussion about this specific case.
> >
> > So it stands to reason that getting current existing and failing
> > EntityNameRole entities (including the PartyRole entity) compliant is
> > implied and thus warranted. And thus tickets can stay as they are. Just
> the
> > order of improvements coming in is a concern that needs to be addressed
> > when they come in. And if such concerns can be addressed and eliminated
> > beforehand, so much the better.
> >
> > Furthermore, one key aspect I would like to mention here. You mentioned
> in
> > your comment (see [1]): 'The current applications IMO are not meant to be
> > used as is'.
> > This is a very wrong point of view, as the many users/contributors in
> user
> > ml see differently.
>
> That is mine, and claiming it is wrong because others see it differently
> is not a valid argument to me.
>
> Claiming that in webtools and partymgr there can be FK errors while
> deleting PartyRole, is IMO not a good argument since those component are
> *technical* ones that should not be used by *non technical* end users.
>
> The idea is not the same for more business component like HR for
> example, where I agree should be more usable for business end user.
>
> > Otherwise they would not raise a thread about the
> > workings of OFBiz, about functionalities not being good enough. Or a
> ticket
> > in JIRA. They expect OFBiz as a business solutions to be usable as is,
> as a
> > minimal viable product (MVP). They don't expect it to be perfect when
> they
> > start using it. They'll trust that it will come along in due time.  And
> > they also don't expect it to have all the bells and whistles a particular
> > developer thinks necessary (while adding no value to the user). But, any
> > improvement brought forward to benefit all can/should go in. That is what
> > they expect.
>
> > And integrators downstream can take that and enhance for their own
> audience
> > (current and future) as they see fit. It is not up to the integrators (as
> > you proclaimed in the same posting: 'It is our choices as Integrators to
> > decide') to decide what goes into OFBiz that works for all users, not
> just
> > their own clients. System integrators don't contribute to an project to
> the
> > ASF. Even if they would be able to do so, at the end the using company
> > decides).
> You are interpreting my words. I was not talking about contribution, but
> about integrators using Apache OFBiz for their customer. The decision I
> was mentioning was about how they design their product to fill the need
> for their customer, where there is not truth but choice to be made.
>
> I remember discussion with you and others in Budapest (old good time)
> that the applications are too big, present many features that
> demonstrate the power of OFBiz, and this fact leads to being hardly
> usable without customization.
> In my experience, anytime I redevelop specific plugins for

Re: [Conclusion] PartyRole usage in OFBiz

2021-11-19 Thread Gil Portenseigne

Hello Pierre,

Inline,

On Fri, Nov 19, 2021 at 06:48:40PM +0100, Pierre Smits wrote:
> Hi Gil, All,
> 
> My apologies, but I have to object to this and for the following reasoning:
> Objections to pursuing improvements to the entity definition (for
> PartyRole) and subsequent addressing front-end issues (screens/forms,
> requests, services etc) for that and other entities impacted were raised,
> before https://cwiki.apache.org/confluence/display/OFBIZ/EntityNameRole was
> brought forward now 4 days ago.

I'm aware about this page and discussion, if i'm not wrong, it is not
about adding lifespan into PartyRole entity. That is the point I wanted
to clarify. I'm not contesting this improvement, that can continue in a
dedicated thread.

If you think that subject is common please clarify to let us take
position on the PartyRole case (the only one I want to tackle at the
moment)

> 
> That page defines the requirements for any and all EntityNameRole entity,
> including PartyRole. And the validity of what was stated there has not been
> contested up to now. Not even by those objecting to changes to PartyRole
> (as it is included in the page) before the date/time of the page, and who
> have remained silent since the availability of the page. I wanted to wait a
> bit longer, so that every contributor (and other readers of the dev ml)
> could have an informed opinion, before suggesting to claim consensus on
> that. But alas...

I did not gave date on purpose, there is no hurry, it was a way to
recenter the discussion about this specific case.
> 
> So it stands to reason that getting current existing and failing
> EntityNameRole entities (including the PartyRole entity) compliant is
> implied and thus warranted. And thus tickets can stay as they are. Just the
> order of improvements coming in is a concern that needs to be addressed
> when they come in. And if such concerns can be addressed and eliminated
> beforehand, so much the better.
> 
> Furthermore, one key aspect I would like to mention here. You mentioned in
> your comment (see [1]): 'The current applications IMO are not meant to be
> used as is'.
> This is a very wrong point of view, as the many users/contributors in user
> ml see differently.

That is mine, and claiming it is wrong because others see it differently
is not a valid argument to me. 

Claiming that in webtools and partymgr there can be FK errors while
deleting PartyRole, is IMO not a good argument since those component are
*technical* ones that should not be used by *non technical* end users.

The idea is not the same for more business component like HR for
example, where I agree should be more usable for business end user.

> Otherwise they would not raise a thread about the
> workings of OFBiz, about functionalities not being good enough. Or a ticket
> in JIRA. They expect OFBiz as a business solutions to be usable as is, as a
> minimal viable product (MVP). They don't expect it to be perfect when they
> start using it. They'll trust that it will come along in due time.  And
> they also don't expect it to have all the bells and whistles a particular
> developer thinks necessary (while adding no value to the user). But, any
> improvement brought forward to benefit all can/should go in. That is what
> they expect.

> And integrators downstream can take that and enhance for their own audience
> (current and future) as they see fit. It is not up to the integrators (as
> you proclaimed in the same posting: 'It is our choices as Integrators to
> decide') to decide what goes into OFBiz that works for all users, not just
> their own clients. System integrators don't contribute to an project to the
> ASF. Even if they would be able to do so, at the end the using company
> decides).
You are interpreting my words. I was not talking about contribution, but
about integrators using Apache OFBiz for their customer. The decision I
was mentioning was about how they design their product to fill the need
for their customer, where there is not truth but choice to be made.

I remember discussion with you and others in Budapest (old good time)
that the applications are too big, present many features that
demonstrate the power of OFBiz, and this fact leads to being hardly
usable without customization. 
In my experience, anytime I redevelop specific plugins for my end user
to simplify to their needs, that is the choice I made as an integrator
human being (not my company).

> We need to work on that perception of contributors with privileges, as it
> seems that this mindset (Integrators decide) is dictates the direction of
> this project.

I never meant that, i'm sure you know it, that is kinda rude.

Can we please focus on the subject ?

Thanks,

Gil



signature.asc
Description: PGP signature

Re: [Conclusion] PartyRole usage in OFBiz

2021-11-19 Thread Pierre Smits

Hi Gil, All,

My apologies, but I have to object to this and for the following reasoning:
Objections to pursuing improvements to the entity definition (for
PartyRole) and subsequent addressing front-end issues (screens/forms,
requests, services etc) for that and other entities impacted were raised,
before https://cwiki.apache.org/confluence/display/OFBIZ/EntityNameRole was
brought forward now 4 days ago.

That page defines the requirements for any and all EntityNameRole entity,
including PartyRole. And the validity of what was stated there has not been
contested up to now. Not even by those objecting to changes to PartyRole
(as it is included in the page) before the date/time of the page, and who
have remained silent since the availability of the page. I wanted to wait a
bit longer, so that every contributor (and other readers of the dev ml)
could have an informed opinion, before suggesting to claim consensus on
that. But alas...

So it stands to reason that getting current existing and failing
EntityNameRole entities (including the PartyRole entity) compliant is
implied and thus warranted. And thus tickets can stay as they are. Just the
order of improvements coming in is a concern that needs to be addressed
when they come in. And if such concerns can be addressed and eliminated
beforehand, so much the better.

Furthermore, one key aspect I would like to mention here. You mentioned in
your comment (see [1]): 'The current applications IMO are not meant to be
used as is'.
This is a very wrong point of view, as the many users/contributors in user
ml see differently. Otherwise they would not raise a thread about the
workings of OFBiz, about functionalities not being good enough. Or a ticket
in JIRA. They expect OFBiz as a business solutions to be usable as is, as a
minimal viable product (MVP). They don't expect it to be perfect when they
start using it. They'll trust that it will come along in due time.  And
they also don't expect it to have all the bells and whistles a particular
developer thinks necessary (while adding no value to the user). But, any
improvement brought forward to benefit all can/should go in. That is what
they expect.
And integrators downstream can take that and enhance for their own audience
(current and future) as they see fit. It is not up to the integrators (as
you proclaimed in the same posting: 'It is our choices as Integrators to
decide') to decide what goes into OFBiz that works for all users, not just
their own clients. System integrators don't contribute to an project to the
ASF. Even if they would be able to do so, at the end the using company
decides).
We need to work on that perception of contributors with privileges, as it
seems that this mindset (Integrators decide) is dictates the direction of
this project.

[1] https://lists.apache.org/thread/n9z54kljr1tmjo340bpontlvttcsttxk

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges).
13 years already. What does time fly (when happy contributing towards
improving OFBiz for all users)

Proud contributor to the ASF since 2006

*Apache Directory , PMC Member*

On Fri, Nov 19, 2021 at 5:03 PM Gil Portenseigne <
gil.portensei...@nereide.fr> wrote:

> Hello,
>
> I will try to summarize the ongoing thread, to produce a conclusion or
> potential plan. Sorry in advance, if I forgot some points.
>
> About the improvement of adding lifespan in PartyRole entity, the "Won't
> do"
> seems to get the consensus, since this improvement do not follow logical
> purpose (might for audit), and will introduce regressions and bugs risks if
> implemented.
>
> The discussion went to a new subjects, like using PartyRelationship for
> party
> selection screens.
> Opinion about removing PartyRole FK from EntityRole entities has been
> expressed.
> Those both topics can be lead into separate thread if needed, to let anyone
> envision it without being polluted by the previous discussion in the
> thread.
>
> If no one object I will close Jira about PartyRole lifespan.
>
> Thanks for your sharing, and Regards.
>
> Gil
>
>
>
>

[Conclusion] PartyRole usage in OFBiz

2021-11-19 Thread Gil Portenseigne

Hello,

I will try to summarize the ongoing thread, to produce a conclusion or
potential plan. Sorry in advance, if I forgot some points.

About the improvement of adding lifespan in PartyRole entity, the "Won't do"
seems to get the consensus, since this improvement do not follow logical
purpose (might for audit), and will introduce regressions and bugs risks if
implemented.

The discussion went to a new subjects, like using PartyRelationship for party
selection screens.
Opinion about removing PartyRole FK from EntityRole entities has been expressed.
Those both topics can be lead into separate thread if needed, to let anyone
envision it without being polluted by the previous discussion in the thread.

If no one object I will close Jira about PartyRole lifespan.

Thanks for your sharing, and Regards.

Gil





signature.asc
Description: PGP signature

Re: PartyRole usage in OFBiz

2021-11-16 Thread Jacques Le Roux


Le 16/11/2021 à 15:57, Jacques Le Roux a écrit :

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.


Except if you consider createPartyRelationshipAndRole, I forgot that point. You 
see others?

BTW, despite having created it, I'm now not sure createPartyRelationshipAndRole 
is relevant. It's only used thrice.

I still find it convenient, but it contraries the idea of removing PartyRole 
altogether. If ever we do that...




Jacques

Re: PartyRole usage in OFBiz

2021-11-16 Thread 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
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 since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory , 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?

Re: PartyRole usage in OFBiz

2021-11-16 Thread Jacques Le Roux

Hi Pierre,

You missed the relation with PartyRole that all have (but PartyRole of course). I believe this relation, or rather the PKs in it, is the crux of the
problem, as David suggested long ago.

The rest sounds good to me. We need to understand is why 15(!) other
EntityNameRoles don't comply with rules 5 and 7.
I hope it's only a miss and not something functional. It's maybe not a problem, and we could try to add them once we are sure that removing PKs in
relation from other EntityNameRoles works.

Jacques

Le 15/11/2021 à 18:48, Pierre Smits a écrit :

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 since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory , 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 > a
écrit :

Le 13/11/2021 à 19:26, Jacques Le Roux a écrit :

Jacopo made an interesting comment at: <>

that:

<
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,

Re: PartyRole usage in OFBiz

2021-11-15 Thread Pierre Smits

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  since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory , 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 > a
> écrit :
>  Le 13/11/2021 à 19:26, Jacques Le Roux a écrit :
> > Jacopo made an interesting comment at: <>
> that:
> >
> >< 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

Re: PartyRole usage in OFBiz

2021-11-15 Thread Jacques Le Roux

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
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 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: <> that:

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
a écrit :

Hi Gil,

Inline...

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

Hello,

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

Re: PartyRole usage in OFBiz

2021-11-15 Thread gil


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 
 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 
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: 
<> that:


   >

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

Re: PartyRole usage in OFBiz

2021-11-15 Thread Jacques Le Roux


Pierre,

Inline...

Le 15/11/2021 à 10:55, Pierre Smits a écrit :

Hi Jacques, All,

Thank you for reminding us of ticket
https://issues.apache.org/jira/browse/OFBIZ-5827, another indicator of the
greater issue at hand. Having reread it today, I must conclude now that
this ticket raised in October 2014 deserves more explanation (especially
regarding edge cases).

Though I have tried to explain the bigger issue in various threads here
(and in tickets) through examples before this thread, I failed to succeed.
Does that mean that any of the related ticket is therefore null and void? I
don't think so, as the greater part of the related tickets pertain to a
specific use-case issue *and* are indicators of the greater issue.

IMO, before we can start working towards a solution and addressing
individual tickets in JIRA (or preferring one over another), we need
answers to this question:

Why should the community allow deviations from the general consensus
regarding Role entities (see [1], meaning having lifespan
fields) to exist when talking about BudgetRole, InvoiceRole,
SegmentGroupRole, SalesOpportunityRole, OrderRole, OrderItemRole,
AgreementRole, CommunicationEventRole, ValidContactMechRole, PartyRole,
FacilityGroupRole, ProductStoreGroupRole, ItemIssuanceRole,
ShipmentReceiptRole, TimesheetRole in its codebase? What are these
exceptional use-cases that make these Role entities deviating
from those under [1] so special that we need to have them in the codebase?
Why not let these deviations reside at party using OFBiz? They can extend
entity models to their particular needs, right?


Though that's not the most important of my concerns in this discussion, of 
which is PartyRole vs  PartyRelationship.

Do you meant that all these entity should be the same but their names and 
specific 1st PK (ie not partyId and roleTypeId that must be everywhere)?
You insinuate that some Roles are deviating, but in which aspects?
Are there no reasonable reasons why some Roles are deviating?

But let's analyse your proposition; it may lead to something...

I had a look in natural (alphabetic) order and grouping them by cases. If we take 
BudgetRole as example, "deviating" ones are:
FinAccountRole, GlAccountRole, BillingAccountRole, ContentRole, DataResourceRole, MarketingCampaignRole, QuoteRole, RequirementRole, have as in 
addition from (as PK) and thru dates


OrderItemRole has in addition, to from (as PK) and thru dates, orderItemSeqId 
(logically as PK)
ProdCatalogRole has in addition, to from (as PK) and thru dates, prodCatalogId 
(logically as PK)
PicklistRole has in addition, to from (as PK) and thru dates, prodCatalogId 
(logically as PK)

ProductRole has in addition, to from (as PK) and thru dates, sequenceNum and 
comments (not PKs)
ProductStoreRole has in addition, to from (as PK) and thru dates, sequenceNum 
(not PK)
PicklistRole has in addition, to from (as PK) and thru dates, 
createdByUserLogin and lastModifiedByUserLogin (not PKs)

SegmentGroupRole, SalesOpportunityRole, OrderRole, AgreementRole, CommunicationEventRole, FacilityGroupRole, ProductStoreGroupRole, ItemIssuanceRole, 
ShipmentReceiptRole, TimesheetRole are similar to BudgetRole


ProductCategoryRole has in addition productCategoryId (logically as PK)
InvoiceRole has in addition datetimePerformed and percentage (not 
PKs)WebSiteRole has in addition from (as PK) and thru dates and webSiteId (not 
PKs)
CommunicationEventRole has in addition contactMechId (not PK)
ValidContactMechRole has logically not partyId PK

Unless I am mistaken, all of them have a "one" relation to PartyRole which is 
another of my concerns.

PartyRole is also similar to BudgetRole but of course has not relation to itself



If we can find those answers, then I believe we can address the use cases
regarding the screens/forms, etc. that a user of a single component can
work with per OOTB functionality of OFBiz (I am here not talking about the
user above all other users), and what the downstream records are that also
need to be generated (as part of the request, if any).

Were do we go from there, and why?

HTH

Jacques




[1] Role entities adhering to the general consensus:
GlAccountRole, BillingAccountRole, ContentRole, DataResourceRole,
WebsiteRole, MarketingCampaignRole, QuoteRole,
RequirementRole,ProdCatalogRole, ProdCategoryRole, ProductRole,
ProductStoreRole, PicklistRole,

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory , PMC Member*


On Mon, Nov 15, 2021 at 8:06 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Le 13/11/2021 à 19:26, Jacques Le Roux a écrit :

Jacopo made an interesting comment at: https://s.apache.org/6s8lr that:

<
by one approach and made more difficult by the other, to both ways of

interpreting PartyRole records.
The current approach, implemented in many

Re: PartyRole usage in OFBiz

2021-11-15 Thread Pierre Smits

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
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  since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory , 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: 
> that:
> >>>
> >>>< 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

Re: PartyRole usage in OFBiz

2021-11-15 Thread Jacques Le Roux

Hi Gil,

Inline...

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

Hello,

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
a écrit :

Le 13/11/2021 à 19:26, Jacques Le Roux a écrit :

Jacopo made an interesting comment at: that:

Hi Jacopo, All,

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

Re: PartyRole usage in OFBiz

2021-11-15 Thread Pierre Smits

Hi Jacques, All,

Thank you for reminding us of ticket
https://issues.apache.org/jira/browse/OFBIZ-5827, another indicator of the
greater issue at hand. Having reread it today, I must conclude now that
this ticket raised in October 2014 deserves more explanation (especially
regarding edge cases).

Though I have tried to explain the bigger issue in various threads here
(and in tickets) through examples before this thread, I failed to succeed.
Does that mean that any of the related ticket is therefore null and void? I
don't think so, as the greater part of the related tickets pertain to a
specific use-case issue *and* are indicators of the greater issue.

IMO, before we can start working towards a solution and addressing
individual tickets in JIRA (or preferring one over another), we need
answers to this question:

Why should the community allow deviations from the general consensus
regarding Role entities (see [1], meaning having lifespan
fields) to exist when talking about BudgetRole, InvoiceRole,
SegmentGroupRole, SalesOpportunityRole, OrderRole, OrderItemRole,
AgreementRole, CommunicationEventRole, ValidContactMechRole, PartyRole,
FacilityGroupRole, ProductStoreGroupRole, ItemIssuanceRole,
ShipmentReceiptRole, TimesheetRole in its codebase? What are these
exceptional use-cases that make these Role entities deviating
from those under [1] so special that we need to have them in the codebase?
Why not let these deviations reside at party using OFBiz? They can extend
entity models to their particular needs, right?

If we can find those answers, then I believe we can address the use cases
regarding the screens/forms, etc. that a user of a single component can
work with per OOTB functionality of OFBiz (I am here not talking about the
user above all other users), and what the downstream records are that also
need to be generated (as part of the request, if any).

[1] Role entities adhering to the general consensus:
GlAccountRole, BillingAccountRole, ContentRole, DataResourceRole,
WebsiteRole, MarketingCampaignRole, QuoteRole,
RequirementRole,ProdCatalogRole, ProdCategoryRole, ProductRole,
ProductStoreRole, PicklistRole,

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory , PMC Member*

On Mon, Nov 15, 2021 at 8:06 AM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Le 13/11/2021 à 19:26, Jacques Le Roux a écrit :
> > Jacopo made an interesting comment at: https://s.apache.org/6s8lr that:
> >
> >< 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
>
>

Re: PartyRole usage in OFBiz

2021-11-15 Thread gil


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 
 a écrit :

Le 13/11/2021 à 19:26, Jacques Le Roux a écrit :
Jacopo made an interesting comment at:  
that:


   >

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

Re: PartyRole usage in OFBiz

2021-11-14 Thread Jacques Le Roux


Le 13/11/2021 à 19:26, Jacques Le Roux a écrit :

Jacopo made an interesting comment at: https://s.apache.org/6s8lr that:

   <   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

Re: PartyRole usage in OFBiz

2021-11-14 Thread Jacques Le Roux

Ha yes indeed, that was wrong as I said in my answer to Taher. I guess we
crossed on wire, I did not write it in a single go.

Le 14/11/2021 à 20:00, Pierre Smits a écrit :

No. I linked to what you stated in [1]
https://github.com/apache/ofbiz-framework/pull/293

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory , PMC Member*

On Sun, Nov 14, 2021 at 6:42 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Hi Pierre,

Inline...

Le 13/11/2021 à 14:45, Pierre Smits a écrit :

Thank you, Gil, for referencing various pre-cursors to this discussion.

As some may experience a case of TLDR given the lenghty threads in your
listing of references, I will try to clarify the issue within its

context.

*** Does a user experience one or more issues with the 'remove'
functionality regarding the PartyRole entity? ***
Yes, they do. The user experiences an error message when he/she/they
removes (meaning delete) an PartyRole in either the party component or in
webtools.
This should be undesirable from the project's perspective. Hence Jacques
remark in [1].

As you somehow quoted me (I guess you speak about my 1st comment in
OFBIZ-5959), I want to mention the end of that comment:

And my next comment follow comments from other,notably from the late
Adrian:

I think it's enough to clarify my thoughts at that moment.

*** What is the root-cause of this issue? ***
This is two-fold:

1. functional: because in various Party and Role setting forms ( in
various applications other than party and webtools) there is no

limit to

which party can be paired to what role. Which is then taken by the
ensureParty as parameters and persisted as a PartyRole record.
2. technical: because of the PartyRole being used as a sql foreign

key

constraint in various other entities, and

*** Can the issue regarding the PartyRole be resolved technically? ***
It is not impossible, so yes. And preferable, as Jacopo points out,

without

introducing new bugs.

Addressing aspect #1, listed above, will reduce the number of erroneous
record going into the PartyRole table.
And evaluating each of the entities relating to aspect #2 whether there

an absolute (as in set-in-stone) necessity for having the sql foreign key
constraint on PartyRole.

When both are addressed, then the risk of introducing enhancements to the
PartyRole (and its associated forms, requests and service functions) is
minimised.

With my recent experience ending by a revert, I tend to agree, we can try
that. But something is unclear to me. What is an "erroneous record going
into the PartyRole table", how to limit them? Before doing anything this
needs to be defined.

For your second proposition, I think we can remove all FKs going to
PartyRole, using one-nofk in relations for instance, as proposed David.
As Scott wondered (I think he never proposed that) an even more audacious
endeavour would be to remove PartyRole altogether.

Jacques

Met vriendelijke groet,

Pierre Smits
*Contributing to* Apache OFBiz since 2008

(without

privileges)
Contributing to the ASF since 2006

*Apache Directory, PMC Member*

On Sat, Nov 13, 2021 at 11:59 AM Jacopo Cappellato <
jacopo.cappell...@gmail.com> wrote:

Thank you Gil.

In my opinion the *Role data model and the way OFBiz leverages it and

the

*Relationship data model are not ideal (some of the issues have been
mentioned in the various threads referenced by Gil) but I don't feel

that

this specific enhancement is relevant enough to justify the risk of
introducing new bugs, issues and regressions.

Jacopo

On Fri, Nov 12, 2021 at 10:07 AM Gil Portenseigne <
gil.portensei...@nereide.fr> wrote:

Hello,

I'm starting a new thread to discuss with the community about an
Improvement that has been submitted by Pierre Smits [1]
This topic has already been discussed in the past [2] and was conclude

a lazy consensus not to implement PartyRole lifespan into OFBiz.
Recently, this improvement was discussed again in Jira [3], and partly
commited, before being reverted when big blocking side effect where
discovered.
A more detailed summary has been made by Jacques here [4].
The enhancement is about adding fromDate and thruDate fields onto
PartyRole entity, modifying its primary key (fromDate)
The fact is that a such big subject need to be addressed with the
community consensus, as it is not trivial.
Please let us know you thoughts about this task and let's decide, if we
need to organize or if we need to close pending Jira with reference to

this

discussion ?

Thanks,
Gil
[1]https://issues.apache.org/jira/browse/OFBIZ-5959
[2]

https://markmail.org/message/pqrmv5vpjgm6iigq#query:+page:1+mid:isaoze65bbciuytc+state:results

Re: PartyRole usage in OFBiz

2021-11-14 Thread Pierre Smits

No. I linked to what you stated in [1]
https://github.com/apache/ofbiz-framework/pull/293


Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory , PMC Member*


On Sun, Nov 14, 2021 at 6:42 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi Pierre,
>
> Inline...
>
> Le 13/11/2021 à 14:45, Pierre Smits a écrit :
> > Thank you, Gil, for referencing various pre-cursors to this discussion.
> >
> > As some may experience a case of TLDR given the lenghty threads in your
> > listing of references, I will try to clarify the issue within its
> context.
> >
> > *** Does a user experience one or more issues with the 'remove'
> > functionality regarding the PartyRole entity? ***
> > Yes, they do. The user experiences an error message when he/she/they
> > removes (meaning delete) an PartyRole in either the party component or in
> > webtools.
> > This should be undesirable from the project's perspective. Hence Jacques
> > remark in [1].
>
> As you somehow quoted me (I guess you speak about my 1st comment in
> OFBIZ-5959), I want to mention the end of that comment:
>
> <>
>
> And my next comment follow comments from other,notably from the late
> Adrian:
>
> < As says Nicolas, this endeavour seems risky. What would be the
> alternatives?>>
>
> I think it's enough to clarify my thoughts at that moment.
>
>
> > *** What is the root-cause of this issue? ***
> > This is two-fold:
> >
> > 1. functional: because in various Party and Role setting forms ( in
> > various applications other than party and webtools) there is no
> limit to
> > which party can be paired to what role. Which is then taken by the
> > ensureParty as parameters and persisted as a PartyRole record.
> > 2. technical: because of the PartyRole being used as a sql foreign
> key
> > constraint in various other entities, and
> >
> > *** Can the issue regarding the PartyRole be resolved technically? ***
> > It is not impossible, so yes. And preferable, as Jacopo points out,
> without
> > introducing new bugs.
> >
> > Addressing aspect #1, listed above, will reduce the number of erroneous
> > record going into the PartyRole table.
> > And evaluating each of the entities relating to aspect #2 whether there
> is
> > an absolute (as in set-in-stone) necessity for having the sql foreign key
> > constraint on PartyRole.
> >
> > When both are addressed, then the risk of introducing enhancements to the
> > PartyRole (and its associated forms, requests and service functions) is
> > minimised.
>
> With my recent experience ending by a revert, I tend to agree, we can try
> that. But something is unclear to me. What is an "erroneous record going
> into the PartyRole table", how to limit them? Before doing anything this
> needs to be defined.
>
> For your second proposition, I think we can remove all FKs going to
> PartyRole, using one-nofk in relations for instance, as proposed David.
> As Scott wondered (I think he never proposed that) an even more audacious
> endeavour would be to remove PartyRole altogether.
>
> Jacques
>
> >
> > Met vriendelijke groet,
> >
> > Pierre Smits
> > *Contributing to* Apache OFBiz  since 2008
> (without
> > privileges)
> > Contributing to the ASF since 2006
> >
> > *Apache Directory, PMC Member*
> >
> >
> > On Sat, Nov 13, 2021 at 11:59 AM Jacopo Cappellato <
> > jacopo.cappell...@gmail.com> wrote:
> >
> >> Thank you Gil.
> >>
> >> In my opinion the *Role data model and the way OFBiz leverages it and
> the
> >> *Relationship data model are not ideal (some of the issues have been
> >> mentioned in the various threads referenced by Gil) but I don't feel
> that
> >> this specific enhancement is relevant enough to justify the risk of
> >> introducing new bugs, issues and regressions.
> >>
> >> Jacopo
> >>
> >>
> >> On Fri, Nov 12, 2021 at 10:07 AM Gil Portenseigne <
> >> gil.portensei...@nereide.fr> wrote:
> >>
> >>> Hello,
> >>>
> >>> I'm starting a new thread to discuss with the community about an
> >>> Improvement that has been submitted by Pierre Smits [1]
> >>> This topic has already been discussed in the past [2] and was conclude
> by
> >>> a lazy consensus not to implement PartyRole lifespan into OFBiz.
> >>> Recently, this improvement was discussed again in Jira [3], and partly
> >>> commited, before being reverted when big blocking side effect where
> >>> discovered.
> >>> A more detailed summary has been made by Jacques here [4].
> >>> The enhancement is about adding fromDate and thruDate fields onto
> >>> PartyRole entity, modifying its primary key (fromDate)
> >>> The fact is that a such big subject need to be addressed with the
> >>> community consensus, as it is not trivial.
> >>> Please let us know you thoughts about this task and let's decide, if we
> >>> need

Re: PartyRole usage in OFBiz

2021-11-14 Thread Jacques Le Roux

Hi Pierre,

Inline...

Le 13/11/2021 à 14:45, Pierre Smits a écrit :

Thank you, Gil, for referencing various pre-cursors to this discussion.

As some may experience a case of TLDR given the lenghty threads in your
listing of references, I will try to clarify the issue within its context.

As you somehow quoted me (I guess you speak about my 1st comment in
OFBIZ-5959), I want to mention the end of that comment:

And my next comment follow comments from other,notably from the late Adrian:

I think it's enough to clarify my thoughts at that moment.

*** What is the root-cause of this issue? ***
This is two-fold:

1. functional: because in various Party and Role setting forms ( in
various applications other than party and webtools) there is no limit to
which party can be paired to what role. Which is then taken by the
ensureParty as parameters and persisted as a PartyRole record.
2. technical: because of the PartyRole being used as a sql foreign key
constraint in various other entities, and

*** Can the issue regarding the PartyRole be resolved technically? ***
It is not impossible, so yes. And preferable, as Jacopo points out, without
introducing new bugs.

Addressing aspect #1, listed above, will reduce the number of erroneous
record going into the PartyRole table.
And evaluating each of the entities relating to aspect #2 whether there is
an absolute (as in set-in-stone) necessity for having the sql foreign key
constraint on PartyRole.

When both are addressed, then the risk of introducing enhancements to the
PartyRole (and its associated forms, requests and service functions) is
minimised.

With my recent experience ending by a revert, I tend to agree, we can try that. But something is unclear to me. What is an "erroneous record going
into the PartyRole table", how to limit them? Before doing anything this needs to be defined.

For your second proposition, I think we can remove all FKs going to PartyRole,
using one-nofk in relations for instance, as proposed David.
As Scott wondered (I think he never proposed that) an even more audacious
endeavour would be to remove PartyRole altogether.

Jacques

Met vriendelijke groet,

Pierre Smits
*Contributing to* Apache OFBiz since 2008 (without
privileges)
Contributing to the ASF since 2006

*Apache Directory, PMC Member*

On Sat, Nov 13, 2021 at 11:59 AM Jacopo Cappellato <
jacopo.cappell...@gmail.com> wrote:

Thank you Gil.

In my opinion the *Role data model and the way OFBiz leverages it and the
*Relationship data model are not ideal (some of the issues have been
mentioned in the various threads referenced by Gil) but I don't feel that
this specific enhancement is relevant enough to justify the risk of
introducing new bugs, issues and regressions.

Jacopo

On Fri, Nov 12, 2021 at 10:07 AM Gil Portenseigne <
gil.portensei...@nereide.fr> wrote:

Hello,

I'm starting a new thread to discuss with the community about an
Improvement that has been submitted by Pierre Smits [1]
This topic has already been discussed in the past [2] and was conclude by
a lazy consensus not to implement PartyRole lifespan into OFBiz.
Recently, this improvement was discussed again in Jira [3], and partly
commited, before being reverted when big blocking side effect where
discovered.
A more detailed summary has been made by Jacques here [4].
The enhancement is about adding fromDate and thruDate fields onto
PartyRole entity, modifying its primary key (fromDate)
The fact is that a such big subject need to be addressed with the
community consensus, as it is not trivial.
Please let us know you thoughts about this task and let's decide, if we
need to organize or if we need to close pending Jira with reference to

this

discussion ?

Thanks,
Gil
[1]https://issues.apache.org/jira/browse/OFBIZ-5959
[2]

https://markmail.org/message/pqrmv5vpjgm6iigq#query:+page:1+mid:isaoze65bbciuytc+state:results

[3]https://issues.apache.org/jira/browse/OFBIZ-5980 (

https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274

)
[4]

https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274

Re: PartyRole usage in OFBiz

2021-11-13 Thread Jacques Le Roux

Hi All,

I'm tempted to dismiss the debate with a wave of hand as it was discussed, and somehow concluded before (only point 4 below* was not conclusive).
Let's still analyse the different perspectives.

Jacopo made an interesting comment at: https://s.apache.org/6s8lr that:

Here is the opinion of one of the 2 OFBiz creators (David) on this subject (a
decade ago): https://markmail.org/message/a3wfv6ap4jrueq6r.
At this time Scott was already in favour of removing PartyRole altogether:
https://markmail.org/message/xwqzqsowaivb7hq7
In relation with this discussion, I then developed the createUpdatePartyRelationshipAndRoles service** that is still not used anywhere, maybe because
of rather ensurePartyRole usage.

Now maybe we need simple and clear arguments for the conclusions I repeat below.

In response to Taher I already spoke about auditing. One argument pro-adding-lifespan to PartyRole less (ie point 1). I use negative there because
there are maybe other pro-adding-lifespan arguments? I doubt there are.

I also think that the point 3 is crucial. Why would we want to have PKs in relations from EntityNameRole entities to PartyRole? I see no reasons but
maybe you see some? Or because of history. This needs to be clarified by investigation.

The point 4 is disputable because of history. I think it's the Gordian Knot that needs to be cut. I mean do we really need PartyRole, but for legacy
reason?

Maybe the point 3 + the usage of createUpdatePartyRelationshipAndRoles is enough to resolve the underlying issue. I think we should try that 1st, w/o
too much expectations.

I hope I'm clear, it's no that easy.

* Here is as simple as possible summary of the conclusions (better refer to
Gil's[4] for complete conclusions):

1. We don't want to add lifespan (add from/thruDate fields) to PartyRole. So
Jira related issues and subtasks should be closed as won't fix.
2. We want (continue and generalise) to use EntityNameRole to handle parties roles
in specific contexts. This follows Len Silverston's "Flexible
Contextual Role Pattern"
3. We want to remove the PKs in relations from EntityNameRole entities to
PartyRole (ie be one-nofk). Hence ensurePartyRole service should be removed
or used another way.
4. It was suggested that PartyRole could be used in specific contexts (eg
filtering in screens before creating a relationship between parties). This
is still disputed because some would prefer to use only PartyRelationship
for that. The reason is PartyRole is not in relation with an
organisation when PartyRelationship is.

** http://svn.apache.org/viewvc?view=revision=r893961

Create or update both parties roles and parties relationship,
partyRelationshipTypeId being mandatory.
The relationship is considered from one side or another (partyId is
checked internally against partyIdFrom)
If a type of parties relationship exists PartyIdTo or PartyIdFrom
are updated.
The history is maintained, allowing to track changes.

Jacques

Le 13/11/2021 à 14:45, Pierre Smits a écrit :

Thank you, Gil, for referencing various pre-cursors to this discussion.

As some may experience a case of TLDR given the lenghty threads in your
listing of references, I will try to clarify the issue within its context.

*** What is the root-cause of this issue? ***
This is two-fold:

*** Can the issue regarding the PartyRole be resolved technically? ***
It is not impossible, so yes. And preferable, as Jacopo points out, without
introducing new bugs.

When both are addressed, then the risk of introducing enhancements to the
PartyRole (and its associated forms, requests and service functions) is
minimised.

Met vriendelijke groet,

Pierre Smits
*Contributing to* Apache OFBiz since 2008 (without
privileges)
Contributing to the ASF since 2006

*Apache Directory, PMC

Re: PartyRole usage in OFBiz

2021-11-13 Thread Jacques Le Roux

Hi Taher,

Inline...

Le 12/11/2021 à 14:20, Taher Alkhateeb a écrit :

Hello Everyone,

From my understanding, fromDate and thruDate are primarily used for historical record purposes. This is useful only if a context exists such as in
relation to an Order, WorkEffort, Request or something like that.

FromDate and thruDate can also be useful in case of auditing. At the moment, PartyRoles can only be removed by their own users. I guess it's on
purpose because of the explanation you give below. Before reverting, I was interested in Pierre's solution provided at OFBIZ-5980, despite the
discussion at OFBIZ-5959, because of the audit aspect. Nothing better for a person to hide something that be able to erase his/her own role. But in
OFBiz, as we already discussed many times, it's not the goal of PartyRole that misses the organisation context. This is rather and correctly handled
by PartyRelationship where the organisation context is present. So it was a red herring as you clearly describe below.

I'll do a a more comprehensive post in this thread.

Jacques

The PartyRole entity on the other hand has a different purpose which I think is not context-bound. It is only used in other contexts to make sure
that a certain party has access to a certain role so the context can be applied. We can say it's almost like a security entity and it serves many
other entities but has no significant value on its own (e.g. I don't care when did we classify someone as customer, I care when was his / her first
order)

Hence history in PartyRole does not seem to serve any logical purpose (unless I'm missing something) and perhaps would lead to higher complexity for
no immediate realized value.

On 11/12/21 14:00, Michael Brohl wrote:

Hi Gil,

thanks for the summary and links to previous discussions and issues.

In my opinion, the conclusion is still valid and I agree to close the pending issues as
"Won't do".

Thanks and best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de

Am 12.11.21 um 10:07 schrieb Gil Portenseigne:

Hello,

A more detailed summary has been made by Jacques here [4].
The enhancement is about adding fromDate and thruDate fields onto PartyRole
entity, modifying its primary key (fromDate)
The fact is that a such big subject need to be addressed with the community
consensus, as it is not trivial.
Please let us know you thoughts about this task and let's decide, if we need to organize or if we need to close pending Jira with reference to
this discussion ?

Thanks,
Gil
[1] https://issues.apache.org/jira/browse/OFBIZ-5959
[2]
https://markmail.org/message/pqrmv5vpjgm6iigq#query:+page:1+mid:isaoze65bbciuytc+state:results
[3] https://issues.apache.org/jira/browse/OFBIZ-5980
(https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274)
[4]
https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274

Re: PartyRole usage in OFBiz

2021-11-13 Thread Pierre Smits

[1] https://github.com/apache/ofbiz-framework/pull/293

Met vriendelijke groet,

Pierre Smits
*Proud* *contributor** of* Apache OFBiz  since
2008 (without privileges)
Proud contributor to the ASF since 2006

*Apache Directory , PMC Member*


On Sat, Nov 13, 2021 at 2:45 PM Pierre Smits  wrote:

> Thank you, Gil, for referencing various pre-cursors to this discussion.
>
> As some may experience a case of TLDR given the lenghty threads in your
> listing of references, I will try to clarify the issue within its context.
>
> *** Does a user experience one or more issues with the 'remove'
> functionality regarding the PartyRole entity? ***
> Yes, they do. The user experiences an error message when he/she/they
> removes (meaning delete) an PartyRole in either the party component or in
> webtools.
> This should be undesirable from the project's perspective. Hence Jacques
> remark in [1].
>
> *** What is the root-cause of this issue? ***
> This is two-fold:
>
>1. functional: because in various Party and Role setting forms ( in
>various applications other than party and webtools) there is no limit to
>which party can be paired to what role. Which is then taken by the
>ensureParty as parameters and persisted as a PartyRole record.
>2. technical: because of the PartyRole being used as a sql foreign key
>constraint in various other entities, and
>
> *** Can the issue regarding the PartyRole be resolved technically? ***
> It is not impossible, so yes. And preferable, as Jacopo points out,
> without introducing new bugs.
>
> Addressing aspect #1, listed above, will reduce the number of erroneous
> record going into the PartyRole table.
> And evaluating each of the entities relating to aspect #2 whether there is
> an absolute (as in set-in-stone) necessity for having the sql foreign key
> constraint on PartyRole.
>
> When both are addressed, then the risk of introducing enhancements to the
> PartyRole (and its associated forms, requests and service functions) is
> minimised.
>
> Met vriendelijke groet,
>
> Pierre Smits
> *Contributing to* Apache OFBiz  since 2008 (without
> privileges)
> Contributing to the ASF since 2006
>
> *Apache Directory , PMC Member*
>
>
> On Sat, Nov 13, 2021 at 11:59 AM Jacopo Cappellato <
> jacopo.cappell...@gmail.com> wrote:
>
>> Thank you Gil.
>>
>> In my opinion the *Role data model and the way OFBiz leverages it and the
>> *Relationship data model are not ideal (some of the issues have been
>> mentioned in the various threads referenced by Gil) but I don't feel that
>> this specific enhancement is relevant enough to justify the risk of
>> introducing new bugs, issues and regressions.
>>
>> Jacopo
>>
>>
>> On Fri, Nov 12, 2021 at 10:07 AM Gil Portenseigne <
>> gil.portensei...@nereide.fr> wrote:
>>
>> > Hello,
>> >
>> > I'm starting a new thread to discuss with the community about an
>> > Improvement that has been submitted by Pierre Smits [1]
>> > This topic has already been discussed in the past [2] and was conclude
>> by
>> > a lazy consensus not to implement PartyRole lifespan into OFBiz.
>> > Recently, this improvement was discussed again in Jira [3], and partly
>> > commited, before being reverted when big blocking side effect where
>> > discovered.
>> > A more detailed summary has been made by Jacques here [4].
>> > The enhancement is about adding fromDate and thruDate fields onto
>> > PartyRole entity, modifying its primary key (fromDate)
>> > The fact is that a such big subject need to be addressed with the
>> > community consensus, as it is not trivial.
>> > Please let us know you thoughts about this task and let's decide, if we
>> > need to organize or if we need to close pending Jira with reference to
>> this
>> > discussion ?
>> >
>> > Thanks,
>> > Gil
>> > [1] https://issues.apache.org/jira/browse/OFBIZ-5959
>> > [2]
>> >
>> https://markmail.org/message/pqrmv5vpjgm6iigq#query:+page:1+mid:isaoze65bbciuytc+state:results
>> > [3] https://issues.apache.org/jira/browse/OFBIZ-5980 (
>> >
>> https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274
>> > )
>> > [4]
>> >
>> https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274
>> >
>>
>

Re: PartyRole usage in OFBiz

2021-11-13 Thread Pierre Smits

Thank you, Gil, for referencing various pre-cursors to this discussion.

As some may experience a case of TLDR given the lenghty threads in your
listing of references, I will try to clarify the issue within its context.

*** Does a user experience one or more issues with the 'remove'
functionality regarding the PartyRole entity? ***
Yes, they do. The user experiences an error message when he/she/they
removes (meaning delete) an PartyRole in either the party component or in
webtools.
This should be undesirable from the project's perspective. Hence Jacques
remark in [1].

*** What is the root-cause of this issue? ***
This is two-fold:

   1. functional: because in various Party and Role setting forms ( in
   various applications other than party and webtools) there is no limit to
   which party can be paired to what role. Which is then taken by the
   ensureParty as parameters and persisted as a PartyRole record.
   2. technical: because of the PartyRole being used as a sql foreign key
   constraint in various other entities, and

*** Can the issue regarding the PartyRole be resolved technically? ***
It is not impossible, so yes. And preferable, as Jacopo points out, without
introducing new bugs.

Addressing aspect #1, listed above, will reduce the number of erroneous
record going into the PartyRole table.
And evaluating each of the entities relating to aspect #2 whether there is
an absolute (as in set-in-stone) necessity for having the sql foreign key
constraint on PartyRole.

When both are addressed, then the risk of introducing enhancements to the
PartyRole (and its associated forms, requests and service functions) is
minimised.

Met vriendelijke groet,

Pierre Smits
*Contributing to* Apache OFBiz  since 2008 (without
privileges)
Contributing to the ASF since 2006

*Apache Directory , PMC Member*

On Sat, Nov 13, 2021 at 11:59 AM Jacopo Cappellato <
jacopo.cappell...@gmail.com> wrote:

> Thank you Gil.
>
> In my opinion the *Role data model and the way OFBiz leverages it and the
> *Relationship data model are not ideal (some of the issues have been
> mentioned in the various threads referenced by Gil) but I don't feel that
> this specific enhancement is relevant enough to justify the risk of
> introducing new bugs, issues and regressions.
>
> Jacopo
>
>
> On Fri, Nov 12, 2021 at 10:07 AM Gil Portenseigne <
> gil.portensei...@nereide.fr> wrote:
>
> > Hello,
> >
> > I'm starting a new thread to discuss with the community about an
> > Improvement that has been submitted by Pierre Smits [1]
> > This topic has already been discussed in the past [2] and was conclude by
> > a lazy consensus not to implement PartyRole lifespan into OFBiz.
> > Recently, this improvement was discussed again in Jira [3], and partly
> > commited, before being reverted when big blocking side effect where
> > discovered.
> > A more detailed summary has been made by Jacques here [4].
> > The enhancement is about adding fromDate and thruDate fields onto
> > PartyRole entity, modifying its primary key (fromDate)
> > The fact is that a such big subject need to be addressed with the
> > community consensus, as it is not trivial.
> > Please let us know you thoughts about this task and let's decide, if we
> > need to organize or if we need to close pending Jira with reference to
> this
> > discussion ?
> >
> > Thanks,
> > Gil
> > [1] https://issues.apache.org/jira/browse/OFBIZ-5959
> > [2]
> >
> https://markmail.org/message/pqrmv5vpjgm6iigq#query:+page:1+mid:isaoze65bbciuytc+state:results
> > [3] https://issues.apache.org/jira/browse/OFBIZ-5980 (
> >
> https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274
> > )
> > [4]
> >
> https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274
> >
>

Re: PartyRole usage in OFBiz

2021-11-13 Thread Jacopo Cappellato

Thank you Gil.

In my opinion the *Role data model and the way OFBiz leverages it and the
*Relationship data model are not ideal (some of the issues have been
mentioned in the various threads referenced by Gil) but I don't feel that
this specific enhancement is relevant enough to justify the risk of
introducing new bugs, issues and regressions.

Jacopo


On Fri, Nov 12, 2021 at 10:07 AM Gil Portenseigne <
gil.portensei...@nereide.fr> wrote:

> Hello,
>
> I'm starting a new thread to discuss with the community about an
> Improvement that has been submitted by Pierre Smits [1]
> This topic has already been discussed in the past [2] and was conclude by
> a lazy consensus not to implement PartyRole lifespan into OFBiz.
> Recently, this improvement was discussed again in Jira [3], and partly
> commited, before being reverted when big blocking side effect where
> discovered.
> A more detailed summary has been made by Jacques here [4].
> The enhancement is about adding fromDate and thruDate fields onto
> PartyRole entity, modifying its primary key (fromDate)
> The fact is that a such big subject need to be addressed with the
> community consensus, as it is not trivial.
> Please let us know you thoughts about this task and let's decide, if we
> need to organize or if we need to close pending Jira with reference to this
> discussion ?
>
> Thanks,
> Gil
> [1] https://issues.apache.org/jira/browse/OFBIZ-5959
> [2]
> https://markmail.org/message/pqrmv5vpjgm6iigq#query:+page:1+mid:isaoze65bbciuytc+state:results
> [3] https://issues.apache.org/jira/browse/OFBIZ-5980 (
> https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274
> )
> [4]
> https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274
>

Re: PartyRole usage in OFBiz

2021-11-12 Thread Taher Alkhateeb


Hello Everyone,

From my understanding, fromDate and thruDate are primarily used for 
historical record purposes. This is useful only if a context exists such 
as in relation to an Order, WorkEffort, Request or something like that.


The PartyRole entity on the other hand has a different purpose which I 
think is not context-bound. It is only used in other contexts to make 
sure that a certain party has access to a certain role so the context 
can be applied. We can say it's almost like a security entity and it 
serves many other entities but has no significant value on its own (e.g. 
I don't care when did we classify someone as customer, I care when was 
his / her first order)


Hence history in PartyRole does not seem to serve any logical purpose 
(unless I'm missing something) and perhaps would lead to higher 
complexity for no immediate realized value.


On 11/12/21 14:00, Michael Brohl wrote:

Hi Gil,

thanks for the summary and links to previous discussions and issues.

In my opinion, the conclusion is still valid and I agree to close the 
pending issues as "Won't do".


Thanks and best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 12.11.21 um 10:07 schrieb Gil Portenseigne:

Hello,

I'm starting a new thread to discuss with the community about an 
Improvement that has been submitted by Pierre Smits [1]
This topic has already been discussed in the past [2] and was 
conclude by a lazy consensus not to implement PartyRole lifespan into 
OFBiz.
Recently, this improvement was discussed again in Jira [3], and 
partly commited, before being reverted when big blocking side effect 
where discovered.

A more detailed summary has been made by Jacques here [4].
The enhancement is about adding fromDate and thruDate fields onto 
PartyRole entity, modifying its primary key (fromDate)
The fact is that a such big subject need to be addressed with the 
community consensus, as it is not trivial.
Please let us know you thoughts about this task and let's decide, if 
we need to organize or if we need to close pending Jira with 
reference to this discussion ?


Thanks,
Gil
[1] https://issues.apache.org/jira/browse/OFBIZ-5959
[2] 
https://markmail.org/message/pqrmv5vpjgm6iigq#query:+page:1+mid:isaoze65bbciuytc+state:results
[3] https://issues.apache.org/jira/browse/OFBIZ-5980 
(https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274)
[4] 
https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274

Re: PartyRole usage in OFBiz

2021-11-12 Thread Michael Brohl


Hi Gil,

thanks for the summary and links to previous discussions and issues.

In my opinion, the conclusion is still valid and I agree to close the 
pending issues as "Won't do".


Thanks and best regards,

Michael Brohl

ecomify GmbH - www.ecomify.de


Am 12.11.21 um 10:07 schrieb Gil Portenseigne:

Hello,

I'm starting a new thread to discuss with the community about an Improvement 
that has been submitted by Pierre Smits [1]
This topic has already been discussed in the past [2] and was conclude by a 
lazy consensus not to implement PartyRole lifespan into OFBiz.
Recently, this improvement was discussed again in Jira [3], and partly 
commited, before being reverted when big blocking side effect where discovered.
A more detailed summary has been made by Jacques here [4].
The enhancement is about adding fromDate and thruDate fields onto PartyRole 
entity, modifying its primary key (fromDate)
The fact is that a such big subject need to be addressed with the community 
consensus, as it is not trivial.
Please let us know you thoughts about this task and let's decide, if we need to 
organize or if we need to close pending Jira with reference to this discussion ?

Thanks,
Gil
[1] https://issues.apache.org/jira/browse/OFBIZ-5959
[2] 
https://markmail.org/message/pqrmv5vpjgm6iigq#query:+page:1+mid:isaoze65bbciuytc+state:results
[3] https://issues.apache.org/jira/browse/OFBIZ-5980 
(https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274)
[4] 
https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274

PartyRole usage in OFBiz

2021-11-12 Thread Gil Portenseigne

Hello,

I'm starting a new thread to discuss with the community about an Improvement 
that has been submitted by Pierre Smits [1]
This topic has already been discussed in the past [2] and was conclude by a 
lazy consensus not to implement PartyRole lifespan into OFBiz.
Recently, this improvement was discussed again in Jira [3], and partly 
commited, before being reverted when big blocking side effect where discovered.
A more detailed summary has been made by Jacques here [4].
The enhancement is about adding fromDate and thruDate fields onto PartyRole 
entity, modifying its primary key (fromDate)
The fact is that a such big subject need to be addressed with the community 
consensus, as it is not trivial.
Please let us know you thoughts about this task and let's decide, if we need to 
organize or if we need to close pending Jira with reference to this discussion ?

Thanks,
Gil
[1] https://issues.apache.org/jira/browse/OFBIZ-5959
[2] 
https://markmail.org/message/pqrmv5vpjgm6iigq#query:+page:1+mid:isaoze65bbciuytc+state:results
[3] https://issues.apache.org/jira/browse/OFBIZ-5980 
(https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274)
[4] 
https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274

Re: [Conclusion] PartyRole usage in OFBiz

Re: [Conclusion] PartyRole usage in OFBiz

Re: [Conclusion] PartyRole usage in OFBiz

Re: [Conclusion] PartyRole usage in OFBiz

[Conclusion] PartyRole usage in OFBiz

Re: PartyRole usage in OFBiz

Re: PartyRole usage in OFBiz

Re: PartyRole usage in OFBiz

Re: PartyRole usage in OFBiz

Re: PartyRole usage in OFBiz

Re: PartyRole usage in OFBiz

Re: PartyRole usage in OFBiz

Re: PartyRole usage in OFBiz

Re: PartyRole usage in OFBiz

Re: PartyRole usage in OFBiz

Re: PartyRole usage in OFBiz

Re: PartyRole usage in OFBiz

Re: PartyRole usage in OFBiz

Re: PartyRole usage in OFBiz

Re: PartyRole usage in OFBiz

Re: PartyRole usage in OFBiz

Re: PartyRole usage in OFBiz

Re: PartyRole usage in OFBiz

Re: PartyRole usage in OFBiz

Re: PartyRole usage in OFBiz

Re: PartyRole usage in OFBiz

Re: PartyRole usage in OFBiz

PartyRole usage in OFBiz

28 matches

Site Navigation

Mail list logo

Footer information