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
