Comment 237 for bug 1160365

On Fri, Apr 19, 2013 at 2:34 PM, Christophe Combelles <email address hidden> wrote:

> I've been taking a considerable amount of time reading almost every
> single message of this thread, so I'd had no time left to express an
> opinion, but here it is: I believe both solutions stink, and that's the
> reason of this blocking situation. Now, I dont have any instant miracle
> solution so if you don't want to lose any more time with this flamewar,
> you can stop reading my post just now. Feel free to tell me if I didn't
> understand some point and I apologize if so.
>
> OpenERP S.A.'s solution is obviously and largely questionnable but it
> makes sense. OpenERP SA has clearly not anticipated all the consequences
> of the semantic move, but the community (I'm part of it) seems to really
> discover or understand this move only these days, and refuses it. So
> everyone here seems to be right.
>
> Why I don't like partner_id + contact_id :
>
> I really don't like company data duplication in the contacts. I don't like
> the impact of the community modules. But I don't like the split between
> contact and partner either, because it's a denial of the fact that even if
> contact_id field is added, all the partner_id fields in the wild will still
> be able to represent a contact as well. As a consequence, we won't be able
> to chose between partner_id and contact_id. In my opinion, the problem is
> absolutely not solved by adding a contact_id field, because the semantic
> lies in the res.partner model, not in the name of the field "partner_id" :
> the partner_id field always points to a res.partner model, which will
> always represent either a contact or a company anyway. Adding a contact_id
> doesn't change this fact.
> The partner_id + contact_id solution really need more, it would require to
> split back again the contacts and the companies so that the partner_id
> field is guaranteed to always be a company. And that would break the b2c
> possibilities. The res.partner model can be a partner or a contact, this is
> too late to revert this idea. Adding a contact_id doesn't hurt, but it will
> never prevent the partner_id from being a contact as well. So what happens
> if we have a contact in both fields ? This can be prevented with onchange
> but it means that the datamodel is not consistent and depends on the UI and
> the javascript. This would allow to write anything though xmlrpc and lead
> to inconsistencies, or duplicate the onchange behaviour in the xmlrpc
> dialog.

Also here I think you are missing another thing Christophes: WE DO override
write and create so YOU CANNOT write a contact into a partner_id field.
Even if you do it with XML/RPC, inside the code via API etc...
But we also set partner_id right inside the on_change, so that just like in
6.1, we have a key to the legal entity right inside the form and we can use
it to filter related records and in other on_changes BEFORE saving the
record, something that even Olivier Dony's solution cannot do because the
commercial_entity_id is computed only when you save the record (aside from
the dramatic semantic permutation of what a partner_id is).

So we don't RELY just on interface and javascript, fortunately no! Else I
would have switched to Tryton directly.
Now, yes, these OpenERP on_changes is IMHO what stinks the more in the
current OpenERP framework: it forces to decide methods signatures and
parameters inside the views and is crappy to call from the code. This is
essentially due to the positional nature of arguments passed instead of
being keyword arguments (how often you should create a glue module just
because 2 other moduels override the same onchange and change the
signature).

Now this bring us again to the roadmap topic. So as everyone can see, yes
during last partner meeting it has been made clear that contacts and
partners would merge into the same table and that there would be only one
field in the interface (shiny demo).
That could have lead us to the contact_id solution which features the
same usability and in fact I was even assuming it was done like that before
discovering you could invoice a contact after the CRM did it for me (I
wouldn't even have tried otherwise).
But the semantic inversion of what a partner_id is wasn't announced no!
And I claim it wasn't even totally planned even by OpenERP SA. This is
proved by this kind of bug where account moves would be related to an
address (1 month ago) or changes of mind whether you can invoice a contact
or not
https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/59
(initially Fabien said yes it's expected, then no! what a
missunderstanding! + patch to forbid it, then Olivier said it was expected
again and rolled back the restriction...)
and also proved by catastrophic 600 lines bugfix: 3 months after the
"sorrysap release", they are forced to do a fix that fake things works
because they COPY data from a company to its contacts.

So in fact the semantic inversion wasn't expect by us, but neither by
OpenERP SA sadly. And now, even with the data copy duct tape so reading
things from a person behaves a bit like reading it from a company, so even
if now everything isn't rewritten to read things directly from
"commercial_entity_id", if one day they want a normalized data model again
without such shitty copy, then yes, of course, they would have to REWRITE
ALL that too. Today their patch is already 10x more code that the
contact_id patch and you can still not group a purchase order by supplier,
but in the future it will just be a lot more than 10x. That's why I say no
more for me.
So, while half of what has been done in 7.0 was never listed in a roadmap,
half of what was in the roadmap has never been done either.
So I would like to remember the new API promise AND the new on_change API.
Well dropped.

Now fortunately, Raphaël Collet and Vo Minh Thu worked on that recently and
they produced a very interesting branch:
https://code.launchpad.net/~openerp-dev/openobject-server/trunk-apiculture-rco
That will finally bring a decent ActiveRecord API to OpenERP just like we
had for 4 years in OOOR, or Tryton more recently. This should decrease the
entry barrier to OpenERP for new developers as they won't need to be "the
druids of the cr uid" anymore.
It will also enable better read caching abilities.
The kind of thing we will be certainly happy to merge into the contact_id
branch when it will be out. So you see, forking is not always the best
thing to do.

Now, in that branch there is still no solution to the on_change problem. It
probably needs to be done like the Tryton DEPENDS feature
http://doc.tryton.org/2.6/trytond/doc/ref/models/fields.html#on-change-with
Looking forward to see that kind of solution implemented in OpenERP. Then
indeed we will have real API's and stop depending on views.

In fact, once you admit to support the weight of maintaining a new branch,
the cool thing is that you feel more comfortable to also take good ideas
from elsewhere. Of course, I will never support diverging too much without
a clean community decision process.

So you see, contact_id doesn't depend just on on_changes fortunately and
contact_id is an optional field you can fill or not (else the legal entity
is used) and as for the on_change limitations, they are a problem of the
framework and in fact the contact_id branch may fix it faster now that we
have this issue.

I think it's hardly any useful to try convincing Fabien and Olivier
anymore, this has all been discussed over and over for more than a month
now. Instead, I think people who finally like the contact_id branch should
help us maintaining it.

Best regards and thanks for having investigated that important issue.