工作流和商业对象关联，描述他们的动态模型运动规律，随着时间的推移还可用于追踪过程。
工作流可以和odoo中任意对象关联，是完全可定制的，工作流用于架构和管理商业对象和文档的周期，定义transitons，触发器等等。
一个模型关联的工作流在模型记录创建的时候创建.
工作流定义属性:
model：固定取值"workflow"
id：任意值，唯一标识本工作流
name: 工作流的名称，任意定义
osv： 本工作流关联的对象类型，是OpenERP模块中定义的某对象名，如采购单对象（purchase.order）。是本工作流处理的数据对象。
on_create：每当系统新产生一个osv 中定义的对象的实例时候，是否对应的产生一个和该对象实例关联的工作流实例。默认是True.
活动（Activity）定义属性
model：固定取值workflow.activity
wkf_id：本Activity所属的工作流id
name: 本Activity名称，任意值
kind：本Activity类型，有Dummy, Function, Subflow, Stop All 四种。kind说明，如果流程到达本节点，系统应执行的动作类别。
Dummy 表示不执行任何动作，即action中定义的代码不会被执行。
Function 表示执行action中定义的python代码，且，执行action_id中定义的server action。常见情况是，action中定义一个write方法，修改流程关联的对象的状态。对于Function类型的节点，action中定义的代码或者返回False，或者返回一个客户端动作id（A client action should be returned）。
Subflow类型表示触发“subflow_id”中指定的工作流。仔细的读者或许要问，工作流的执行总是和某个被处理的对象关联，是的，如果定义了action，subflow 关联的对象id 由action中定义的代码返回。如果没有定义action，系统默认subflow关联的对象和本节点所属的工作流处理的对象id一致。stopall类型表示，流程到此节点则结束，但结束前，系统仍会执行action中的代码。
signal_send：执行完本节点的动作（action及action_id定义的动作）后，应向别的工作流发往的signal，格式是：subflow.signal。subflow_id和signal_send必须配合使用，subflow_id表示，触发子工作流subflow_id，在该子工作流中，通常必须定义signal_send，signal_send定义父流程中的某个signal，表示，子流程处理结束后触发父流程中的信号subflow.signal。注意，用于父子流程通信的工作流signal必须是形如subflow.* 。例如，在HR模块的workflow "wkf_expenses"中，需要开发票时候，它触发流程account模块中的工作流“account.wkf”（<field name="subflow_id" ref="account.wkf"/>）。account.wkf处理完成后，发出信号subflow.paid 通知wkf_expenses流程（<field name="signal_send">subflow.paid</field>）。wkf_expenses中定义了信号subflow.paid（<field name="signal">subflow.paid</field>）。
split_mode：有三个选项，XOR，OR，AND，默认是XOR。XOR 表示，由本节点始发的出迁移中，沿着第一个满足迁移条件的迁移跳转。OR 表示由本节点始发的出迁移中，只要满足迁移条件即沿该迁移跳转。AND 表示由本节点始发的出迁移中，只有所有迁移皆满足迁移条件才跳转，而且是同时沿所有迁移跳转。XOR 只有一个跳转，OR 有零或多个跳转，AND 有零或全部跳转。
join_mode：有两个选项，XOR，AND，默认是XOR。XOR 表示，以本节点为终点的入迁移中，只要有一个跳至本节点，即执行本节点的action。AND 表示，以本节点为终点的入迁移中，只有所有迁移都已经跳至本节点，才执行本节点的action。
flow_start：表示流程的开始节点。
flow_stop：表示流程的结束节点。
迁移（Transition）的定义中的属性
act_from：本迁移的起始节点，引用之前定义的Activity。
act_to：本迁移的结束节点，引用之前定义的Activity。
signal：触发本迁移的信号，表示，如果系统收到signal定义的信号，则触发本迁移。触发信号有三种方式，1）最常见的是用户点击视图中的“name = 本处定义的signal”的button，此时相当于向系统发送迁移信号量。系统会根据视图中的对象id，找到对象关联的workflow，再找到与button name相同的signal，触发之。2）调用workflow_service的方法：trg_validate(self, uid, res_type, res_id, signal, cr)，此方法表示，触发对象类型res_type关联的workflow的signal信号，工作流实例关联的对象实例是 res_id。3）子流程的signal_send 发出的信号，此种情况前文已说过。
condition：迁移的条件，是一段Python代码，通常是一个函数调用。当系统收到signal中定义的信号时候，检查此处的条件，条件为真则实际触发迁移。
trigger_model和trigger_expr_id：此二字段表示启动一个新工作流实例。trigger_model定义对象类型，trigger_expr_id 定义一段Python代码，返回trigger_model类型的对象id。此二字段表示，如果act_from 中的action 执行完毕，且condition 条件OK，则系统中插入一个trigger_model类型，trigger_expr_id返回的对象id关联的工作流实例。然后，可以调用workflow_service的方法trg_trigger(self, uid, res_type, res_id, cr)实际执行该工作流。
工作流可以和odoo中任意对象关联，是完全可定制的，工作流用于架构和管理商业对象和文档的周期，定义transitons，触发器等等。
一个模型关联的工作流在模型记录创建的时候创建.
工作流定义属性:
model：固定取值"workflow"
id：任意值，唯一标识本工作流
name: 工作流的名称，任意定义
osv： 本工作流关联的对象类型，是OpenERP模块中定义的某对象名，如采购单对象（purchase.order）。是本工作流处理的数据对象。
on_create：每当系统新产生一个osv 中定义的对象的实例时候，是否对应的产生一个和该对象实例关联的工作流实例。默认是True.
活动（Activity）定义属性
model：固定取值workflow.activity
wkf_id：本Activity所属的工作流id
name: 本Activity名称，任意值
kind：本Activity类型，有Dummy, Function, Subflow, Stop All 四种。kind说明，如果流程到达本节点，系统应执行的动作类别。
Dummy 表示不执行任何动作，即action中定义的代码不会被执行。
Function 表示执行action中定义的python代码，且，执行action_id中定义的server action。常见情况是，action中定义一个write方法，修改流程关联的对象的状态。对于Function类型的节点，action中定义的代码或者返回False，或者返回一个客户端动作id（A client action should be returned）。
Subflow类型表示触发“subflow_id”中指定的工作流。仔细的读者或许要问，工作流的执行总是和某个被处理的对象关联，是的，如果定义了action，subflow 关联的对象id 由action中定义的代码返回。如果没有定义action，系统默认subflow关联的对象和本节点所属的工作流处理的对象id一致。stopall类型表示，流程到此节点则结束，但结束前，系统仍会执行action中的代码。
signal_send：执行完本节点的动作（action及action_id定义的动作）后，应向别的工作流发往的signal，格式是：subflow.signal。subflow_id和signal_send必须配合使用，subflow_id表示，触发子工作流subflow_id，在该子工作流中，通常必须定义signal_send，signal_send定义父流程中的某个signal，表示，子流程处理结束后触发父流程中的信号subflow.signal。注意，用于父子流程通信的工作流signal必须是形如subflow.* 。例如，在HR模块的workflow "wkf_expenses"中，需要开发票时候，它触发流程account模块中的工作流“account.wkf”（<field name="subflow_id" ref="account.wkf"/>）。account.wkf处理完成后，发出信号subflow.paid 通知wkf_expenses流程（<field name="signal_send">subflow.paid</field>）。wkf_expenses中定义了信号subflow.paid（<field name="signal">subflow.paid</field>）。
split_mode：有三个选项，XOR，OR，AND，默认是XOR。XOR 表示，由本节点始发的出迁移中，沿着第一个满足迁移条件的迁移跳转。OR 表示由本节点始发的出迁移中，只要满足迁移条件即沿该迁移跳转。AND 表示由本节点始发的出迁移中，只有所有迁移皆满足迁移条件才跳转，而且是同时沿所有迁移跳转。XOR 只有一个跳转，OR 有零或多个跳转，AND 有零或全部跳转。
join_mode：有两个选项，XOR，AND，默认是XOR。XOR 表示，以本节点为终点的入迁移中，只要有一个跳至本节点，即执行本节点的action。AND 表示，以本节点为终点的入迁移中，只有所有迁移都已经跳至本节点，才执行本节点的action。
flow_start：表示流程的开始节点。
flow_stop：表示流程的结束节点。
迁移（Transition）的定义中的属性
act_from：本迁移的起始节点，引用之前定义的Activity。
act_to：本迁移的结束节点，引用之前定义的Activity。
signal：触发本迁移的信号，表示，如果系统收到signal定义的信号，则触发本迁移。触发信号有三种方式，1）最常见的是用户点击视图中的“name = 本处定义的signal”的button，此时相当于向系统发送迁移信号量。系统会根据视图中的对象id，找到对象关联的workflow，再找到与button name相同的signal，触发之。2）调用workflow_service的方法：trg_validate(self, uid, res_type, res_id, signal, cr)，此方法表示，触发对象类型res_type关联的workflow的signal信号，工作流实例关联的对象实例是 res_id。3）子流程的signal_send 发出的信号，此种情况前文已说过。
condition：迁移的条件，是一段Python代码，通常是一个函数调用。当系统收到signal中定义的信号时候，检查此处的条件，条件为真则实际触发迁移。
trigger_model和trigger_expr_id：此二字段表示启动一个新工作流实例。trigger_model定义对象类型，trigger_expr_id 定义一段Python代码，返回trigger_model类型的对象id。此二字段表示，如果act_from 中的action 执行完毕，且condition 条件OK，则系统中插入一个trigger_model类型，trigger_expr_id返回的对象id关联的工作流实例。然后，可以调用workflow_service的方法trg_trigger(self, uid, res_type, res_id, cr)实际执行该工作流。
扫一扫
4115
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
