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.