一、工作流定义:
<?xml version="1.0"?>
<terp><data>
<record model="workflow" id=workflow_id>
<field name="name">workflow.name</field>
<field name="osv">resource.model</field>
<field name="on_create">True | False</field>
</record>
</data></terp>
model:固定取值"workflow"
id:任意值,唯一标识本工作流
name: 工作流的名称,任意定义
osv:本工作流关联的对象类型,是OpenERP模块中定义的某对象名,如采购单对象(purchase.order)。是本工作流处理的数据对象。
on_create:每当系统新产生一个osv 中定义的对象的实例时候,是否对应的产生一个和该对象实例关联的工作流实例。默认是True.
工作流和工作流实例:工作流定义了对某一类型的对象,如采购订单(PO)的处理流程。例如,PO单的一般处理流程也许是:1)新建PO,State = draft;2)审批PO,审批的同时,a)系统自动产生收货单,工仓库收货;b)系统自动产生凭据(Invoice),供财务确认付款;c)系统自动产 生PDF的采购订单,并自动EMail给该PO单对应的供应商。但对于特定的某个PO对象,需要一个工作流实例,以记录本PO对象处在流程的哪个阶段,如 PO1尚在draft状态,PO2已经审批通过。
PO单的审批,以及对应的a)、b)、c)的动作,都可以在OE的工作流中定义解决,而不需要全编码在PO对象上。即工作流实现了流程处理相关的代码和被处理对象的代码相分离,降低了不同处理代码的耦合性,增加了系统功能的柔软性。
二、活动(Activity)定义
<record model="workflow.activity" id="activity_id">
<field name="wkf_id" ref="workflow_id"/>
<field name="name">activity.name</field>
<field name="kind">dummy | function | subflow | stopall</field>
<field name="subflow_id">subflow_id</field>
<field name="action">(...)</field>
<field name="action_id">(...)</field>
<field name="split_mode">XOR | OR | AND</field>
<field name="join_mode">XOR | AND</field>
<field name="signal_send">(...)</field>
<field name="flow_start">True | False</field>
<field name="flow_stop">True | False</field>
</record>
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)的定义
迁移的完整 XML 定义格式如下。
<record model="workflow.transition" id="transition_id">
<field name="act_from" ref="activity_id_1"/>
<field name="act_to" ref="activity_id_2"/>
<field name="signal">(...)</field>
<field name="condition">(...)</field>
<field name="trigger_model">(...)</field>
<field name="trigger_expr_id">(...)</field>
</record>
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)实际执行该工作流。实际使用例子请参考Sale模块的工作流定义 wkf_sale:
<field name="trigger_model">procurement.order</field>
<field name="trigger_expr_id">procurement_lines_get()</field>
迁移(Transition)的定义漏了权限组group_id,修正如下。表示只有该权限组可以触发本迁移。
迁移的完整 XML 定义格式如下。
<record model="workflow.transition" id="transition_id">
<field name="act_from" ref="activity_id_1"/>
<field name="act_to" ref="activity_id_2"/>
<field name="group_id" ref="groupid"/>
<field name="signal">(...)</field>
<field name="condition">(...)</field>
<field name="trigger_model">(...)</field>
<field name="trigger_expr_id">(...)</field>
</record>
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)实际执行该工作流。实际使用例子请参考Sale模块的工作流定义 wkf_sale:
procurement.order
procurement_lines_get()
深入理解OpenERP的工作流(Workflow),布布扣,bubuko.com
深入理解OpenERP的工作流(Workflow)
原文:http://www.cnblogs.com/jacker1979/p/3785664.html