openerp-community team mailing list archive
-
openerp-community team
-
Mailing list archive
-
Message #00743
Re: [Merge] lp:~openerp-community/openobject-server/context-in-workflows into lp:openobject-server
-
To:
openerp-community@xxxxxxxxxxxxxxxxxxx
-
From:
Olivier Dony <odo@xxxxxxxxxxx>
-
Date:
Wed, 14 Dec 2011 11:20:26 +0100
-
In-reply-to:
<CAArDTh_H=WyXoexOhkuiFwR93vP=bGcdohPdf7Q8c3mzdEQBVA@mail.gmail.com>
-
Organization:
OpenERP s.a.
-
User-agent:
Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
On 12/13/2011 11:49 PM, Raphaël Valyi - http://www.akretion.com wrote:
> 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
To me this is a separate issue, and I don't see any reason why we should
not have these business methods conform to the API, and take a proper
context, just like all the others.
Not having the context provided in some cases is something else.
> 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) ?
If we can have the transaction context propagate to business code
without being available inside the workflow engine, then why not.
But if the easiest method to do that in 6.1 is to have the wkf engine
propagate it, then perhaps it's worth it.
> 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)
Many of these methods will be or will call normal business methods, so I
don't see why they should follow a different contract.
> 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.
Could be a partial answer to the issue, but it looks to me this wouldn't
be worth the trouble for such poor outcome. In that case we can accept
MPs that add the context where people need it for special purposes, but
not bother with adding it to all workflow-called methods by default.
References