>
>
> As Olivier said, the problem of raphael's branch is not that he tried to
> limit changes. The problem is that he tries to simulate the v6.1 logic on
> top of the v7 data model/semantic which as no sense.
>
> This leads to:
>   - a lot of side effects as he impacts all business documents
>   - a wrong usage of objects according to how they have been developed
>

I strongly disagree with this claim Fabien: during 8 years, hundreds of
people collaborated to make the model we have in 6.1 work. And that model
almost never used contacts, only marginally as an extra field. But
partner_id was NEVER a contact and this is exactly what the code has been
developed for, not only in the official addons but also in the thousands of
community modules you are so proud to quote.

On the contrary, the 7.0 developments were mostly web/usability things
(unfortunately) and that change to put addresses and partners inside the
same table (which is a good move I think) but WITHOUT anticipating almost
anything related to the semantic change of partner_id and the relational
cardinality discrepancies with contacts being in partner_id for a code that
was absolutely not planed for that. As this bug and others mentioned
regressions around contact just proves it. That is OpenERP objects were
certainly not developed for partner_id to be eventually a contact as you
claim. Only the recent v7 4-5 social eye candy features nobody here really
cares about at best.

I totally don't want to revert everything to 6.1. It's cool that you can
pick anything in the contact_id field because everything is now in the same
table. It's cool if you can send a mail or a message to a company or a
person with the same code and SQL key.
Now I say it's not because SOME code can cope both with persons and
companies that you can blindly mix them ALWAYS as if they were the same
thing. Specially in a world that is all carried by SQL which determine what
we can do or not at a reasonable effort and performance at the end of the
day.

And you say it's "Raphaël", but if you read carefully the thread, EVERYBODY
here said they want 2 keys: the partner_id key and the contact_id key.
NOBODY here stood up and said "mixing companies and contacts in partner_id
is the right thing, OpenERP SA is right". NOT A SINGLE guy except Olivier
and you defended that idea.
Sorry but you are blind if you don't see this from reading the thread.

You say my code impacts everything, but I think instead it fixes all the
issues that have been opposed to you in this thread. Oh yes, it currently
send the email to the company instead of the contact, but it's something
much less critical and easy to fix, specially easy as with my code you can
still use contact_id because you can CHOOSE if you want a contact or
partner_id which is guaranteed to be the company (or physical person) just
like the vast majority of existing code expects.

As for the code not being very clean: well of course, once things are
screwed in the core, un-crewing them without forking might be acrobatic,
that's acknowledged.
At least that code proves it's possible to fix v7 and this is what I
wanted. People can easily try the module at
https://bugs.launchpad.net/openobject-addons/+bug/1160365/comments/27
and see everything they would expect when using contacts/addresses just
work again as they expected.

Now, yes, we need to be organized to see how we actually implement it.
There are several solutions on the table:

   1. do it more cleanly inside the ORM and merge it. And also use
   contact_id in some 4-5 places in the addons where it should really use the
   contact (sending email, propagate contact from CRM to order to invoice,
   from PO to invoice, at least). That supposes we have confidence OpenERP SA
   will listen.
   2. continue to do it as a monkey patch and complete it to get contact_id
   properly used in the scenarios just mentioned. But that may mean getting
   hard times merging OpenERP SA work in the future when you will release that
   the single key solution doesn't do it and start adding a new key, assuming
   the partner_id semantic swap more widely (despite you are now minimizing
   the impact). In principle, as you accept partner_id to be a company, that
   should still mostly work with my module despite making code ugly and
   slower. But may be not forever. Also, people like us won't want to rely on
   your ideas for the migrations of our customers (I cannot imagine you put
   the address in the partner_id of my the invoices of my customers), so yes,
   at some point that will end up questioning if we can resell OpenERP SA
   services and be partners. Not being partners may certainly question if we
   will accept to be victims of the organized commercial distortion of the
   open source meritocracy. So escalation is to be feared unfortunately even
   if that's is really not what we wished.
   3. we do the changes in a branch, like an OCB branch and maintain it
   collectively. Despite it's cleaner, it's also more fragmenting for the
   OpenERP community. Our modules like localization will work on OCB branch
   but not a chance on OpenERP SA branch not even in degraded mode. The time
   passing, it may raise the same questions as 2) about commercial
   collaboration with OpenERP SA.
   4. we fork more assumingly sooner. Certainly not something that I
   wished. But today I see that: going the way SA wants is suicide for our
   customers which have real ERP expectations where you can analyse and cross
   data by customer/supplier and not only by contact. Having to maintain a
   branch seems like less work than believing we can change in just a few
   month all OpenERP codebase which took hundreds of people nearly 10 years to
   work is it was known to work until 6.1 that made OpenERP reputation to
   date. This is all the most impossible to believe when we see how much
   effort we should usually do to get just a little regression fixed in the
   official branch.


Regards.