Comment 93 for bug 1160365

Revision history for this message
Fabien (Open ERP) (fp-tinyerp) wrote : Re: [Bug 1160365] Re: [7.0] incorrect handling of contact/companies for invoicing and related purposes

> 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

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