WORKFLOWS (FLUJOS DE TRABAJO).
Se utilizan para estructurar, y gestionar los ciclos de vida de objetos, y documentos.
Definiendo transiciones, trigger (eventos), etc. etc. con herramientas gráficas.
Como de costumbre, los flujos de trabajo, sus actividades (acciones o nodos), y sus transiciones (condiciones), se declaran como un fichero XML.
Declaración del Workflow.
Los flujos de trabajo son declarados en objetos que poseen un campo “state” (“estado”).Parámetros:
• id → ID único para identificar el workflow. Siempre empieza por “wkf_”+objeto
• model=”workflow” → Le indicamos que estamos definiendo un “Workflow”.
• Name → Nombre para el Workflow (Obligatorio).
• Osv → Nombre del objeto al que le estamos definiendo el Workflow
• on_create → Crear el Workflow al crear el objeto.
Ejemplo de una declaración del workflow (flujo de trabajo):
<?xml version="1.0" encoding="UTF8"?>
<openerp>
<data>
<record id="wkf_nombreobjetodelworkflow" model="workflow">
<field name="name">nombremodulo.basic</field>
<field name="osv">object.name</field>
<field name="on_create">True</field>
</record>
</data>
</openerp>
Declaración de las Actividades del Workflow.
Aquí definimos las distintas actividades del Workflow. Para entendernos, aquí definimos los distintos estados del Workflow.Parámetros:
• id → ID único para identificar la acción del workflow. Siempre empieza por “act_”+acción.
• model=”workflow.activity” → Le indicamos que estamos definiendo una nueva actividad del “Workflow”.
• wkf_id ref=”id_workflow” → Le indico el IDE del Workflow al que pertenece esta actividad.
• flow_start → Le indico que es el primer estado del Workflow.
• flow_stop → Le indico que es el último estado del Workflow.
• name→ Le indico el valor del estado que estoy definiendo.
• kind → Tipo de acción a realizar cuando el nodo es activado por una transición.
Valores posibles:
• “dummy” → Cuando no va a realizar ninguna acción
• “function” → Para ejecutar una función.
• “subflow” →Para ejecutar un subflow. Para entender que es un 'subflow', imaginemos un pedido que tiene su propio workflow, este pedido depende de una factura que tiene su propio workflow. Si estoy tratanto del workflow del pedido, y para realizar cualquier operación con este pedido, necesito saber el workflow de su factura, este workflow de la factura se convierte en un subflow'.
• stopall → Para terminar el Workflow tras las activación.
• action → Nombre de la función que se ejecutará.
• subflow_id: ID del subflow a ejecutar.
Ejemplo de declaraciones de actividades:
<record id="act_estado1" model="workflow.activity">
<! Le indico a que workflow pertenece este estado >
<field name="wkf_id" ref="wkf_nombreobjetodelworkflow"/>
<! Le indico que este es el primer estado del workflow >
<field name="flow_start">True</field>
<! Le indico el valor del estado del workflow >
<field name="name">estado1</field>
<! Le indico que va a ejecutar una función >
<field name="kind">function</field>
<! Nombre de la función que va a ejecutar >
<field name="action">action_estado1()</field>
</record>
<record id="act_estado2" model="workflow.activity">
<field name="wkf_id" ref="wkf_nombreobjetodelworkflow"/>
<! Le indico que este es el último estado del workflow >
<field name="flow_stop">True</field>
<field name="name">estado2</field>
<field name="kind">function</field>
<field name="action">action_estado2()</field>
</record>
Declaración de las Transiciones del Workflow.
Aquí definimos las distintas transicciones del Workflow.Parámetros:
• id → ID único para identificar la transición del workflow. Siempre empieza por
“trans_”+”estado desde”+”_”+”estado hasta”.
• model=”workflow.transition” → Le indicamos que estamos definiendo una nueva transición del “Workflow”.
• act_from → ID de la actividad desde.
• act_to → ID de la actividad hasta.
• signal → Botón que ejecutará la transición.
• condition → Función que se ejecutará antes de ejecutar esta transición. Si esta función devuelve “false”, no se ejecutará esta transición.
<record id="trans_estado1_estado2" model="workflow.transition">
<field name="act_from" ref="act_estado1"/>
<field name="act_to" ref="act_estado2"/>
<field name="signal">boton_estado1</field>
<field name="condition">test_author()</field>
</record>
<record id="trans_estado2_estado1" model="workflow.transition">
<field name="act_from" ref="act_estado2"/>
<field name="act_to" ref="act_estado1"/>
<field name="signal">boton_estado2</field>
</record>
Como hemos visto en el atributo SIGNAL le indicamos el botón que ejecutará la transición, pero no solamente hay que indicarle el botón, sino que también tenemos que modificar el botón que hemos definido. Esta sería ahora la definición del botón:
<button name="boton_estado1" states="estado1" string="Estado 1" icon="gtkok"/>
<button name="boton_estado2" states="estado2" string="Estado 2" icon="gtkok"/>
Debemos de tener en cuenta que solo se mostrará el “boton_estado1” cuando el estado
del Workflow sea igual a “estado1”. Esto se lo indicamos con el atributo 'states=”estado1”'.
El “boton_estado2” solo se mostrará cuando el estado del Workflow sea igual a “estado2”.
HEREDAR UN WORKFLOW.
Se nos puede dar el caso en que necesitemos heredar el workflow de algún objeto deOpenERP para añadirle nuevos estados. En tal caso deberemos de realizar lo siguiente:
1.- Declaro una nueva actividad:
<record id="act_pending_installation" model="workflow.activity">
<field name="wkf_id" ref="avanzosc_stock_prodlot_wk.wkf_stock_lot"/>
<field name="name">pendinginstallation</field>
<field name="kind">function</field>
<field name="action">action_pending_installation()</field>
</record>
Lo único distinto de lo visto hasta ahora es la siguiente línea:
<field name=”wkf_id” ref=”.........”/> → <nombre_carpeta/modulo>.<id del workflow a
heredar>
Lo que indico en esta línea es el módulo/carpeta que estoy heredando, un punto, y el ID
del workflow a heredar.
2.- Declaro nuevas transiciones al Workflow, y utilizo algunas actividades heredadas:
<record model="workflow.transition" id="stock_lot_trans_nouse_pendinginstallation">
<field name="act_from" ref="avanzosc_stock_prodlot_wk.act_nouse" />
<field name="act_to" ref="act_pending_installation" />
<field name="signal">button_pending_installation</field>
</record>
Lo único distinto de lo visto hasta ahora es la siguiente línea:
<field name=”act_from” ref=”....”/> → <nombre_carpeta/modulo>.<id de la actividad a
heredar>
Muy bueno el post gracias
ResponderBorrarmuy bueno el post, pero una consulta, yo uso la version 7 y en la transicion aparece asi el signal:
ResponderBorrarfield name="signal">subflow.done</field
mi consulta es, ese "subflow.done" a que hace referencia? pues no es un boton y no se que puede ser.
Gracias y saludos.