[5.0] ir_act_window element doesn't eval domain

thank you for the contributions.

Hi guys, sorry for the interruption,but I have come across a serious problem when the context or domain contains any field of the source model.

You may try to install account_voucher module and have a go.

The current fix is only valid in the case of domain="[('section_id','=', ref('my_module.my_id'))]".
But it can fail with a shout on domain="[('section_id','=',section_id)]" (Provided source and target objects have the field section_id).

Hope this helps.
Thanks.

Hello Guys,

Here is a proposed patch to tryout.

Eval() can only be useful if the domain/context has ref().

But, if the domain/context has a field as I exemplified in the above post, it could fail.

Moreover,its difficult to evaluate eval(X) only when X has a ref().

Would you please check the following patch and share your view?

Thanks.

Hi Jay

What about if the domain raise an exception, doesn't we evaluate the context ?, i think so

Regards,

It's my fault, in fact, we can evaluate a domain with a call to the time.strftime function or with the current_date variable (defined in the client)

I'm going to revert your code, it's my fault.

So, I propose that you override the search method for your object and you use the context variable.

This definitely does not qualify as a bug, changed to wishlist.

Hello guys,

At the client side, date,time,uid,any field ,etc. are handled properly.(/tools/__init__.py)

We only need to parse the ref(xml_id) from server to client.

Other than, ref, its the duty of client, so try except sounds a cleaner way.

Thanks.

I personally disagree with 'wishlist' tag to this one.

Your views please.

I dislike wishlist as well

In crm.case we must filter as section_id otherwise all crm.case for the partner are seen, not only the case lead for example.

Regards,

Try this on context

<act_windows .... context="{'my_section': section_id}" .../>

raise an error, and this is a bug, the patch proposed per Jay as a good compromise

Regards,

BTW, as this is not a bug, it makes no sense to propose a merge on stable for this.

We could think about this for trunk, but the use cases for this seem quite rare, except the case you mention.
In your case, how about something like:

     domain="[('section_id.code','=', 'leads'))]"

... or anything similar, keeping in mind that this is evaluated on the client side and then passed to search().

I know this seems a *little* bit more fragile, but it seems acceptable to me, if you pick a column that is sufficiently unique (and if you are hardcoding the domain based on it, it is probably because there is something unique about it)

I have made a test in a python console

>>> domain = "[('section_id', '=', section_id)]"
>>>
>>> domain = eval(domain)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in <module>
NameError: name 'section_id' is not defined
>>> domain
"[('section_id', '=', section_id)]"

The patch as Jay propose works, the domain variable doesn't alter after evaluate and keep teh compatibility with the old functionnality.

Regards,

Christophe Chauvet wrote:
> I dislike wishlist as well

I guess you do since you did not mark it as a wishlist ;-)
But the definition of a bug is not hard to understand, especially in this case, where you simply wish/would like the system to support a new feature, as far as I can see.

> In crm.case we must filter as section_id otherwise all crm.case for the partner are seen,
> not only the case lead for example.

Yes I understood your example, but that's normally not an issue because the CRM modules have a wizard for creating the menus etc. See also my previous post for an alternative if you want to hardcode sections and menus in your own modules.

As I wrote already,

We only have to eval any context/domain when it contains an xml_id reference. The time,uid,any field ,etc. are handled properly at client end. Tell me if you disagree.

The domain="[('section_id','=',section_id)]" is a case which is fair and fine, we have to get domain passed to client and client will take care of this.

Currently, we can't do an operation like finding 'ref' string from unEVALed context/domain and if it has 'ref', then eval(x).

So, try except sounds to be a good way as of now.

I would go for the patch which stops the headache.

If we have a Better solution, we can have that applied.

Thanks.

Jay, i have the same point of view.

when update/install module, we must evaluate context and domain for each element (record, menuitem, act_window, wizard, report) but in some circumstance we must keep the domain/context and not evaluate it, because the client evaluate it when it's necessary.

Regards,

It has been fixed.
Thanks.