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闪亮登场