Re: PartyRole usage in OFBiz

[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&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.

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

Re: [VOTE] Apache OFBiz 18.12.02

[Jacques Le Roux]

Le 13/11/2021 à 12:01, Jacopo Cappellato a écrit :

On Fri, Nov 5, 2021 at 11:12 AM Wiebke Pätzold 
wrote:


[...]
I committed the fix for the build in release18.12 and I also proviede a
PR for the ERROR Jacques mentioned for ViewBlogArticle in the following
Jira Ticket:

https://issues.apache.org/jira/browse/OFBIZ-12363

I would suggest to test these PR as well and then provid the new release
with both fixes.


Thank you Wiebke.
Should I proceed now with the preparation of the tentative release files?

Jacopo


Hi Jacopo,

Yes I think so

Jacques

Re: PartyRole usage in OFBiz

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

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&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274)
[4] 
https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274

Re: PartyRole usage in OFBiz

[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&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274
>> > )
>> > [4]
>> >
>> https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274
>> >
>>
>

Re: PartyRole usage in OFBiz

[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&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274
> > )
> > [4]
> >
> https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274
> >
>

Re: [VOTE] Apache OFBiz 18.12.02

[Jacopo Cappellato]

On Fri, Nov 5, 2021 at 11:12 AM Wiebke Pätzold 
wrote:

> [...]
> I committed the fix for the build in release18.12 and I also proviede a
> PR for the ERROR Jacques mentioned for ViewBlogArticle in the following
> Jira Ticket:
>
> https://issues.apache.org/jira/browse/OFBIZ-12363
>
> I would suggest to test these PR as well and then provid the new release
> with both fixes.


Thank you Wiebke.
Should I proceed now with the preparation of the tentative release files?

Jacopo

Re: PartyRole usage in OFBiz

[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&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274
> )
> [4]
> https://issues.apache.org/jira/browse/OFBIZ-5980?focusedCommentId=17441274&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17441274
>