流程活动

流程流转是工作流的控制结构，流程活动是工作流实际动作执行的地方，变更数据记录状态，发送通知邮件。

不同类型的流程活动：Dummy、Function、Subflow 和 Stop all，可以处理不同的事务。每种不同类型的流程活动具有不同的一些属性信息。

流程启动和结束

属性flow_start是布尔值，设置当流程实例化后是否执行该活动。可以设置多个流程活动的 flow_start 属性为 True。当实例化流程时，odoo 将处理这些活动，然后处理其后续的流程流转。

属性flow_stop是布尔值，设置流程活动是否结束当前的流程实例。工作流实例在所有属性flow_stop为True的流程活动都结束后，认为该流程实例结束。

让 odoo 知道流程实例是否结束非常非常重要。一个流程可以包含另一个流程（称为“子流程”），当子流程结束后其对应的流程活动结束。

子流程

一个流程活动可以嵌入一个完整的工作流，称为子流程（相对于被嵌入的父流程）。该流程的实例化是由 subflow_id 属性指定的。

备注：在图形模式下，除非该流程活动是 Subflow 类型，否则不能设定该属性。当嵌入的子流程结束后，该流程活动被认为结束。（参见上述的 flow_stop 属性）。

从子流程发送标识

当一个流程作为子流程被嵌入一个流程的流程活动，子流程可以通过其所在的流程活动向父流程发送标识，标识由 signal_send 属性设定。odoo 在处理这类活动时，向父流程实例发送 signal_send 属性值并且加上 "subflow." 前缀的标识。

换句话说，父流程可以像流程活动一样对待子流程以处理子流程的交互和转换。

服务端操作

通过设定流程活动的 action_id 属性，可以让流程活动调用服务器端的操作。

Python操作

一个流程活动可以执行一些 Python 代码，通过 action 属性设定。运行的上下文环境与 Conditions 部分的解释一致。

流程分支

在一个流程活动处理完成后， odoo 通过流程流转条件的判断到达流程的下一个流程活动。然而，如果存在多个转换条件，odoo 必须决定哪一个（些）流程活动作为后续的流程处理。

这个选择是由 split_mode 属性控制：

XOR（缺省）

缺省情况下，odoo 使用第一个符合条件的分支（按照 sequence 顺序），其他分支将被忽略。

OR

在 OR 模式下，所有流转控制条件同时评估然后通过该节点，不符合条件的分支将被忽略，即使后来符合条件。

AND

在 AND 模式下，odoo 将一直等待，直到所有条件都符合，然后通过该节点。（类似于 OR 模式）

在OR和AND模式下，都将导致同一流程实例下多个流程活动处于活动状态。

流程合并

像节点输出转换条件可以组合决定该节点是否通过一样，节点输入转换条件也可以通过组合条件决定是否进入该节点的处理。

该行为 join_mode 属性控制：

XOR（缺省）

所有输入都将触发该流程活动被处理。

AND

流程活动直到所有输入条件都满足时才被激活和处理。

流程活动种类

流程活动类型定义了一个流程活动可以处理的工作类型。

Dummy (dummy, 缺省)

空流程活动，或者调用一个服务器端操作。经常用于流程流转的“派发器 dispatch”或者“集线器 hubs”。

Function (function)

运行 python 代码，执行服务器端操作。

Stop all (stopall)

完全结束流程实例并且标识为结束状态。

Subflow (subflow)

开始执行另一个流程，一旦子流程结束，那么该流程活动结束处理。

缺省情况下，子流程的实例化与父流程使用相同的数据记录。但是也可以通过Python代码返回数据记录标识改变这种缺省的方式（与子流程相同的数据实体）。嵌入的子流程实例将使用指定标识的数据记录。