Comment 129 for bug 1160365

In response to Fabien's call for support for Raphaël's solution, Therp does indeed support the idea and principles that it is built upon. In terms of implementation details, we understand that it is a proof of concept and we still think a mix-in class would be an elegant solution.

We prefer the use of a field called contact_id over inconsistently changing the semantics of partner_id. In the OpenERP 7.0 data model with or without the changes suggested by OpenERP SA, it refers to the company partner on accounting moves, but on invoices it can also refer to the contact partner. In Raphaël's solution, having partner_id referring to the company partner is not only consistent in terms of data model, it is also compatible with previous versions of OpenERP. It also prevents the need for elaborate workarounds on business documents that lack the direct link to the company partner in the OpenERP 7.0 data model.

We prefer that the system reads the relevant data directly from the partner_id field instead of that data being copied from the company to its contacts. Keeping the partner_id and its original meaning, and allowing the relevant data to be read from it directly, will prevent many regressions and data integrity problems in official and community modules.

We think that that stability, in terms of minimizing the number of bugs that integrators and users are being confronted with in using OpenERP 7.0 is more important than sticking to the 'no database changes in stable' policy of OpenERP SA.

It seems to me that a solution built on these principles does everything that OpenERP SA had in mind for OpenERP 7.0. If that is the case (maybe Fabien can comment on that), and if it is indeed the no-changes policy of OpenERP SA that drives the adoption of elaborate code that copies data around in a relational database and breaks the fundamental link between commercial entities and business document in its ERP system, then that policy is bad and has to be violated just this once or maybe even be changed to simply having a very high threshold for such changes. We would find it scary if OpenERP SA could not find a pragmatic way of dealing with this policy in times of crisis such as this one.

We would gladly contribute to implementing the adoption of these principles in the core of OpenERP 7.0 as proposed by Maxime if Fabien promises to give it a chance even if it breaks the no-changes policy. Migration scripts will be included.