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.