[Conclusion] PartyRole usage in OFBiz

[Gil Portenseigne <gi...@nereide.fr>]

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

Re: [Conclusion] PartyRole usage in OFBiz

[Michael Brohl <mi...@ecomify.de>]

+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, <gi...@nereide.fr>
> 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 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
>>
>>

Re: [Conclusion] PartyRole usage in OFBiz

[Scott Gray <sc...@hotwaxsystems.com>]

(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, <gi...@nereide.fr>
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 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
>
>

Re: [Conclusion] PartyRole usage in OFBiz

[Gil Portenseigne <gi...@nereide.fr>]

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

Re: [Conclusion] PartyRole usage in OFBiz

[Pierre Smits <pi...@apache.org>]

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 <https://ofbiz.apache.org/> 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 <https://directory.apache.org>, PMC Member*


On Fri, Nov 19, 2021 at 5:03 PM Gil Portenseigne <
gil.portenseigne@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
>
>
>
>