Pierre,
Inline...
Le 15/11/2021 à 10:55, Pierre Smits a écrit :
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?
Though that's not the most important of my concerns in this discussion, of
which is PartyRole vs PartyRelationship.
Do you meant that all these entity should be the same but their names and
specific 1st PK (ie not partyId and roleTypeId that must be everywhere)?
You insinuate that some <entityName>Roles are deviating, but in which aspects?
Are there no reasonable reasons why some <entityName>Roles are deviating?
But let's analyse your proposition; it may lead to something...
I had a look in natural (alphabetic) order and grouping them by cases. If we take
BudgetRole as example, "deviating" ones are:
FinAccountRole, GlAccountRole, BillingAccountRole, ContentRole, DataResourceRole, MarketingCampaignRole, QuoteRole, RequirementRole, have as in
addition from (as PK) and thru dates
OrderItemRole has in addition, to from (as PK) and thru dates, orderItemSeqId
(logically as PK)
ProdCatalogRole has in addition, to from (as PK) and thru dates, prodCatalogId
(logically as PK)
PicklistRole has in addition, to from (as PK) and thru dates, prodCatalogId
(logically as PK)
ProductRole has in addition, to from (as PK) and thru dates, sequenceNum and
comments (not PKs)
ProductStoreRole has in addition, to from (as PK) and thru dates, sequenceNum
(not PK)
PicklistRole has in addition, to from (as PK) and thru dates,
createdByUserLogin and lastModifiedByUserLogin (not PKs)
SegmentGroupRole, SalesOpportunityRole, OrderRole, AgreementRole, CommunicationEventRole, FacilityGroupRole, ProductStoreGroupRole, ItemIssuanceRole,
ShipmentReceiptRole, TimesheetRole are similar to BudgetRole
ProductCategoryRole has in addition productCategoryId (logically as PK)
InvoiceRole has in addition datetimePerformed and percentage (not
PKs)WebSiteRole has in addition from (as PK) and thru dates and webSiteId (not
PKs)
CommunicationEventRole has in addition contactMechId (not PK)
ValidContactMechRole has logically not partyId PK
Unless I am mistaken, all of them have a "one" relation to PartyRole which is
another of my concerns.
PartyRole is also similar to BudgetRole but of course has not relation to itself
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).
Were do we go from there, and why?
HTH
Jacques
[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
