openerp-community team mailing list archive

[Raphaël Valyi - http://www.akretion.com <rvalyi@xxxxxxxxx>]

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 <button
name="wkf_test" context="{'test': 'ok'}"/> could be extremely powerful with
context being propagated.

So in any case I'm not 100% what is best here. But probably if we decide
workflows don't propagate the context, we should still refactor the methods
it call to support the standard context arguments so it can be used in a
more modular way, no?

So at the end what would we decide:
1) workflow propagate the context (it doesn't mean it should use it itself;
this can be checked) ?
2) the methods called by workflow don't propagate the context at all either
(sounds it sucks to me, cause would force overkill database accesses when
we are already not that fast in transactions)
3) the methods called by the workflow engine, pass the context if they have
some passed. However the workflow engine don't give them the context, so
it's useful only in overrides or when those methods are called outside from
the workflow engine.

What do you guys think?



On Tue, Dec 13, 2011 at 5:58 PM, Fabien (Open ERP) <fp@xxxxxxxxxxx> wrote:

> Olivier,
>
> Are you sure it's a good idea to allow context in workflows ?
>
> Workflows are not used for user interface interactions, but for
> controlling the
> evolution of the object. It has no sense to put context on constraints
> and, for
> the same reason, I don't think we should allow context in workflows.
>
> An activity should not depend on a context but on data stored on the
> object.
> The goal of the workflow is to easily modify it, add/remove some
> transitions, etc.
> If we depend on contexts, we may loose this modularity.
>
> I am still not sure about this, but I would not allow the context to be
> used in
> workflows, for the same reason that it has no sense to put context on
> constraints.
>
>
> On 13/12/11 19:05, Olivier Dony (OpenERP) wrote:
> > FWIW, you can have a look at the branch where I tested merging the same
> thing[1].
> >
> > As I explain on my merge prop there, I think we need more work on the
> addons side in order to get any benefit from this work, and that will be
> much more tricky. I started a wip of changing addons in this manner[2] but
> it is far from complete or working yet, and perhaps it's too much at this
> point.
> >
> >
> > [1] lp:~openerp-dev/openobject-server/trunk-workflow-context-odo
> > [2] lp:~openerp-dev/openobject-addons/trunk-workflow-context-odo
> >
>
>
> --
>
> https://code.launchpad.net/~openerp-community/openobject-server/context-in-workflows/+merge/85518
> You proposed lp:~openerp-community/openobject-server/context-in-workflows
> for merging.
>

-- 
https://code.launchpad.net/~openerp-community/openobject-server/context-in-workflows/+merge/85518
Your team OpenERP Community is subscribed to branch lp:~openerp-community/openobject-server/context-in-workflows.