> > > > 1 field (contact_id) displayed to the user, named Customer and searching > through companies and contacts. > > 1 field (partner_id) hidden by default, set automatically to the first > commercial entity in the tree (at the moment contact_id is chosen) and used > for invoicing. > > Did you notice that: > - it requires to change all objects (if john.doe@acme fills a claim, > the answer will be send to info@acme, and it's the same for all printed > documents) > Fabien, OpenERP SA isn't paying me to do your job, that's us paying you. So it's was just a quick proof of concept as I explained. Of course it would need to be completed. In such case, for you the code is very simple instead of what we have to do it you swap partner_id semantic. In these rare cases, you just have to change partner_id by contact_id in the code. That's it. And also it's much less critical features than say screwing your intrastat reports or not being able to compare your supplier prices. In any case it's way simpler to fix. > - it sometimes has no sense: applicants (what's the company for an > applicant?), bank statements (there are no contact on a statement), ... > Fabien, I agree, that some objects fields should opt-out for not receiving a contact_id decoration. I had mentioned that in the code already. I started elaborating a list of which fields may not be eligible for such contact_id decoration: Help is welcome in columns H and I: https://docs.google.com/a/akretion.com.br/spreadsheet/ccc?key=0AlrjP6ETn3tJ If contact_id decoration should be an opt-in or opt-out based on these results is totally up for debate. Also we may not add a contact_id on a field that is already restricted to a commercial entity (while having a contact_id here wouldn't hurt either as partner_id would be correct, it would just be useless that's it). I explained the idea here: https://docs.google.com/a/akretion.com.br/document/d/1CvPz-BZnZ-waQZoFpdIM6aNjjcbdLadGQqTZFL3lw7A/edit#heading=h.19sozwzfx45i - you sometimes loose information: if you modify partner_id, it magically > overwrite your contact_id (loss of data) we have two solutions here: 1. require that you write both the contact and the partner in these cases (it's pretty rare code write on the partner alone once it has already been written, would that loose the contact in any critical manner here? unlikely) 2. I think we could drop that feature once we make sure the addons properly write into contact_id when they should (like from a CRM lead to a sale order). Also, as I show contact_id even when it's empty when there is a partner_id, eventually that may not even be required at all. Not sure. > - if a module already defined contact_id for another purpose, you have a > conflict > Well in the very rare cases (5 cases in the whole the official addons) a field is called contact_id and points to a res.partner, we can assume it's really meant to carry a contact and we skip adding a contact field. Honestly Fabien is much easier to handle than having for instance to rewrite all our localization and the fiscal-rules (that would involve testing and fixing 10 000 lines of code just for that) where we should adapt everything in case partner_id is suddenly a contact which anyway is illegal here. So I mean, yes this isn't that easy. But this is your fault, it's you who created that mess and said it was ready for release. Not us. Also you seem to forget all the conflicts that may happen when people would otherwise add their own commercial_entity keys and on_change (to be able to filter before record is saved) which would certainly create much more critical conflicts as instead of deciding something structuring in the core, we would let anyone have to make their own inconsistent decisions. Can we please stay factual, and argue with real scenario based on tests? > Real examples will help the discussion become clearer. Otherwise, it looks > like we are turning around without progress. > Sorry: but when you say: it's normal to bring just the related contacts or it's normal you have to fill that field on the contact because contact is the right granularity. I say, no! All these modules have been made for the granularity to be the company until v6.1. You cannot now change their granularity and claim it's the expected functional result. We can certainly also reason. It avoids underestimating the issue just because we missed 90% of the issues with a quick superficial scan. It also avoids we get the impression everything is addressed just because you changed your mind so many time. Also just to remind you Fabien, over the last 2 weeks: 1. can we invoice contacts? yes, it's perfectly normal. then no! what a misunderstanding! + code forbidding it on the surface (only). Then no, of course we can invoice a contact! 2. can we have a contact belonging to several companies? yes absolutely. But wait, there is a catch, you should create a contact for each company... 3. does the company granuarity matter? No! the contact is the right granularity! Wait, actually it's true, you may need to group your invoice by customer/supplier, so we add that extra module assuming the total permutation of contact_id and partner_id that everyone should adapt too in their modules. I tried to summarize the whole issue here: https://docs.google.com/presentation/d/1y0njSpm9kqJPGFUQQTiRMIpT1M5CfKppNhslvpl-aM4/pub?start=false&loop=false&delayms=3000#slide=id.p Feedback is welcome so that I can improve it. Regards. And yes, this is a boring issue. Boring for everybody for sure, but it's certainly not by underestimating it that we will do any good in our projects.