OFBiz › OFBiz - User

Party Relationship and Party Roles

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

16 messages Options

Mansour

Party Relationship and Party Roles

I consulted the Data Model Resource Book to refresh my memory about
the modelling for the roles and relationship for Party.

In ofbiz, we have PartyRelationship between two parties. So each party
ID is used as a key, combined with the relationship type. The book
mentions on page 42, that when customizing the model, it's recommended
to draw the relationship between party roles.

The part that I find confusing is, if we have the two party IDs in the
party_role entity, why don't we create the relationship between two
party roles, instead of duplicating the information in the
party_relationship entity ? For example, currently we have,

party_relationship:
- from party id
- to party id
- from role type id
- to role type id
- start date
- end date .....

Can't we just use,
party_relationship:
-from role
- to role
- party relationship type

assuming John has the role of developer. IBM has the role of employer.
We can use the directly in the party relationship. Using the current
model, we need to add the role_type to the party_relationship. If John
is no longer a developer, then we need to update in two entities, the
party_relationship, and the roles.

I am not sure I understand the description in the book, and the design in ofbiz.

Can someone kindly clarify the picture for me ??

Thank you.

taher

Re: Party Relationship and Party Roles

Hi Mansour,

Simply speaking the party_role entity assigns roles to parties which can be
applied to many entities among which one of them is party_relationship. For
example, WorkEffortPartyAssignment links a party to a workeffort through a
role. Thus the partyrole is an entity to be (depending on some factors)
used for validation of the existence of the role before assigning it to one
of the relationship entities. At least that's my interpretation of it.

Taher Alkhateeb
On Oct 12, 2014 12:58 AM, "Mansour Al Akeel" <[hidden email]>
wrote:

> I consulted the Data Model Resource Book to refresh my memory about
> the modelling for the roles and relationship for Party.
>
> In ofbiz, we have PartyRelationship between two parties. So each party
> ID is used as a key, combined with the relationship type. The book
> mentions on page 42, that when customizing the model, it's recommended
> to draw the relationship between party roles.
>
> The part that I find confusing is, if we have the two party IDs in the
> party_role entity, why don't we create the relationship between two
> party roles, instead of duplicating the information in the
> party_relationship entity ? For example, currently we have,
>
> party_relationship:
> - from party id
> - to party id
> - from role type id
> - to role type id
> - start date
> - end date .....
>
> Can't we just use,
> party_relationship:
> -from role
> - to role
> - party relationship type
>
> assuming John has the role of developer. IBM has the role of employer.
> We can use the directly in the party relationship. Using the current
> model, we need to add the role_type to the party_relationship. If John
> is no longer a developer, then we need to update in two entities, the
> party_relationship, and the roles.
>
> I am not sure I understand the description in the book, and the design in
> ofbiz.
>
> Can someone kindly clarify the picture for me ??
>
> Thank you.
>

Mansour

Re: Party Relationship and Party Roles

Taher,
Thank you for th detailed explainatin. I understand the purpose of
party_role, and asking why do we link party_relatinship to party, rather
than party_role.

Party_role entity contains partyIDs and roles types, still we duplicate
this infomation in party_relationship.

I hope this clarifies the source of confusion. The explaination in the book
was not clear to me either.

Thank you for any help.
On 2014-10-11 6:48 PM, "Taher Alkhateeb" <[hidden email]>
wrote:

> Hi Mansour,
>
> Simply speaking the party_role entity assigns roles to parties which can be
> applied to many entities among which one of them is party_relationship. For
> example, WorkEffortPartyAssignment links a party to a workeffort through a
> role. Thus the partyrole is an entity to be (depending on some factors)
> used for validation of the existence of the role before assigning it to one
> of the relationship entities. At least that's my interpretation of it.
>
> Taher Alkhateeb
> On Oct 12, 2014 12:58 AM, "Mansour Al Akeel" <[hidden email]>
> wrote:
>
> > I consulted the Data Model Resource Book to refresh my memory about
> > the modelling for the roles and relationship for Party.
> >
> > In ofbiz, we have PartyRelationship between two parties. So each party
> > ID is used as a key, combined with the relationship type. The book
> > mentions on page 42, that when customizing the model, it's recommended
> > to draw the relationship between party roles.
> >
> > The part that I find confusing is, if we have the two party IDs in the
> > party_role entity, why don't we create the relationship between two
> > party roles, instead of duplicating the information in the
> > party_relationship entity ? For example, currently we have,
> >
> > party_relationship:
> > - from party id
> > - to party id
> > - from role type id
> > - to role type id
> > - start date
> > - end date .....
> >
> > Can't we just use,
> > party_relationship:
> > -from role
> > - to role
> > - party relationship type
> >
> > assuming John has the role of developer. IBM has the role of employer.
> > We can use the directly in the party relationship. Using the current
> > model, we need to add the role_type to the party_relationship. If John
> > is no longer a developer, then we need to update in two entities, the
> > party_relationship, and the roles.
> >
> > I am not sure I understand the description in the book, and the design in
> > ofbiz.
> >
> > Can someone kindly clarify the picture for me ??
> >
> > Thank you.
> >
>

taher

Re: Party Relationship and Party Roles

Hi Mansour,

I have two points to make on your below question:

First, please note the Data Model book is not followed 100% in OFBiz, although it adheres to it quite well.

Second, the model is made stronger by having foreign keys to all the entities you mentioned! The PartyRelationship entity has foreign keys to Party, RoleType _AND_ PartyRole and I believe this _IS_ the correct way. You assign foreign keys to the original entity which holds the referenced key instead of a foreign key to a foreign key to a foreign key ... bad design in my opinion.

HTH
Taher Alkhateeb

----- Original Message -----

From: "Mansour Al Akeel" <[hidden email]>
To: "user" <[hidden email]>
Sent: Sunday, 12 October, 2014 5:31:33 AM
Subject: Re: Party Relationship and Party Roles

Taher,
Thank you for th detailed explainatin. I understand the purpose of
party_role, and asking why do we link party_relatinship to party, rather
than party_role.

Party_role entity contains partyIDs and roles types, still we duplicate
this infomation in party_relationship.

I hope this clarifies the source of confusion. The explaination in the book
was not clear to me either.

Thank you for any help.
On 2014-10-11 6:48 PM, "Taher Alkhateeb" <[hidden email]>
wrote:

taher

Re: Party Relationship and Party Roles

Hi Mansour,

Also one more point to add, the PartyRelationship has a fromDate and thruDate in addition to status! These dates bound the relationship through time and hence if as in your question John is no longer a developer then he would still have the role of a Developer in PartyRole which expires in a certain thruDate in PartyRelationship without being deleted!

So in fact you keep the history of entities through time which is also a very powerful design concept if you think about it.

Taher Alkhateeb

----- Original Message -----

From: "Taher Alkhateeb" <[hidden email]>
To: [hidden email]
Sent: Sunday, 12 October, 2014 6:35:54 AM
Subject: Re: Party Relationship and Party Roles

Hi Mansour,

I have two points to make on your below question:

First, please note the Data Model book is not followed 100% in OFBiz, although it adheres to it quite well.

Second, the model is made stronger by having foreign keys to all the entities you mentioned! The PartyRelationship entity has foreign keys to Party, RoleType _AND_ PartyRole and I believe this _IS_ the correct way. You assign foreign keys to the original entity which holds the referenced key instead of a foreign key to a foreign key to a foreign key ... bad design in my opinion.

HTH
Taher Alkhateeb

----- Original Message -----

From: "Mansour Al Akeel" <[hidden email]>
To: "user" <[hidden email]>
Sent: Sunday, 12 October, 2014 5:31:33 AM
Subject: Re: Party Relationship and Party Roles

Taher,
Thank you for th detailed explainatin. I understand the purpose of
party_role, and asking why do we link party_relatinship to party, rather
than party_role.

Party_role entity contains partyIDs and roles types, still we duplicate
this infomation in party_relationship.

I hope this clarifies the source of confusion. The explaination in the book
was not clear to me either.

Thank you for any help.
On 2014-10-11 6:48 PM, "Taher Alkhateeb" <[hidden email]>
wrote:

Jacopo Cappellato-4

Re: Party Relationship and Party Roles

In reply to this post by Mansour

Hi Mansour,

I will start with one example.
Let's say that in OFBiz we have two companies (i.e. two PartyGroup), "ABC inc" and "CDE inc", that run two different stores selling goods to their customers; the only way to represent that a given person "John Black" is customer of "ABC inc", but not of "CDE inc", is using a party relationship: "John Black is a customer of the seller ABC inc". Now suppose that John Black is also an employee of "CDE inc"; we can represent it with another party relationship: "John Black is an employee of the employer CDE inc".
The "party role" entity should be used to specify what are the roles that a party can play. In our example, for John Black we would have two roles: "customer" and "employee".

Summary:
* "party role": the roles that a given party *can* play
* "party relationship": the actual roles played by a given party (with respect to other parties).

Unfortunately in OFBiz, most of the screens and services are not implemented considering "party relationships" but only "party roles". This simplification is a weakness of the current implementation.
For example, a screen that lists all the "customers" doesn't make much sense if you don't specify the company that is selling goods. Currently, if in OFBiz a party has the role of "customer" then the system considers the party is a customer in all the relationships.

In my opinion we should refactor this by:
a) deprecating the party role entity
b) modify the existing code that is using party roles to use party relationships
c) use an _NA_ party id to specify party relationship that apply to all parties
d) in order to do #b we will need to specify, in most of the applications, the company in which the logged in user is connected: in this way if a user is associated to "ABC inc", in the "find customer" screen she will only see parties that are customers of "ABC inc"
e) (optional) normalize the from/to positions in PartyRelationship by sorting them by role type id (this would simplify lookups etc)

I hope it is useful information and I didn't add more confusion.

Jacopo

On Oct 11, 2014, at 11:57 PM, Mansour Al Akeel <[hidden email]> wrote:

> I consulted the Data Model Resource Book to refresh my memory about
> the modelling for the roles and relationship for Party.
>
> In ofbiz, we have PartyRelationship between two parties. So each party
> ID is used as a key, combined with the relationship type. The book
> mentions on page 42, that when customizing the model, it's recommended
> to draw the relationship between party roles.
>
> The part that I find confusing is, if we have the two party IDs in the
> party_role entity, why don't we create the relationship between two
> party roles, instead of duplicating the information in the
> party_relationship entity ? For example, currently we have,
>
> party_relationship:
> - from party id
> - to party id
> - from role type id
> - to role type id
> - start date
> - end date .....
>
> Can't we just use,
> party_relationship:
> -from role
> - to role
> - party relationship type
>
> assuming John has the role of developer. IBM has the role of employer.
> We can use the directly in the party relationship. Using the current
> model, we need to add the role_type to the party_relationship. If John
> is no longer a developer, then we need to update in two entities, the
> party_relationship, and the roles.
>
> I am not sure I understand the description in the book, and the design in ofbiz.
>
> Can someone kindly clarify the picture for me ??
>
> Thank you.

Jacopo Cappellato-4

Re: Party Relationship and Party Roles

On Oct 12, 2014, at 7:09 AM, Jacopo Cappellato <[hidden email]> wrote:

> a) deprecating the party role entity

One clarification: I didn't mean to say that we should remove the party role entity; in fact it would be still useful because, in order to play different party relationship, we will need to store different information for the party; the party role entity is useful to tell you what are the roles that can be played by a given party; what I meant to say is that in mostly all business logics/screens we should replace lookups to party roles with lookups to party relationships.

Jacopo

taher

Re: Party Relationship and Party Roles

In reply to this post by Jacopo Cappellato-4

Hi Jacopo,

Deprecating the PartyRole would mean definitely going against the data
model book in such a very fundamental domain (Party) would it not?

Every entity in that book serves a purpose which you explained yourself.
Furthermore, reporting on all roles past and present in all kinds of
contexts is very easy through PartyRole instead of scavenging data from a
hundred different places.

I also think PartyRole is used for security to allow attaching the party to
different contexts only if they are allowed to play that role.

My 2 cents

Taher Alkhateebn
On Oct 12, 2014 8:10 AM, "Jacopo Cappellato" <
[hidden email]> wrote:

> Hi Mansour,
>
> I will start with one example.
> Let's say that in OFBiz we have two companies (i.e. two PartyGroup), "ABC
> inc" and "CDE inc", that run two different stores selling goods to their
> customers; the only way to represent that a given person "John Black" is
> customer of "ABC inc", but not of "CDE inc", is using a party relationship:
> "John Black is a customer of the seller ABC inc". Now suppose that John
> Black is also an employee of "CDE inc"; we can represent it with another
> party relationship: "John Black is an employee of the employer CDE inc".
> The "party role" entity should be used to specify what are the roles that
> a party can play. In our example, for John Black we would have two roles:
> "customer" and "employee".
>
> Summary:
> * "party role": the roles that a given party *can* play
> * "party relationship": the actual roles played by a given party (with
> respect to other parties).
>
> Unfortunately in OFBiz, most of the screens and services are not
> implemented considering "party relationships" but only "party roles". This
> simplification is a weakness of the current implementation.
> For example, a screen that lists all the "customers" doesn't make much
> sense if you don't specify the company that is selling goods. Currently, if
> in OFBiz a party has the role of "customer" then the system considers the
> party is a customer in all the relationships.
>
> In my opinion we should refactor this by:
> a) deprecating the party role entity
> b) modify the existing code that is using party roles to use party
> relationships
> c) use an _NA_ party id to specify party relationship that apply to all
> parties
> d) in order to do #b we will need to specify, in most of the applications,
> the company in which the logged in user is connected: in this way if a user
> is associated to "ABC inc", in the "find customer" screen she will only see
> parties that are customers of "ABC inc"
> e) (optional) normalize the from/to positions in PartyRelationship by
> sorting them by role type id (this would simplify lookups etc)
>
> I hope it is useful information and I didn't add more confusion.
>
> Jacopo
>
> On Oct 11, 2014, at 11:57 PM, Mansour Al Akeel <[hidden email]>
> wrote:
>
> > I consulted the Data Model Resource Book to refresh my memory about
> > the modelling for the roles and relationship for Party.
> >
> > In ofbiz, we have PartyRelationship between two parties. So each party
> > ID is used as a key, combined with the relationship type. The book
> > mentions on page 42, that when customizing the model, it's recommended
> > to draw the relationship between party roles.
> >
> > The part that I find confusing is, if we have the two party IDs in the
> > party_role entity, why don't we create the relationship between two
> > party roles, instead of duplicating the information in the
> > party_relationship entity ? For example, currently we have,
> >
> > party_relationship:
> > - from party id
> > - to party id
> > - from role type id
> > - to role type id
> > - start date
> > - end date .....
> >
> > Can't we just use,
> > party_relationship:
> > -from role
> > - to role
> > - party relationship type
> >
> > assuming John has the role of developer. IBM has the role of employer.
> > We can use the directly in the party relationship. Using the current
> > model, we need to add the role_type to the party_relationship. If John
> > is no longer a developer, then we need to update in two entities, the
> > party_relationship, and the roles.
> >
> > I am not sure I understand the description in the book, and the design
> in ofbiz.
> >
> > Can someone kindly clarify the picture for me ??
> >
> > Thank you.
>
>

Mansour

Re: Party Relationship and Party Roles

In reply to this post by Jacopo Cappellato-4

Jacopo,
Thank you a lot for your help. I will ask my questions in-line.

On Sun, Oct 12, 2014 at 1:09 AM, Jacopo Cappellato
<[hidden email]> wrote:
> Hi Mansour,
>
> I will start with one example.
> Let's say that in OFBiz we have two companies (i.e. two PartyGroup), "ABC inc" and "CDE inc", that run two different stores selling goods to their customers; the only way to represent that a given person "John Black" is customer of "ABC inc", but not of "CDE inc", is using a party relationship: "John Black is a customer of the seller ABC inc". Now suppose that John Black is also an employee of "CDE inc"; we can represent it with another party relationship: "John Black is an employee of the employer CDE inc".
> The "party role" entity should be used to specify what are the roles that a party can play. In our example, for John Black we would have two roles: "customer" and "employee".
>
I will build on the example you gave, and model this scenario using
PartyRole refrenced from PartyRelation.
So we have four Roles involved.
CUSTOMER
SELLER
EMPLOYEE
EMPLOYER

John Black is a "CUSTOMER" when BUYING from the "SELLER" ABC inc.
John Black is an EMPLOYEE when WORKING_FOR the "EMPLOYER" CDE inc.

In this case, we don't need to define the party ids in the
PartyRelationship, because the PartyRole entity has them. All we do is
we reference PartyRole(s).

> Summary:
> * "party role": the roles that a given party *can* play
> * "party relationship": the actual roles played by a given party (with respect to other parties).
>

This clarifies it. But don't we find this confusing ? Why does someone
get involved into a DEVELOPER relationship if she does not have the
DEVELOPER PartyRole ? I mean the whole point is data integrity, by
allowing only certain parties to be engaged in a specific
relationship. This way we are allowing everyone to have any
relationship. I hope I made my point clear.

> Unfortunately in OFBiz, most of the screens and services are not implemented considering "party relationships" but only "party roles". This simplification is a weakness of the current implementation.
> For example, a screen that lists all the "customers" doesn't make much sense if you don't specify the company that is selling goods. Currently, if in OFBiz a party has the role of "customer" then the system considers the party is a customer in all the relationships.
>
> In my opinion we should refactor this by:
> a) deprecating the party role entity
> b) modify the existing code that is using party roles to use party relationships
> c) use an _NA_ party id to specify party relationship that apply to all parties
> d) in order to do #b we will need to specify, in most of the applications, the company in which the logged in user is connected: in this way if a user is associated to "ABC inc", in the "find customer" screen she will only see parties that are customers of "ABC inc"
> e) (optional) normalize the from/to positions in PartyRelationship by sorting them by role type id (this would simplify lookups etc)
>
> I hope it is useful information and I didn't add more confusion.
>
> Jacopo
>
> On Oct 11, 2014, at 11:57 PM, Mansour Al Akeel <[hidden email]> wrote:
>
>> I consulted the Data Model Resource Book to refresh my memory about
>> the modelling for the roles and relationship for Party.
>>
>> In ofbiz, we have PartyRelationship between two parties. So each party
>> ID is used as a key, combined with the relationship type. The book
>> mentions on page 42, that when customizing the model, it's recommended
>> to draw the relationship between party roles.
>>
>> The part that I find confusing is, if we have the two party IDs in the
>> party_role entity, why don't we create the relationship between two
>> party roles, instead of duplicating the information in the
>> party_relationship entity ? For example, currently we have,
>>
>> party_relationship:
>> - from party id
>> - to party id
>> - from role type id
>> - to role type id
>> - start date
>> - end date .....
>>
>> Can't we just use,
>> party_relationship:
>> -from role
>> - to role
>> - party relationship type
>>
>> assuming John has the role of developer. IBM has the role of employer.
>> We can use the directly in the party relationship. Using the current
>> model, we need to add the role_type to the party_relationship. If John
>> is no longer a developer, then we need to update in two entities, the
>> party_relationship, and the roles.
>>
>> I am not sure I understand the description in the book, and the design in ofbiz.
>>
>> Can someone kindly clarify the picture for me ??
>>
>> Thank you.
>

Mansour

Re: Party Relationship and Party Roles

In reply to this post by Jacopo Cappellato-4

Jacopo,

If we normalize the data and reference PartyRole from
PartyRelationship, and remove the fields:

partyIdFrom
partyIdTo
roleTypeIdFrom
roleTypeIdTo
fromDate
thruDate

And replace them with:

fromRole
toRole

Then we will eliminate this confusion. We would still of course use
PartyRelationship, and not depricate it. In the business login and
security, we will need to check both PartyRole and PartyRelationship
depending on what the service is doing.

For searching, and party lookups, I completely agree with you. We can
still sort them and search role type to obtain a PartyRelationship.

Thank you.

On Sun, Oct 12, 2014 at 1:19 AM, Jacopo Cappellato
<[hidden email]> wrote:
> On Oct 12, 2014, at 7:09 AM, Jacopo Cappellato <[hidden email]> wrote:
>
>> a) deprecating the party role entity
>
> One clarification: I didn't mean to say that we should remove the party role entity; in fact it would be still useful because, in order to play different party relationship, we will need to store different information for the party; the party role entity is useful to tell you what are the roles that can be played by a given party; what I meant to say is that in mostly all business logics/screens we should replace lookups to party roles with lookups to party relationships.
>
> Jacopo

Jacopo Cappellato-4

Re: Party Relationship and Party Roles

In reply to this post by Mansour

On Oct 12, 2014, at 8:01 AM, Mansour Al Akeel <[hidden email]> wrote:

> Jacopo,
> Thank you a lot for your help. I will ask my questions in-line.
>
> On Sun, Oct 12, 2014 at 1:09 AM, Jacopo Cappellato
> <[hidden email]> wrote:
>> Hi Mansour,
>>
>> I will start with one example.
>> Let's say that in OFBiz we have two companies (i.e. two PartyGroup), "ABC inc" and "CDE inc", that run two different stores selling goods to their customers; the only way to represent that a given person "John Black" is customer of "ABC inc", but not of "CDE inc", is using a party relationship: "John Black is a customer of the seller ABC inc". Now suppose that John Black is also an employee of "CDE inc"; we can represent it with another party relationship: "John Black is an employee of the employer CDE inc".
>> The "party role" entity should be used to specify what are the roles that a party can play. In our example, for John Black we would have two roles: "customer" and "employee".
>>
> I will build on the example you gave, and model this scenario using
> PartyRole refrenced from PartyRelation.
> So we have four Roles involved.
> CUSTOMER
> SELLER
> EMPLOYEE
> EMPLOYER
>
> John Black is a "CUSTOMER" when BUYING from the "SELLER" ABC inc.
> John Black is an EMPLOYEE when WORKING_FOR the "EMPLOYER" CDE inc.
>
> In this case, we don't need to define the party ids in the
> PartyRelationship, because the PartyRole entity has them. All we do is
> we reference PartyRole(s).

If I understand, you are suggesting to extend/use PartyRole in place of PartyRelationship; why not using PartyRelationship instead?

>
>
>> Summary:
>> * "party role": the roles that a given party *can* play
>> * "party relationship": the actual roles played by a given party (with respect to other parties).
>>
>
> This clarifies it. But don't we find this confusing ? Why does someone
> get involved into a DEVELOPER relationship if she does not have the
> DEVELOPER PartyRole ?

It can't. The process should look like:
1) add developer information to a party and add the DEVELOPER role to it; this means that now the party can play the role of a developer in some party relationship
2) create one or more party relationship where the party is a developer for some other party

Jacopo

> I mean the whole point is data integrity, by
> allowing only certain parties to be engaged in a specific
> relationship. This way we are allowing everyone to have any
> relationship. I hope I made my point clear.
>
>
>> Unfortunately in OFBiz, most of the screens and services are not implemented considering "party relationships" but only "party roles". This simplification is a weakness of the current implementation.
>> For example, a screen that lists all the "customers" doesn't make much sense if you don't specify the company that is selling goods. Currently, if in OFBiz a party has the role of "customer" then the system considers the party is a customer in all the relationships.
>>
>> In my opinion we should refactor this by:
>> a) deprecating the party role entity
>> b) modify the existing code that is using party roles to use party relationships
>> c) use an _NA_ party id to specify party relationship that apply to all parties
>> d) in order to do #b we will need to specify, in most of the applications, the company in which the logged in user is connected: in this way if a user is associated to "ABC inc", in the "find customer" screen she will only see parties that are customers of "ABC inc"
>> e) (optional) normalize the from/to positions in PartyRelationship by sorting them by role type id (this would simplify lookups etc)
>>
>> I hope it is useful information and I didn't add more confusion.
>>
>> Jacopo
>>
>> On Oct 11, 2014, at 11:57 PM, Mansour Al Akeel <[hidden email]> wrote:
>>
>>> I consulted the Data Model Resource Book to refresh my memory about
>>> the modelling for the roles and relationship for Party.
>>>
>>> In ofbiz, we have PartyRelationship between two parties. So each party
>>> ID is used as a key, combined with the relationship type. The book
>>> mentions on page 42, that when customizing the model, it's recommended
>>> to draw the relationship between party roles.
>>>
>>> The part that I find confusing is, if we have the two party IDs in the
>>> party_role entity, why don't we create the relationship between two
>>> party roles, instead of duplicating the information in the
>>> party_relationship entity ? For example, currently we have,
>>>
>>> party_relationship:
>>> - from party id
>>> - to party id
>>> - from role type id
>>> - to role type id
>>> - start date
>>> - end date .....
>>>
>>> Can't we just use,
>>> party_relationship:
>>> -from role
>>> - to role
>>> - party relationship type
>>>
>>> assuming John has the role of developer. IBM has the role of employer.
>>> We can use the directly in the party relationship. Using the current
>>> model, we need to add the role_type to the party_relationship. If John
>>> is no longer a developer, then we need to update in two entities, the
>>> party_relationship, and the roles.
>>>
>>> I am not sure I understand the description in the book, and the design in ofbiz.
>>>
>>> Can someone kindly clarify the picture for me ??
>>>
>>> Thank you.
>>

Jacopo Cappellato-4

Re: Party Relationship and Party Roles

In reply to this post by taher

On Oct 12, 2014, at 7:22 AM, Taher Alkhateeb <[hidden email]> wrote:

> Hi Jacopo,
>
> Deprecating the PartyRole would mean definitely going against the data
> model book in such a very fundamental domain (Party) would it not?

Please read my follow up email where I have clarified what I meant with "deprecation".

>
> Every entity in that book serves a purpose which you explained yourself.
> Furthermore, reporting on all roles past and present in all kinds of
> contexts is very easy through PartyRole instead of scavenging data from a
> hundred different places.

This simplicity is in fact a weakness of the current applications that prevents you from using (most of) them in a multi divisional setup.

Jacopo

>
> I also think PartyRole is used for security to allow attaching the party to
> different contexts only if they are allowed to play that role.
>
> My 2 cents
>
> Taher Alkhateebn
> On Oct 12, 2014 8:10 AM, "Jacopo Cappellato" <
> [hidden email]> wrote:
>
>> Hi Mansour,
>>
>> I will start with one example.
>> Let's say that in OFBiz we have two companies (i.e. two PartyGroup), "ABC
>> inc" and "CDE inc", that run two different stores selling goods to their
>> customers; the only way to represent that a given person "John Black" is
>> customer of "ABC inc", but not of "CDE inc", is using a party relationship:
>> "John Black is a customer of the seller ABC inc". Now suppose that John
>> Black is also an employee of "CDE inc"; we can represent it with another
>> party relationship: "John Black is an employee of the employer CDE inc".
>> The "party role" entity should be used to specify what are the roles that
>> a party can play. In our example, for John Black we would have two roles:
>> "customer" and "employee".
>>
>> Summary:
>> * "party role": the roles that a given party *can* play
>> * "party relationship": the actual roles played by a given party (with
>> respect to other parties).
>>
>> Unfortunately in OFBiz, most of the screens and services are not
>> implemented considering "party relationships" but only "party roles". This
>> simplification is a weakness of the current implementation.
>> For example, a screen that lists all the "customers" doesn't make much
>> sense if you don't specify the company that is selling goods. Currently, if
>> in OFBiz a party has the role of "customer" then the system considers the
>> party is a customer in all the relationships.
>>
>> In my opinion we should refactor this by:
>> a) deprecating the party role entity
>> b) modify the existing code that is using party roles to use party
>> relationships
>> c) use an _NA_ party id to specify party relationship that apply to all
>> parties
>> d) in order to do #b we will need to specify, in most of the applications,
>> the company in which the logged in user is connected: in this way if a user
>> is associated to "ABC inc", in the "find customer" screen she will only see
>> parties that are customers of "ABC inc"
>> e) (optional) normalize the from/to positions in PartyRelationship by
>> sorting them by role type id (this would simplify lookups etc)
>>
>> I hope it is useful information and I didn't add more confusion.
>>
>> Jacopo
>>
>> On Oct 11, 2014, at 11:57 PM, Mansour Al Akeel <[hidden email]>
>> wrote:
>>
>>> I consulted the Data Model Resource Book to refresh my memory about
>>> the modelling for the roles and relationship for Party.
>>>
>>> In ofbiz, we have PartyRelationship between two parties. So each party
>>> ID is used as a key, combined with the relationship type. The book
>>> mentions on page 42, that when customizing the model, it's recommended
>>> to draw the relationship between party roles.
>>>
>>> The part that I find confusing is, if we have the two party IDs in the
>>> party_role entity, why don't we create the relationship between two
>>> party roles, instead of duplicating the information in the
>>> party_relationship entity ? For example, currently we have,
>>>
>>> party_relationship:
>>> - from party id
>>> - to party id
>>> - from role type id
>>> - to role type id
>>> - start date
>>> - end date .....
>>>
>>> Can't we just use,
>>> party_relationship:
>>> -from role
>>> - to role
>>> - party relationship type
>>>
>>> assuming John has the role of developer. IBM has the role of employer.
>>> We can use the directly in the party relationship. Using the current
>>> model, we need to add the role_type to the party_relationship. If John
>>> is no longer a developer, then we need to update in two entities, the
>>> party_relationship, and the roles.
>>>
>>> I am not sure I understand the description in the book, and the design
>> in ofbiz.
>>>
>>> Can someone kindly clarify the picture for me ??
>>>
>>> Thank you.
>>
>>

Mansour

Re: Party Relationship and Party Roles

In reply to this post by Jacopo Cappellato-4

>> In this case, we don't need to define the party ids in the
>> PartyRelationship, because the PartyRole entity has them. All we do is
>> we reference PartyRole(s).
>
> If I understand, you are suggesting to extend/use PartyRole in place of PartyRelationship; why not using PartyRelationship instead?

Not exactly ! I am suggesting to use BOTH for a PartyRelationship. A
party that has a Role of Type MANAGER, can be involved in a MANAGE
relationship.
In the current setup, any party can get engaged in any relation. So
the Party "John Black", does not need to have the PartyRole "Customer"
in order to have a relationship with DEF inc.
And similarly, ABC inc does not need to have EMPLOYER ROLE in order to
have an EMPLOYMENT relationship with other Party.

The relationship is defined by two roles. Each role is defined by
Party and RoleType.

>
>>
>>
>>> Summary:
>>> * "party role": the roles that a given party *can* play
>>> * "party relationship": the actual roles played by a given party (with respect to other parties).
>>>
>>
>> This clarifies it. But don't we find this confusing ? Why does someone
>> get involved into a DEVELOPER relationship if she does not have the
>> DEVELOPER PartyRole ?
>
> It can't. The process should look like:
> 1) add developer information to a party and add the DEVELOPER role to it; this means that now the party can play the role of a developer in some party relationship
> 2) create one or more party relationship where the party is a developer for some other party
>

Perfect. So we are on the same page here. This is how I would model
it. But the current model doesn't enforce this constraints. It allows
the party "Mary" to be involved in a relationship that with
"DEVELOPER" RoleType.
Please note that she does not have DEVELOPER Role, but the
PartyRelationship entity has the fields "roleTypeIdFrom" and
"roleTypeIdTo" which allows to break this constraints, and create
confusion.

Mansour

Re: Party Relationship and Party Roles

Jacopo,

The way to enforce the constraints is to define the PartyRelationship
between pair of PartyRoles, and NOT between partyIds and roleTypes.
This is what I meant.

On Sun, Oct 12, 2014 at 2:54 AM, Mansour Al Akeel
<[hidden email]> wrote:

>>> In this case, we don't need to define the party ids in the
>>> PartyRelationship, because the PartyRole entity has them. All we do is
>>> we reference PartyRole(s).
>>
>> If I understand, you are suggesting to extend/use PartyRole in place of PartyRelationship; why not using PartyRelationship instead?
>
> Not exactly ! I am suggesting to use BOTH for a PartyRelationship. A
> party that has a Role of Type MANAGER, can be involved in a MANAGE
> relationship.
> In the current setup, any party can get engaged in any relation. So
> the Party "John Black", does not need to have the PartyRole "Customer"
> in order to have a relationship with DEF inc.
> And similarly, ABC inc does not need to have EMPLOYER ROLE in order to
> have an EMPLOYMENT relationship with other Party.
>
> The relationship is defined by two roles. Each role is defined by
> Party and RoleType.
>
>
>>
>>>
>>>
>>>> Summary:
>>>> * "party role": the roles that a given party *can* play
>>>> * "party relationship": the actual roles played by a given party (with respect to other parties).
>>>>
>>>
>>> This clarifies it. But don't we find this confusing ? Why does someone
>>> get involved into a DEVELOPER relationship if she does not have the
>>> DEVELOPER PartyRole ?
>>
>> It can't. The process should look like:
>> 1) add developer information to a party and add the DEVELOPER role to it; this means that now the party can play the role of a developer in some party relationship
>> 2) create one or more party relationship where the party is a developer for some other party
>>
>
> Perfect. So we are on the same page here. This is how I would model
> it. But the current model doesn't enforce this constraints. It allows
> the party "Mary" to be involved in a relationship that with
> "DEVELOPER" RoleType.
> Please note that she does not have DEVELOPER Role, but the
> PartyRelationship entity has the fields "roleTypeIdFrom" and
> "roleTypeIdTo" which allows to break this constraints, and create
> confusion.

Jacopo Cappellato-4

Re: Party Relationship and Party Roles

Are you sure it is not already implemented like this?

See the following constraints from the Partyrelationship entity definition:

<relation type="one" fk-name="PARTY_REL_FPROLE" title="From" rel-entity-name="PartyRole">
<key-map field-name="partyIdFrom" rel-field-name="partyId"/>
<key-map field-name="roleTypeIdFrom" rel-field-name="roleTypeId"/>
</relation>
<relation type="one" fk-name="PARTY_REL_TPROLE" title="To" rel-entity-name="PartyRole">
<key-map field-name="partyIdTo" rel-field-name="partyId"/>
<key-map field-name="roleTypeIdTo" rel-field-name="roleTypeId"/>
</relation>

Jacopo

On Oct 12, 2014, at 9:05 AM, Mansour Al Akeel <[hidden email]> wrote:

> Jacopo,
>
> The way to enforce the constraints is to define the PartyRelationship
> between pair of PartyRoles, and NOT between partyIds and roleTypes.
> This is what I meant.
>
>
>
> On Sun, Oct 12, 2014 at 2:54 AM, Mansour Al Akeel
> <[hidden email]> wrote:
>>>> In this case, we don't need to define the party ids in the
>>>> PartyRelationship, because the PartyRole entity has them. All we do is
>>>> we reference PartyRole(s).
>>>
>>> If I understand, you are suggesting to extend/use PartyRole in place of PartyRelationship; why not using PartyRelationship instead?
>>
>> Not exactly ! I am suggesting to use BOTH for a PartyRelationship. A
>> party that has a Role of Type MANAGER, can be involved in a MANAGE
>> relationship.
>> In the current setup, any party can get engaged in any relation. So
>> the Party "John Black", does not need to have the PartyRole "Customer"
>> in order to have a relationship with DEF inc.
>> And similarly, ABC inc does not need to have EMPLOYER ROLE in order to
>> have an EMPLOYMENT relationship with other Party.
>>
>> The relationship is defined by two roles. Each role is defined by
>> Party and RoleType.
>>
>>
>>>
>>>>
>>>>
>>>>> Summary:
>>>>> * "party role": the roles that a given party *can* play
>>>>> * "party relationship": the actual roles played by a given party (with respect to other parties).
>>>>>
>>>>
>>>> This clarifies it. But don't we find this confusing ? Why does someone
>>>> get involved into a DEVELOPER relationship if she does not have the
>>>> DEVELOPER PartyRole ?
>>>
>>> It can't. The process should look like:
>>> 1) add developer information to a party and add the DEVELOPER role to it; this means that now the party can play the role of a developer in some party relationship
>>> 2) create one or more party relationship where the party is a developer for some other party
>>>
>>
>> Perfect. So we are on the same page here. This is how I would model
>> it. But the current model doesn't enforce this constraints. It allows
>> the party "Mary" to be involved in a relationship that with
>> "DEVELOPER" RoleType.
>> Please note that she does not have DEVELOPER Role, but the
>> PartyRelationship entity has the fields "roleTypeIdFrom" and
>> "roleTypeIdTo" which allows to break this constraints, and create
>> confusion.

Mansour

Re: Party Relationship and Party Roles

Jacopo,
Thank you a lot. I missed this one.
It explains it and removes the confusion.

On Sun, Oct 12, 2014 at 3:10 AM, Jacopo Cappellato
<[hidden email]> wrote:

> Are you sure it is not already implemented like this?
>
> See the following constraints from the Partyrelationship entity definition:
>
> <relation type="one" fk-name="PARTY_REL_FPROLE" title="From" rel-entity-name="PartyRole">
> <key-map field-name="partyIdFrom" rel-field-name="partyId"/>
> <key-map field-name="roleTypeIdFrom" rel-field-name="roleTypeId"/>
> </relation>
> <relation type="one" fk-name="PARTY_REL_TPROLE" title="To" rel-entity-name="PartyRole">
> <key-map field-name="partyIdTo" rel-field-name="partyId"/>
> <key-map field-name="roleTypeIdTo" rel-field-name="roleTypeId"/>
> </relation>
>
> Jacopo
>
> On Oct 12, 2014, at 9:05 AM, Mansour Al Akeel <[hidden email]> wrote:
>
>> Jacopo,
>>
>> The way to enforce the constraints is to define the PartyRelationship
>> between pair of PartyRoles, and NOT between partyIds and roleTypes.
>> This is what I meant.
>>
>>
>>
>> On Sun, Oct 12, 2014 at 2:54 AM, Mansour Al Akeel
>> <[hidden email]> wrote:
>>>>> In this case, we don't need to define the party ids in the
>>>>> PartyRelationship, because the PartyRole entity has them. All we do is
>>>>> we reference PartyRole(s).
>>>>
>>>> If I understand, you are suggesting to extend/use PartyRole in place of PartyRelationship; why not using PartyRelationship instead?
>>>
>>> Not exactly ! I am suggesting to use BOTH for a PartyRelationship. A
>>> party that has a Role of Type MANAGER, can be involved in a MANAGE
>>> relationship.
>>> In the current setup, any party can get engaged in any relation. So
>>> the Party "John Black", does not need to have the PartyRole "Customer"
>>> in order to have a relationship with DEF inc.
>>> And similarly, ABC inc does not need to have EMPLOYER ROLE in order to
>>> have an EMPLOYMENT relationship with other Party.
>>>
>>> The relationship is defined by two roles. Each role is defined by
>>> Party and RoleType.
>>>
>>>
>>>>
>>>>>
>>>>>
>>>>>> Summary:
>>>>>> * "party role": the roles that a given party *can* play
>>>>>> * "party relationship": the actual roles played by a given party (with respect to other parties).
>>>>>>
>>>>>
>>>>> This clarifies it. But don't we find this confusing ? Why does someone
>>>>> get involved into a DEVELOPER relationship if she does not have the
>>>>> DEVELOPER PartyRole ?
>>>>
>>>> It can't. The process should look like:
>>>> 1) add developer information to a party and add the DEVELOPER role to it; this means that now the party can play the role of a developer in some party relationship
>>>> 2) create one or more party relationship where the party is a developer for some other party
>>>>
>>>
>>> Perfect. So we are on the same page here. This is how I would model
>>> it. But the current model doesn't enforce this constraints. It allows
>>> the party "Mary" to be involved in a relationship that with
>>> "DEVELOPER" RoleType.
>>> Please note that she does not have DEVELOPER Role, but the
>>> PartyRelationship entity has the fields "roleTypeIdFrom" and
>>> "roleTypeIdTo" which allows to break this constraints, and create
>>> confusion.
>