[
https://issues.apache.org/jira/browse/OFBIZ-5980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17441274#comment-17441274
]
Jacques Le Roux edited comment on OFBIZ-5980 at 11/9/21, 6:36 PM:
------------------------------------------------------------------
Hi Pierre, All,
As you know, we had this discussion before. Gil proposes to continue the
discussion I tried to summarize at
[https://markmail.org/message/isaoze65bbciuytc].
To make thinkgs clear to everyone, below is the (lightly amended) content of
this summary. This said, to get the gist of it, it's better to read the
complete discussion. It's not that long (10 short messages).
But 1st we need to clarify the vocabular to be sure that everyone is speaking
about the same things.
# Suraj wrote the subject as "All roleType entities should maintain lifespan".
Reading the following posts, I don't think he was speaking about RoleType and
RoleTypeAttr but rather of EntityNameRole entities (including PartyRole)
# I asked to Nicolas
{quote}Hi Nicolas, Could you elaborate on the "hidden PartyRole value"? How is
it hidden? What does that mean exactly? Is it only about a hidden field in a
form for pre-selection?
{quote}but got no answers. I think he was speaking about filtering in screens
before creating a relationship between a party and another.
h4. Here is the summary
{quote}Nothing was added for almost 2 weeks. So I think we reached a lazy
consensus, let me summarise it here, as I see it:
# We don't want to add lifespan (add from/thruDate fields) to roleType
entities; so OFBIZ-5959, its subtasks and related tasks should be closed as
won't fix.
# We want (continue and generalise) to use EntityNameRole to handle parties
roles in specific contexts. This follows Len Silverston's "Flexible Contextual
Role Pattern" as {-}shown in figure 4 of [https://s.apache.org/tE19] and
explained there.{-}{^}*{^}
# We want to remove the FKs from EntityNameRole entities to PartyRole; so
ensurePartyRole service should be removed or used another way.{^}**{^}
It was suggested that PartyRole could be used in specific contexts. Filtering
in screens before creating a relationship between a party and another (I guess
that's what Nicolas proposed). Entity comes to mind (ie to create an
EntityNameRole record). This is though still disputed because some would prefer
to use only PartyRelationship for that, see OFBIZ-5827 and OFBIZ-5832 Pierre
Smits created for instance. The reason is PartyRole is not in relation with an
organisation when PartyRelationship is. So we still need to agree on
this.{^}***{^}
Note that there are cases were PartyRole is still needed. Notably for
PartyGoups like in createAcctgTransAndEntries:
{code:xml}
<!-- the organization party must be an internal organization -->
<entity-one entity-name="PartyRole" value-field="partyRole"
use-cache="true" auto-field-map="false">
<field-map field-name="partyId"
from-field="acctgTransEntry.organizationPartyId"/>
<field-map field-name="roleTypeId"
value="INTERNAL_ORGANIZATIO"/>
</entity-one>
<if-empty field="partyRole">
<log level="warning" message="The party with id
[${acctgTransEntry.organizationPartyId}] is not an internal organization; the
following accounting transaction will be ignored: ${acctgTransEntry}"/>
<else>
{code}
About the point 2, I want to add that the alternative would be to use the data
model proposed in Figure 9. But IMO it's better to decouple the 2 models
(business and architecture data models) and only possibly use the specific one
(business model) "on paper" to explain things to shareholders and alike...
There is no hurry because I think we don't want to deliver this before freezing
the next release (ie in about a month) and it's a big task. But we can already
work on it by creating Jira/s and providing patches for review.
Please check and let me know your thoughts if needed
{quote}
\* This no longer exists. For those we have not the book you can Google for :
[https://www.google.com/search?q=%22Flexible+Contextual+Role+Pattern%22&ie=UTF-8]
\** I quoted myself in a previous post from the same thread. As it's not so
clear, I meant to remove the relations from EntityNameRole entities to PartyRole
\*** I believe it's the 1st way to explore
A more recent discussion on the subject is
[https://markmail.org/message/4nmxre36cs7mjw4y]. There were more information
and opinions given in that convo.
as a conclusion I think we need an overhaul about EntityNameRole entities and
PartyRelationship
HTH (and not confusing)
was (Author: jacques.le.roux):
Hi Pierre, All,
As you know, we had this discussion before. Gil proposes to continue the
discussion I tried to summarize at
[https://markmail.org/message/isaoze65bbciuytc].
To make thinkgs clear to everyone, below is the (lightly amended) content of
this summary. This said, to get the gist of it, it's better to read the
complete discussion. It's not that long (10 short messages).
But 1st we need to clarify the vocabular to be sure that everyone is speaking
about the same things.
# Suraj wrote the subject as "All roleType entities should maintain lifespan".
Reading the following posts, I don't think he was speaking about RoleType and
RoleTypeAttr but rather of EntityNameRole entities (including PartyRole)
# I asked to Nicolas
{quote}Hi Nicolas, Could you elaborate on the "hidden PartyRole value"? How is
it hidden? What does that mean exactly? Is it only about a hidden field in a
form for pre-selection?
{quote}but got no answers. I think he was speaking about filtering in screens
before creating a relationship between a party and another.
h4. Here is the summary
{quote}Nothing was added for almost 2 weeks. So I think we reached a lazy
consensus, let me summarise it here, as I see it:
# We don't want to add lifespan (add from/thruDate fields) to roleType
entities; so OFBIZ-5959, its subtasks and related tasks should be closed as
won't fix.
# We want (continue and generalise) to use EntityNameRole to handle parties
roles in specific contexts. This follows Len Silverston's "Flexible Contextual
Role Pattern" as {-}shown in figure 4 of [https://s.apache.org/tE19] and
explained there.{-}{^}*{^}
# We want to remove the FKs from EntityNameRole entities to PartyRole; so
ensurePartyRole service should be removed or used another way.{^}**{^}
It was suggested that PartyRole could be used in specific contexts. Filtering
in screens before creating a relationship between a party and another (I guess
that's what Nicolas proposed). Entity comes to mind (ie to create an
EntityNameRole record). This is though still disputed because some would prefer
to use only PartyRelationship for that, see OFBIZ-5827 and OFBIZ-5832 Pierre
Smits created for instance. The reason is PartyRole is not in relation with an
organisation when PartyRelationship is. So we still need to agree on
this.{^}***{^}
Note that there are cases were PartyRole is still needed. Notably for
PartyGoups like in createAcctgTransAndEntries:
{code:xml}
<!-- the organization party must be an internal organization -->
<entity-one entity-name="PartyRole" value-field="partyRole"
use-cache="true" auto-field-map="false">
<field-map field-name="partyId"
from-field="acctgTransEntry.organizationPartyId"/>
<field-map field-name="roleTypeId"
value="INTERNAL_ORGANIZATIO"/>
</entity-one>
<if-empty field="partyRole">
<log level="warning" message="The party with id
[${acctgTransEntry.organizationPartyId}] is not an internal organization; the
following accounting transaction will be ignored: ${acctgTransEntry}"/>
<else>
{code}
About the point 2, I want to add that the alternative would be to use the data
model proposed in Figure 9. But IMO it's better to decouple the 2 models
(business and architecture data models) and only possibly use the specific one
(business model) "on paper" to explain things to shareholders and alike...
There is no hurry because I think we don't want to deliver this before freezing
the next release (ie in about a month) and it's a big task. But we can already
work on it by creating Jira/s and providing patches for review.
Please check and let me know your thoughts if needed
{quote}
* This no longer exists. For those we have not the book you can Google for :
[https://www.google.com/search?q=%22Flexible+Contextual+Role+Pattern%22&ie=UTF-8]
** I quoted myself in a previous post from the same thread. As it's not so
clear, I meant to remove the relations from EntityNameRole entities to PartyRole
*** I believe it's the 1st way to explore
A more recent discussion on the subject is
[https://markmail.org/message/4nmxre36cs7mjw4y]. There were more information
and opinions given in that convo.
as a conclusion I think we need an overhaul about EntityNameRole entities and
PartyRelationship
HTH (and not confusing)
> Have the ability to revoke (expire) roles of a party
> ----------------------------------------------------
>
> Key: OFBIZ-5980
> URL: https://issues.apache.org/jira/browse/OFBIZ-5980
> Project: OFBiz
> Issue Type: Bug
> Components: party
> Affects Versions: Trunk
> Reporter: Pierre Smits
> Assignee: Pierre Smits
> Priority: Major
> Labels: roles
> Fix For: Upcoming Branch
>
>
> Currently it is only possible to delete a PartyRole record from a party.
> Which leads to error messages, when that particular Partyrole record is
> associated with records in other entities where the PartyRole entity is set
> as a relation (through <relation rel-entity-name="PartyRole"> which is
> applied as a foreign key relation in the underlying dbms ).
> Examples of such related entities that are:
> * entity-name="MarketingCampaignRole"
> * entity-name="BudgetRole"
> In order to avoid such, it is better to revoke the PartyRole record by
> setting an expiration date (end date) on the record.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
