Friday, October 15, 2010

base_contact module, heaven or hell?

Well, a lot of companies when they saw the partners (without the base_contact), they think that they need contacts separated from the addresses. In 70% of the cases they don't need it really but if they need it you think directly... base_contact... but this module is hell or heaven?

Just comment it!

Good reading for the CEO of OpenERP:,descCd-description.html


  1. Pragtech solved that in there version of there crm, the way it should be !!!
    I do believe the team should take a look at it

  2. i can guess who the hell you are. there are very few dirty minds who beleve in cut short ohters line to show there's big. i am sure you proove to be one of them .

  3. A person is a person is a person.

    A person has attributes.

    A person can be classified by a "person class" or whatever -- business, organization, employee, friend, neighbor, race car driver. THIS IS Object Oriented 101. OpenERP violates the most basic tenet of OO design.


    RESULT REDUNDANT code with addresses and phone numbers spread all over the place. Four times the work.

    I'd rather have a common "person" with appropriate attributes and the new derived classes of persons according to their type(s).

  4. Your diagram is misleading. There are no duplicate / redundant keys in the relationship, as your diagram suggests.

    - The 'job_id' field on Contacts is a fields.related field, which returns the 'Main Job' of the contact. This value is calculated, not stored.
    - I do not believe there is a 'job_id' field on res_partner_address, however there is a 'job_ids' field, which again is a 'virtual' one2many field just used in the UI
    - The partner_id field on Contacts is again a fields.related field which is used in the UI. If you bothered to look at the actual database tables you would see that again this value is not actually stored.

    The relationship between partners and contacts is as so:

    * partners have multiple addresses (FK: partner_id on res_partner_address)
    * addresses have mupltiple job roles (FK: address_id on res_partner_job)
    * jobs are linked to a contact (FK: contact_id on res_partner_job)

    Thats it!

    I actually think the structure introduced by base_contact is very good. It allows contacts to be linked to multiple addresses and multiple companies, which is something not possible in a lot of other CRM systems I have used.

  5. @ Russell Briggs - Spot on.
    @ Anon - A person is a person, a job is a job, an address is an address, and a company is a company. What's your problem?

    base_contact offers a very good model for contact management (one of the few that avoids having to hijack contact entries to store company or street/postal addresses) but it alters the OpenERP schema in such a way that unless modules provide explicit support for it, they become broken.

    _My_ problem with this whole mess is that you read the documentation and you're told the product supports either of two contact models. Great, you decide base_contact fits your needs and get started. later, you find that CRM is broken, but find crm_base_contact, which fixes most but not all the problems. This pattern is repeated over and over - all over the place you find module related to contacts (LDAP sync etc) but few if any are designed with base_contact in mind.

    It should either be made the default or removed completely IMO. I'd prefer the former since its very good, but resigned to the latter because it breaks so many things. :(

    Wondering if it all could have been different if the initial terp implementation had used res_contact instead of res_address for the contacts. Then all the other objects in the system that refer to a contact, would still work when you added the concepts of address and job. Unfortunately, res_address was actually a contact, so now with base_contact, everywhere other objects refer to a contact, they point to an office street address - GRRRRR.