Se define como flujo de trabajo (workflow) un sistema de secuencia de tareas de un proceso de negocio, que permite seguir una serie de pasos predefinidos para la aprobación de un contenido antes de ser público.

De forma paralela Drupal posee un sistema de roles y permisos que nos facilita que cualquier usuario pueda crear contenidos específicos dentro de nuestro portal, dependiendo del rol que le asignemos.

En ciertos casos,  cuando nos encontramos con un volumen de publicación de contenidos importante, podemos tener la necesidad de que, previamente a la publicación de un contenido, éste deba ser revisado y aprobado por un rol superior. En este caso, lo ideal es configurar un ciclo de aprobación o "workflow", en el que los usuarios con un rol determinado, Autor, pueda crear un tipo de contenido (noticia, post, texto en un apartado...), pero esta no será visible, hasta que un Editor la compruebe, y de su visto bueno.

En Drupal, la configuración de un sistema de workflow, permite, mediante la combinación de varios módulos, ampliar la posibilidades de publicación, incluso integrando a usuarios no registrados.

Los módulos que solemos utilizar son:

• Módulo rules http://drupal.org/project/rules
• Módulo workflow http://drupal.org/project/workflow
• Módulo views http://drupal.org/project/views

Iniciamos el proceso de generación de un sistema de workflow en Drupal

Partimos de un Drupal básico correctamente configurado, con los roles Autor y Editor,  y seguimos los siguientes pasos para configurar el módulo workflow:

1. Configurar el flujo de trabajo

A través de la administración, en el apartado Administrar › Construcción de la página › Workflow Añadir un nuevo workflow en la pestaña "Add workflow", con el nombre “Aprobación noticias ”.

El siguiente paso, es añadir un nuevo estado, que se incorpora al estado por defecto (creation). El estado (creation) se asigna por defecto a un contenido recién creado, sobre el que todavía no se ejecutó el flujo de trabajo.

Tenemos la posibilidad de añadir más estados en la opción "Add state". En este caso, el estado Revisado y No disponible. 

• De estado Creation a Borrador, usuario author.
• De Borrador a Revisado, usuario Editor
• De Borrador a No disponible, usuario Editor
• De Revisado a Borrador, usuario author
• De No disponible a Borrador, usuario author

Drupal nos ofrece la opción de "Access control"  para añadir permisos adicionales sobre los estados, combinando el rol, y el estado actual del nodo. Estos permisos, sobreescriben los permisos por defecto que incorporta el CMS Drupal

2. Configuración de las Reglas asociadas

El módulo Rules permite a los administradores programar accciones para que se activen después de ejecutarse un evento. Su potencia y flexibilidad hacen que sea un de los módulos más útiles para los sitios web que integrar gran cantidad de interlocutores y cargas de usuarios.

Desde la administración interna, en el apartado situado en Administrar › Rules › Triggered rules, se añade una nueva regla.

La primera regla, es la que comienza el flujo de aprobación, y atiende a los siguientes criterios:

• Un usuario con rol Autor, crea una noticia.
• El contenido pasa su estado de (creation) a Borrador.
• Se envía un correo al usuario Editor, notificando que tiene nuevo contenido que revisar.
• Se envía un correo al usuario Autor, notificándole que el contenido no será publicado hasta que el editor lo valide.

La segunda regla, se ejecuta cuando un Editor aprueba el contenido.

• Un usuario con rol Editor, después de revisar la noticia, la aprueba.
• Cambia el estado de la noticia, de Borrador a Revisado.
• El nodo cambia su estado a publicado
• Envía un correo al usuario author, notificando que su noticia ha sido publicada.

La tercera regla, se ejecuta cuando un Editor rechaza el contenido.

• Un usuario con rol Editor, después de revisar la noticia, la rechaza.
• Cambia el estado de la noticia, de Borrador a No disponible.
• Envía un correo al usuario Autor, notificando que su noticia no ha sido publicada.

En este caso, el usuario tiene la opción de modificar el contenido, ejecutando el workflow de nuevo.

La cuarta regla, se ejecuta cuando un usuario Autor, modifica un contenido, volviendo al estado Borrador y despublicando el contenido.

• Un usuario con rol Autor, modifica una notica de la que es propietario (author).
• Cambia el estado de la noticia, de Revisado, a Borrador.
• Se ejecuta de nuevo el workflow de aprobación.

3. Gestión interna de noticias en estado Borrador

Para facilitar la visualización del listado de noticias pendientes de aprobación hemos optado por la opción de crear una vista accesible solo a usuarios con rol editor, que liste los recursos con estado "Borrador", ordenados por fecha de publicación, en orden descendente.Esta vista lista los recursos todavía sin aprobar, listados desde el más antiguo al más actual, paginados en 10 elementos. El objetivo es facilitar la gestión de las peticiones.

Para revisar una noticia, basta con accedera ella a través de su título, y llegar al detalle de la noticia.

Una vez dentro, y revisada, el editor tiene accesible una pestaña con el texto "workflow", donde, que abre el formulario de aprobación. En este apartado, cambia el estado Borrador, por el estado Revisado o No disponible.

Además, dispone de un apartado Comentario, al que añadir una anotación, y un histórico de comentarios para llevar un registro más preciso.

Es en esta fase en la que se activan las reglas configuradas, ejecutando el workflow.

Esta funcionalidad se puede extender también a usuarios no logueados, siempre y cuando se acompañe de un módulo captcha correctamente configurado.

Esta casuística la explicaremos en próximos post para no acabar con la cabeza loca :)