Re: [VOTE] Apache OFBiz 18.12.02 (second attempt)

[Jacques Le Roux]

+1

$ ./verify-ofbiz-release.sh apache-ofbiz-18.12.02.zip
sha check of file: apache-ofbiz-18.12.02.zip
Using sha file: apache-ofbiz-18.12.02.zip.sha512
apache-ofbiz-18.12.02.zip: BED7D644 ED80DDE3 C94FDD53 473E49DD 5A29CF84 0FFC53D5 2CDBA1F3 FFE5F8B8 48DF123E EB816159 708C01A8 31ECBF7F D7476CD3 
59369170 F73EEB60 491768AC
apache-ofbiz-18.12.02.zip: BED7D644 ED80DDE3 C94FDD53 473E49DD 5A29CF84 0FFC53D5 2CDBA1F3 FFE5F8B8 48DF123E EB816159 708C01A8 31ECBF7F D7476CD3 
59369170 F73EEB60 491768AC

sha checksum OK

GPG verification output
gpg: Signature made Tue Nov 16 17:00:38 2021
gpg:    using RSA key 7A580908847AF9E0
gpg: Good signature from "Jacopo Cappellato (CODE SIGNING KEY) 
"

Tests OK but I had to change maxErrors to 39654 to pass checkstyle

Jacques


Le 16/11/2021 à 17:26, Jacopo Cappellato a écrit :

This is the second vote thread to publish "Apache OFBiz 18.12.02", the
second release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.02.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.02.zip.asc: the detached signature file
* apache-ofbiz-18.12.02.zip.sha512: checksum file

Please download and test the zip file and its signatures (for instructions
on testing the signatures see http://www.apache.org/info/verification.html).

Vote:
[ +1] release as Apache OFBiz 18.12.02
[ -1] do not release

This vote will be open for 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Best Regards,

Jacopo

[VOTE] Apache OFBiz 18.12.02 (second attempt)

[Jacopo Cappellato]

This is the second vote thread to publish "Apache OFBiz 18.12.02", the
second release from the release18.12 branch.

The release files can be downloaded from here:
https://dist.apache.org/repos/dist/dev/ofbiz/
and are:
* apache-ofbiz-18.12.02.zip
* KEYS: text file with keys
* apache-ofbiz-18.12.02.zip.asc: the detached signature file
* apache-ofbiz-18.12.02.zip.sha512: checksum file

Please download and test the zip file and its signatures (for instructions
on testing the signatures see http://www.apache.org/info/verification.html).

Vote:
[ +1] release as Apache OFBiz 18.12.02
[ -1] do not release

This vote will be open for 5 days.

For more details about this process please refer to
http://www.apache.org/foundation/voting.html

Best Regards,

Jacopo

Re: PartyRole usage in OFBiz

[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 

EntityNameRole (was re: PartyNameRole)

[Pierre Smits]

Hi Jacques, All,

My apologies. I should have pulled it out of the originating thread. Doing
so now.

See inline.

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 Tue, Nov 16, 2021 at 3:48 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

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

As the necessity to having a relation to PartyRole for other EntityNameRole
definitions is a topic of discussion in the other thread (as it was back
then), I chose to leave it out for now. As soon as a consensus has been
reached regarding that topic it can be included in the page.


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

I presume, that the contributor who contributed the entity definition
either:

   1. started from scratch (without knowing about another contributor's
   commits that are similar)
   2. took the PartyRole entity as inspiration, copy-pasted it and adjusted
   to his/her/them needs, without researching whether similar EntityNameRole
   definitions existed
   3. didn't see the need to include fromDate and thruDate

Or maybe all of the above, if that is possible.
Aspect #1 would explain why some don't comply with rule #2.



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

Re: PartyRole usage in OFBiz

[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

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

It