On 04/10/2013 09:11 PM, Fabien (Open ERP) wrote:
>> Now trying to hide the conceptual errors
>> with a model that is conceptually bad anyway.
>
> This is where we disagree. We think the data model in v7 is good. (even
> better than in v6.1).
>
>
> On the invoice, we have a field partner_id which contains "Joël,
> Camptocamp".
> Your claim is that the data model is not good because it can not work
> without
> another field "Camptocamp". (let's call it partner_commercial_id)
>
> This field must be:
>     - related: it's implementation is one line:
> fields.related('partner_id','commercial_id')
>     - readonly: no other value than "Camptocamp" is possible
>
> It's clear that adding a readonly function field:
>     - DOES NOT change anything to the data model (you just add a redundancy)
>     - DOES NOT change anything to what you can do in the code, instead of
> doing
>       invoice.partner_id.commercial_id, you would do:
> invoice.partner_commercial_id

You hit the point, Fabien.
Nobody said that the new model can not work, with some changes in some 
places. But you are in the future.
We are facing the reality and we are in the present.

Your model *is not backward compatible*, and today, the addons have not 
been changed to be compatible with your new data model.
Do the official addons have been modified to use 
'partner_id.commercial_id' instead of 'partner_id'? I don't think so 
(not only the invoice)
Do the 3000 community addons you are so proud of have been modified to 
use it? No

Worse, the field is still called 'partner_id', so the addons will still 
behave, but incorrectly.

The whole point was to say: if we ensure that we only have a 'commercial 
entity' in the field 'partner_id', we are backward compatible.

Summarizing:
Yesterday (6.1) in partner_id: only 'commercial entity', modules using 
them as commercial entities
Today (7.0) in partner_id: any type of partner, but modules still using 
them, wrongly, as commercial entities

Do you see the problem?

>
>
> Your extra field is just a technical artifact to allow group_by on
> "commercial
> entities" in invoices rather than "invoiced entities". Nothing more.
>
> We agree it's a good feature (we proposed it for v8 and, now we agree to
> do a
> module for v7) but: it's not a legal requirement, nor does it change
> anything to
> the data model (as you just add a function field)
>
>
> To be clear, we did one mistake in v7; the contacts did not inherited
> from accounting
> fields from their companies (like pricelists, account receivable) We
> should have
> done what we did for the address for these fields too. We missed that
> point. It's a
> 20 lines patch. The rest is just misunderstandings and fears.
>
>> And in any case, such semantic and conceptual changes should have been
>> debated explicitly at least 1 year before a version, certainly not 100
>> days after the "LTS" release.
>
> Yes, I do agree. We did not received enough feedback from the community
> on the version 7, during the RC phase. We got much more feedback for v6.1.
>
> These may be the reasons:
>     - We did less Release Candidate for v7 (1) than 6.1. (3)
>     - partners were expecting the v6.1 more than the v7 because there were
>       2 years between v6.1 and v7, compared to 10 months between v6.1 and
>       v7.
>     - most partners were still in their v6.1 implementations (as this
> version had
>       only 10 months old) and none really had the time to test v7. On
> v6.1, some
>       even started to deploy on trunk
>
> We will try to improve this for the next versions.
>
>
> Fabien
>


-- 
Guewen Baconnier
Business Solutions Software Developer

Camptocamp SA
PSE A, CH-1015 Lausanne
Phone: +41 21 619 10 39
Office: +41 21 619 10 10
http://www.camptocamp.com/