CustRequestParty entity

[Adrian Crum-3]

The CustRequestParty entity seems to be an implementation of the Request
Role Type entity in The Data Model Resource Book. Besides the name
difference, the only other difference is using Role Type instead of
Request Role Type. Reusing Role Type in this way is okay from my
perspective. The problem is, the CustRequestParty entity isn't related
to Role Type, instead it is related to PartyRole - which requires a
PartyRole entry.

That is an extremely limiting relationship - a party can't be related to
a Request in a particular role unless they are already a member of that
role.

I would like to change that relationship from PartyRole to RoleType. Any
thoughts?

-Adrian

[David E. Jones-2]

On May 13, 2011, at 1:28 PM, Adrian Crum wrote:

> The CustRequestParty entity seems to be an implementation of the Request Role Type entity in The Data Model Resource Book. Besides the name difference, the only other difference is using Role Type instead of Request Role Type. Reusing Role Type in this way is okay from my perspective. The problem is, the CustRequestParty entity isn't related to Role Type, instead it is related to PartyRole - which requires a PartyRole entry.
>
> That is an extremely limiting relationship - a party can't be related to a Request in a particular role unless they are already a member of that role.

Pretty much all *Role and *Party entities are setup this way, and in fact nearly all entities that have pairs of partyId and roleTypeId have a type one relationship to PartyRole. This is a pattern that goes back to the beginning of OFBiz and is used throughout the project.

I agree with making the change so that all of these have fks to Party and RoleType separately, so not requiring an entry in PartyRole, but keep in mind that's a big change. I've actually done this in the Mantle UDM, but that was easy because there aren't any dependencies on that data model yet... for OFBiz it's a bit more work.

BTW, this goes back to the original pattern for party roles where the concept was that a party being in a role (ie with a PartyRole record) means nothing, and roles should just be used to define how parties are related to other records in the system. However, no one seems to want to follow that pattern so by de facto practice it's a moot point, and IMO ideally we would get rid of PartyRole altogether, or use it for specific and limited circumstances. The reason is that 99% of the time someone comes up with a constraint like "Party X is in Role Y" they are forgetting other important details, like in Role Y for Record Z.

-David

[Adrian Crum-3]

On 5/13/2011 1:36 PM, David E Jones wrote:

> On May 13, 2011, at 1:28 PM, Adrian Crum wrote:
>
>> The CustRequestParty entity seems to be an implementation of the Request Role Type entity in The Data Model Resource Book. Besides the name difference, the only other difference is using Role Type instead of Request Role Type. Reusing Role Type in this way is okay from my perspective. The problem is, the CustRequestParty entity isn't related to Role Type, instead it is related to PartyRole - which requires a PartyRole entry.
>>
>> That is an extremely limiting relationship - a party can't be related to a Request in a particular role unless they are already a member of that role.
> Pretty much all *Role and *Party entities are setup this way, and in fact nearly all entities that have pairs of partyId and roleTypeId have a type one relationship to PartyRole. This is a pattern that goes back to the beginning of OFBiz and is used throughout the project.
>
> I agree with making the change so that all of these have fks to Party and RoleType separately, so not requiring an entry in PartyRole, but keep in mind that's a big change. I've actually done this in the Mantle UDM, but that was easy because there aren't any dependencies on that data model yet... for OFBiz it's a bit more work.
>
> BTW, this goes back to the original pattern for party roles where the concept was that a party being in a role (ie with a PartyRole record) means nothing, and roles should just be used to define how parties are related to other records in the system. However, no one seems to want to follow that pattern so by de facto practice it's a moot point, and IMO ideally we would get rid of PartyRole altogether, or use it for specific and limited circumstances. The reason is that 99% of the time someone comes up with a constraint like "Party X is in Role Y" they are forgetting other important details, like in Role Y for Record Z.
>

Thanks for the reply!

I don't think this particular change is a big one. I suspect the
relationship can be changed without much fuss, but I will check into it
further.

There shouldn't be any confusion about Party Role if we follow the
author's reasoning for it: It is intended to describe the party's role
in the enterprise or organization. In Request Role, the relationship
being described is a party's role in the request, not the party's role
in the enterprise. That's why Request Role is related directly to a Role
Type and not a Party Role.

-Adrian

[David E. Jones-2]

On May 13, 2011, at 1:47 PM, Adrian Crum wrote:

> On 5/13/2011 1:36 PM, David E Jones wrote:
>> On May 13, 2011, at 1:28 PM, Adrian Crum wrote:
>>
>>> The CustRequestParty entity seems to be an implementation of the Request Role Type entity in The Data Model Resource Book. Besides the name difference, the only other difference is using Role Type instead of Request Role Type. Reusing Role Type in this way is okay from my perspective. The problem is, the CustRequestParty entity isn't related to Role Type, instead it is related to PartyRole - which requires a PartyRole entry.
>>>
>>> That is an extremely limiting relationship - a party can't be related to a Request in a particular role unless they are already a member of that role.
>> Pretty much all *Role and *Party entities are setup this way, and in fact nearly all entities that have pairs of partyId and roleTypeId have a type one relationship to PartyRole. This is a pattern that goes back to the beginning of OFBiz and is used throughout the project.
>>
>> I agree with making the change so that all of these have fks to Party and RoleType separately, so not requiring an entry in PartyRole, but keep in mind that's a big change. I've actually done this in the Mantle UDM, but that was easy because there aren't any dependencies on that data model yet... for OFBiz it's a bit more work.
>>
>> BTW, this goes back to the original pattern for party roles where the concept was that a party being in a role (ie with a PartyRole record) means nothing, and roles should just be used to define how parties are related to other records in the system. However, no one seems to want to follow that pattern so by de facto practice it's a moot point, and IMO ideally we would get rid of PartyRole altogether, or use it for specific and limited circumstances. The reason is that 99% of the time someone comes up with a constraint like "Party X is in Role Y" they are forgetting other important details, like in Role Y for Record Z.
>>
>
> Thanks for the reply!
>
> I don't think this particular change is a big one. I suspect the relationship can be changed without much fuss, but I will check into it further.
>
> There shouldn't be any confusion about Party Role if we follow the author's reasoning for it: It is intended to describe the party's role in the enterprise or organization. In Request Role, the relationship being described is a party's role in the request, not the party's role in the enterprise. That's why Request Role is related directly to a Role Type and not a Party Role.

Yeah, this is exactly the sort of misunderstanding I'm referring to. You wrote "It is intended to describe the party's role in the enterprise or organization" and "not the party's role in the enterprise. That's why Request Role is related directly to a Role Type and not a Party Role."

However, a record in PartyRole is NOT meant to represent a Party's role within the enterprise or organization, if you want to model that you should have a PartyRelationship record going between the Party record for the enterprise or organization... not a PartyRole that just ties a partyId to a roleTypeId without any consideration of the enterprise or organization. It's inflexible and generally bad modeling, and if something in The Data Model Resource Book seems to describe it this way I'd be surprised, chances are whatever you think means this really means something else.

-David

[Adrian Crum-3]

On 5/13/2011 1:53 PM, David E Jones wrote:

> On May 13, 2011, at 1:47 PM, Adrian Crum wrote:
>
>> On 5/13/2011 1:36 PM, David E Jones wrote:
>>> On May 13, 2011, at 1:28 PM, Adrian Crum wrote:
>>>
>>>> The CustRequestParty entity seems to be an implementation of the Request Role Type entity in The Data Model Resource Book. Besides the name difference, the only other difference is using Role Type instead of Request Role Type. Reusing Role Type in this way is okay from my perspective. The problem is, the CustRequestParty entity isn't related to Role Type, instead it is related to PartyRole - which requires a PartyRole entry.
>>>>
>>>> That is an extremely limiting relationship - a party can't be related to a Request in a particular role unless they are already a member of that role.
>>> Pretty much all *Role and *Party entities are setup this way, and in fact nearly all entities that have pairs of partyId and roleTypeId have a type one relationship to PartyRole. This is a pattern that goes back to the beginning of OFBiz and is used throughout the project.
>>>
>>> I agree with making the change so that all of these have fks to Party and RoleType separately, so not requiring an entry in PartyRole, but keep in mind that's a big change. I've actually done this in the Mantle UDM, but that was easy because there aren't any dependencies on that data model yet... for OFBiz it's a bit more work.
>>>
>>> BTW, this goes back to the original pattern for party roles where the concept was that a party being in a role (ie with a PartyRole record) means nothing, and roles should just be used to define how parties are related to other records in the system. However, no one seems to want to follow that pattern so by de facto practice it's a moot point, and IMO ideally we would get rid of PartyRole altogether, or use it for specific and limited circumstances. The reason is that 99% of the time someone comes up with a constraint like "Party X is in Role Y" they are forgetting other important details, like in Role Y for Record Z.
>>>
>> Thanks for the reply!
>>
>> I don't think this particular change is a big one. I suspect the relationship can be changed without much fuss, but I will check into it further.
>>
>> There shouldn't be any confusion about Party Role if we follow the author's reasoning for it: It is intended to describe the party's role in the enterprise or organization. In Request Role, the relationship being described is a party's role in the request, not the party's role in the enterprise. That's why Request Role is related directly to a Role Type and not a Party Role.
> Yeah, this is exactly the sort of misunderstanding I'm referring to. You wrote "It is intended to describe the party's role in the enterprise or organization" and "not the party's role in the enterprise. That's why Request Role is related directly to a Role Type and not a Party Role."
>
> However, a record in PartyRole is NOT meant to represent a Party's role within the enterprise or organization, if you want to model that you should have a PartyRelationship record going between the Party record for the enterprise or organization... not a PartyRole that just ties a partyId to a roleTypeId without any consideration of the enterprise or organization. It's inflexible and generally bad modeling, and if something in The Data Model Resource Book seems to describe it this way I'd be surprised, chances are whatever you think means this really means something else.
>
>

Right. I over-simplified the meaning of Party Role to demonstrate the
differences in this case. Thank you for the clarification.

Semantics aside, we agree that the existing entity relationship I
described is incorrect, right?

-Adrian

[David E. Jones-2]

On May 13, 2011, at 2:02 PM, Adrian Crum wrote:

> On 5/13/2011 1:53 PM, David E Jones wrote:
>> On May 13, 2011, at 1:47 PM, Adrian Crum wrote:
>>
>>> On 5/13/2011 1:36 PM, David E Jones wrote:
>>>> On May 13, 2011, at 1:28 PM, Adrian Crum wrote:
>>>>
>>>>> The CustRequestParty entity seems to be an implementation of the Request Role Type entity in The Data Model Resource Book. Besides the name difference, the only other difference is using Role Type instead of Request Role Type. Reusing Role Type in this way is okay from my perspective. The problem is, the CustRequestParty entity isn't related to Role Type, instead it is related to PartyRole - which requires a PartyRole entry.
>>>>>
>>>>> That is an extremely limiting relationship - a party can't be related to a Request in a particular role unless they are already a member of that role.
>>>> Pretty much all *Role and *Party entities are setup this way, and in fact nearly all entities that have pairs of partyId and roleTypeId have a type one relationship to PartyRole. This is a pattern that goes back to the beginning of OFBiz and is used throughout the project.
>>>>
>>>> I agree with making the change so that all of these have fks to Party and RoleType separately, so not requiring an entry in PartyRole, but keep in mind that's a big change. I've actually done this in the Mantle UDM, but that was easy because there aren't any dependencies on that data model yet... for OFBiz it's a bit more work.
>>>>
>>>> BTW, this goes back to the original pattern for party roles where the concept was that a party being in a role (ie with a PartyRole record) means nothing, and roles should just be used to define how parties are related to other records in the system. However, no one seems to want to follow that pattern so by de facto practice it's a moot point, and IMO ideally we would get rid of PartyRole altogether, or use it for specific and limited circumstances. The reason is that 99% of the time someone comes up with a constraint like "Party X is in Role Y" they are forgetting other important details, like in Role Y for Record Z.
>>>>
>>> Thanks for the reply!
>>>
>>> I don't think this particular change is a big one. I suspect the relationship can be changed without much fuss, but I will check into it further.
>>>
>>> There shouldn't be any confusion about Party Role if we follow the author's reasoning for it: It is intended to describe the party's role in the enterprise or organization. In Request Role, the relationship being described is a party's role in the request, not the party's role in the enterprise. That's why Request Role is related directly to a Role Type and not a Party Role.
>> Yeah, this is exactly the sort of misunderstanding I'm referring to. You wrote "It is intended to describe the party's role in the enterprise or organization" and "not the party's role in the enterprise. That's why Request Role is related directly to a Role Type and not a Party Role."
>>
>> However, a record in PartyRole is NOT meant to represent a Party's role within the enterprise or organization, if you want to model that you should have a PartyRelationship record going between the Party record for the enterprise or organization... not a PartyRole that just ties a partyId to a roleTypeId without any consideration of the enterprise or organization. It's inflexible and generally bad modeling, and if something in The Data Model Resource Book seems to describe it this way I'd be surprised, chances are whatever you think means this really means something else.
>>
>>
>
> Right. I over-simplified the meaning of Party Role to demonstrate the differences in this case. Thank you for the clarification.
>
> Semantics aside, we agree that the existing entity relationship I described is incorrect, right?

Good question, I don't know that it's "incorrect"... but it is certainly cumbersome, and the initial point of that constraint (to help avoid the use of PartyRole without any context) is totally lost on probably every single person who uses OFBiz, with maybe just a couple of exceptions, so the pattern has failed in its intent.

The main point of my first response is that the pattern is used in dozens of places, to see a list look at the WebTools Entity Reference for the PartyRole entity and look at all of the type "many" relationships. Every one of those follows the pattern you described for CustRequestParty.

It's a good point that it is cumbersome and is of little use, and so we might as well get rid of those everywhere...

-David

[Adrian Crum-3]

On 5/13/2011 2:07 PM, David E Jones wrote:

> On May 13, 2011, at 2:02 PM, Adrian Crum wrote:
>
>> On 5/13/2011 1:53 PM, David E Jones wrote:
>>> On May 13, 2011, at 1:47 PM, Adrian Crum wrote:
>>>
>>>> On 5/13/2011 1:36 PM, David E Jones wrote:
>>>>> On May 13, 2011, at 1:28 PM, Adrian Crum wrote:
>>>>>
>>>>>> The CustRequestParty entity seems to be an implementation of the Request Role Type entity in The Data Model Resource Book. Besides the name difference, the only other difference is using Role Type instead of Request Role Type. Reusing Role Type in this way is okay from my perspective. The problem is, the CustRequestParty entity isn't related to Role Type, instead it is related to PartyRole - which requires a PartyRole entry.
>>>>>>
>>>>>> That is an extremely limiting relationship - a party can't be related to a Request in a particular role unless they are already a member of that role.
>>>>> Pretty much all *Role and *Party entities are setup this way, and in fact nearly all entities that have pairs of partyId and roleTypeId have a type one relationship to PartyRole. This is a pattern that goes back to the beginning of OFBiz and is used throughout the project.
>>>>>
>>>>> I agree with making the change so that all of these have fks to Party and RoleType separately, so not requiring an entry in PartyRole, but keep in mind that's a big change. I've actually done this in the Mantle UDM, but that was easy because there aren't any dependencies on that data model yet... for OFBiz it's a bit more work.
>>>>>
>>>>> BTW, this goes back to the original pattern for party roles where the concept was that a party being in a role (ie with a PartyRole record) means nothing, and roles should just be used to define how parties are related to other records in the system. However, no one seems to want to follow that pattern so by de facto practice it's a moot point, and IMO ideally we would get rid of PartyRole altogether, or use it for specific and limited circumstances. The reason is that 99% of the time someone comes up with a constraint like "Party X is in Role Y" they are forgetting other important details, like in Role Y for Record Z.
>>>>>
>>>> Thanks for the reply!
>>>>
>>>> I don't think this particular change is a big one. I suspect the relationship can be changed without much fuss, but I will check into it further.
>>>>
>>>> There shouldn't be any confusion about Party Role if we follow the author's reasoning for it: It is intended to describe the party's role in the enterprise or organization. In Request Role, the relationship being described is a party's role in the request, not the party's role in the enterprise. That's why Request Role is related directly to a Role Type and not a Party Role.
>>> Yeah, this is exactly the sort of misunderstanding I'm referring to. You wrote "It is intended to describe the party's role in the enterprise or organization" and "not the party's role in the enterprise. That's why Request Role is related directly to a Role Type and not a Party Role."
>>>
>>> However, a record in PartyRole is NOT meant to represent a Party's role within the enterprise or organization, if you want to model that you should have a PartyRelationship record going between the Party record for the enterprise or organization... not a PartyRole that just ties a partyId to a roleTypeId without any consideration of the enterprise or organization. It's inflexible and generally bad modeling, and if something in The Data Model Resource Book seems to describe it this way I'd be surprised, chances are whatever you think means this really means something else.
>>>
>>>
>> Right. I over-simplified the meaning of Party Role to demonstrate the differences in this case. Thank you for the clarification.
>>
>> Semantics aside, we agree that the existing entity relationship I described is incorrect, right?
> Good question, I don't know that it's "incorrect"... but it is certainly cumbersome, and the initial point of that constraint (to help avoid the use of PartyRole without any context) is totally lost on probably every single person who uses OFBiz, with maybe just a couple of exceptions, so the pattern has failed in its intent.
>
> The main point of my first response is that the pattern is used in dozens of places, to see a list look at the WebTools Entity Reference for the PartyRole entity and look at all of the type "many" relationships. Every one of those follows the pattern you described for CustRequestParty.
>
> It's a good point that it is cumbersome and is of little use, and so we might as well get rid of those everywhere...
>

The point I made earlier is that The Data Model Resource Book does not
put that constraint on the Request Role entity. The defacto OFBiz
pattern of enforcing that constraint everywhere a Role Type is used is
what seems incorrect to me. I suppose we could debate if the book is
incorrect, but I need to move on to other things...  ;-)

-Adrian

[David E. Jones-2]

On May 13, 2011, at 2:21 PM, Adrian Crum wrote:

> On 5/13/2011 2:07 PM, David E Jones wrote:
>> On May 13, 2011, at 2:02 PM, Adrian Crum wrote:
>>
>>> On 5/13/2011 1:53 PM, David E Jones wrote:
>>>> On May 13, 2011, at 1:47 PM, Adrian Crum wrote:
>>>>
>>>>> On 5/13/2011 1:36 PM, David E Jones wrote:
>>>>>> On May 13, 2011, at 1:28 PM, Adrian Crum wrote:
>>>>>>
>>>>>>> The CustRequestParty entity seems to be an implementation of the Request Role Type entity in The Data Model Resource Book. Besides the name difference, the only other difference is using Role Type instead of Request Role Type. Reusing Role Type in this way is okay from my perspective. The problem is, the CustRequestParty entity isn't related to Role Type, instead it is related to PartyRole - which requires a PartyRole entry.
>>>>>>>
>>>>>>> That is an extremely limiting relationship - a party can't be related to a Request in a particular role unless they are already a member of that role.
>>>>>> Pretty much all *Role and *Party entities are setup this way, and in fact nearly all entities that have pairs of partyId and roleTypeId have a type one relationship to PartyRole. This is a pattern that goes back to the beginning of OFBiz and is used throughout the project.
>>>>>>
>>>>>> I agree with making the change so that all of these have fks to Party and RoleType separately, so not requiring an entry in PartyRole, but keep in mind that's a big change. I've actually done this in the Mantle UDM, but that was easy because there aren't any dependencies on that data model yet... for OFBiz it's a bit more work.
>>>>>>
>>>>>> BTW, this goes back to the original pattern for party roles where the concept was that a party being in a role (ie with a PartyRole record) means nothing, and roles should just be used to define how parties are related to other records in the system. However, no one seems to want to follow that pattern so by de facto practice it's a moot point, and IMO ideally we would get rid of PartyRole altogether, or use it for specific and limited circumstances. The reason is that 99% of the time someone comes up with a constraint like "Party X is in Role Y" they are forgetting other important details, like in Role Y for Record Z.
>>>>>>
>>>>> Thanks for the reply!
>>>>>
>>>>> I don't think this particular change is a big one. I suspect the relationship can be changed without much fuss, but I will check into it further.
>>>>>
>>>>> There shouldn't be any confusion about Party Role if we follow the author's reasoning for it: It is intended to describe the party's role in the enterprise or organization. In Request Role, the relationship being described is a party's role in the request, not the party's role in the enterprise. That's why Request Role is related directly to a Role Type and not a Party Role.
>>>> Yeah, this is exactly the sort of misunderstanding I'm referring to. You wrote "It is intended to describe the party's role in the enterprise or organization" and "not the party's role in the enterprise. That's why Request Role is related directly to a Role Type and not a Party Role."
>>>>
>>>> However, a record in PartyRole is NOT meant to represent a Party's role within the enterprise or organization, if you want to model that you should have a PartyRelationship record going between the Party record for the enterprise or organization... not a PartyRole that just ties a partyId to a roleTypeId without any consideration of the enterprise or organization. It's inflexible and generally bad modeling, and if something in The Data Model Resource Book seems to describe it this way I'd be surprised, chances are whatever you think means this really means something else.
>>>>
>>>>
>>> Right. I over-simplified the meaning of Party Role to demonstrate the differences in this case. Thank you for the clarification.
>>>
>>> Semantics aside, we agree that the existing entity relationship I described is incorrect, right?
>> Good question, I don't know that it's "incorrect"... but it is certainly cumbersome, and the initial point of that constraint (to help avoid the use of PartyRole without any context) is totally lost on probably every single person who uses OFBiz, with maybe just a couple of exceptions, so the pattern has failed in its intent.
>>
>> The main point of my first response is that the pattern is used in dozens of places, to see a list look at the WebTools Entity Reference for the PartyRole entity and look at all of the type "many" relationships. Every one of those follows the pattern you described for CustRequestParty.
>>
>> It's a good point that it is cumbersome and is of little use, and so we might as well get rid of those everywhere...
>>
>
> The point I made earlier is that The Data Model Resource Book does not put that constraint on the Request Role entity. The defacto OFBiz pattern of enforcing that constraint everywhere a Role Type is used is what seems incorrect to me. I suppose we could debate if the book is incorrect, but I need to move on to other things...  ;-)

I don't know that it would be correct to even wonder whether or not the book is correct... in The Data Model Resource Book itself it mentions that the patterns and concepts in the book are not a physical data model and are not even meant to be used literally, they are just logical data model patterns.

Taking a quick peek at the book, there is detail about this in the "What Is the Intent of This Book and These Models?" section of Chapter 1 starting at the 4th paragraph, and the first few sections of Chapter 15 which talks about implementing the data model.

-David

[Adrian Crum-3]

On 5/13/2011 2:33 PM, David E Jones wrote:

> On May 13, 2011, at 2:21 PM, Adrian Crum wrote:
>
>> On 5/13/2011 2:07 PM, David E Jones wrote:
>>> On May 13, 2011, at 2:02 PM, Adrian Crum wrote:
>>>
>>>> On 5/13/2011 1:53 PM, David E Jones wrote:
>>>>> On May 13, 2011, at 1:47 PM, Adrian Crum wrote:
>>>>>
>>>>>> On 5/13/2011 1:36 PM, David E Jones wrote:
>>>>>>> On May 13, 2011, at 1:28 PM, Adrian Crum wrote:
>>>>>>>
>>>>>>>> The CustRequestParty entity seems to be an implementation of the Request Role Type entity in The Data Model Resource Book. Besides the name difference, the only other difference is using Role Type instead of Request Role Type. Reusing Role Type in this way is okay from my perspective. The problem is, the CustRequestParty entity isn't related to Role Type, instead it is related to PartyRole - which requires a PartyRole entry.
>>>>>>>>
>>>>>>>> That is an extremely limiting relationship - a party can't be related to a Request in a particular role unless they are already a member of that role.
>>>>>>> Pretty much all *Role and *Party entities are setup this way, and in fact nearly all entities that have pairs of partyId and roleTypeId have a type one relationship to PartyRole. This is a pattern that goes back to the beginning of OFBiz and is used throughout the project.
>>>>>>>
>>>>>>> I agree with making the change so that all of these have fks to Party and RoleType separately, so not requiring an entry in PartyRole, but keep in mind that's a big change. I've actually done this in the Mantle UDM, but that was easy because there aren't any dependencies on that data model yet... for OFBiz it's a bit more work.
>>>>>>>
>>>>>>> BTW, this goes back to the original pattern for party roles where the concept was that a party being in a role (ie with a PartyRole record) means nothing, and roles should just be used to define how parties are related to other records in the system. However, no one seems to want to follow that pattern so by de facto practice it's a moot point, and IMO ideally we would get rid of PartyRole altogether, or use it for specific and limited circumstances. The reason is that 99% of the time someone comes up with a constraint like "Party X is in Role Y" they are forgetting other important details, like in Role Y for Record Z.
>>>>>>>
>>>>>> Thanks for the reply!
>>>>>>
>>>>>> I don't think this particular change is a big one. I suspect the relationship can be changed without much fuss, but I will check into it further.
>>>>>>
>>>>>> There shouldn't be any confusion about Party Role if we follow the author's reasoning for it: It is intended to describe the party's role in the enterprise or organization. In Request Role, the relationship being described is a party's role in the request, not the party's role in the enterprise. That's why Request Role is related directly to a Role Type and not a Party Role.
>>>>> Yeah, this is exactly the sort of misunderstanding I'm referring to. You wrote "It is intended to describe the party's role in the enterprise or organization" and "not the party's role in the enterprise. That's why Request Role is related directly to a Role Type and not a Party Role."
>>>>>
>>>>> However, a record in PartyRole is NOT meant to represent a Party's role within the enterprise or organization, if you want to model that you should have a PartyRelationship record going between the Party record for the enterprise or organization... not a PartyRole that just ties a partyId to a roleTypeId without any consideration of the enterprise or organization. It's inflexible and generally bad modeling, and if something in The Data Model Resource Book seems to describe it this way I'd be surprised, chances are whatever you think means this really means something else.
>>>>>
>>>>>
>>>> Right. I over-simplified the meaning of Party Role to demonstrate the differences in this case. Thank you for the clarification.
>>>>
>>>> Semantics aside, we agree that the existing entity relationship I described is incorrect, right?
>>> Good question, I don't know that it's "incorrect"... but it is certainly cumbersome, and the initial point of that constraint (to help avoid the use of PartyRole without any context) is totally lost on probably every single person who uses OFBiz, with maybe just a couple of exceptions, so the pattern has failed in its intent.
>>>
>>> The main point of my first response is that the pattern is used in dozens of places, to see a list look at the WebTools Entity Reference for the PartyRole entity and look at all of the type "many" relationships. Every one of those follows the pattern you described for CustRequestParty.
>>>
>>> It's a good point that it is cumbersome and is of little use, and so we might as well get rid of those everywhere...
>>>
>> The point I made earlier is that The Data Model Resource Book does not put that constraint on the Request Role entity. The defacto OFBiz pattern of enforcing that constraint everywhere a Role Type is used is what seems incorrect to me. I suppose we could debate if the book is incorrect, but I need to move on to other things...  ;-)
> I don't know that it would be correct to even wonder whether or not the book is correct... in The Data Model Resource Book itself it mentions that the patterns and concepts in the book are not a physical data model and are not even meant to be used literally, they are just logical data model patterns.
>
> Taking a quick peek at the book, there is detail about this in the "What Is the Intent of This Book and These Models?" section of Chapter 1 starting at the 4th paragraph, and the first few sections of Chapter 15 which talks about implementing the data model.
>
>

Would you mind sharing with us the mantle UDM for Requests? I would be
interested in working on this, and if I can get it to match what you
have in mind - then so much the better.

-Adrian