search on res.partner.address as field one2many is only zip search

Hello Antoine ,

I have checked this issue with stable 6.1 as well as trunk.
As per our bug management policy we can consider bug if its producible with trunk
or for stable if its blocking point.But Its not a blocking point and only
producible with stable 6.1,So we can not consider this as bug.
If you have a support and maintenance contract with us
then you can contact at <email address hidden>.

They will definitely help you.

Thanks for understanding!

Hello Antoine,

My detailed investigation said that the name_search method is working perfect.

The original problem resides in OpenERP Kernel (expression.py) which evaluates the domains and calls the different search methods within the server.

As a part of the fix, I have attached a patch and I am sure it will work for you.

Additionally, Talking about the question you asked:
- How args work : args will have values only in the case of domains. E.g. Go to Event form(event module), or Delivery Order where Address is a many2one field, over there if that field has any domain, you would get the value or args.

Thinking globally, this problem is linked to expression.py and should be addressed for the fix.

I replicated the problem by putting sale order line on sale Order's search panel and faced the issue.
The issue is, while GTK calls any name_search, server treats the limit as default value(because gtk passes limit only and only if the limit is supplied/chosen). BUT, when name_search is called by expression.py in order to perform search on one2many field, it passes limit=None which is totally unfair.

I will patch the server very soon and you will feel the bug-free behavior.

Jignesh, if I am not wrong, the parser stays same for trunk too and it should also have this bug.

Thanks,
Hitesh Panara,
Serpent Consulting Services.

Guys,

Yes, this is a bug.

Jignesh, please recheck in trunk.

Thanks Hitesh.

Guys,

The fix has been included in the merge linked to this bug.

For now, it has been given for 6.1 only. But it affects 6.0 and trunk too. We can contribute merges as and when needed.

I am sure this bug does not need any OPW to owe a fix.

Hope to get it considered.

Enjoy the fix.

Regards,
Serpent Consulting Services.

Hello SerpentCS ,

Thanks for review.

Yes I agree with you , name search pass as argument limit=None but It does not affect to search.
I have checked this issue with trunk as well as 6.1 . I have put order line in search view of sale order but I did not face any problem with name_search in trunk .here i attached a video for 6.1 which shows the correct search without remove limit field in search.so as per my opinion we can change a code in
res.partner.address in name search method rather then change in expression.py.I have attached a video
trunk which working fine with o2m in search view.

Correct me if i am wrong.

Thanks and waiting for reply!.

Jignesh,

Thanks for the attention. You are right, but think at core level.

Let me say this way:

There won't be any issue ofcourse because you did not use any code based on limit in sale.order.
Sale Order line searched everything based on its name, so its pretty obvious not to face it.

The case of address is specific where you used limit-based calculation of name and hence this aim made us realize the issue.

Though this is the only and best example to prove the problem, it does not mean to fix it in module.

The actual fact is, limit is forcefully passed as None.

Additionally, trunk will not raise the issue because name_search() does not use limit anymore.

Let's thank Antoine for that.

Best Regards,
Serpent Consulting Services.

Hi all,

It seems based on Jignesh's 6.1 video that the bug described by Antoine cannot be reproduce in 6.1 anymore. He may have use the initial 6.1 release, which indeed contained a bug in the name_search() of res.partner.address. This was fixed recently at revision [1], so by using a version dated after that revision the bug should be gone. I suppose we can mark this bug as Fixed by commit [1], unless Antoine can provide steps to reproduce this against a newer version.

Concerning the discussion on a more fundamental issue in the ORM (expression.py), I think there is no bug there either, as I explained on the related merge proposal by Serpent CS (see my review in [2]).

Hope this clears up the topic.

Thanks to all of you for reporting and analyzing this issue!

[1] Server v6.1 revision 4120 rev-id: <email address hidden>
[2] https://code.launchpad.net/~serpent-consulting-services/openobject-server/SerpentCS-971627-bug-6.1/+merge/101032

Olivier,

I tend to agree with you on server side, but the bug still persists. Lets say atleast on addons.

I see the video of 6.1 by Jignesh, I wonder about line 360 of res_partner.py (0:25). You feel its working due to this line does the trick, it compares name first and then the others.

"ids = self.search(cr, user, [('name', '=', name)], args, limit=limit, context=context)" -- I do not have this line.

Look at http://bazaar.launchpad.net/~openerp/openobject-server/6.1/view/head:/openerp/addons/base/res/res_partner.py#L347, I have this code.

I do not see this line and that is what making me do more analysis.

The reason being the condition on "len(ids) < limit", when name_search gets limit=None and hence any search on contacts of partner results in ONLY the search of zip. All the other criterias are getting ignored.

I would say rev 4021 causes regression.

Scenario : Go to partners:search something on contacts field, results are not the right ones.

I would like to request you to recheck.

Thanks for taking time for the review, appreciated.

Apologies for any confusions.

Regards,
Serpent Consulting Services.

Hoping this time to help via another proposal.

https://code.launchpad.net/~serpent-consulting-services/openobject-server/SerpentCS-971627-bug-6.1/+merge/101215 it is.

Thanks.

On 04/08/2012 11:57 PM, Serpent Consulting Services wrote:
> I see the video of 6.1 by Jignesh, I wonder about line 360 of
> res_partner.py (0:25). You feel its working due to this line does the
> trick, it compares name first and then the others.

Oh indeed, missed that, thanks for replying.

In fact the fix for this is the same as the one for bug 955051, as shown in the following merge proposal:
https://code.launchpad.net/~openerp-dev/openobject-addons/6.1-opw-572802-skh/+merge/100146

I suggest we apply the same minimalist patch here.

This should finally be fixed in 6.1 after revision 4138 rev-id: <email address hidden> (using the same fix as for related bug 955051 )

Thanks for your patience!

Olivier,

Thanks for accepting the bug and minimalizing the patch and doing it straight away late night.

This is an excellent example of communication and your accuracy.

Finally, the analysis has been fruitful to fix the bug and this bug is no more, RIP.

3 Cheers!

Regards,
Serpent Consulting Services.

Nice !
Fix is OK for me.

Thanks all.