Comment 160 for bug 1160365

On 15/04/13 03:04, Maxime Chambreuil (http://www.savoirfairelinux.com)
wrote:
> @fabien
>
> We all agree we need 2 levels, but disagree on field names:
> * The community wants contact and partner
> * OpenERP SA wants partner and commercial_entity

I think we disagree on the principle, not on the field names. We want
partner_id, commercial_id because:
   - partner_id is the main field (commercial_id is just a readonly
function field to guarantee consistency)
   - commercial_id is not required on all objects as it's exactly the
same than partner_id.commercial_id, so we will just put it where it's
required as a technical artifact to allow specific reporting, not
everywhere.

> If we were having this discussion a year ago I would say : "Let's go
> with your data model with the same field names : contact vs partner" and
> OpenERP SA would have implemented it during 2012.
>
> Unfortunately, we never had this discussion last year, you chose to use
> one field partner_id and forgot about the second level. You realized the
> problem 3 months after the release and now you want to add the second
> level with commercial_entity_id.

As I said, we don't want to add a second level everywhere as it's just
redundancy. But we are ready to create modules for every object the
community would like to change because it's compatible with our point of
view.

> You are just trying to push your solution into our throat, because you
> already did the migration of your modules to the new field names. You
> leave us with no other way than migrating our modules AND updating them
> to your field names. You made a mistake and the community has to assume
> it. This is not fair and unprofessional.

It's not community against OpenERP SA. Whatever the solution we choose,
the community have to adapt their modules to v7 for plenty of others
reasons (res.partner.address does not exists, new form views, ...)
Renaming contact_id into partner_id is just 10 minutes of work per module.

The reason we think we should keep our model is because it's implemented
in trunk for one year and we did extensive tests and adapted all modules
for it. Trying to change this would have the opposite impact of what you
try to do: create much more bugs.

> Where does this lead us ?
> 1) OpenERP SA merges Olivier's branch and the community adapts his modules to use partner vs commercial entity.
> 2) OpenERP SA assumes his responsibility, reverts its modules to use contact vs partner, releases a 7.1 and handles the migration from 7.0 to 7.1.

1. the community adapt his modules
2. the community adapt his modules + we change all official modules (one
year) + review migrations

And they are no real argument that makes us fell our data model is
wrong. I only hear one valid argument for now on: "desactivating a contact".

> Fabien, can you provide a third option where each party will at least
> get out of this situation with something ? Otherwise the frustration
> will go on forever.

I'll try to make a proposition later today.

> Can you also make sure the Community is involved earlier in the process
> to avoid this situation in the future ? I hope we will use this
> situation as a way to grow and move forward.

Yes, we did not foreseen such a misunderstanding on the model otherwise,
we would have communicated earlier on the reasons of this change. (I
don't think we would have done it differently, because we think it's the
best approach for the product.) But this model is not new, we explained
it and demo it at the community days 2012, so it's in trunk since one year.

And, they are much more changes that this one in the v7 (v7 = around
1400 tasks for us). It's quite complex to explain every change into the
detail. We try to do our best: we invested a lot of time on the release
note that has more than 100 pages. But I agree it's not enough.

So, I think:

1. We can improve the way we communicate for sure. It's often a problem.
2. But we will still have such misunderstandings in the future (around
once a year, that's the current frequency)

Fabien