Comment 13 for bug 1160365

On 03/26/2013 09:17 PM, Raphaël Valyi - http://www.akretion.com wrote:
> @Fabien, this enable reading the proper data inside the contact record.
>
> But
> 1) how will you decide which fields exactly are copied or not?
> 2) how does it scales across modules adding fields in res.partner, which
> fields will be copied or not?

I tried to answer both questions that in part B of the solution:

  "when writing() on a partner that is an commercial party, all the values of
invoicing/accounting-related fields will be automatically copied to all
descendants that are not commercial party themselves (e.g. pricelist, G/L
accounts, payment terms, etc.). The list of fields to copy will be returned by
a method on res.partner that can be overridden in other modules."

Or did you mean something else?

> 3) what about all the existing business logic that makes a decision by
> taking some arbitrary foreign key pointing to the res.partner table and
> comparing it with partner_id. What leads you to warranty us with so much
> assurance that the code will always be consistent with the expected
> behavior if partner_id can now randomly be the parent company or any of its
> contacts?

The idea is that there should not be many places in the code where a direct
comparison of partner_id is necessary and where a mismatch of contact vs
company would cause a dangerous or hidden logic error, except in accounting.
Accounting is directly addressed by the proposed solution, and a search for
"if.*partner_id.*=" or "'partner_id'.*'='" (for domains) in the Python code of
addons reveals nothing relevant outside of accounting.

There might be a few cases where a domain in a view or context action needs to
be changed to use "child_of" instead of "=", but those cases should be mostly
usability issues.

> IMHO you are not considering this pitfall enough.

We are considering it quite seriously, but have not found any valid
counter-example so far. The examples that have been mentioned are either not
correct (all accounting examples so far are properly addressed by the solution)
or not specific enough that we can actually verify them.

> And again, what is the advantage over adding a contact_id field?

It's simply in line with the concept of the 7.0 model. Adding a contact_id
field would defeat the purpose of the new model:
- it would cause useless duplication of fields: in the 7.0 model a contact is
really meant to be a first-class partner, and it is responsible for delegating
its properties when needed to a parent company. So any partner
(contact/address/company) must encompass the full range of attributes without
requiring any direct pointer to its parent. A direct link to second partner
should only be required when there is a user choice involved (such as when an
different Invoice Partner or Delivery Partner can be chosen on a SO). In all
other cases a single partner reference must be enough, that's the whole point.
- it validates the fact that a contact is the right level of granularity in
most cases. Adding a second "parent" field in all cases would mix granularity
levels.

Basically if we introduce the 7.0 model *and* start adding extra partner fields
on all business documents, we're adding confusion/overhead rather than simplifying.

@everyone: I know this topic is very broad and it seems like it has
implications everywhere, but please try to use short and precise examples of
use cases for which you have a concern, so we can discuss on firm ground.