Comment 236 for bug 1160365

On Fri, Apr 19, 2013 at 2:48 PM, Christophe Combelles <email address hidden> wrote:

> Mmh the 3rd paragraph of my previous comment is confusing, the first 2
> sentences (data duplication + impact on community modules) was related
> to the openerp solution, not partner_id + contact_id.

Christophe: in any case, I think you didn't get it: the partner_id +
contact_id solution idea is: WE WILL PUT A TYPE on what is a legal entity
or what is a mere contact of a legal entity. And, in the business fields,
we will add these domains OF COURSE to RESTRICT to a legal entity when it's
required on business documents.

The only reason why we didn't do it yet is: supposed somebody already
corrupted his database by mixing contacts in partner_id. We offer him a
chance to still at least try our solution today.
In any case, the way we override write and create, you are guaranteed you
can only write a legal entity into a partner_id, which is what code
expects. Once we make some SQL tools to migrate back and forth between the
two worlds, we may probably add these domains indeed.

Also, in the future, depending on how we emancipate from the main branch
(guaranteed we will not do it in the next 6 months where we will offer us a
chance to come back to the official branch), we will probably add an
"address" type. Today, like on 6.1, addresses and contacts are the same
thing. So contacts cannot reuse addresses and addresses have a birthday and
things like that. It's rarely such a big deal; just create a contact for
every address, it does the job in the vast majority of the time. Now yes,
ideally we "extract" the address concept and make it something some
specific fields can put a restriction on. Then eventually the contact_id of
a purchase.order could be contact BUT NOT a mere address, while the
contact_id of a picking could eventually be just an address (may be).

In any case, having both contacts, addresses and companies in the same
table provides a great advantage:
the contact_id field can allow to select any kind of records in only one
visible field in the interface, so it does make B2C easier. And this is
really FUD to try making believe the contact_id solution is a rejection of
that.

In any case, I think some people already understood what this is all about.
Now it's a matter of organisation.
Unless OpenERP SA considers the contact_id option, here we are going to
maintain that tracking branch to use on v7 as I explained in the slides. We
see we will have all advantages of v7 (definitely a lot) but none of what
we think are shortcomings.

What doesn't destroy you makes you stronger.

Cheers.