(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, <gil.portensei...@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 > >
