Read acknowledgment

Resumen

Una pequeña plantilla de prueba de concepto, reutilizable para cualquier flujo del tipo “N usuarios deben confirmar que han leído un documento”. Un flujo de trabajo maestro, iniciado manualmente sobre un documento, lanza una revisión hija por cada revisor en paralelo; una vez que todas las hijas han confirmado, el maestro cierra el bucle y marca el documento como leído por completo.

Download master workflow: read-acknowledgment.okmflow

Download slave workflow: read-acknowledgment-review.okmflow

Diagrama

Master

Slave

Cómo funciona

1. El maestro (read-acknowledgment) se inicia manualmente sobre un documento. Obtiene todos los usuarios con ROLE_SUPERVISOR y lanza un hijo read-acknowledgment-review por usuario, en paralelo.
2. Cada hijo muestra el documento a su revisor con un único botón “Yes, I have read it” y un comentario opcional.
3. Cuando un revisor confirma, el hijo añade una nota al documento (comentario, además de quién lo leyó y cuándo) e informa de vuelta al maestro, y a continuación finaliza.
4. Mientras tanto, el maestro espera en una tarea asignada al usuario system. Una acción programada comprueba periódicamente cuántos revisores han informado; en cuanto lo han hecho todos, libera la espera y el maestro finaliza, marcando el documento como leído por completo.

Comunicación entre flujos de trabajo (contexto)

El maestro y sus hijos nunca comparten un campo de documento para esto; solo se comunican entre sí a través de variables de contexto de instancia de proceso.

Variable	Establecida por	Leída por
uuid, reviewer, initiator, srcProcInsId	El maestro, al lanzar cada hijo	El hijo: identifica qué par documento/usuario gestiona y a qué instancia maestra debe informar.
pendingReviewers, pendingTotal	El maestro, justo después de lanzar a todos los hijos	La propia acción programada del maestro: la lista/recuento contra el que comprueba el progreso.
status_<reviewer>	Cada hijo, en cuanto su revisor confirma, escrita directamente en la instancia de proceso del maestro	La acción programada del maestro: cuenta cuántos revisores han respondido.

Un nodo de acción programada (nombre que empieza por scheduled) adjunto al maestro se ejecuta según un temporizador y compara las confirmaciones recibidas con pendingTotal; en cuanto coinciden, libera la tarea de espera del maestro para que pueda finalizar.

Requisitos previos

Antes de desplegar este flujo de trabajo, lo siguiente debe existir en OpenKM.

Usuarios y roles

Identificador	Tipo	Usado en	Descripción
ROLE_SUPERVISOR	Rol	Notify all admins	Cada usuario con este rol recibe una tarea de lectura en paralelo; sin pool/autoasignación, cada uno obtiene su propio proceso hijo. Debe tener al menos un usuario asignado además del iniciador; si no existe ninguno, la acción Notify all admins del maestro falla inmediatamente.

Grupo de metadatos

El grupo de propiedades okg:read_acknowledgment debe estar registrado en OpenKM antes de la primera ejecución; no se crea automáticamente al desplegar los ficheros .okmflow, y ws.propertyGroup.addGroup(...) falla la primera vez que se procesa un documento si falta. El maestro lo aplica de forma programática (Notify all admins y Finalize); el usuario nunca lo rellena. La definición a importar es metadata.xml, junto a los dos ficheros .okmflow en la carpeta de la plantilla:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE property-groups PUBLIC "-//OpenKM//DTD Property Groups 3.12//EN"
                                 "http://www.openkm.com/dtd/property-groups-3.12.dtd">
<property-groups>
  <property-group label="Read acknowledgment" name="okg:read_acknowledgment">
    <select label="Reading status" name="okp:read_acknowledgment.status" type="simple" readonly="true">
      <option label="Pending" value="Pending" />
      <option label="All read" value="All read" />
    </select>
  </property-group>
</property-groups>

Un único campo de solo lectura, status: se establece a Pending en cuanto el maestro lanza las revisiones hijas, y pasa a All read mediante Finalize en cuanto llega la última confirmación.