New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[IMP] Add possibility to handle multiple addresses, emails and phones per partner #1

Open
rruebner opened this Issue Apr 13, 2016 · 11 comments

Comments

Projects
None yet
9 participants
@rruebner
Copy link

rruebner commented Apr 13, 2016

We want to add the possibility to handle multiple addresses, emails and phones per partner. Based on OpenERP v6.1 we want to add new models to store address (res.partner.address), email (res.partner.email) and phone (res.partner.phone) data. The partner views will also be updated to illustrate the new handling. For the beginning we concentrate on odoo v8 but it is intended to do it also for v9.

The structure should look like

  • Company (res.partner with is_company=True)
    • Address 1
    • Address 2
    • Partner 1
      • Address 1
      • Email 1 (eg. private)
      • Email 2 (eg. business)
    • Partner 2
      • Address 1 (private 1)
      • Address 2 (private 2)
      • Phone (mobile)
      • Phone (Fax)
  • Partner (res.partner with is_company=False)
    • Address 1
    • Address 2
    • Address 3
    • Email 1
    • Email 2
    • Phone 1

The more interesting (and difficult) part is which other code parts we have to change. We end up in two possibilities.

Possibility 1

Like in v6.1 we check all res.partner relation fields and replace the needed relations with res.partner.address. In addition we have to update a lot of code and template parts to use the new relation in a correct way. We have to do it in a similar way for res.partner.email and res.partner.phone (replace the email and phone fields in res.partner).

Possibility 2

Instead of replacing the res.partner fields we use related fields to match the address fields. Therefore we add a new preferred field for address, lets call it preferred_address, which is related to res.partner.address. Now we change the res.partner street field to a related field which points to the res.partner.address street field and do that with all other address data (type, street2, city, zip, state_id, country_id). res.partner.address has also a preferred field (boolean) which controls which address is used in the res.partner preferred_address field.

We use another approach for email and phone fields. I will show the approach only for email because it is the same like for phone. The new model res.partner.email contains the fields type (private, business etc.), email (the email address) and preferred (boolean). The preferred field controls which email is used in the res.partner email field.

The advantage is that we don't need to update much code parts because we continue to use odoo res.partner fields like street, city, email etc. One disadvantage is that we are limited to the preferred selection, means that we can't change the used address in sale orders for example.

What do you think?
Is someone already working on it?
Does somebody knows if odoo plans to add multiple address, email and phone handling?
Do you have better ideas / approches / solutions?

@Benniphx Benniphx self-assigned this Apr 13, 2016

@rruebner rruebner assigned rruebner and unassigned Benniphx Apr 13, 2016

@Benniphx Benniphx assigned Benniphx and unassigned rruebner Apr 13, 2016

@Benniphx Benniphx removed the help wanted label Apr 13, 2016

@Benniphx Benniphx added this to the planning milestone Apr 13, 2016

@Benniphx Benniphx self-assigned this Apr 13, 2016

@jholze

This comment has been minimized.

Copy link
Member

jholze commented Apr 13, 2016

👍

@mtelahun

This comment has been minimized.

Copy link

mtelahun commented Apr 14, 2016

I think this is the way it should have been done from the beginning. However, it is also important to be as backward compatible as possible because in addition to the standard modules there are many public and private modules that assume the current address model. Changing the data model to possibility 1 will effectively make it impossible to for those module to work "out of the box" with your module. In light of this I am in favor of possibility 2.

@mtelahun

This comment has been minimized.

Copy link

mtelahun commented Apr 15, 2016

Take a look at: tko_partner_multiple_phones and tko_partner_multiple_emails in https://github.com/thinkopensolutions/tkobr-addons

@anajuaristi

This comment has been minimized.

Copy link

anajuaristi commented Apr 15, 2016

It's much more simple.
For multiple addreses, contacts, just separate by type on partner form view and add type on kanban view. If you need more, create new filtered menus. That's all.
About phones you can write as many as you want on same single field. Just add a separator character between them
About emails... each address / contact has got his own one so you have multiple by now. But if you need more for the commercial partner separate with comma o semicolon
That's all. You don't need complex developments to cover what you need.

Wishing this helps...
Ana

@lehi3u1989

This comment has been minimized.

Copy link

lehi3u1989 commented Apr 17, 2016

Hi, I have another approach to simplify the code structure, no need to create new models res.partner.address, res.partner.email, res.partner.phone but still ensure our expected result. We just use the existing res.partner model with field parent_id and child_ids, but need to do some adjustments.

Assumptions:

  • A Company (is_company=True) can have many sub Contact Info (*). Contact Info could be a person, an address, a phone, an email ...
  • A Contact (person, is_company=False) can have many sub other Contact Info which are not persons, but address, phone, email
  • A Contact Info is a res.partner with is_company=False, has a Type (person, address, phone, email ...), and a field Is Prefered to be considered as the main contact info
  • A Company only has 1 main contact info for each Type (person, address, phone, email ...)
  • A Contact (person) only has 1 main contact info for each Type (address, phone, email ...), CANNOT have other sub Contact persons.
  • A Contact info (address, phone, email ...) CANNOT have other sub Contact info.
  • The end-user should know how and when to use each type.

Company Partner (res.partner with is_company=True):

  • Tab Contacts, change its name to Contact Info (*). Change kanban view to list view, so that we can sort by Type, see the preferred ones.
  • Only allow to add child Contact Partners (res.partner with is_company=False, can be person, address, phone, or email)
  • Let fields: address, street, zip, city, email, phone, mobile, fax ... as they are. They are just info for the Company Partner. I will explain in Set Default Values chapter below.

Contact Partner (res.partner with is_company=False):

  • Use it as a concept of several different things: a contact (a person), an address, a phone number.
  • Add a new field Partner Type (can be a Selection field, or Many2one to new model res.partner.type) with values: person, address, email, phone.... This field is only visble for Contact Partner.
  • Depending on the selected Type, show / hide the related fields: address (street, street2, city, zip, state, country), email, phone
  • If Type = person, let fields: address, street, zip, city, email, phone, mobile, fax ... as they are. They are just info for the Contact person. I will explain in Set Default Values chapter below.

Set default values:

  • On Company Partner, auto set default values for address (street, street2, city, zip, state, country), email, phone from its preferred Contact Person, Address, Email, Phone. In case it has a preferred Contact Person, AND a preferred Address, AND a preferred Email .... values from contact info (address, email, phone) has higher priority than Contact Person.
  • On Contact Partner, auto set default values for address (street, street2, city, zip, state, country), email, phone from its preferred Address, Email, Phone
  • On Sale Orders form, the default Address of Customer will be set for Delivery Address.

Just an idea, not sure it will work perfectly.
What do you think?

@rruebner

This comment has been minimized.

Copy link
Author

rruebner commented Apr 18, 2016

Thanks for the participation so far.

One more thing (don't know why I forgot it): we already use a customized company / partner / address / email handling in one of our customer projects. We need the structure described in the issue above and we thought it is time to cleanup our project implementation and provide a more general solution with a complete separation of addresses, emails and phones. And cause we already worked with OpenERP v6.1 in the past we thought it would be a good try to solve this "issue" like it was done in v6.1.

Another reason for the separation of the addresses at least: Currently we have 38760 addresses in our customer project and it will be more and more. We store them as res.partner objects (total count of res.partner entries is 92243 now), like @lehi3u1989 also suggested. We also extend res.partner with custom fields which results in 83 fields which will be stored for each res.partner entry. But we only want to store real address data like street, street2, zip, city, state_id, country etc., lets say 10 fields per address entry (for email and phone it should be far less data to store). Now we store the whole 83 fields for each address which is an unnecessary overhead in my opinion.
Another reason for the separation is to check if we can improve the performance because we encountered some leaks in combination with res.partner accesses in our monitoring tool.

@anajuaristi This was our first solution in the beginning of the project but it wasn't manageable in a proper way for our customer and their needs.

@mtelahun, @lehi3u1989 Like mentioned above we already have a customized handling. But I will look at your suggestions / modules because it sounds similar to our approach.

Maybe this kind of address, email and phone separation is to specific to provide it as general solution, I don't know. Also a good point from @mtelahun is the backward compatibility to avoid rewriting each custom module which uses res.partner in some way.

More ideas, suggestions, discussions are welcome.

@guewen

This comment has been minimized.

Copy link

guewen commented Apr 18, 2016

You might be interested in this old thread: https://bugs.launchpad.net/openobject-server/+bug/1151947

@Yenthe666

This comment has been minimized.

Copy link

Yenthe666 commented Apr 19, 2016

Judging by your two cases I would go with case 2. If you would choose for option 1 you would have to write a lot of xpath expressions and you have a lot of risk of moving fields. Imagine having to migrate this from one Odoo version to another, then it will become even more painfull.
Possibility 2 sounds like less hassle and easier to maintain in the future.

@Benniphx

This comment has been minimized.

Copy link
Member

Benniphx commented Apr 19, 2016

Internally we also think what solution 2 is the best way to go. We just wanted to get some more information so we may did not oversaw some outcomes.
@Yenthe666 yes you are right a migration would bring me nightmares as well.

@ghost

This comment has been minimized.

Copy link

ghost commented Apr 25, 2017

We solved the need of customer with solution similar to one suggested by @lehi3u1989 on v8 and it works fine for now.
But now he wants to move to v10, so do we some concrete decided solution for this yet or porting the working solution is the best way to go for now ?

@jholze

This comment has been minimized.

Copy link
Member

jholze commented Apr 25, 2017

@rruebner can you maybe check. Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment