Workflows

在odoo中，工作流是管理一组与模型记录相关联的“要做的事”的技术产品。工作流提供了一种更高级的方式来管理要在记录中执行的任务。

更具体的说，工作流是一个有向图，其中节点称为“活动”，弧称为“过渡”。

• activity定义了应该在odoo服务器中完成的工作，比如改变一些记录的状态或者发送邮件
• transitions控制工作流如何从一个活动到另一个活动

在工作流的定义中，可以将条件、信号和触发添加到transitions上，因此工作流的行为取决于用户的动作（比如单击按钮）、记录的更改或者任意Python代码。

总之，odoo的工作流系统提供：

• 记录（文件）随时间的演变的描述
• 基于各种灵活条件的自动动作
• 公司角色和验证步骤的管理
• 管理对象之间的交互
• 文档的可视化表示贯穿其生命周期

例如，基本顺序有如下流程：

订单从草稿状态开始，可以被用户确认，然后发送（关闭）或者取消

使用Odoo的公司可能希望在订单中增加折扣支持，在这种情况下，销售人员拥有最高15%的自由裁量折扣权限，但如果折扣超过15%，则需要经理验证。工作流可以在线修改以添加相关步骤，无需编辑Python或XML文件:

因为活动可以执行任意操作，因此验证可以自动向相关员工发送验证请求。

基础

用数据文件定义工作流很简单：工作流与活动和转换的记录一起给出，例如，下面是用XML定义的两个活动的简单序列。

<record id="test_workflow" model="workflow">
    <field name="name">test.workflow</field>
    <field name="osv">test.workflow.model</field>
    <field name="on_create">True</field>
</record>

<record id="activity_a" model="workflow.activity">
    <field name="wkf_id" ref="test_workflow"/>
    <field name="flow_start">True</field>
    <field name="name">a</field>
    <field name="kind">function</field>
    <field name="action">print_a()</field>
</record>
<record id="activity_b" model="workflow.activity">
    <field name="wkf_id" ref="test_workflow"/>
    <field name="flow_stop">True</field>
    <field name="name">b</field>
    <field name="kind">function</field>
    <field name="action">print_b()</field>
</record>

<record id="trans_a_b" model="workflow.transition">
    <field name="act_from" ref="activity_a"/>
    <field name="act_to" ref="activity_b"/>
</record>

worfklow总是根据特定的模型来定义(该模型由模型工作流上的属性osv给出)。将在该模型上调用活动或转换中指定的方法。

第一个activity的flow_start属性为True，以便odoo知道在实例化工作流之后从哪里开始遍历，因为在工作流记录上on_create被设置为True，所以每个新创建的记录都会实例化工作流。(否则，工作流应该通过其他方式进行实例化，例如从某些模块Python代码中进行实例化。)

当工作流被实例化时，它从活动“a”开始。这个活动的kind为function，这意味着aciton print_a()是对模型test.workflow的方法调用（通常cr, uid, ids, context参数会传给您）。

“a”和“b”之间的转换没有指定任何条件。这意味着在处理了“a”之后，工作流实例立即从“a”变为“b”，因此也处理了“b”活动。

活动

虽然转换可以看作是工作流的控制结构，但是活动是所有事情发生的地方，从更改记录状态到发送电子邮件。

有多种不同的活动：Dummy,Function,Subflow,and Stop all,每个在处理活动时都在做不同的事情。除此之外，活动还有其它的属性，将在下一节介绍

flow start 和 flow stop

属性flow_start是一个布尔值，指定在实例化工作流时是否处理活动。多个活动可以将其属性flow_start设置为True。当为记录实例化工作流时，Odoo会简单地处理所有的记录，然后评估它们所有的传出转换。

属性flow_stop是一个布尔值，用于指定活动是否停止工作流实例。当将其所有活动的flow_stop属性设置为True完成时，就认为工作流实例已经完成。

Odoo知道一个工作流实例什么时候完成对Odoo来说很重要。工作流可以具有实际上是另一个工作流(称为子流)的活动;当子流完成时，该活动就完成了。

Subflow

活动可以嵌入一个完整的工作流，称为子流(嵌入工作流称为父工作流)。要实例化的工作流由属性subflow_id指定。

Note:
在GUI中，除非活动的类型是子流，否则无法设置该属性。

当子流完成时(请参阅上面的属性flow_stop)，就认为活动已经完成(并且它的传出转换已经准备好进行评估)。

从子流发送信号

当工作流嵌入到工作流的活动(作为子流)中时，sublow可以通过在属性signal_send中提供一个信号名，将自己的活动中的信号发送到父工作流。Odoo通过向父工作流实例发送signal_send的值来处理这些活动。
换句话说，当活动在sublow中执行时，可以在父工作流中进行响应和转换。

服务器动作

活动可以通过在属性action_id中指定其ID来运行“服务器操作”。

python动作

一个活动可以执行一些python代码，通过属性action给出。评估环境和下面所述环境相同

分裂模式

在处理一个活动之后，odoo会评估它的转换，以到达工作流中的下一个活动。然而，如果一个活动有多个转换，那么Odoo必须决定要跟随哪个活动。

这个选择由split_mode属性控制:

XOR(default)

默认情况下，Odoo会使用满足条件的第一个转换(按顺序)。所有其他转换都被忽略。

OR

在或模式中，所有满足条件的转换都同时遍历。尚未有效的转换将被忽略，即使它们稍后变得有效。

AND

在和模式中，Odoo会等待所有的转换都被满足，并且会遍历所有的转换(很像OR模式)。

OR和AND模式都将导致活动在同一个工作流中处于活动状态。

Join mode

正如传出的转换条件可以组合在一起来决定是否可以遍历它们一样，传入的转换可以组合在一起来决定是否以及何时可以处理活动。

join_mode属性控制这些行为：

XOR(default)
任何输入转换都能启动活动并开始处理

AND
只有所有的输入转换被遍历之后，活动才能启动并开始处理

Kinds

活动的类型定义了活动可以执行的工作类型。

Dummy (dummy, default)
什么也不做或者调用服务器动作，经常用作传输的调度或集线器

Function (function)
运行一些python代码，执行服务器动作

Stop all (stopall)
完全停止工作流实例，并将其标记为已完成

Subflow (subflow)
开始执行另一个工作流，一旦工作流完成，活动就完成处理
默认情况下，子工作流与父工作流有相同的记录实例，通过提供返回记录ID(与子流相同的数据模型)的Python代码，可以改变这种行为。然后，嵌入的子流实例就是给定记录之一。

Transitions

转换提供了协调工作流的控制结构。当一个活动完成时，工作流引擎试图跨越从完成的活动到下一个活动的转换。以其最简单的形式(如上例所示)，它们按顺序链接活动，活动在之前的活动完成之后就会被处理。
而不是一下运行完所有的活动，也可以等待转换，只在满足某些条件时才进行转换。标准是条件、信号和触发器。下面几节将详细介绍它们。

Conditions

当一个活动完成时，它的传出转换将被检查，以确定工作流实例是否可能继续通过它们并到达下一个活动。当只定义了一个条件(即，没有定义信号或触发器)，条件由Odoo评估，如果它评估为True，worklfow实例通过转换进行。如果条件不满足，那么在每次修改关联记录时，或者通过显式方法调用进行重新计算。

默认情况下，属性条件(即，要计算的表达式)只是“True”，它通常计算为True。注意，条件可能有好几行;在这种情况下，最后一个值决定是否可以进行转换。

在条件评估环境中，可以方便地定义几个符号(除了Odoo safe_eval环境):

• 所有模型的列名，和
• 浏览记录的所有属性

Signals

除了条件之外，转换还可以指定信号名。当存在这样的信号名时，即使条件的值为True，也不会直接进行转换。取而代之的是过渡阶段，等待被唤醒。

为了唤醒具有已定义信号名称的转换，必须将信号发送到工作流实例。发送信号的一种常见方法是在用户界面中使用按钮，使用元素，其中信号名作为按钮的属性名。单击按钮后，信号将发送到当前记录的工作流实例。

当信号被发送给工作流实例时，条件仍然被评估

Triggers

当条件评估为False时，不会进行转换（因此导致活动不会被立即处理），不过，通过提供所谓的触发器，工作流实例可以获得跨越转换的新机会。其思想是，当条件不满足时，触发器将被记录在数据库中。稍后，可以唤醒安装了这些触发器的工作流实例，让它们重新评估转换条件。这种机制通过只获取其中的一部分(那些已经安装了触发器的实例)而不是所有的实例，从而降低了唤醒工作流实例的成本。

触发器在数据库中记录为记录id(以及模型名称)，并引用等待这些记录的工作流实例。转换定义提供一个模型名(属性trigger_model)和一个Python表达式(属性trigger_expression)，该表达式求值为给定模型中的记录id列表。这些记录中的任何一个都可以唤醒它们关联的工作流实例。

Note
当重新尝试转换时，不会重新安装触发器。