Hi Jacques, All, Thank you for reminding us of ticket https://issues.apache.org/jira/browse/OFBIZ-5827, another indicator of the greater issue at hand. Having reread it today, I must conclude now that this ticket raised in October 2014 deserves more explanation (especially regarding edge cases).
Though I have tried to explain the bigger issue in various threads here (and in tickets) through examples before this thread, I failed to succeed. Does that mean that any of the related ticket is therefore null and void? I don't think so, as the greater part of the related tickets pertain to a specific use-case issue *and* are indicators of the greater issue. IMO, before we can start working towards a solution and addressing individual tickets in JIRA (or preferring one over another), we need answers to this question: Why should the community allow deviations from the general consensus regarding <entityName>Role entities (see [1], meaning having lifespan fields) to exist when talking about BudgetRole, InvoiceRole, SegmentGroupRole, SalesOpportunityRole, OrderRole, OrderItemRole, AgreementRole, CommunicationEventRole, ValidContactMechRole, PartyRole, FacilityGroupRole, ProductStoreGroupRole, ItemIssuanceRole, ShipmentReceiptRole, TimesheetRole in its codebase? What are these exceptional use-cases that make these <entityName>Role entities deviating from those under [1] so special that we need to have them in the codebase? Why not let these deviations reside at party using OFBiz? They can extend entity models to their particular needs, right? If we can find those answers, then I believe we can address the use cases regarding the screens/forms, etc. that a user of a single component can work with per OOTB functionality of OFBiz (I am here not talking about the user above all other users), and what the downstream records are that also need to be generated (as part of the request, if any). [1] <entityName>Role entities adhering to the general consensus: GlAccountRole, BillingAccountRole, ContentRole, DataResourceRole, WebsiteRole, MarketingCampaignRole, QuoteRole, RequirementRole,ProdCatalogRole, ProdCategoryRole, ProductRole, ProductStoreRole, PicklistRole, Met vriendelijke groet, Pierre Smits *Proud* *contributor** of* Apache OFBiz <https://ofbiz.apache.org/> since 2008 (without privileges) Proud contributor to the ASF since 2006 *Apache Directory <https://directory.apache.org>, PMC Member* On Mon, Nov 15, 2021 at 8:06 AM Jacques Le Roux < jacques.le.r...@les7arts.com> wrote: > Le 13/11/2021 à 19:26, Jacques Le Roux a écrit : > > Jacopo made an interesting comment at: https://s.apache.org/6s8lr that: > > > > <<There are pros and cons, or rather scenarios that are 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 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 > >
