Odoo Addons (MOVED TO GITHUB)

Bug #1160365
Comment #149

Comment 149 for bug 1160365

Revision history for this message

Michael Telahun Makonnen (mmakonnen) wrote on 2013-04-14:

#149

+1 for partner_id + contact_id

@ fabien said in reply #146:
" As you may know; users should never change the company of a contact
because the contact started to work for another company. The only valid
reason [1] to change the company of a contact is because you fix a
wrongly created record. And, for those that want to handle contacts that
change of companies, we have the base_contact module for this.

Your problem is not related at all with the current discussion. It just
points out a usability issue which is that a user may change the company
of a contact for an invalid reason. "

You can't have it both ways. Either the contact is a "first-class" object or it isn't. If it is a first-class object then it should represent a real world person. When a company changes address you change the company's address. You don't create a second company with a different address. If John Doe changes company you should change John Doe's address to the new company and OpenERP should still behave correctly. It's disingenuous of you to blame the inconsistencies in your data model on the user.

Having said that...

No one disagrees that a contact should be a first-class object in the database model. I like it and pretty much everybody else also seems to like it. The problem we have with that is when you take that and apply it to the business model (I am making a distinction between the data model and the business model). In the business model a contact is not a first-class object. The first-class object is always the entity you have a business relationship with (ie. the company). The contacts are incidental to this relationship and they can change, disappear, whatever without affecting the relationship whatsoever. So when you send an invoice you can send it to the contact, but the recipient should be the company, not the contact. Notice, I didn't say it should be addressed to the company. It's a subtle, but very important distinction.

From your addition of a 'commercial_id' field to res.partner it seems like you also acknowledge that there is at least *a* distinction...

... Which leads to the next problem we have: So, if you acknowledge the need for a 'commercial_id' why do you have to "silently" change the semantics of a very important field implicitly acknowledged by your pre-7.0 data *and* business model as the "commercial_id" but misspelled as partner_id? Keep the misspelling and put the contact in its own field called contact_id. By your own acknowledgement the contact was a rarely used feature in previous versions. So I have to believe that from the point of view of creating the least disruption this is the simplest solution that is the closest to the business model.

Lastly, you've stated that one of the reasons for not going the partner_id + contact_id route is that it would change the 7.0 database schema. This is a moot point. There would have been no need to change the schema had all this been discussed with your community before hand. The fact that we are contemplating changing the schema now, after 7.0, is as a result of OpenERP SA not having thought out the implications of its changes completely before releasing 7.0 to the world and should not be held against the community.

In many ways what we are seeing being played out in this thread is not unique to OpenERP or OpenERP SA. It happens to all companies and all programmers. It happens to me and I'm sure it happens to Raphael, Maxim, Guewen, Stefan, Ana, Nhomar and everybody else. We spend a lot of time and effort analyzing a situation and then implementing a solution. Then when we discover a problem with the solution we try to find some way to solve it without throwing away all the effort we've already put into it. We find all sorts of kludges and band aids to make the solution come out more or less right [like copying the same exact data all over the place :-( (whatever happened to the DRY -Don't Repeat Yourself- principle?)], and for those situations where it might not be correct we console ourselves with platitudes like: "well, that's not really a real-world situation", "no, that's user error", or "but you're not doing it the right way". Sometimes this is enough, but sometimes it isn't. In those cases when it's not enough we have to have the moral courage to say "OK, we thought we had accounted for everything, but there is this really big class of problems where our solution isn't good enough. So maybe we have to re-think our idea."

OpenERP SA, please have the moral courage to do the right thing.

And if nothing I've said so far has made a difference think about this: When this change causes problems to real-world customers, it's not OpenERP (or OpenERP SA) that they're going to blame. They're going to blame your partners. They are going to complain about your partners. And all the partners and community members who have spoken up on this thread are *universally* against your implementation.

+1 for partner_id + contact_id

Your problem is not related at all with the current discussion. It just
points out a usability issue which is that a user may change the company
of a contact for an invalid reason. "

You can't have it both ways. Either the contact is a "first-class" object or it isn't.  If it is a first-class object then it should represent a real world person. When a company changes address you change the company's address. You don't create a second company with a different address.  If John Doe changes company you should change John Doe's address to the new company and OpenERP should still behave correctly.  It's disingenuous of you to blame the inconsistencies in your data model on the user.

Having said that...

No one disagrees that a contact should be a first-class object in the database model.  I like it and pretty much everybody else also seems to like it.  The problem we have with that is when you take that and apply it to the business model (I am making a distinction between the data model and the business model).  In the business model a contact is not a first-class object. The first-class object is always the entity you have a business relationship with (ie. the company). The contacts are incidental to this relationship and they can change, disappear, whatever without affecting the relationship whatsoever.  So when you send an invoice you can send it to the contact, but the recipient should be  the company, not the contact. Notice, I didn't say it should be addressed to the company. It's a subtle, but very important distinction.

From your addition of a 'commercial_id' field to res.partner it seems like you also acknowledge that there is at least *a* distinction...

... Which leads to the next problem we have: So, if you acknowledge the need for a 'commercial_id' why do you have to "silently" change the semantics of a very important field implicitly acknowledged by your pre-7.0 data *and* business model as the "commercial_id" but misspelled as partner_id? Keep the misspelling and put the contact in its own field called contact_id.  By your own acknowledgement the contact was a rarely used feature in previous versions. So I have to believe that from the point of view of creating the least disruption this is the simplest solution that is the closest to the business model.

Lastly, you've stated that one of the reasons for not going the partner_id + contact_id route is that it would change the 7.0 database schema.  This is a moot point.  There would have been no need to change the schema had all this been discussed with your community before hand.  The fact that we are contemplating changing the schema now, after 7.0, is as a result of OpenERP SA not having thought out the implications of its changes completely before releasing 7.0 to the world and should not be held against the community.

In many ways what we are seeing being played out in this thread is not unique to OpenERP or OpenERP SA. It happens to all companies and all programmers. It happens to me and I'm sure it happens to Raphael, Maxim, Guewen, Stefan, Ana, Nhomar and everybody else.  We spend a lot of time and effort analyzing a situation and then implementing a solution.  Then when we discover a problem with the solution we try to find some way to solve it without throwing away all the effort we've already put into it.  We find all sorts of kludges and band aids to make the solution come out more or less right [like copying the same exact data all over the place :-(  (whatever happened to the DRY -Don't Repeat Yourself- principle?)], and for those situations where it might not be correct we console ourselves with platitudes like: "well, that's not really a real-world situation",  "no, that's user error", or "but you're not doing it the right way".  Sometimes this is enough, but sometimes it isn't. In those cases when it's not enough we have to have the moral courage to say "OK, we thought we had accounted for everything, but there is this really big class of problems where our solution isn't good enough. So maybe we have to re-think our idea."

OpenERP SA, please have the moral courage to do the right thing.

And if nothing I've said so far has made a difference think about this:  When this change causes problems to real-world customers, it's not OpenERP (or OpenERP SA) that they're going to blame. They're going to blame your partners. They are going to complain about your partners. And all the partners and community members who have spoken up on this thread are *universally* against your implementation.