Odoo10参考系列--工作流
在Odoo中，一个工作流是一个和一个去管理与模型记录关联的一套“要做的事”的技术产品。工作流提供了一种更高级别的方法来组织任务，以便在记录中执行。
更具体地说，工作流是一个有向图，其中节点被称为“活动”，而弧称为“转换”。
- 活动定义的工作，应在Odoo服务器完成，例如改变一些记录的状态，或发送电子邮件
- 转换控制工作流如何从活动进展到活动
在工作流的定义中，可以将条件、信号和触发器附加到转换，从而工作流的行为取决于用户操作（如单击按钮）、更改记录或任意的Python代码。
总之，Odoo的工作流系统提供了：
- 记录（文档）随时间的演变的描述
- 基于各种灵活条件的自动操作
- 公司角色管理和验证步骤
- 对象间交互的管理
- 文档流在其生命周期中的可视化表示
例如，一个基本的顺序可以有以下的流程：
顺序在草稿状态下开始，可以由用户确认，然后可以装运（关闭）或取消。
使用Odoo公司可能要添加折扣支持订单，在销售人员的自由裁量权高达15%折扣，但折扣超过15%需要经理确认。可以在不编辑Python或XML文件的情况下在线更改工作流以添加相关步骤：
因为活动可以执行任意操作，验证可以自动向相关人员发送验证请求。
注
需要修改订单视图以添加管理人员的接受折扣按钮
基础
用数据文件定义工作流是很简单的：一个记录“工作流”和活动记录和转换一起给出。例如，这里是一个用XML定义的两个活动的简单序列：
test.workflow
test.workflow.model
True
True
a
function
print_a()
True
b
function
print_b()
signal_goto_b
一个工作流总是相对于一个特定的模型定义 (模型workflow的属性osv给的模型)。将在该模型上调用活动或转换中指定的方法。
在上面的例子代码中，一个被称为“test_workflow”创建工作流。它是由两个活动，名为“a”和“b”，和一个转变，从“a”到“b”组成。
第一个活动有其设置为True的属性flow_start，因此Odoo知道当它实例化后从哪里开始工作流的遍历。因为在工作流记录上on_create 设置为True，工作量为每一个新创建的记录进行实例化。(否则，工作流应该通过其他方式实例化， 如从一些模块的Python代码)
当工作流实例化以后，它开始活动"a"。这个活动是一个 function，这意味着活动print_a() 是一个调用模型test.workflow的方法(常见的cr, uid, ids, context 参数传递个给你)。
"a"和"b"之间的转换指定一个信号，但不指定任何条件。这意味着工作流实例将立即从"a"到"b"，当信号 signal_goto_b 收到这样的过程活动"b"的活动print_b()
活动
虽然转换可以被视为工作流的控制结构，但活动是发生在所有事情发生的地方，从更改记录状态到发送电子邮件。
各种各样的活动存在： Dummy, Function, Subflow, 和Stop all,每次处理活动时都做不同的事情。除了它们，还有其他性质的活动，在接下来的章节中详细介绍。
流程开始和流程停止
属性flow_start 是一个布尔值，它指定当工作流被实例化后活动是否被处理。多个活动可以有它们的属性 flow_start 设置值为True。当为一个记录初始化一个工作流， Odoo将简单处理所有并评估所有输出后的转换。
属性 flow_stop 是一个布尔值，它指定活动是否停止工作量实例。当所有带有设置值为True的属性flow_stop的活动已经完成时，一个工作流实例认为已经完成。
这对Odoo知道何时一个工作流实例已经完成很重要。一个工作流可以有一个活动，它事实上是另一个工作流(叫做子流程)；当子流程完成时那个活动也就完成了。
子流程
一个活动可以嵌入一个完整的工作流程，称为子流程 (嵌入工作流称为父工作流)。工作流实例化指定属性subflow_id
注
在GUI(图形用户界面)中，该属性不能被设置，除非活动的类型是Subflow.
当子流程完成时(详见上面的属性 flow_stop)活动认为是完成的(并准备评估其输出转换)。
从子流发送信号
当一个工作流被嵌入在一个工作流的活动 (作为一个子流) 中，子流可以通过给定在属性 signal_send中的信号名称从其本身活动发送一个信号到其父工作流中。Odoo处理那些活动通过发送一个前缀为"subflow."的signal_send的值到其父工作流实例中。
换句话说，它是可能的反应，在父工作流得到转换活动在子流程执行
服务器活动
一个活动可以通过指定其在属性action_id中的ID而运行为一个"服务器活动"
Python活动
一个活动通过给定属性action可以执行一些Python代码。评价环境和本章节中条件部分解释内容是一样的。
分割模式
在一个活动已经被处理后，Odoo评估其向下一个流总活动的转换。
但是，如果一个活动有多个转换, Odoo必须决定哪个活动或接下来的活动。
这个选择是由 split_mode 属性控制：
XOR (默认的)
默认情况下，Odoo将使用第一个转换(按 sequence 顺序) ，它的条件是满足的。所有其他转换都被忽略
OR
在OR 模式下，所有满足条件的转换同时横贯。无效的转换将被忽略，即使它们稍后生效
AND
在AND 模式下，Odoo将等待所有转换满足，并将遍历所有这些转换 (非常像OR模式)
OR 和AND 模式将导致活动是在同一工作流中活动
加盟模式
正如传出的转换条件可以组合在一起以决定它们是否可以被遍历一样，传入的转换可以组合在一起，以决定是否以及何时处理活动。
join_mode 属性控制的行为有：
XOR (默认的)
任何传入的转换都能激活该活动并开始处理.
AND
只有遍历传入的所有转换后，才启用并处理该活动
种类
活动的种类定义了活动可以执行的工作类型。
Dummy (dummy, 默认的)
什么都不做，或者调用服务器操作。 经常用作分派或收集转换的“集线器”
Function (function)
运行一些Python代码，执行服务器操作
Stop all (stopall)
完全停止工作流实例并将其标记为已完成.
Subflow (subflow)
开始执行另一个工作流，一旦工作流完成，活动就完成了处理。
默认情况下，子流实例化和父工作流一样的记录。 通过提供返回记录id(对同一数据模型作为子流程)的Python代码，可以改变这种行为。嵌入式的子流程实例则是一个给定的记录
转换
转换提供了控制结构来编排工作流。当一个活动完成时，工作流引擎试图跨越已完成活动的转换，转到下一个活动。 在最简单的形式（如上面的例子）中，它们按顺序链接活动： 一旦活动完成，活动就被处理。
它不可能一下子运行所有的活动，而是可以等待转换，只有在满足某些标准时才进行转换。 标准是条件、信号和触发器。它们在下面的章节中详细介绍。
条件
当一个活动完成时，检查其传出的转换，以确定工作流实例是否有可能继续进行，并到达下一个活动。当只有一个条件的定义（即无信号或触发定义），条件通过Odoo评价，如果条件为True，该工作流实例进行转换。如果条件不满足，它将重新评估每一次相关的被修改的记录，或者通过显式调用方法去做。
默认情况下，属性 condition (即评估表达式)恰好为"True"，则一般评估为True。 注意，条件可能是几行长；在这种情况下，最后一个值决定是否可以转换。
在条件评估环境中，方便地定义了几个符号 (除了Odoo的 safe_eval环境)：
- 所有模型列名
- 所有浏览记录的属性
信号
除了一个条件外，转换可以指定一个信号名。当出现这样的信号名时，即使条件求值为True，也不直接进行转换。 I取而代之的是等待被唤醒的转换块。
为了唤醒具有定义的信号名的转换，信号必须发送到工作流实例。发送信号的一种常用方法是使用用户界面中的一个按钮，使用元素 并将信号名作为按钮的属性name。单击按钮后，信号将被发送到当前记录的工作流实例。
注
当将信号发送到工作流实例时，仍然对该条件进行评估
触发器
在评估为False的条件下，不进行转换 (因此它不会立即处理的活动)。尽管如此，工作流实例通过提供所谓的触发器，可以在这个转换过程中获得新的进展机会。其思想是，当条件不满足时，触发器就被记录在数据库中。 稍后，可以唤醒安装触发器的工作流实例，并提供它们重新评估它们的转换条件。这种机制通过仅仅命中部分实例(那些已经安装了触发器)而不是所有实例，使得更容易唤醒工作流实例。
触发器被记录在数据库中作为记录ID（与模型名一起），并引用等待这些记录的工作流实例。转型的定义提供了一个模型名称(属性trigger_model) 和Python表达式 (属性trigger_expression) 计算列表中给出的模型记录ID。这些记录中的任何一个都可以唤醒与它们关联的工作流实例。
注
每当重新尝试转换时，触发器都不会重新安装
ps：有翻译不当之处，欢迎留言指正。
原文地址：https://www.odoo.com/documentation/10.0/reference/workflows.html