Comment 118 for bug 1160365

E few more protestations against what is being decided by Fabien and Olivier:

1)
indeed: just like as Ana said, in an ERP, what matters the most are legal/commercial entities. Contacts may be interesting to store, but if I should choose between two keys of analysis and relating things, the commercial entity is definitely what matters the most. Loosing in general that key at the profit of of the contact and making the commercial entity the exception to have again is total nonsense for an ERP. This is all the more nonsense that during 8 years OpenERP has been made and tested this way vs not even tested once in production after this half un-assumed semantic change from the very last months of wild development. This kind of bug just proves it.

2)
Olivier claims that OpenERP SA proposition is less invasive than the two keys one that one of my module at https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/27 that impacts every business object. Excuse me to say it: "this is bullshit". All right, my module adds a contact_id key that the developer may need to consider or explicitly opt out what a big deal for a contact field that has almost never been used critically before...
My module adding a contact_id key automatically on all objects with a partner_id isn't something more difficult to handle than OpenERP ORM adding a create_date or a write_date on every object.
The view customization to hide partner_id and show contact_id can be seen as just having a new "contact" widget setting both keys appropriately but hiding partner_id in easy edition mode.

Hell what is more important: put in danger all the proven critical ERP features that made OpenERP reputation all these years till 6.1 included and totally rely on partner_id being the commercial/legal entity OR saying OpenERP SA should just review a bit the 4-5 new social eye candy features introduced in v7 (never tested well in production, hardly even wanted as a priority by OpenERP users)?

What is more critical: not being able to consolidate, filter or relate any business any data by customer/supplier OR sending an email by mistake to the email of company instead of the email of a contact?

3) by refusing to apply a systematic solution to the problem: you are introducing a dangerous amount of entropy and inconsistencies all over the place. Indeed: some objects will have the 2 keys: a sale order historically and now an invoice with your patch module after we complained mostly about invoicing specifically (we were just pointing the most obvious issue, it doesn't mean it's the only one, we have been clear about that). But for all other objects, the randomness if partner_id is a company or just a contact of it will continue with no guarantee you can consolidate, filter or relate on these chaotic partner_id keys.

That means, by refusing to adopt a systematic solution, you are just moving the border between order and chaos a bit further where users didn't complained yet. But you are not fixing the problem at all! You are just moving the issue to a new random, inconsistent and moving place. As users and integrators will keep discovering bugs and complaining about these new places, chances are you will keep moving the border away, introducing new inconsistencies and forcing to progressively rewrite all the codebase to switch the partner_id semantic with a new field that stupidly isn't the contact one just as you already proposed to do in your main account module.

4) you seem to admit that when analysis matters, the commercial/legal entity key matters and that is why you created one for the invoices at least in that shitty patch module now.
But you tell that this fields need to be a fields.related.
And I say NO because:

a) a fields.related kills the liberty to eventually pick a company that isn't the usual contact company (the base_contact concept of having a contact that can belong to more than one company).

b) if you take the case where you have a form with many2one field where you will ask the user to relate a records that belong to the same customer/supplier, of course partner_id won't do it anymore because that will be just a contact eventually and you will need to add a new commercial_entity_id field on your own (so in every object eventually).
but when you will do that, if you use a field.related, you won't be able to pass commercial_entity_id in a filter or an on_change before saving the record where field.relate is computed.

That is in fact what you should use in forms is an on_change for automatically setting it, just as I did in my proposal at https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/27 (but adding the right contact_id key one).

5) consequently, by refusing to fix the problem systematically, you will force all the implementers to gradually re-add all these commercial_entity_id second keys on all object where they will need a company granularity (that is most of the time as we said).
And you will also force them to implement all these on_changes in a chaotic way (and also change all the partner_id logic as soon as they discover it doesn't work with contacts).
That is, you will create a hell of incompatible modules each creating these keys and overlapping on_changes their own ways.
And with the other guys like us that will keep assuming partner_id is a commercial/legal entity legal before because we see no way out of what you entered now and don't want to adapt all our localisations to that dead end model.

Tell me again all that is less intrusive and safer than our 2 keys proposals with contact_id right now...

Time to admit you just screwed it and work on the real solution for the goodness of everyone.

My 2cts