← Back to team overview

openerp-community team mailing list archive

Re: lp:~openerp-community/openobject-server/context-in-workflows into lp:openobject-server

 

> 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).

The simplest is just to add the keyword argument. If you install all addons from openobject-addons/trunk (well, n10l_de breaks for me) you can get an idea of the scale of the impact. The query "SELECT wkf.osv, wkf_activity.action FROM wkf, wkf_activity WHERE wkf_id = wkf.id AND kind =  'function' AND action LIKE '%()%'" gives you some 80 methods to convert.

The person to prepare such a merge could temporarily hack in Nan's introspection check to iterate over these methods at loading time to see if all have been covered.

The question is whether this 'last minute'(?) API change is fair towards 3rd party addon developers but AFAIK stranger things have been pulled off in this community ;-) In that respect it would be informative when a proper RC1 is planned.

Cheers,
Stefan.

-- 
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.


Follow ups

References