👍

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.

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

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

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?

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.

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

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.

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.

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 ?

@rruebner can you maybe check. Thanks