Hello Fabien, 1) If I'm not wrong about it, on issue is that if you don't pass the context you'll for instance miss important things like translations. So for instance if I create an invoice upon the order (through the workflow) but if if that invoice fails to create for some reason, the error message it will display will not be localized properly (you'll eventually find out the sale_order.user_id lang or something like that but won't be very precise. Or am I wrong? Also I believe you were using some Python frame inspection for that but is was extremely slow, am I correct, was it related? 2) we also have an issue with the methods the workflow call: those methods are easily called from different paths and easily they need the standard context system to be modular. Look at such methods: http://bazaar.launchpad.net/~akretion-team/openobject-addons/sale-modular-picking-better-context/revision/5761 or http://bazaar.launchpad.net/~akretion-team/openobject-addons/sale-modular-picking-better-context/revision/5760 Actually for a modular API, we really have the case were Sebastien Beau would need to override the beginning of the method chain to inject some custom context key. Later in the call chain, the will override again and hope he will get his context back so he can take some custom action. Usually it's done in the same transaction and it seems overkill to write some data in the database to just re-read it a few method calls later while it could come from memory. The issue is that is seems pointless then to have all those clean methods correctly propagating the context and using it normally being usually called by some piggy workflow method that wouldn't pass them the context and would instead use a useless meaningless arg* signature. Wouldn't it be better to just propagate the context all the way through? IMHO it was right to say constraints should not depend on context. But for the workflow I'm really not sure. I see many modularity benefit of having that. A system like Christophe gives with things like