Comment 141 for bug 1160365

>
>
> > 1 field (contact_id) displayed to the user, named Customer and searching
> through companies and contacts.
> > 1 field (partner_id) hidden by default, set automatically to the first
> commercial entity in the tree (at the moment contact_id is chosen) and used
> for invoicing.
>
> Did you notice that:
> - it requires to change all objects (if john.doe@acme fills a claim,
> the answer will be send to info@acme, and it's the same for all printed
> documents)
>

Fabien, OpenERP SA isn't paying me to do your job, that's us paying you. So
it's was just a quick proof of concept as I explained. Of course it would
need to be completed.
In such case, for you the code is very simple instead of what we have to do
it you swap partner_id semantic.
In these rare cases, you just have to change partner_id by contact_id in
the code. That's it.
And also it's much less critical features than say screwing your intrastat
reports or not being able to compare your supplier prices. In any case it's
way simpler to fix.

> - it sometimes has no sense: applicants (what's the company for an
> applicant?), bank statements (there are no contact on a statement), ...
>

Fabien, I agree, that some objects fields should opt-out for not receiving
a contact_id decoration. I had mentioned that in the code already.
I started elaborating a list of which fields may not be eligible for such
contact_id decoration:
Help is welcome in columns H and I:
https://docs.google.com/a/akretion.com.br/spreadsheet/ccc?key=0AlrjP6ETn3tJ<https://docs.google.com/a/akretion.com.br/spreadsheet/ccc?key=0AlrjP6ETn3tJdC1CUEw2bGQ1RkhDR0lmS2dGT1E4eWc#gid=0>

If contact_id decoration should be an opt-in or opt-out based on these
results is totally up for debate.

Also we may not add a contact_id on a field that is already restricted to a
commercial entity (while having a contact_id here wouldn't hurt either as
partner_id would be correct, it would just be useless that's it).
I explained the idea here:
https://docs.google.com/a/akretion.com.br/document/d/1CvPz-BZnZ-waQZoFpdIM6aNjjcbdLadGQqTZFL3lw7A/edit#heading=h.19sozwzfx45i

  - you sometimes loose information: if you modify partner_id, it magically
> overwrite your contact_id (loss of data)

we have two solutions here:

   1. require that you write both the contact and the partner in these
   cases (it's pretty rare code write on the partner alone once it has already
   been written, would that loose the contact in any critical manner here?
   unlikely)
   2. I think we could drop that feature once we make sure the addons
   properly write into contact_id when they should (like from a CRM lead to a
   sale order). Also, as I show contact_id even when it's empty when there is
   a partner_id, eventually that may not even be required at all. Not sure.

> - if a module already defined contact_id for another purpose, you have a
> conflict
>

Well in the very rare cases (5 cases in the whole the official addons) a
field is called contact_id and points to a res.partner, we can assume it's
really meant to carry a contact and we skip adding a contact field.

Honestly Fabien is much easier to handle than having for instance to
rewrite all our localization and the fiscal-rules (that would involve
testing and fixing 10 000 lines of code just for that) where we should
adapt everything in case partner_id is suddenly a contact which anyway is
illegal here. So I mean, yes this isn't that easy. But this is your fault,
it's you who created that mess and said it was ready for release. Not us.
Also you seem to forget all the conflicts that may happen when people would
otherwise add their own commercial_entity keys and on_change (to be able to
filter before record is saved) which would certainly create much more
critical conflicts as instead of deciding something structuring in the
core, we would let anyone have to make their own inconsistent decisions.

Can we please stay factual, and argue with real scenario based on tests?
> Real examples will help the discussion become clearer. Otherwise, it looks
> like we are turning around without progress.
>

Sorry: but when you say: it's normal to bring just the related contacts or
it's normal you have to fill that field on the contact because contact is
the right granularity. I say, no! All these modules have been made for
the granularity to be the company until v6.1. You cannot now change their
granularity and claim it's the expected functional result.

We can certainly also reason. It avoids underestimating the issue just
because we missed 90% of the issues with a quick superficial scan. It also
avoids we get the impression everything is addressed just because you
changed your mind so many time. Also just to remind you Fabien, over the
last 2 weeks:

   1. can we invoice contacts? yes, it's perfectly normal. then no! what a
   misunderstanding! + code forbidding it on the surface (only). Then no, of
   course we can invoice a contact!
   2. can we have a contact belonging to several companies? yes absolutely.
   But wait, there is a catch, you should create a contact for each company...
   3. does the company granuarity matter? No! the contact is the right
   granularity! Wait, actually it's true, you may need to group your invoice
   by customer/supplier, so we add that extra module assuming the total
   permutation of contact_id and partner_id that everyone should adapt too in
   their modules.

I tried to summarize the whole issue here:
https://docs.google.com/presentation/d/1y0njSpm9kqJPGFUQQTiRMIpT1M5CfKppNhslvpl-aM4/pub?start=false&loop=false&delayms=3000#slide=id.p
Feedback is welcome so that I can improve it.

Regards.
And yes, this is a boring issue. Boring for everybody for sure, but it's
certainly not by underestimating it that we will do any good in our
projects.