Flujo de Aprobación

Cuando la edición es una actividad de equipo, la publicación debería incluir un segundo par de ojos. El workflow de aprobación de Chinaski (desactivado por defecto, se activa en Settings → Workflow) hace que los editores envíen su trabajo para revisión en lugar de publicar directamente; un admin lo aprueba:lo cual lo publica en vivo: o lo devuelve con una nota. Esta página explica el ciclo de revisión para páginas y posts.

Activarlo

En Settings → Workflow:

• Marca Require approval before editors can publish.
• Opcionalmente, define un review notification email : la dirección que recibe una nota cada vez que algo se envía (con el nombre de quien lo envía, el título y un enlace directo de edición).

Los admins están exentos por definición: siempre publican como ellos mismos.

La vida de una página o post en revisión

1. El editor escribe. Cada elemento comienza como borrador con el editor y la vista previa de siempre.
2. Enviar para revisión. Cuando un editor hace clic en Publish (con la aprobación requerida): o pulsa el botón Submit for Review: el elemento pasa a Pending review. Todavía no está vivo en el site, y el mensaje flash dice exactamente qué pasó: “Your changes have been submitted for admin review before publishing.” Cualquier elemento rechazado previamente puede reenviarse después de las ediciones.
3. El admin decide. En la pantalla de edición, el admin ve los botones Approve y Reject (mostrados solo donde aplican):
   • Approve publica el elemento de verdad: la insignia de revisión se pone verde (Approved), el contenido sale a la luz y el site se reconstruye automáticamente. Para los posts, se estampa una fecha de primera publicación en el momento de la aprobación. Un schedule futuro obsoleto adjunto al elemento se limpia para que no quede ahí después.
   • Reject devuelve el elemento al autor como Returned, con una razón opcional. Permanece sin publicar y aparece en la pantalla de edición del autor como rechazado, listo para revisarse y reenviarse.
4. Todos se enteran. El creador recibe un correo en cualquier caso : “aprobado” o “devuelto para revisión” con la razón: siempre que su cuenta tenga una dirección de correo (manejado por la configuración SMTP de la opción de notificaciones). Cada envío/aprobación/rechazo se registra en el audit log con quién, qué y qué elemento.

Lo que experimentan los editores

• No hay nada que instalar: el botón Publish mismo se convierte en “enviar para revisión” : el editor ve la confirmación del envío de inmediato.
• El “publicar ahora” editorial desde el calendario o una publicación masiva se comporta igual (envío a revisión): los editores nunca burlan la compuerta.
• Las operaciones masivas respetan la regla también: seleccionar varias páginas y hacer clic en publicar envía cada página pendiente/rechazada a revisión (y los admins siguen publicando directamente).
• La caja de Status del editor muestra el chip del workflow junto a la insignia live/draft: Draft · Pending review · Approved · Returned : así, de un vistazo, sabes dónde está cada elemento.
• La protección de “ya en revisión pendiente”: un elemento no puede enviarse dos veces; los admins aprueban una vez y la insignia se estabiliza. Reenviar desde un elemento rechazado, claro está, está permitido después de las ediciones.

Lo que reciben los revisores

• El enlace directo de edición en el correo de envío : clic para abrir el elemento.
• Los controles habituales de Preview (historial, borradores) aplican antes de aprobar.
• Approve = salir a la luz: el botón publica y despacha la reconstrucción del site en una sola acción, así que “aprobado” significa que los lectores pueden verlo.
• Reject toma el título más una razón opcional (que se envía por correo y se registra) y devuelve el elemento.

Quién revisa a quién

• Los admins lo revisan todo: hay una sola capa de decisión (sin roles intermedios de revisor).
• Los elementos en revisión no se arman en la cola de otra persona: cualquier admin ve el elemento pendiente en las listas normales de páginas/posts y en el calendario de contenido, así que “¿quién espera?” lo responden las pantallas estándar de contenido, no un dashboard aparte.
• Schedules: un editor que envía un elemento que tenía fecha de publicación futura mantiene ese plan intacto: pero si un Approve llega después de la hora de publicación programada ha sido limpiada durante la revisión, la aprobación publica inmediatamente (el código limpia cualquier schedule obsoleto para que la aprobación no adjunte una hora futura sorpresiva).

La letra pequeña

• El interruptor aplica a páginas y posts; los bloques, snippets y otros estructurales tienen sus propias reglas de publicación (son menos visibles en la cara del site). Las versiones de documentos tienen un pipeline de revisión separado e independiente en el módulo Documents.
• El workflow protege contra la publicación accidental o no autorizada, no contra la censura: los admins mantienen la capacidad completa de publicar directamente, y cada decisión se registra en el audit log de cualquier manera.
• Los correos de notificación al revisor son opcionales; el workflow funciona sin ellos (el admin ve los elementos pendientes en las listas; “submitted for review” aparece en el audit log).
• Si apruebas una página que se envió mientras todavía había una fecha de publicación futura fijada, la publicación ocurre en el momento de la aprobación : la fecha futura se limpia en lugar de quedarse ahí.

La versión corta

Flipea el interruptor, y “publicar” para los editores se convierte en “enviar para revisión”: los admins aprueban (publicar + rebuild en un paso) o rechazan con una nota, el audit log registra ambas direcciones, y nadie tiene que confiar solo en las buenas intenciones.