openerp-expert-framework team mailing list archive

[Olivier Dony <odo@xxxxxxxxxxx>]

On 24/05/10 10:24, P. Christeas wrote:
> There is a new phenomenon, like a bug, that has been triggered in my version 
> of the server. I believe, at this point, it calls for some discussion:

Huh?


> In an attempt to tighten security of pythonic code, I have replaced instances 
> of eval() with one safe_eval(), customized to /not/ expose dangerous functions 
> (did you know that 'import' can be called through eval() ? )

Sure. BTW I've been working on a clean version of the various safe_eval
patches that have been seen left and right so far, including your
previous work that was merged some time ago in trunk.

As this branch is going to be merged soon in trunk, you may want to have
a look at it, and maybe do some of your work on top of it instead of the
current trunk:
 lp:~openerp-dev/openobject-server/trunk-safe-eval

It's been some time since I've started it, and I remember I needed to
still fix some locals/globals to make it work everywhere, but it's on my
todo list to finish before 6.0, and I'll probably get to it next week.


> Notably, now, in stock/product_view.xml:product.search.stock.form, we have a 
> context like {'location': self } . Really, what is that supposed to mean? How 
> is it used? Isn't 'self' the product.product class?

This is part of the new context filters that can be used in search views
in 6.0. This 'context' is evaluated only on the client-side, and 'self'
is going to contain the current value of the corresponding widget.
It's used to change the values that are displayed in the search results
by changing the context dynamically (here the stock level depends on the
location)

If you are evaluating this specific context on the server-side, then I
think something is wrong. Is the server (trunk) doing that at the moment?


> Major question is: what objects should be exposed at the context of the eval() 
> of the context? (confused wording? ) 

Looks like you are mostly talking of the eval() of context values on the
client-side. At the moment it can use 'uid', 'time'/'datetime',
'current_date' and 'active_id' and now 'self' when relevant.
We're planning to make this more consistent and documented, and also
give access to more attributes of the current user (but remember that
this is all supposed to be client-side-only at the moment)

Hope this helps...


-- 
Olivier Dony