Comment 90 for bug 1160365

On 10/04/13 16:32, Guewen Baconnier @ Camptocamp wrote:
> On 04/10/2013 04:26 PM, Guewen Baconnier wrote:
>
>> That's an end user point of view. I won't argue because that's not the
>> most important point for me, even if it sounds a bit like 'we remove
>> them because they reveal the flaws of our model'.
>>
>> So, finally you admit that you broke the o2m relations linked to
>> res.partner, and you have to admit that you broke all the community
>> modules which were relying on the one2many, expecting that a o2m was
>> linked to the correct partner_id. And that without any note or warning.
>>
> I meant that the problem on views can be "fixed" by replacing the o2m in
> views by links / buttons.
>
> But that's "only" a view problem.

No, it's not a problem at all. It's the correct behaviour.

On this structure:
   Camptocamp
     - Camptocamp, France
     - Camptocamp, Switzerland

If I do a delivery order to "Camptocamp, France", it's normal that there are
no delivery order for "Camptocamp, Switzerland". The opposite would be a
mistake. And it's the same for claims, invoices, ... This is true for
the view
AND on the object. Having something else would be completly wrong.

If I understand, in the field claim_ids on the partner "Camptocamp", you
expect to see claims from "Camptocamp, France"? I don't think it has sense.
(at least according to the semantic we used to define partners which are
different entities)

The child_of we propose is not a way to 'simulate' that claims or
invocies to
"Camptocamp, Switzerland" also belong to "Camptocamp, France". That's
wrong, these are different.

It's just a tool to help searching recursively in the group (just a UI
feature) but
it's clear that each document belong to a different partner.

>
> The same can occurs in the code, in the logic of the code, and I don't
> think any of:
> - the official addons
> - the community addons
> have been adapted to use the 'child_of' instead of the '='.
>