Moving addresses and contact mechanisms among parties

[Jon Levy]

We use the trytonspain's party_communication module, which basically uses Addresses to model individuals associated with the Party, and makes Contact Mechanism many2one on Addresses. (party_relationship may be the more recommended solution, but we found it not as helpful.)

Now we want to be able to move Addresses from one Party to another. Digging into the Party module, there is an odd implementation for preventing changing an Address's, or Contact Mechanism's, Party. Instead of just making the field readonly, there are UserError calls in overwritten write methods.[1] If this a legacy implementation (something that today would just be handled with readonly)?

Is anyone aware of traps lurking if I allow change of the Addresses' party field (by making it read/write and removing the hooks in the overridden write methods)? (This would also involve overloading Address's write to ensure that all of the Address's Contact Mechanisms move along with it.)

[1] http://hg.tryton.org/modules/party/file/3.4/address.py#l158
http://hg.tryton.org/modules/party/file/3.4/contact_mechanism.py#l87

Any insights would be greatly appreciated.

[Cédric Krier]

On 2017-09-26 17:34, Jon Levy wrote:
> We use the trytonspain's party_communication module, which basically uses Addresses to model individuals associated with the Party, and makes Contact Mechanism many2one on Addresses. (party_relationship may be the more recommended solution, but we found it not as helpful.)
>
> Now we want to be able to move Addresses from one Party to another. Digging into the Party module, there is an odd implementation for preventing changing an Address's, or Contact Mechanism's, Party. Instead of just making the field readonly, there are UserError calls in overwritten write methods.[1] If this a legacy implementation (something that today would just be handled with readonly)?
>
> Is anyone aware of traps lurking if I allow change of the Addresses' party field (by making it read/write and removing the hooks in the overridden write methods)? (This would also involve overloading Address's write to ensure that all of the Address's Contact Mechanisms move along with it.)

This is there on purpose to keep the data integrity.
Everywhere there is a constraint on address Many2One to be linked to a
specific party. So we manage the address has been part of the party.
We could not use 'readonly' attribute because it is not yet an enforced
constraint [1].

I really think that you should use the party_relationship module and
never use an address as a party.


[1] https://bugs.tryton.org/issue4207

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Jon Levy]

On Wednesday, September 27, 2017 at 2:35:10 AM UTC-4, Cédric Krier wrote:

> We could not use 'readonly' attribute because it is not yet an enforced
> constraint [1].

So it sounds like the overloading the write method was just to enforce readonly. Are you aware of anything that would break by lifting this constraint (either by using my own version of the address module, or by monkeypatching)?

> I really think that you should use the party_relationship module and
> never use an address as a party.

Companies are made up of individuals. This is a real-world concept that Tryton should embrace modeling it (when appropriate to a given deployment). I don't love party_communication, but think it is better than party_relationship for our needs.

[Cédric Krier]

On 2017-09-27 08:25, Jon Levy wrote:
> On Wednesday, September 27, 2017 at 2:35:10 AM UTC-4, Cédric Krier wrote:
>
> > We could not use 'readonly' attribute because it is not yet an enforced
> > constraint [1].
> So it sounds like the overloading the write method was just to enforce
> readonly. Are you aware of anything that would break by lifting this
> constraint (either by using my own version of the address module, or
> by monkeypatching)?

Yes almost all modules: sale, purchase, invoice, stock, project etc.

> > I really think that you should use the party_relationship module and
> > never use an address as a party.
>
> Companies are made up of individuals. This is a real-world concept
> that Tryton should embrace modeling it (when appropriate to a given
> deployment). I don't love party_communication, but think it is better
> than party_relationship for our needs.

And Tryton does with the module party_relationship following the best
practice from https://www.amazon.com/Data-Model-Resource-Book-Vol/dp/0471380237
Using addresses to modeling employees is so wrong because well an
address is a location [1] and it does not change in contrary of an
employee who can change of company or even work for two companies at the
same time.
So I doubt "party_communication" is better for your needs because you
need to break Tryton for that.


[1] https://en.wikipedia.org/wiki/Address_(geography)

[Jon Levy]

On Wednesday, September 27, 2017 at 11:50:07 AM UTC-4, Cédric Krier wrote:
> On 2017-09-27 08:25, Jon Levy wrote:
> > Companies are made up of individuals. This is a real-world concept
> > that Tryton should embrace modeling it (when appropriate to a given
>

> And Tryton does with the module party_relationship . . .

> Using addresses to modeling employees is so wrong because well an
> address is a location

I take your point that, as the maintainer, you want address to mean address (instead of it meaning individual). The UI for party_relationship makes it very inconvenient to open up a party/company and figure the name of an employee to call. If there is UI built for this, please let me know. I will go ahead and try to design one and, if that works, will try to migrate away from party_communication.

[Jon Levy]

Trying to solve part of the UI problem: a One2Many field has the ability to show the form view of the related model, but as far as I know a Many2One does not. This means that, in order to edit the party in party_relationship you need to first open the relation and then open the related party in a pop-up. Am I understanding that right?

(It is less convenient to go directly to the party because the user will want to go directly to the most important entity (ie the company), rather than locate the company staff member from among the entire sea of parties (especially when identical names are a possibility).

[Cédric Krier]

On 2017-09-27 18:55, Jon Levy wrote:
> On Wednesday, September 27, 2017 at 9:39:52 PM UTC-4, Jon Levy wrote:
> > On Wednesday, September 27, 2017 at 11:50:07 AM UTC-4, Cédric Krier wrote:
> > > On 2017-09-27 08:25, Jon Levy wrote:
> > > > Companies are made up of individuals. This is a real-world concept
> > > > that Tryton should embrace modeling it (when appropriate to a given
> > >
> > > And Tryton does with the module party_relationship . . .
> > > Using addresses to modeling employees is so wrong because well an
> > > address is a location
> >
> > I take your point that, as the maintainer, you want address to mean
> > address (instead of it meaning individual). The UI for
> > party_relationship makes it very inconvenient to open up a
> > party/company and figure the name of an employee to call. If there
> > is UI built for this, please let me know. I will go ahead and try
> > to design one and, if that works, will try to migrate away from
> > party_communication.
>
> Trying to solve part of the UI problem: a One2Many field has the
> ability to show the form view of the related model, but as far as I
> know a Many2One does not. This means that, in order to edit the party
> in party_relationship you need to first open the relation and then
> open the related party in a pop-up. Am I understanding that right?

Yes. This is an issue that comes up from time to time.
I guess we would need to have a widget similar to One2Many but for
Many2One.

It is also possible to add a Many2Many instead of the One2Many relations
but the relation needs to be typed.

[Sergi Almacellas Abellana]

El 27/09/17 a les 17:48, Cédric Krier ha escrit:

> On 2017-09-27 08:25, Jon Levy wrote:
>> On Wednesday, September 27, 2017 at 2:35:10 AM UTC-4, Cédric Krier wrote:
>>
>>> We could not use 'readonly' attribute because it is not yet an enforced
>>> constraint [1].
>> So it sounds like the overloading the write method was just to enforce
>> readonly. Are you aware of anything that would break by lifting this
>> constraint (either by using my own version of the address module, or
>> by monkeypatching)?
> Yes almost all modules: sale, purchase, invoice, stock, project etc.
>
>>> I really think that you should use the party_relationship module and
>>> never use an address as a party.
>> Companies are made up of individuals. This is a real-world concept
>> that Tryton should embrace modeling it (when appropriate to a given
>> deployment). I don't love party_communication, but think it is better
>> than party_relationship for our needs.
> And Tryton does with the module party_relationship following the best

> practice fromhttps://www.amazon.com/Data-Model-Resource-Book-Vol/dp/0471380237

> Using addresses to modeling employees is so wrong because well an
> address is a location [1] and it does not change in contrary of an
> employee who can change of company or even work for two companies at the
> same time.
> So I doubt "party_communication" is better for your needs because you
> need to break Tryton for that.

I must admint that I have used party_comunication and the same aproach
when party_relationship did not exist. Once having tested the new
party_relationship module, we did the switch immediately as the latter
had a lot of benefits:

- You don't need to duplicate address in case there are several contacts
of the same party
- You can save the type of relation which gives more information.
- It allows to have the same contact related to several parties without
duplicating the information.



--
Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk

[Jon Levy]

On Thursday, September 28, 2017 at 2:35:05 AM UTC-4, Cédric Krier wrote:
> I guess we would need to have a widget similar to One2Many but for
> Many2One.

Yes, that would be awesome. Indeed, I think it would be transformative to the interfaces that Tryton allows.

> It is also possible to add a Many2Many instead of the One2Many relations
> but the relation needs to be typed.

I don't understand. Is there a way to coerce Many2Many to provide the desired behavior on a Many2One field--i.e., giving access to the fields on the underlying record?

[Jon Levy]

On Thursday, September 28, 2017 at 3:30:47 AM UTC-4, Sergi Almacellas Abellana wrote:

> I must admint that I have used party_comunication and the same aproach
> when party_relationship did not exist. Once having tested the new
> party_relationship module, we did the switch immediately as the latter
> had a lot of benefits:

How did you deal with the UI problems? When a user goes to the party page for XYZ Corporation, and wants to add a salesperson for XYZ, they want to be able to do it simply--not either (1) digging down through pop-ups first for party relationship, then for a new party, and then back up to the relationship, or (2) leaving the XYZ screen to create a new party.

I understand that party_relationship has a more robust data model than party_communication, but, in the trade-off between UI and flexible data model, UI sometimes should win, especially the use case does not require complex spaghetti Many2Many relationship between employees and their companies.

[Cédric Krier]

On 2017-09-28 07:46, Jon Levy wrote:
> > It is also possible to add a Many2Many instead of the One2Many relations
> > but the relation needs to be typed.
>
> I don't understand. Is there a way to coerce Many2Many to provide the
> desired behavior on a Many2One field--i.e., giving access to the
> fields on the underlying record?

I mean any One2Many for which the target has a Many2One, can be
displayed as a Many2Many. But adding new record can only work if the
target can be filled with only the source and origin. So it is not
possible for the relationship because it needs the type of relation.

[Sergi Almacellas Abellana]

El 28/09/17 a les 16:52, Jon Levy ha escrit:

> On Thursday, September 28, 2017 at 3:30:47 AM UTC-4, Sergi Almacellas Abellana wrote:
>
>> I must admint that I have used party_comunication and the same aproach
>> when party_relationship did not exist. Once having tested the new
>> party_relationship module, we did the switch immediately as the latter
>> had a lot of benefits:
> How did you deal with the UI problems? When a user goes to the party page for XYZ Corporation, and wants to add a salesperson for XYZ, they want to be able to do it simply--not either (1) digging down through pop-ups first for party relationship, then for a new party, and then back up to the relationship, or (2) leaving the XYZ screen to create a new party.

We use the following steps:

1. Create a new relationship.
2. Type the relationship name in the relatioship and use tab to select
the required
3. Type the contact name on the Party field, if existing it will show up
(and you just select like in the previous step). Otherwise use the
create option to create a new party (name will be prefilled on newer
versions) and then fill the details if required.

For me it's not too complex.

[Jon Levy]

Cédric and Sergi,
Thank you for you help in understanding this. I have worked with the UI of party_relationship and gotten it to a point that I think is adequate. I made One2Many function field for related contact mechanisms on party. That way, you only have to drill down when adding a contact mechanism, not when looking one up.

I will go ahead and migrate away from party_communication.

[Cédric Krier]

After some more thoughts, you can open the party of a relation directly
without having to open the relation popup first. You just have to use
the context menu (right click) on the line and select To>Edit.
This feature does not exist on sao but I think we could implement it by
making the text of a Many2One in a list view as a link that open a
popup.

Another options will be to show the Many2One buttons on the list view.
So when it is not edited, you will have (on both client) the open
folder. And when edited, it will be like on sao now, you will have both
buttons.
For the non-edited view, I do not know if it will not bloat too much the
view. At least in sao, we could replace the button by a link.

[Jon Levy]

On Sunday, October 1, 2017 at 4:20:06 AM UTC-4, Cédric Krier wrote:
> After some more thoughts, you can open the party of a relation directly
> without having to open the relation popup first. You just have to use
> the context menu (right click) on the line and select To>Edit.

Woah! I didn't know about this feature and just tried it. Pretty sweet!

> Another options will be to show the Many2One buttons on the list view.
> So when it is not edited, you will have (on both client) the open
> folder. And when edited, it will be like on sao now, you will have both
> buttons.
> For the non-edited view, I do not know if it will not bloat too much the
> view. At least in sao, we could replace the button by a link.

I'm not sure I understand.

Thanks for the tip!