Odoo(OpenERP) 序列和工作流


Odoo(OpenERP) 序列和工作流

www.chinamaker.net 2011-02-09 16:06:00 admin

一序列
序号名称
序号的显示名称
序号类型
序号的类型
编辑序列
前缀
生成序号的前缀,可以用一些系统变量
后缀
生成序号的后缀,可以用一些系统变量
数字位数
生成序号的数字位数(不含前缀和后缀),不足位时会在前面补0
增量
每次序号增加的数字
下一编号
系统将生成的下一个序号
二、工作流
一、工作流定义:



workflow.name
resource.model
True|False




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)定义


activity.name
dummy|function|subflow|stopall
subflow_id
(...)
(...)
XOR|OR|AND
XOR|AND
(...)
True|False
True|False



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”()。account.wkf处理完成后,发出信号subflow.paid通知wkf_expenses流程(subflow.paid)。wkf_expenses中定义了信号subflow.paid(subflow.paid)。

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定义格式如下。



(...)
(...)
(...)
(...)



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()
迁移(Transition)的定义漏了权限组group_id,修正如下。表示只有该权限组可以触发本迁移。
迁移的完整XML定义格式如下。




(...)
(...)
(...)
(...)


 

来源:苏州远鼎官网


相关标签 TAG :  odoo工作流  序列  


苏州远鼎

运用前沿科学技术,苏州远鼎信息技术有限公司以开源管理软件产品为核心,为企业和政府组织提供软件及服务,是OpenERP(Odoo)专业服务商,中国开源管理软件服务市场的领跑者。

Read More

远鼎产品

联系远鼎

  • 苏州工业园区星湖街328号22栋301
  • +86-0512-69361217
  • odoo@chinamaker.net
  • www.chinamaker.net