Comment 131 for bug 1160365

Fabien,

I do not feel that you are addressing my issues. It is not about whether Olivier's code implements the principles that you set out correctly, it is the principles themselves. I am sure that Olivier is capable enough of copying data around in a relational database, but it is simply bad practice to do so. I can see that it is possible to retrieve the company partner for any business document using some Python code, but not having them linked directly is pretty odd for an ERP. I can see that having a partner_id and a commercial_entity_id, provided by a separate module gives a complete set of information, but it changes the meaning of partner_id around which causes inconsistent naming in the core (compare the use of 'partner_id' on the accounting models) and incompatibility with legacy code. It also creates the need for an uncertain amount of such modules to complement other models.

In my post I argued that the changes in the 7.0 datamodel is unnecessarily disruptive. Its consequences cannot be tested by a small team of community members. Instead, our customers will be the guinea pigs testing the changes and we have been told by them in the past that they do not appreciate it. We will also encounter the real problems when discussing with them the management reporting that they need, or when they want to talk about customizing the semantics of partners and contacts for their own needs. We cannot anticipate and test every scenario at this point. The principles underlying the 7.0 datamodel and the proposed solution undermines the stability of OpenERP and to be honest, we have problems enough with it already in terms of number of bugs that exist.

Keeping the partner_id semantics the same as in earlier versions means less code changes means less bugs. That is currently a high priority. Our customers expect a product to mature in that sense. We cannot suggest our customers to migrate to 7.0 if it means more instability or paying to create customizations to implement core functionality that existed in an uncustomized older version.

In terms of functionality, we surely agree. Having the contact as the starting point of every business document is a good thing to have. So please consider the approach that we favour. Raphaël's idea to keep partner_id semantics in tact and add the contact_id for the user to work with is very transparent, suits your purposes fine, can be implemented elegantly and brings less instability. So please confirm if you can be pragmatic about a minor set of database changes in 7.0 and we will give you something to test.