Comment 27 for bug 1160365

Revision history for this message
Raphaƫl Valyi - http://www.akretion.com (rvalyi) wrote :

Hello,

So I implemented a module attempting to fix the contact data model in OpenERP v7.

Basically, for every OpenERP business object having a partner_id field, it adds a new contact_id field.
Then it override the views so that by default only the contact_id field is shown to the user. In contact_id, the user can select any contact just as in the regular v7. BUT, in the on_change event, the partner_id field is set with the proper related "commercial entity".

Features:
========

1) The partner_id field is really what the code as always been expected, you don't need to sell your soul anymore to the devil by believing blindly unprepared code can cope with such a huge semantic change (contacts in partner_id).

2) As your documents are guaranteed to have a proper commercial entity key, then grouping and relating documents by companies just work again.

3) All documents also have a contact_id key to keep a reference to the contact.

4) You can even search documents both by contacts or by companies.

5 ) There is a new "Advanced Contact Management" security group. If you belong to that group, then you see both contact_id and partner_id in the forms, so you could eventually set a contact from a different company if you want. This could pave the way to some kind of base_contact module in v7.

6) The way I add the contact_id field is extensible. You could extend my decorator to add extra intermediary levels (and security groups) if that's of any use: like contact < regional division < national division < company. Of course all that could be inferred again from the contact, but having it directly in the documents, may ease analysis and relating documents. Well in any case, this is just an idea, as it is, it only adds the contact_id field.

Current Limitations:
=================

1) The contact_id field may not be propagated from a document to another because the official codebase is ignoring contact_id so far. Well, this isn't such a big deal, because you won't need to propagate a contact from a document to another so often. Main use cases could be: CRM to sale order, sale order to invoice and purchase order to invoice. For these simple case, we could easily override the few involved methods specifically to ensure contact_id is passed. In any case, with my module, at least now you have a guarantee that the "commercial entity" is kept between document. That is in any case you can match upon partner_id as before: you may get documents from other contacts, but at least you won't miss any anymore.

2) if you don't belong to the "advanced contact management" group and see only the contact_id field and if some from on_change sets the partner_id field in the form. Then your contact_id field isn't going to be updated at the moment. Suggestions to work around this are welcome. Fortunately, the case may not be common, and again, we could override it specifically.

That's it. I don't claim it's perfect yet. It's a first version. Feedback and suggestions are welcome.

Here is the module:
http://bazaar.launchpad.net/~akretion-team/openobject-addons/akretion_b2b_unfck/files/head:/akretion_b2b_unfck

Best regards.