support for 'or' in attrs keyword

Could you check this patch ?

Thanks

Which one ? You did not attach any patch.

But If you're talking about mine, I noticed that the eval function lacks a case where context is False, in this case it should returns False.
But as this was obvious, I did not think you needed to be told about this.

As this is clearly a new feature, this modification have to be done on trunk.

I totally agree. If a usable patch exists for 5.0, interested people can apply it on their own.
Ideally, it should be documented in the release file of 5.0.8 under a section "known limitations" of something similar.
Please, I beg you for strictly no more feature in 5.0 - I'm going to spend 3 hours today fixing my setup because of another "improvement".
Lionel

Hello Guys,

I am happy to attach a patch for any version. This patch does not harm anything,instead it adds a nice facility to use OR in attrs.

@Nicolas Évrard,

Thank you for the patch, it gave us direction to move forth.We are thankful to you for posting this thread here and alerting us for the same.

I have improved the code that will support OR for any number of tuples inside.(e.g. ['|', A, '|', B, C,D] to be evaluated as (
( A OR (B OR C) ) AND D )

Would you please apply this patch and let us know?

Thanks.

Well, I do not like the fact that it works for any number of tuples because you have to know the operation precedence (and it's not the kind of case where people knows it by eart).
IIMHO it lacks readability.

@Numérigraphe
The patch is backward compatible with the old way to express conditions. To bad we do not have test cases to ensure this.

Hello Nicolas,

This patch satisfies 100% possibilities of any domain.

Would you please tell me any case where this patch fails, I would like to test more.

And, 'any tuples' means any no. of conditions as domains.

Thanks.

I am aware that this patch safisties 100% of any domain. But the readabilty issue is IMHO important.

Hello Nicolas,

   What exactly do you mean by readability? Do you mean the attrs domain syntax. Kindly be clear.

    Here are few test cases that i have tested.

[('type','=','cash'),('type','=','consolidation')]--------A AND B
['|',('type','=','cash'),('type','=','consolidation')] --------A OR B
[('type','!=','view'),'|',('type','=','cash'),('type','=','consolidation')]---------A AND (B OR C)
['|',('type','!=','view'),('type','=','cash'),('type','!=','consolidation')]--------(A OR B) AND C
['|',('type','!=','view'),'|',('type','=','cash'),('type','=','consolidation')]--------A OR (B OR C)
['|',('type','!=','view'),'|','|',('type','=','sale'),('type','=','cash'),('type','=','consolidation')]-------A OR ((B OR C) OR D)
['|','|',('type','!=','view'),'|',('type','=','sale'),('type','=','cash'),('type','=','consolidation')]-------(A OR (B OR C)) OR D
['|','|',('type','!=','view'),('type','=','sale'),('type','=','cash'),('type','!=','consolidation')]-------((A OR B) OR C) AND D
['|', ('type', '!=', 'view'), '|', ('type', '=', 'sale'), '|', ('type', '=', 'cash'), ('type', '!=', 'consolidation')]-----A OR (B OR (C OR D))

Thanks for your interest.

The fourth example Might be interpreted by someone who is not aware of the operator precedence as (A or B or C).

I Way prefer [('|', ('a', '=', 2), ('|', ('b', '=', 3), ('c', '=', 4)))] ... but your mileage may vary.

Hello Nicolas,

    We are using pre-order notation for this. So we need to go according to that as conventionally we have been using this notations. It will not be an issue of readability as pre-order notations are very familiar.

 Both the cases are different here.

For A OR B OR C we use ---> ['|','|',(A),(B),(C)]
For A OR (B OR C) we use ----> ['|',(A),'|',(B),(C)]

    Let us know your view.

Thanks

fullmarks to Anup. its good pach.

Anup, Can you create a branch with you patch.
I'll review it and then merge it into the trunk dev branch if ok.

Any news about the web-client "OR" bug ? Any patches or help to fix it in the current version?

Hello beroz,

For web client,
Its new feature, so it will take time to implement, because there are some other important issues to implement.
Will try to cover it soon.

Thanks.

Hello All,

Sorry for inconvenience.

I have improved attrs keyword for `OR` in trunk-dev-web branch for web-client, it will be merge with Trunk webclient soon.
I am attaching patch for stable (Any version of 5.0.x). Kindly check.

Thanks.

On 11 Jun 2010, at 16:07, sma (Open ERP) wrote:

>
> I am attaching patch for stable (Any version of 5.0.x). Kindly check.

No, the version 5.0 stay as it. This is a new feature for the trunk.

--
Christophe Simonis
SaaS & GTK client R&D Manager
OpenERP sa
Chausée de Namur, 40
1367 Grand-Rosière
Tel: +32 81 81 37 00
http://openerp.com
http://odoo.com

Hi, this should be done in trunk.

For the gtk client, you are missing the appearance of the function call inside widget/view/tree_gtk/parser.py.

This bug should either be fixed or the documentation fixed. The technical memento states that all the operations for search are valid, which would include 'or' and it's not the case.

The 6.0 branch will imply many more changes than bugfixes. It think this bug should be fixed and released in a bugfix release of the 5.X series.

There's a bug in the code of the patch.

The old code started the if with "if model and ...". The current code does not check if there is a model before doing anything and so in some situations, when there is no model, it raises an exception, when all it should do would be to just return None as the old one.

I see that this bug now says "Fix Released", I'm not sure WHERE it's been released. If you can point me to the current code, I can prepare a patch.

I checked Anup's branch and it has a if model: at a certain point. So I guess it's possible that the bug is not there.

Sorry for the noise in that case. I'm used to patches being updated in the bug log, or at least comments about them getting updated instead of having to check the branches just in case there was a change that nobody reported... :-\

I am confused,its fixed in desktop client and not in web?
please clarify.

the BUG still affect the web client(6.0.2)

This bug is being closed as Won't Fix in the OpenERP Web Client project, as it is not going to be developed further after the 6.0 series. It will be replaced in 6.1 by a newer and better web frontend known as the OpenERP Web project[1], so further R&D efforts on the 6.0 project would be wasted.
Bugs affecting customers in production of course continue to be handled via the OpenERP Enterprise (OPW) maintenance service.
You can find more details about this in the Bug Management FAQ[2].