Comment 162 for bug 1160365

Hello Fabien, inline answers:

On Mon, Apr 15, 2013 at 2:46 AM, Fabien (Open ERP) <email address hidden> wrote:

> On 15/04/13 03:04, Maxime Chambreuil (http://www.savoirfairelinux.com)
> wrote:
> > @fabien
> >
> > We all agree we need 2 levels, but disagree on field names:
> > * The community wants contact and partner
> > * OpenERP SA wants partner and commercial_entity
>
> I think we disagree on the principle, not on the field names. We want
> partner_id, commercial_id because:
> - partner_id is the main field (commercial_id is just a readonly
> function field to guarantee consistency)
> - commercial_id is not required on all objects as it's exactly the
> same than partner_id.commercial_id, so we will just put it where it's
> required as a technical artifact to allow specific reporting, not
> everywhere.
>

Fabien
if you follow the discussion, we propose adding contact_id selectively, not
everywhere, only where it makes sense, please read
https://docs.google.com/a/akretion.com.br/document/d/1CvPz-BZnZ-waQZoFpdIM6aNjjcbdLadGQqTZFL3lw7A/edit#heading=h.mdjw907uuzcb
and
https://docs.google.com/spreadsheet/ccc?key=0AlrjP6ETn3tJdC1CUEw2bGQ1RkhDR0lmS2dGT1E4eWc#gid=0

So it's not really different in term avoiding redundance.
The big difference is that "partner_id + commercial_entity_id" is a
semantic swap of the last 8 years of development and forces to review the
logic of all official and community module, while our "partner_id +
contact_id" proposal keeps the semantic untouched, that is much less bugs
are to expect.

[...]
> It's not community against OpenERP SA. Whatever the solution we choose,
> the community have to adapt their modules to v7 for plenty of others
> reasons (res.partner.address does not exists, new form views, ...)
>

The other adaptations were much simpler: the view migration is trivial. As
for the address migration: as modules tend to use companies much more than
contacts, contacts wasn't such a big deal to migrate. In any case that was
mostly about simply using the same table now. Not so much logic change.

> Renaming contact_id into partner_id is just 10 minutes of work per module.
>

NO NO AND NO
Are you kidding or lying?

If we adopt "partner_id + contact_id" then yes, indeed, it's just changing
the name to use contact_id at the few place where you really want a contact.

On the contrary, if we adopt "partner_id + commercial_entity_id", we should
review all the relational logic everywhere as I explained here:
https://docs.google.com/presentation/d/1y0njSpm9kqJPGFUQQTiRMIpT1M5CfKppNhslvpl-aM4/pub?start=false&loop=false&delayms=3000#slide=id.p

>
> The reason we think we should keep our model is because it's implemented
> in trunk for one year and we did extensive tests and adapted all modules
> for it. Trying to change this would have the opposite impact of what you
> try to do: create much more bugs.
>

I think you are kidding Fabien
Come on, you didn't test anything of the issues I presented in the slides!
you came to think about the issue of reading data from contact (and copying
them) 3 months after you said release was ready (this bug)
you only fixed the financial accounting moves on the surface 2 months after
the release after this thread:
http://www.linkedin.com/groups/B2B-related-question-all-Fans-165657.S.214411619
and 3 months after the release you were still largely denying documents
need an SQL key to the company (all this thread) where you started
accepting the idea of two keys only after 130 posts telling you it was
wrong.

So the sad truth, is that you tested very little the consistency of the
data and reporting when users start mixing companies and persons in these
fields.
During all that time, even when the accounting move were relating to the
contact 1 month ago, the runbot was always green because it doesn't test
things like that.

Conclusion; v7 focused on other things (that are welcome) but didn't test
contacts/address consistency any close to all the real deployments in
productions until v6.1 included.
That is, what people can trust is what we had in 6.1, not what we have in 7
to the respect of contact management.

That is, the partner_id semantic has to be preserved at all cost.
Meanwhile, the few new social features of v7 can certainly keep using only
contacts because they have been designed specially for that.
So my proposal is to be selective and careful in which fields we repair
with a contact_id and which ones we leave as it is.

But in no case a field that was a company or physical person till v6.1 can
now silently receive contacts unless you can prove the code has been
extensively checked and changed for that. With all these bugs you are
exactly proving us, this hasn't been anticipated at all.
In a sense that's good, that means it's pretty safe to preserve the
semantic based on what we had in 6.1.

Of course, you can help filling the table and argue if you want to
demonstrate us you really anticipate some such field has been prepared for
receiving contacts.

1. the community adapt his modules
> 2. the community adapt his modules + we change all official modules (one
> year) + review migrations
>

You are very optimistic here Fabien. I fear things don't go that way.

> [...]
>
> Yes, we did not foreseen such a misunderstanding on the model otherwise,
> we would have communicated earlier on the reasons of this change. (I
> don't think we would have done it differently, because we think it's the
> best approach for the product.) But this model is not new, we explained
> it and demo it at the community days 2012, so it's in trunk since one year.
>

I was indeed disappointed people made the mistake to be amazed by the Apple
like presentation of v7 instead of investing this deeply and trusting you
blindly to drive such a change. I was always urging Akretion guys to move
their fuck up and discuss precisely THIS issue with other participants. I
was expecting crap and I was right to be on the defensive. That's just too
side people were only impressed by the new web-client and the blablabla
instead of paying attention to this.
But come on even you didn't anticipate any of the problem that I have
explained in these slides until at least 3 months after the release:
https://docs.google.com/presentation/d/1y0njSpm9kqJPGFUQQTiRMIpT1M5CfKppNhslvpl-aM4/pub?start=false&loop=false&delayms=3000#slide=id.p
How can you tell that we have been warned about everything?

This is everything you posted about the topic:
http://v6.openerp.com/node/1169/2012/06
Now compare that with the pitfalls I describe in the slides...
I would have love you publish such slides 1 year before to say: "hey people
be extremely careful because you will need to change everything this way
and pay attention to this and this". But the sad truth is you didn't think
about that part of the problem, that's it.

So yes we knew that you would put partners and addresses in the same table.
BUT, we would never think you would silently make fields that used to point
to companies now point to their person contacts and screw all the
relational cardinality.
This is so crazy, that the 1st day I released you could invoice a contact
and that is was using the partner_id field I reported as a bug of course.
So nobody would actually expect you would do such confusion.
Simple as that.
yes you could have everything in the same table, but you could not mix
everything in any field as if it was the same thing.
The best proof you cannot do that is that is that now you are finally
admitting the need for a second commercial entity field (without contacts
inside!) but in the meanwhile you screwed all the existing semantic and
hence all the advanced functional logic.
You could mix things only in NEW fields designed for that and that had to
be called contact_id, properly setting partner_id as you now want to do
with commercial_entity_id.

You say you see no bug. But my customers used to group their purchase order
per supplier, they used to compare their purchase prices per supplier in
the PO lines, they used to do all sorts of intrastat reports where what
matters are the company data, not the data of the contact of course. All
that is screwed but this is only the easier to understand. Nhomar gave you
a few example too

> And, they are much more changes that this one in the v7 (v7 = around
> 1400 tasks for us). It's quite complex to explain every change into the
> detail. We try to do our best: we invested a lot of time on the release
> note that has more than 100 pages. But I agree it's not enough.

This is the big problem Fabien: you make the confusion between a roadmap
and a release note.
And again in that release note, you were still anticipating none of the
pitfalls I'm describing in the slides.

Looking forward for a real solution.