Comment 9 for bug 1160365

Revision history for this message
Raphaƫl Valyi - http://www.akretion.com (rvalyi) wrote : Re: [Bug 1160365] Re: [7.0] incorrect handling of contact/companies for invoicing and related purposes

> @raphael
> > Wouldn't that be by kind of "overriding the read of res.partner" to read
> the value from
> > the parent_id in case of a company contact as I described in A) ?
>
> No, overwriting the create and write, so that all contacts have the
> right data in the DB.
>
> When you write on the main company, it will write the same to data to
> all children contacts. That's what we already do for contacts that share
> the address with the company and it works fine in v7.
>

@Fabien, this enable reading the proper data inside the contact record.

But
1) how will you decide which fields exactly are copied or not?
2) how does it scales across modules adding fields in res.partner, which
fields will be copied or not?

And mostly
3) what about all the existing business logic that makes a decision by
taking some arbitrary foreign key pointing to the res.partner table and
comparing it with partner_id. What leads you to warranty us with so much
assurance that the code will always be consistent with the expected
behavior if partner_id can now randomly be the parent company or any of its
contacts?
So for me, out of the box, sometimes there will be a match and sometimes
not. While until v6.1 the code always assumed it should match if that's the
same partner_id company, no matter what user selected as the contact.
I gave several examples of them in a previous comment without having to
search a lot.

IMHO you are not considering this pitfall enough.

And again, what is the advantage over adding a contact_id field?
You want to be able to use contact_id anywhere because you believe this is
better (I don't, I think this predates the reporting and business data
integrity). But is there any urgency to try to make this new feature work?
Having so many strong indicators regressions will not be detected nor fixed
easily, shouldn't we better adopt a conservative stance that is FIRST do a
solution that protect us against regressions AND THEN eventually implement
the new feature in a next release, while taking all the care to guarantee
there is not a bunch of hidden regressions BEFORE releasing?

My 2 cents.