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: Welcome Wiebke Pätzold as new committer!

2021-11-14 Thread Priya Sharma 
Congratulations Wiebke!

On Thu, 4 Nov 2021 at 13:32, Nicolas Malin  wrote:

> Hello Wiebke, welcome aboard !
>
> Nicolas
>
> On 29/10/2021 16:47, Jacques Le Roux wrote:
> > Welcome aboard Wiebke,
> >
> > Your work is much appreciated!
> >
> > Jacques
> >
> > Le 27/10/2021 à 12:57, Aditya Sharma a écrit :
> >> The OFBiz PMC has invited Wiebke to become a new committer and we are
> >> pleased to announce that she has accepted the nomination.
> >>
> >> Wiebke has been an active contributor to Apache OFBiz since February
> >> 2020,
> >> and has made some significant contributions on minilang migration.
> >> She has
> >> also been helping out Michael with Apache OFBiz blogs.
> >>
> >> Thank you Wiebke for your valuable contributions so far and
> >> congratulations
> >> for your new role!
> >>
> >> Welcome aboard!
> >>
> >> Thanks and Regards,
> >> Aditya Sharma
> >
>
>

-- 
Best Regards,
Priya

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

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

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 to

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.

*** 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 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&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: [ofbiz-framework] branch release18.12 updated: Improved: modifies GH workflows to run on all branches

2021-11-14 Thread Jacques Le Roux 

Ha wait got it, no java nor js files changed, please forget it

Le 14/11/2021 à 15:49, jler...@apache.org a écrit :

Did not work either, asked at 
https://github.com/github/codeql-action/issues/462#issuecomment-968304521

Le 14/11/2021 à 15:39, jler...@apache.org a écrit :

This is an automated email from the ASF dual-hosted git repository.

jleroux pushed a commit to branch release18.12
in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git


The following commit(s) were added to refs/heads/release18.12 by this push:
  new 91357bb  Improved: modifies GH workflows to run on all branches
91357bb is described below

commit 91357bbf0eabd147b87385fd94cb0b139058fa12
Author: Jacques Le Roux 
AuthorDate: Sun Nov 14 15:39:02 2021 +0100

 Improved: modifies GH workflows to run on all branches
  I followed this answer: 
https://github.com/github/codeql-action/issues/462
 Too bad, it does not seem to work
https://github.com/apache/ofbiz-framework/actions/workflows/codeql-analysis.yml?query=branch%3Arelease18.12
 (OK for trunk: 
https://github.com/apache/ofbiz-framework/actions/workflows/codeql-analysis.yml?query=)
  I try the other syntax, ie '**'
---
  .github/workflows/codeql-analysis.yml | 1 +
  1 file changed, 1 insertion(+)

diff --git a/.github/workflows/codeql-analysis.yml 
b/.github/workflows/codeql-analysis.yml
index 35d32c7..f4205f4 100644
--- a/.github/workflows/codeql-analysis.yml
+++ b/.github/workflows/codeql-analysis.yml
@@ -25,6 +25,7 @@ name: "CodeQL"
    on:
    push:
+    branches: [ '**' ]
  paths:
  - '**.java'
  - '**.js'

Re: [ofbiz-framework] branch release18.12 updated: Improved: modifies GH workflows to run on all branches

2021-11-14 Thread jler...@apache.org 

Did not work either, asked at 
https://github.com/github/codeql-action/issues/462#issuecomment-968304521

Le 14/11/2021 à 15:39, jler...@apache.org a écrit :

This is an automated email from the ASF dual-hosted git repository.

jleroux pushed a commit to branch release18.12
in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git


The following commit(s) were added to refs/heads/release18.12 by this push:
  new 91357bb  Improved: modifies GH workflows to run on all branches
91357bb is described below

commit 91357bbf0eabd147b87385fd94cb0b139058fa12
Author: Jacques Le Roux 
AuthorDate: Sun Nov 14 15:39:02 2021 +0100

 Improved: modifies GH workflows to run on all branches
 
 I followed this answer: https://github.com/github/codeql-action/issues/462

 Too bad, it does not seem to work
 
https://github.com/apache/ofbiz-framework/actions/workflows/codeql-analysis.yml?query=branch%3Arelease18.12
 (OK for trunk: 
https://github.com/apache/ofbiz-framework/actions/workflows/codeql-analysis.yml?query=)
 
 I try the other syntax, ie '**'

---
  .github/workflows/codeql-analysis.yml | 1 +
  1 file changed, 1 insertion(+)

diff --git a/.github/workflows/codeql-analysis.yml 
b/.github/workflows/codeql-analysis.yml
index 35d32c7..f4205f4 100644
--- a/.github/workflows/codeql-analysis.yml
+++ b/.github/workflows/codeql-analysis.yml
@@ -25,6 +25,7 @@ name: "CodeQL"
  
  on:

push:
+branches: [ '**' ]
  paths:
  - '**.java'
  - '**.js'