Revisions y revisión

Chinaski conserva el historial editorial en tres capas: borradores autoguardados para la persona que escribe, instantáneas completas de cada versión guardada de un elemento, y un flujo de aprobación que mueve los borradores por la revisión. Esta página explica cada capa y el ciclo de "devolver para revisión" que cierra el círculo.

Respuestas rápidas

• ¿Qué pasa cuando guardo? Se captura una instantánea completa de la página, post o documento antes de que tu cambio se escriba: el historial está siempre al menos un paso detrás de tu edición actual.
• ¿Mientras sigo escribiendo? Tu edición en progreso se autoguarda como un borrador por usuario, mantenido por separado del contenido guardado y de los borradores de otros usuarios. Descartarlo restaura la versión guardada.
• ¿Qué pasa cuando una revisión es "devuelta"? El elemento pendiente vuelve al editor con una razón opcional (registrada y enviada por correo), y puede revisarlo y reenviarlo.

Revisions

Cada página, post y documento mantiene su propia trayectoria de revisiones:

• Vista de lista: más nuevas primero, con un resumen a nivel de campo y un marcador de qué campos cambiaron respecto a la siguiente revisión. Cuando la lista excede el límite visible, la lista lo dice.
• Diffs: compara cualquier revisión contra el contenido vivo actual, o dos revisiones entre sí.
• Restore: las páginas y los posts pueden revertirse a cualquier revisión seleccionada; la restauración en sí se audita.

Cada entidad conserva un historial acotado (se conservan las entradas más nuevas por elemento; las muy antiguas se descartan), así que el historial no puede crecer sin límite.

Borradores (autoguardado)

Mientras editas, tu formulario se autoguarda como un borrador que te pertenece: una clave de borrador combina tu ID de usuario con el elemento, así que dos editores trabajando en la misma página tienen cada uno su propio estado de autoguardado y no pueden sobrescribir las pulsaciones de botón sin terminar del otro. Puedes descartar tu borrador explícitamente; también nunca sobrescribe automáticamente la página comprometida.

El flujo de revisión

Cuando Require approval (Settings → Workflow) está activado, el contenido de los no-administradores pasa por un ciclo de revisión con cuatro estados:

Draft → Pending review → Approved (publicado)

con Rejected como el estado de retorno del ciclo.

• Submit for review: un editor envía el elemento hacia arriba; pasa a pending review (esto también es lo que ocurre automáticamente cuando la aprobación está activada y un editor pulsa "publish"). El correo de notificación de revisión configurado recibe un mensaje con el título, el nombre del remitente y un enlace directo para revisarlo.
• Approve: un administrador aprueba: el elemento se publica de inmediato y se despacha un build; cualquier fecha de programación futura sobrante se limpia para que la página aprobada realmente salga al aire. El creador del contenido recibe un correo de aprobación si su cuenta tiene una dirección, y la notificación se audita.
• Reject (devolver para revisión): un administrador rechaza con una razón opcional. El elemento vuelve a su editor con un estado "rejected", la razón se registra en el audit log, y se envía un correo al creador. Puede entonces editarlo y enviarlo de nuevo.
• Un elemento rechazado o en borrador puede reenviarse cualquier cantidad de veces; las re-aprobaciones son todas decisiones frescas.

Dos cosas que saber en la práctica

• Las notificaciones por correo necesitan SMTP (Settings → Email) y se omiten por completo en modo air-gap: el flujo sigue funcionando; lo que falta es la entrega de los mensajes. Todo lo demás (estados, entradas de auditoría, confirmaciones flash) sigue funcionando.
• La aprobación publica y reconstruye. Aprobar no es un sello de goma sobre un estado de borrador previo: cambia el elemento a publicado y dispara el build del site para ese contenido.

Reutilización de revisiones en todas partes

Otros tipos de contenido reutilizan la misma maquinaria: los blocks y los stacks mantienen sus propias trayectorias de revisiones con la misma interfaz de diff-y-restore, los elementos de medios toman una instantánea en cada guardado, y cada acción de restauración se audita con el nombre del actor.