Odoo Workflow 工作流

对工作流概念的理解

工作流就是对象的状态(处理流程), 比如一个订单有 draft, confirmed, done之类的状态.
工作流是个有向图, 节点就是活动 activity, 从活动转到下一个活动叫转换 transition.

使用数据文件定义工作流

<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"/>
    <field name="signal">signal_goto_b</signal>
</record>

• 创建了一个 test_workflow 的工作流, 它由两个名为“a”和“b”的活动和一个从“a”到“b”的转换组成。
• flow_start 设置为 True, Odoo 实例化后在这个节点启动工作流遍历.
• on_create 设置为 True, 为每个新纪录创建新的工作流.
• 当接受到信号时, 工作流从活动a到活动b

Activities 活动

活动的类型, 定义了活动做什么工作
活动定义那些应该被 Odoo 服务端完成的工作, 比如 改变一些 record 的状态, 或者发送邮件.
Dummy: 默认, 什么也不做, 或调用 server action.
Function: 运行 Python 代码, 执行 server action
Stop all: 停止工作流实例, 标记已完成
Subflow: 开始执行其他的工作流, 当工作流完成, 活动完成处理.

流程启动和停止

flow_start: 布尔值, 当 workflow 实例化的时候, 是否执行这个节点
flow_stop: 布尔值, 当执行这个节点的时候, 是否结束 workflow.

当 flow_stop 设置为 True 的所有活动都完成时, 工作流标记结束.

子流

一个完整的工作流可以嵌入到节点中, 叫子流.
由属性中的 subflow_id 指定要被实例化的工作流.

从子流发送信号

当执行子流中的节点时, 可以发送信号到工作流中, 使工作流发生转换.
属性 signal_send 的值就是信号名称

Server actions

通过属性 action_id 设置 server action 的 ID, 来运行 server action.

Python action

action 属性: 活动运行的 Python 代码.

Split mode

当活动被处理后, Odoo 评估转换, 以到达下一个活动.
当一个活动有多于一个的转换时, Odoo 需要确定跟踪哪个或哪些活动.
XOR: 默认值, Odoo 会按顺序判断转换, 当条件为真, 转换发生, 其他转换被忽略.
OR: 满足条件的转换会同时遍历, 未生效的转换会被忽略.
AND: 直到所有转换都满足条件时, 所有转换才会被遍历.

应用场景: 例如 split_mode 的三个选项，XOR，OR，AND。
以办公审批流程中的“会签”为例，
XOR表示，所有审批人中，只要一个人审批了，就表示审批通过。
AND表示，只有所有人都审批了，才表示审批通过。

Join mode

输入转换可以组合在一起, 决定是否和何时可以处理活动
XOR: 默认值, 只要有转换输入, 启动活动和开始处理
AND: 当所有输入的转换都被遍历时, 才启动活动和处理

Transitions 转换

转换组织工作流的控制结构, 由一个活动跳到另一个活动
当前面的活动完成时, 转换会转向到下一个活动
可以设置"标准", "信号", "触发"等作为标准, 使只有满足标准时, 转换才会发生.

Conditions 条件

当一个节点完成时, Odoo 会检查转换, 确定工作流实例是否被处理和转换到下一个活动.
当只设置了条件, 而没有设置信号和触发时, Odoo 会评估条件, 条件满足则启动转换, 如果条件不满足, 与之相关连的记录每次被修改时, 条件都会被重新评估.

Signals 信号

除了条件之外，转换可以指定信号。 当设置信号时, 即使条件的计算结果为“True”，也不会直接进行转换。转换会被阻止，等待被唤醒。

要唤醒一个定义了信号的转换, 需要把信号发给工作流实例.
一个常见的的方式是, 使用用户界面的按钮, 按钮元素 <button/> 通过 name 属性设置信号.
当点击按钮时, 信号会被发送到工作流实例.

Triggers 触发

当条件不满足时, 转换不会被执行, 所以活动也不会立即被处理.
但工作流实例可以通过触发(trigger), 来重新启动转换.

当条件不满足时, 触发会被记录到数据库中. 稍后, 可以唤醒安装了这些触发的工作流实例, 重新评估条件是否满足.

工作流模型

`class Workflow` 工作流  
- name: 工作流名称  
- osv: 关联的模型  

`class WorkflowActivity` 活动  
- kind: 活动类型  
- name: 活动名称  
- join_mode: 转换输入  
- split_mode: 转换输出  
- flow_start: 当工作流实例化时处理执行此活动
- flow_stop:  布尔值, 标记是否结束 workflow  
- subflow_id:  指定要被实例化的工作流 
- action: 运行 Python 代码  
- signal_send: 信号  
- action_id: 关联的 server action  
- wkf_id: 关联的 workflow  


`class WorkflowInstance` 工作流实例  
- res_type: 关联的模型  
- wkf_id: 关联的工作流模型    
- state: 工作流实例的状态, 是否激活  
- res_id: 关联模型的实例对象  

`class WorkflowTransition`  转移  
- signal: 接收到信号启动转移  
- act_from: 活动的实例对象  
- act_to: 活动的实例对象  
- condition: 条件  


`class WorkflowWorkitem`  
- act_id   
- inst_id   
- subflow_id  
- state  
 
`class WorkflowTriggers`   
- instance_id  
- workitem_id  
- model  
- res_id  

参考

Workflows