OpenERP v7 contacts management. Why the

"contact_id solution" is the best one

by Raphaël Valyi - Akretion.comv0.9.0

backed unanimously by all the OpenERP expertsbug https://bugs.launchpad.net/openobject-addons/+bug/1160365 gathered more than 210 posts in a month from the most experienced OpenERP implementers around the world, including many prominent partners.● all said they want the contact_id + partner_id solution● none defended OpenERP SA solution to use just one

key● none prefered OpenERP SA idea to finally leave

partner_id for contacts but add a new field commercial_entity_id that points to the legal entity again, because it's a semantic permutation of all what have been done on OpenERP the last 8 years...

which alternatives are we talking about?remember: problem technical description: http://www.slideshare.net/RaphalValyi/open-erp-v7-contacts-issue?utm_source=ss&utm_medium=upload&utm_campaign=quick-view

our "contact_id" solution:https://code.launchpad.net/~openerp-community/openobject-server/contact-id-solution-for-v7-contact-management/+merge/159316https://code.launchpad.net/~openerp-community/openobject-addons/contact-id-solution-for-v7-contact-management/+merge/159320

OpenERP SA's solution:https://code.launchpad.net/~openerp-dev/openobject-server/7.0-fix-contact-company-handling/+merge/157577https://code.launchpad.net/~openerp-dev/openobject-addons/7.0-fix-contact-company-handling/+merge/157576

Myth 1: "Raphaël's branch is buggy"one may question why OpenERP SA ignored community and made a mean caricature of a POC that should have been their job to have investigated once everybody said it was the right data model to fix the problem.

But anyway, now we are 100% green on all the tests they tried to prove us we were wrong:https://docs.google.com/spreadsheet/ccc?key=0AhmEftWbRs4sdHJqY2lfeU1HR3hwQm85QS1hQTVMcnc#gid=0

That is more green than them on their own test suite...But we will have ours...

seeing is believing

scenario 1 - all green:http://www.youtube.com/watch?v=TjouFdPnn2Y&list=PLDo85hjMzeJPT2JzEt3wUSLWHLTo4SQIg&index=1

scenario 2 - all green:http://www.youtube.com/watch?v=B4-JNlwxZ-w&list=PLDo85hjMzeJPT2JzEt3wUSLWHLTo4SQIg

We are already green on the other scenarii, videos are coming to prove it for these who would like to spread FUD.

Myth 2: "Raphael's branch is more invasive"-> Our fix has 10x less code! than theirs just to fix their own test suite:

https://code.launchpad.net/~openerp-dev/openobject-server/7.0-fix-contact-company-handling/+merge/157577https://code.launchpad.net/~openerp-dev/openobject-addons/7.0-fix-contact-company-handling/+merge/157576https://code.launchpad.net/~openerp-community/openobject-server/contact-id-solution-for-v7-contact-management/+merge/159316https://code.launchpad.net/~openerp-community/openobject-addons/contact-id-solution-for-v7-contact-management/+merge/159320

number lines of patch

partner_id + commercial_entity_id

contact_id + partner_id

server (+441/-93) 3 files modified +148/-0) 2 files modified

addons (+335/-38) 26 files modified 33/-29) 17 files modified

Myth 3: "OpenERP innovated in version 7.0, contact_id is refusing the innovation"● we also think moving persons/contact and company in

the same table was great● the thing is despite contact could be anything we never

believed an ERP could work without also maintaining a key to the related legal entity of a business document

● we also have only one contact field in the user interface

● user can see NO DIFFERENCE with OpenERP SA in term of record edition usability

Seeing is believing:http://www.youtube.com/watch?v=TjouFdPnn2Y&list=PLDo85hjMzeJPT2JzEt3wUSLWHLTo4SQIg&index=1

Myth 4: they "tested it for 12 months OpenERP has been made for mixing persons and companies in a single key"

● probably the social features developed over the last months were done for partner_id being a contact. Well we don't touch them an pass them contact_id at the few required spots to ensure social things work the same.

● But in any case, one thing is these few shiny social features developed by OpenERP SA alone over the last months VS the collective construction of the mission critical ERP features of OpenERP these last 8 years in association with hundreds of experts from the community.

Myth 4: they "tested it for 12 months OpenERP has been made for mixing persons and companies in a single key"No sorry the fix they are now making wasn't something "designed" at all. I rather call that an urgent and ugly duct tape to avoid telling the truth and taking care about guys in productions.

2 months after the release, invoicing a picking was still creating financial moves toward the address instead of the company:http://www.linkedin.com/groups/B2B-related-question-all-Fans-165657.S.214411619http://bazaar.launchpad.net/~openerp/openobject-addons/7.0/revision/8810

Also the critical severity of the the "contacts" bug discovered as generalized 3 months after the LTS release shows that things weren't planned properly. It wasn't "designed" to fully work this way.

My interpretation:

OpenERP SA did the mistake to "believe" only one key to the contact would be enough (you can infer the compay from the contact, no?). So they thought they could drop the other key and use only partner_id as a contact, that would be simpler!

But now under the pressure, they finally released that two keys in the data model were actually needed for B2B ERP features.

So since they already started using partner_id both for persons and companies, they now want that the legal entity is carried by a key called commercial_entity_id instead of partner_id. That is it has permuted what kind of record a partner_id in the same code means!

Myth 5: "OpenERP SA's solution is a serious solution"It's not!!!So now that they finally released that some code expecting a company now receives a person randomly in partner_id, in order to fake that a person can now behave like company, they now propose to:● hard copy fiscal and accounting company data over all

its contacts. Duplicating their properties records.. (see server patch)

● reading and writing company data to persons may work on the surface. But in term of cardinality it introduce many hidden regression in the official and third party code base.

● it still means a semantic permutation of two fields, it's why their patch is so huge (to fix just the invoice object)

Our contact_id solution is clean instead!OpenERP SA's solution: permutation

Our contact_id solution: preserved semantic

person legal entity

v6.1 address_id partner_id

v7 partner_id commercial_entity_id

person legal entity

v6.1 address_id partner_id

v7 contact_id partner_id

Our contact_id solution is clean instead!That is our solution repairs things before entering the code: it repairs the user interface directly so that the user selects a contact but under the cover, it properly sets the related partner_id and the existing codebase receives exactly what it expects: a legal entity.

If we want to do social features with the contact, we can still use contact_id!

Myth6: It's not a matter of variable name!!No because we aren't dealing with just an isolated piece of code where we could just replace the variable names.fields names are all inter-dependent from:● data from databases● foreign keys in the schema● variables passed back and forth to the user interface in

very complex manner● functions in a galaxy of third party modules calling

themselves and injecting determined variables only

Myth6: It's not a matter of variable name!!It means that we have a problem with cardinality essentially.

That is when we iterate over all records linked to a company. If instead we iterate over records related to a mere contact of this company, results are very unexpected (we miss records essentially).

Same thing happens when searching if things pointing to a given person or company exist or not.

My other slides give more details examples about this chaoshttp://www.slideshare.net/RaphalValyi/open-erp-v7-contacts-issue?utm_source=ss&utm_medium=upload&utm_campaign=quick-view

Our contact_id solution is still social...

● we can still search both by contact or by company● auto-completion works● we can group both by contact or by company (they

cannot)● we can relate both by contact or by company (they

cannot)

Myth 7: "impact on third party module is similar"No!! Absolutely not and this is the main catch!If you don't understand this yourself you should absolutely get in touch with the people who understand the problem, don't be abused with that.

With the refusal to integrate our 200 code lines patch, that would endup forcing the community to literally review and change the logic of hundreds of thousands of lines of code globally!

Let's explaining why...

Myth 7: "impact on third party module is similar"Indeed: porting from 6.1 to 7.0 is already some work, but it's a bit mechanical.Now, if instead the partner_id semantic is permuted, people will have to be very careful about the cardinal discrepancies in their code, they may need to● rewrite their iterations over records related to

companies● rewrite "domains" and search for related records● rewrite their SQL reports● introduce new keys to the company (missing else) and

pass them back and forth in the user interface...All that should be done by people with deep functional understanding instead, probably some regressions only detected in production...

Myth 7: "impact on third party module is similar"data copy and duplication from the company to its contacts definitely helps to hide some issues for reading company data on person records.

But it doesn't come free either: people have to think what data they will get duplicated or not. For instance you hardly can copy the company country to the contact country. But your code may now read it from a contact..

And it only hides the issue at the price of a very ugly non CODD canonical data model. That is: one day, to have a clean normalized data model again, all that will have to be rewritten anyway, reading things on the right entity: the company

Not adopting the contact_id solution will fragment the ecosystem!

1. If OpenERP SA drops his solution. No fork will be created to absolutely duplicate data and permute the semantic because nobody approves that...

2. But in the contrary option. Some will see our solution is much easier to migrate existing codebase to and that it doesn't blindly trust semantic permutation will have a very limited impacted only (eg functional regressions for years). So some of us will use that branch anyway.

Not adopting the contact_id solution will fragment the ecosystem!

Illustration: Akretion Brazil: we already migrated 15 000 lines of localization alone to v7.0 but assuming partner_id was still a legal entity.We have 5 customers in production in 7.0 waiting for a solution for contacts quickly.

We aren't going to rewrite again these 15 000 lines of code overnight to make it work with partner_id as a contact, just because OpenERP SA did a mistake they don't want to assume it.

Not adopting the contact_id solution will fragment the ecosystem!

Instead, using that branch is much less risky for us: we can use v7 already with the same robustness as 6.1. We don't need to have to rely on anybody hypothetically fixing or not in the future the regressions they are just introducing now by assuming the semantic permutation.

Is it a fork?

good question.Well at least for no this is not the objective.We still have some hope to maintain a synergy in the OpenERP ecosystem.

Our objective is simply to be able to keep doing large B2B projects with OpenERP without to have to put too much faith in overnight big bang rewrite neither too much faith SA will some day fix all the advanced B2B bugs they are introducing now with the permutation.

Then what the f*ck is it?

Today it's a tracking branch proposal● ideally merged weekly from OpenERP SA's branch just

like OCB branch● ideally THIS would be the OCB branch. Let's see if we

can agree on that● merging will require some manual work. But not as

much as you could think: ○ if no 'partner_id' is detected in a diff, then merge will

be automatic!○ else (5-10% of addons merges?) then yes, some

simple manual work will be required to avoid doing crap.

Today it's a tracking branch proposal● because OpenERP SA still accepts that partner_id can

be a company (it can be a person or a company in their model). Their code will in fact largely works in our code: if we take the commercial_entity of a company, it will be the same id, it will still work!

● So the risk is very limited: the risk is basically only to loose the contact record somewhere because we used their partner_id instead of contact_id. Well not mission critical, easy to fix! That's what we said since the beginning: I prefer sending a mail to a company instead of a contact rather than screwing predictive cash flow reporting because ids don't match anymore.

● instead our code will likely need some adaption to work in OpenERP SA world.

Where does it bring us?

In fact, migrating a database back and forth from our branch or to the permuted OpenERP SA branch is mostly some 15 SQL commands to rename 2 columns for some ~6 entities:

partner_id <-> contact_idcommercial_entity_id <-> partner_id

And also trigger the data duplication to the contacts on OpenERP SA's branch (and cry silently with your teddy bear).

where does it bring us?

So we are doing this to keep being able to be successful with OpenERP v7 during 2013.After 6 months or one year, it may take these directions:● OpenERP SA merge to our solution again● may be OpenERP SA will have fixed B2B contacts issues

in general and we could migrate to OpenERP SA branch by rewriting our modules to match the permutation (at least no need to do it now).

● It can keep being a tracking branch if that's the easiest solution

● Else, yes, that can be a fork. In any case we aren't going to fork alone like crazy. So that doesn't depend on just us.

Where does it bring us?

In the meantime, thanks to these bijective 15 lines SQL scripts we could still revert decisions.

We could even still take advantage of Enterprise contracts: migrate to the permuted OpenERP SA be, version, apply the script and be back in the non permuted world for which we adapt our modules.

Now of course, that doesn't mean we would love to keep selling them if that's us who should do editor's job, but that's another story.

What's next?

● keep trying pressuring OpenERP SA to take what we think is the right decision

● prove automatic merge is easy by simulating it from the past (get an estimate how automatic it is)

● prove SQL columns renames can take us back and forth from the two worlds.

● give attention to our projects again with this branch● see who is with us if we aren't with OpenERP SA● put at work a rotation to do the merge tracking job and

merge from OCB if we aren't OCB (you are with us Stefan, right?)

● keep elaborating organization so that we can keep moving this forward with or without OpenERP SA.

● right now: get some sleep ;-)