> 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.
> 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, commercial_ id)
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_
This field must be: related( 'partner_ id','commercial _id')
- related: it's implementation is one line:
fields.
- readonly: no other value than "Camptocamp" is possible
It's clear that adding a readonly function field: partner_ id.commercial_ id, you would do: partner_ commercial_ id
- 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.
invoice.
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