openerp 经典收藏 workflow中的‘非典型’自动触发器trigger_model（转载）

workflow中的‘非典型’自动触发器trigger_model

原文：http://cn.openerp.cn/workflow%E4%B8%AD%E7%9A%84%E9%9D%9E%E5%85%B8%E5%9E%8B%E8%87%AA%E5%8A%A8%E8%A7%A6%E5%8F%91%E5%99%A8trigger_model/

Openerp中workflow的设计机制

工作流程系统在OpenERP里是非常有用的机制，可以用于即时描述单据(模型)状态的演进过程。工作流实现了状态流转的可配置，通过迁移的condition代替python代码中的判断语句，通过迁移的signal增加审批按钮，增加了系统的灵活性。工作流程是完全可以定制的，这些流程可以调整适用于几乎所有公司的作业流程和交易逻辑。 这个工作流程系统使OpenERP非常有弹性， 而且可以不用编程增加新功能,就可以支持不断变化的需要。对于单据的审批，以及对应的的动作，都可以在OE的工作流中定义解决，而不需要全在对象上进行编码。即工作流实现了流程处理与对象的业务逻辑的代码相分离，降低了不同处理代码的耦合性，增加了系统功能的柔软性。

如上所说工作流定义了对某一类型的对象，为model的处理流程，每当系统新产生一个model的实例（resource）时候，则对应产生一个工作流实例（workinstance）。如：创建sale.order实例时系统自动启动一个对应的工作流实例 。

简而言之就是工作流定义流程，工作流实例记录对象在流程的哪个阶段，如SO中，SO1在draft状态，SO2已经审批通过。

上面一方的大论过后，下面我们来揭开trigger_model的神秘面纱

工作流就像是隐藏在对象幕后的一个灵敏而又聪明的监视器，闻风而动，它并不会傻傻的每时每刻去检查这些条件，只有当对象发生了变化，这个监视器才会敏锐的捕获信息，随后去检查条件是否满足，可否迁移，当然，仅有这聪明和敏锐是难成大事的，所谓大师就是看到别人看不到的东西，下面我们看看：
当你创建了一张Sale Order，你想当它发货确认以后，就让Sale order的状态为Done，你确认Sale order的时候，它乖乖的会检查一次，当前处在未发货状态，condition为False，状态不能变，但是过几天我们发货了，这时你发现这工作流装死，它不给你的Sale Order状态改为 Done，你怒了，把这小子狠批一顿，工作流委屈的说，那是别人家的事（外部的对象）你得让他和我打个招呼…，于是你想想也有道理，于是你跑去别人家也装了监视器（子工作流），那边有变化就发个信号过来
这个监视器是这样设计的（子工作流）：当Activity为subflow的类型时，进入该状态节点（activity）触发“subflow_id”中指定的工作流。在sale模块的workflow “wkf_sale”中， 需要开发票时候，它触发流程account模块中的工作流“account.invioce.basic” （field name=”subflow_id” ref=”account.wkf”）。 account.wkf处理完成后，发出信号subflow.paid 通知wkf_sale流程（field name=”signal_send”>subflow.paid<）。 销售订单的工作流中从invioce子工作流节点到invioce_end节点的transition条件中定义了信号subflow.paid=True，当条件满足时就实现状态跳转，用于父子流程通信的工作流signal必须是形如subflow.*

可是过几天麻烦来了，有人家不让你装这个监视器（有些对象没有定义工作流如stock.move），这可咋办,你为难了,这时候trigger_model闪亮登场

<field name="trigger_model">stock.move</field>

<field name="trigger_expr_id">[move_id.id]</field>

trigger_model:触发你去检查迁移条件的外部对象类型
trigger_expr_id:trigger_model类型的对象ids，可以是一段Python代码，也可以定义一个方法，返回ids

大喜之余，立马动手

<record id="ship_to_ongoing" model="workflow.transition">

   <field name="act_from" ref="state_ship" />

   <field name="act_to" ref="state_ongoing" />

   <field name="trigger_model">stock.picking</field>

   <field name="trigger_expr_id">[out_picking_id.id]</field>

   <field name="condition">test_out_shipping_done()</field>

</record>

沾沾自喜，再一次再一次被耍了，我改变picking对象状态的时候，它没有在去检查condition

What Amazing Happens! 低头grep…,目标出现。。。

./procurement/procurement_workflow.xml:171:            <field name="trigger_model">stock.move</field>

./procurement/procurement.py:431:            wf_service.trg_trigger(uid, 'procurement.order', id, cr)

映衬标题，‘非典型’触发器trigger_model，它并不是那么自动，你得在定义的模块中手动调用wf_service.trg_trigger方法，第一次触发的时候它在数据库中写入wkf_trigger：
1 model = trigger_model

2 res_ids = trigger_expr_id定义的ids

3 workitem_id = workitem id of act_from activity

4 inst_id = instance id of the wrk_flw （参见addons/base/ir/workflow/work.py 下的wkf_triggers）

wkf_trigger就像是一个过滤器，只有哪些对象的特定记录改变了，才会让这工作流去check

trigger_model这个神奇的利器在OpenERP 7.0却仅有中account.move.line, procurement.order 和 stock.move中 用到了

越厉害的东西越危险，高内聚低耦合的设计理念，openerp玩转自如，面纱已落地….