Community mailing list archives

community@mail.odoo.com

Re: Sale and purchase workflow

by
Camptocamp SA, Guewen Baconnier - Software Developer, Camptocamp
- 09/17/2015 05:33:58
On Wed, Sep 16, 2015 at 1:17 PM, Fabien Pinckaers <fp@odoo.com> wrote:
>
>> Simple example: we used to have
>> action_done on sales orders that we could overwrite when an order was
>> fully delivered and invoiced, now how could we trigger on that event
>> programatically (not using inefficient automated actions)?
>
>
>
> Good example: on a workflow, you can extend: action_done, invoiced,
> received, sent. That's it! You have basically ~4 hooks you can extend,
> nothing more. That's not what I call extensible. We often need to extend on
> much more complex events than this.
>
> Automated actions are as inefficient as workflows: they both evaluate a
> status at every write on the document.

Thanks for agreeing about the inefficiency :-)
The difference is that the workflow does the evaluation anyway and
only once for the state, with a possibility to hook actions, where
each new automated action will add its own evaluation. That could be
not an issue with a standard Odoo with no modules, but could grow
badly if each module adds nearly the same automated action because
each one needs to evaluate for instance the delivery status of a sales
order. An efficient design for such things could be to have a core
that publish events on which consumers can subscribe from the addons
(so the evaluation is done once, not by each addon).

> But the difference is that Automated
> Actions allows an unlimited way to hook yourself. (and performance is still
> better than workflows) You can even hook on 'temporal events', example: Is
> still in "To Invoice" state after 3 months after validation of SO.
> And the action is much easier since you just change fields, you don't need
> to sync the workflow and put it in a consistent state.
>
> I also think it's better if you can extend programatically. (which is, by
> the way, against a workflow approach whereas it's the workflow that should
> trigger the code and not the other way around --> even if we often had to do
> it the other way around because workflows were too constraining)
>
> There are several approaches to hook in the code. Use the one that fits your
> use case:
>
> - extend on the action, not the event (easy if you want to change the
> behaviour of an action, just a method to overwrite)
> - extend on the recompute of the computed field (easy if you want to trigger
> something new on a change: e.g. if the invoice_status changed, just a method
> to overwrite)
> - extend on write/create (not super clean, but basically the same than what
> the workflow was doing)
> - extend the trigger of the change of the computed field (extend @depends)
>
> Since the status of the document is defined by computed fields, you have
> more consistencies guarantees. Whereas with workflows, you continuously have
> to sync both the fields and the workflow to stay in a consistent state.
> (which is a mess when developing, and painful to debug). --> You have an
> unnecessary redundancy between the values of the fields (state,. ..) and the
> state of the workflow.
>
> From any point of view (document consistency, extensibility, ease of
> development, ease of customization without development), I don't see a
> single advantage of using workflows for sale & purchase.
>
> For other needs, workflow may be interesting. But sale & purchase are too
> advanced to be managed by a single workflow.
>
> --
> Fabien
>

I look forward to attempt that by myself, thanks for the detailed hints.

-- 
Guewen