OpenERP "contact id solution" to the contacts issue in v7


Published on

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

OpenERP "contact id solution" to the contacts issue in v7

  1. 1. OpenERP v7 contactsmanagement. Why the"contact_id solution" is thebest oneby Raphaël Valyi - Akretion.comv0.9.0
  2. 2. backed unanimously byall the OpenERP expertsbug gathered more than 210 posts in amonth from the most experienced OpenERP implementersaround the world, including many prominent partners.● all said they want the contact_id + partner_id solution● none defended OpenERP SA solution to use just onekey● none prefered OpenERP SA idea to finally leavepartner_id for contacts but add a new fieldcommercial_entity_id that points to the legal entityagain, because its a semantic permutation of allwhat have been done on OpenERP the last 8 years...
  3. 3. which alternatives are wetalking about?remember: problem technical description: "contact_id" solution: SAs solution:
  4. 4. Myth 1: "Raphaëls branch isbuggy"one may question why OpenERP SA ignored communityand made a mean caricature of a POC that should havebeen their job to have investigated once everybody said itwas the right data model to fix the problem.But anyway, now we are 100% green on all the teststhey tried to prove us we were wrong: is more green than them on their own test suite...But we will have ours...
  5. 5. seeing is believingscenario 1 - all green: 2 - all green: are already green on the other scenarii, videos arecoming to prove it for these who would like to spread FUD.
  6. 6. Myth 2: "Raphaels branch ismore invasive"-> Our fix has 10x less code! than theirs justto fix their own test suite: linesof patchpartner_id +commercial_entity_idcontact_id +partner_idserver (+441/-93) 3 files modified +148/-0) 2 filesmodifiedaddons (+335/-38) 26 files modified 33/-29) 17 filesmodified
  7. 7. Myth 3: "OpenERP innovated inversion 7.0, contact_id is refusing theinnovation"● we also think moving persons/contact and company inthe same table was great● the thing is despite contact could be anything we neverbelieved an ERP could work without also maintaining akey to the related legal entity of a business document● we also have only one contact field in the userinterface● user can see NO DIFFERENCE with OpenERP SA interm of record edition usabilitySeeing is believing:
  8. 8. Myth 4: they "tested it for 12 monthsOpenERP has been made for mixingpersons and companies in a single key"● probably the social features developed over the lastmonths were done for partner_id being a contact. Wellwe dont touch them an pass them contact_id at the fewrequired spots to ensure social things work the same.● But in any case, one thing is these few shiny socialfeatures developed by OpenERP SA alone over the lastmonths VS the collective construction of themission critical ERP features of OpenERP theselast 8 years in association with hundreds of expertsfrom the community.
  9. 9. Myth 4: they "tested it for 12 monthsOpenERP has been made for mixingpersons and companies in a single key"No sorry the fix they are now making wasnt something"designed" at all. I rather call that an urgent and ugly ducttape to avoid telling the truth and taking care about guys inproductions.2 months after the release, invoicing a picking was stillcreating financial moves toward the address instead of thecompany: the critical severity of the the "contacts" bugdiscovered as generalized 3 months after the LTS releaseshows that things werent planned properly. It wasnt"designed" to fully work this way.
  10. 10. My interpretation:OpenERP SA did the mistake to "believe" only one key to thecontact would be enough (you can infer the compay from thecontact, no?). So they thought they could drop the other keyand use only partner_id as a contact, that would be simpler!But now under the pressure, they finally released that twokeys in the data model were actually needed for B2B ERPfeatures.So since they already started using partner_id both forpersons and companies, they now want that the legal entity iscarried by a key called commercial_entity_id instead ofpartner_id. That is it has permuted what kind of record apartner_id in the same code means!
  11. 11. Myth 5: "OpenERP SAssolution is a serious solution"Its not!!!So now that they finally released that some code expecting acompany now receives a person randomly in partner_id, inorder to fake that a person can now behave like company,they now propose to:● hard copy fiscal and accounting company data over allits contacts. Duplicating their properties records.. (seeserver patch)● reading and writing company data to persons may workon the surface. But in term of cardinality it introducemany hidden regression in the official and third partycode base.● it still means a semantic permutation of two fields, itswhy their patch is so huge (to fix just the invoice object)
  12. 12. Our contact_id solution isclean instead!OpenERP SAs solution: permutationOur contact_id solution: preservedsemanticperson legal entityv6.1 address_id partner_idv7 partner_id commercial_entity_idperson legal entityv6.1 address_id partner_idv7 contact_id partner_id
  13. 13. Our contact_id solution isclean instead!That is our solution repairs things before entering thecode: it repairs the user interface directly so that the userselects a contact but under the cover, it properly sets therelated partner_id and the existing codebase receivesexactly what it expects: a legal entity.If we want to do social features with the contact, we can stilluse contact_id!
  14. 14. Myth6: Its not a matter ofvariable name!!No because we arent dealing with just an isolated piece ofcode 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 invery complex manner● functions in a galaxy of third party modules callingthemselves and injecting determined variables only
  15. 15. Myth6: Its not a matter ofvariable name!!It means that we have a problem with cardinalityessentially.That is when we iterate over all records linked to acompany. If instead we iterate over records related to amere contact of this company, results are very unexpected(we miss records essentially).Same thing happens when searching if things pointing to agiven person or company exist or not.My other slides give more details examples about this chaos
  16. 16. Our contact_id solution isstill social...● we can still search both by contact or by company● auto-completion works● we can group both by contact or by company (theycannot)● we can relate both by contact or by company (theycannot)
  17. 17. Myth 7: "impact on thirdparty module is similar"No!! Absolutely not and this is the main catch!If you dont understand this yourself you should absolutelyget in touch with the people who understand the problem,dont be abused with that.With the refusal to integrate our 200 code linespatch, that would endup forcing the community toliterally review and change the logic of hundreds ofthousands of lines of code globally!Lets explaining why...
  18. 18. Myth 7: "impact on thirdparty module is similar"Indeed: porting from 6.1 to 7.0 is already some work, butits a bit mechanical.Now, if instead the partner_id semantic is permuted,people will have to be very careful about the cardinaldiscrepancies in their code, they may need to● rewrite their iterations over records related tocompanies● rewrite "domains" and search for related records● rewrite their SQL reports● introduce new keys to the company (missing else) andpass them back and forth in the user interface...All that should be done by people with deep functionalunderstanding instead, probably some regressions onlydetected in production...
  19. 19. Myth 7: "impact on thirdparty module is similar"data copy and duplication from the company to its contactsdefinitely helps to hide some issues for reading companydata on person records.But it doesnt come free either: people have to think whatdata they will get duplicated or not. For instance you hardlycan copy the company country to the contact country. Butyour code may now read it from a contact..And it only hides the issue at the price of a very ugly nonCODD canonical data model. That is: one day, to have aclean normalized data model again, all that will have tobe rewritten anyway, reading things on the right entity:the company
  20. 20. Not adopting the contact_id solutionwill fragment the ecosystem!1. If OpenERP SA drops his solution. No fork will becreated to absolutely duplicate data and permute thesemantic because nobody approves that...2. But in the contrary option. Some will see our solution ismuch easier to migrate existing codebase to and that itdoesnt blindly trust semantic permutation will have avery limited impacted only (eg functional regressions foryears). So some of us will use that branch anyway.
  21. 21. Not adopting the contact_id solutionwill fragment the ecosystem!Illustration: Akretion Brazil: we already migrated 15 000lines of localization alone to v7.0 but assumingpartner_id was still a legal entity.We have 5 customers in production in 7.0 waiting for asolution for contacts quickly.We arent going to rewrite again these 15 000 linesof code overnight to make it work with partner_id as acontact, just because OpenERP SA did a mistake they dontwant to assume it.
  22. 22. Not adopting the contact_id solutionwill fragment the ecosystem!Instead, using that branch is much less risky for us: we canuse v7 already with the same robustness as 6.1. We dontneed to have to rely on anybody hypothetically fixing or notin the future the regressions they are just introducing nowby assuming the semantic permutation.
  23. 23. 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 theOpenERP ecosystem.Our objective is simply to be able to keep doing large B2Bprojects with OpenERP without to have to put too muchfaith in overnight big bang rewrite neither too much faithSA will some day fix all the advanced B2B bugs they areintroducing now with the permutation.Then what the f*ck is it?
  24. 24. Today its a tracking branchproposal● ideally merged weekly from OpenERP SAs branch justlike OCB branch● ideally THIS would be the OCB branch. Lets see if wecan agree on that● merging will require some manual work. But not asmuch as you could think:○ if no partner_id is detected in a diff, then merge willbe automatic!○ else (5-10% of addons merges?) then yes, somesimple manual work will be required to avoid doingcrap.
  25. 25. Today its a tracking branchproposal● because OpenERP SA still accepts that partner_id canbe a company (it can be a person or a company in theirmodel). Their code will in fact largely works inour code: if we take the commercial_entity of acompany, it will be the same id, it will still work!● So the risk is very limited: the risk is basically onlyto loose the contact record somewhere because weused their partner_id instead of contact_id. Well notmission critical, easy to fix! Thats what we saidsince the beginning: I prefer sending a mail to acompany instead of a contact rather than screwingpredictive cash flow reporting because ids dont matchanymore.● instead our code will likely need some adaption to workin OpenERP SA world.
  26. 26. Where does it bring us?In fact, migrating a database back and forth from ourbranch or to the permuted OpenERP SA branch is mostlysome 15 SQL commands to rename 2 columns for some ~6entities:partner_id <-> contact_idcommercial_entity_id <-> partner_idAnd also trigger the data duplication to the contacts onOpenERP SAs branch (and cry silently with your teddybear).
  27. 27. where does it bring us?So we are doing this to keep being able to be successful withOpenERP 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 issuesin general and we could migrate to OpenERP SA branchby rewriting our modules to match the permutation (atleast no need to do it now).● It can keep being a tracking branch if thats the easiestsolution● Else, yes, that can be a fork. In any case we arent goingto fork alone like crazy. So that doesnt depend on justus.
  28. 28. Where does it bring us?In the meantime, thanks to these bijective 15 lines SQLscripts we could still revert decisions.We could even still take advantage of Enterprisecontracts: migrate to the permuted OpenERP SA be,version, apply the script and be back in the non permutedworld for which we adapt our modules.Now of course, that doesnt mean we would love to keepselling them if thats us who should do editors job, butthats another story.
  29. 29. Whats next?● keep trying pressuring OpenERP SA to take what wethink is the right decision● prove automatic merge is easy by simulating it from thepast (get an estimate how automatic it is)● prove SQL columns renames can take us back and forthfrom the two worlds.● give attention to our projects again with this branch● see who is with us if we arent with OpenERP SA● put at work a rotation to do the merge tracking job andmerge from OCB if we arent OCB (you are with usStefan, right?)● keep elaborating organization so that we can keepmoving this forward with or without OpenERP SA.● right now: get some sleep ;-)