openerp-community team mailing list archive

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

Ok,

So Olivier and Fabien, I'm happy that it seems we totally share the same
opinion: none of us wants workflow behavior to be context driven, this
would be bad. BUT, there is not valid reason usual business methods to be
half broken because today when they are invoked through the workflow they
receive no context.

What I propose is:

1) as a first step: change the signature of those common business methods
such as:
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
So they accept the standard context argument and properly propagate it.

Honestly there aren't too many such actions, if we quickly review stock,
sale, purchase and account, with probably a change in around 20 methods I'm
pretty sure we would cover 90% of the use cases.

I insist today those methods usually have a nonsense useless *args argument
that limit a lot their capabilities when overridden or when calling other
normal business methods. So I mean this is not like if we were breaking
something already self consistent: it's not consistent today.
Today that *args is not used, so it's quite safe I think to replace it by a
"context" arg, basic testing would ensure we are not breaking anything.


2) Eventually, still up to debate, the workflow engine propagate the
context (I'm not 100% sure but I would go for that while still having the
strong policy that workflow themselves should not be context dependent).
If the workflow engine starts passing the context, we should avoid passing
the context where it's not expected. May be one way is to simply pass it as
the last argument (would not break where *args is expected) rather than a
keyword argument, OR, eventually we do some signature checking before
calling as Albert did (sounds less good to me but not sure).


3) Eventually workflow calls and clients can be modified to properly pass
the context when triggering workflow actions. But once most of the common
business signatures are in place, to me this is no API change so this could
be gradually added during the 6.1 release life cycle.


As for keeping the context and the cursor and uid in thread local, of
course, I think this will need to be done in the future. But this may be
effective may be only in 2 years, so we also need a decent solution for the
next 2 years.



On Wed, Dec 14, 2011 at 8:29 AM, Olivier Dony (OpenERP) <odo@xxxxxxxxxxx>wrote:

> On 12/13/2011 08:58 PM, Fabien (Open ERP) 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.
>
> Actually, workflows execute business operations requested by users, and
> are mostly called in the context of user transactions. When a workflow
> button sends a signal, the workflow engine actually produces the result
> to send back to the user, by invoking business code.
> Granted, the workflow activities themselves don't need the context, but
> the business code they are calling does.
>
>
> > 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.
>
> Indeed the goal is not to make the workflow itself depend on the
> context, but to have it propagate it to the business code that it calls.
> The workflow is a controller that invokes business code in the context
> of a user transaction, and business code is in general context-aware, so
> why would the workflow engine break this contract?
>
>
> > 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.
>
> We don't want constraints to be context-aware because it would be a bad
> incentive for developers. And they really don't need it, because
> constraints should never alter the data in any way (not call mutating
> business code) and have their error messages properly localized by the
> ORM. I think this is different for the workflow engine, which acts as a
> controller.
>
> BTW, we'll have to address this in a more global way for next release if
> we change the API to have a thread-local (or similar) handling of the
> transaction context. If we can allow that transaction context to be
> propagated to business code in all circumstances, and that without
> making it available to the actual workflow engine, I'm happy with it.
> However if we have to choose, it looks to me that having business code
> behave properly in all circumstances (even when called via workflows) is
> a more important goal than preventing the design of context-dependent
> workflows.
>
> --
>
> 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.