Révisions & relecture

Chinaski conserve l'historique éditorial en trois couches : les brouillons autosauvegardés pour la personne qui tape, les instantanés complets pour chaque version enregistrée d'un élément, et un flux d'approbation qui fait passer les brouillons par la relecture. Cette page explique chaque couche et le cycle « retour pour révision » qui boucle la boucle.

Réponses rapides

Que se passe-t-il quand j'enregistre ? Un instantané complet de la page, du post ou du document est capturé avant que votre modification ne soit écrite ; l'historique est toujours au moins un cran derrière votre édition en cours.
Pendant que je tape encore ? Votre édition en cours s'autosauvegarde comme un brouillon par utilisateur, conservé séparément du contenu enregistré et des brouillons des autres utilisateurs. L'abandonner restaure la version enregistrée.
Que se passe-t-il quand une relecture est « retournée » ? L'élément en attente repart vers l'éditeur avec une raison optionnelle (consignée et envoyée par e-mail), et il peut réviser et soumettre à nouveau.

Révisions

Chaque page, post et document conserve sa propre piste de révisions :

Vue en liste: du plus récent au plus ancien, avec un résumé au niveau des champs et un marqueur indiquant quels champs ont changé par rapport à la révision suivante. Lorsque la liste dépasse le plafond visible, la liste le dit.
Diffs: comparer n'importe quelle révision au contenu en ligne actuel, ou deux révisions entre elles.
Restauration: pages et posts peuvent être ramenés à n'importe quelle révision sélectionnée ; la restauration elle-même est auditée.

Chaque entité conserve un historique borné (les entrées les plus récentes par élément sont gardées ; les très anciennes sortent), de sorte que l'historique ne peut pas croître sans limite.

Brouillons (autosauvegarde)

Pendant que vous éditez, votre formulaire s'autosauvegarde comme un brouillon qui vous appartient : une clé de brouillon combine votre ID utilisateur avec l'élément, de sorte que deux éditeurs travaillant sur la même page aient chacun leur propre état d'autosauvegarde et ne puissent pas écraser les saisies inachevées de l'autre. Vous pouvez abandonner votre brouillon explicitement ; il ne surcharge jamais non plus automatiquement la page validée.

Le flux de relecture

Lorsque Require approval (Settings → Workflow) est activé, le contenu des non-admins passe par un cycle de relecture à quatre états : Brouillon → En attente de relecture → Approuvé (publié) avec Rejeté comme état de rebouclage.

Soumettre pour relecture: un éditeur fait monter l'élément ; il passe en attente de relecture (c'est aussi ce qui arrive automatiquement lorsque l'approbation est activée et qu'un éditeur clique sur « publish »). L'e-mail de notification de relecture configuré reçoit un message avec le titre, le nom du soumetteur et un lien direct pour le relire.
Approuver: un admin approuve : l'élément est immédiatement publié et un build est déclenché ; toute date de programmation future résiduelle est effacée pour que la page approuvée passe réellement en ligne. Le créateur du contenu reçoit un e-mail d'approbation si son compte a une adresse, et la notification est auditée.
Rejeter (retour pour révision): un admin rejette avec une raison optionnelle. L'élément retourne à son éditeur avec un statut « rejeté », la raison est consignée dans l'audit log, et le créateur reçoit un e-mail. Il peut ensuite éditer et soumettre à nouveau.
Un élément rejeté ou en brouillon peut être soumis à nouveau autant de fois que nécessaire ; les ré-approbations sont toutes des décisions fraîches.

Deux choses à savoir en pratique

Les notifications par e-mail nécessitent SMTP (Settings → Email) et sont entièrement ignorées en mode air-gap : le flux fonctionne toujours ; c'est la livraison des messages qui manque. Tout le reste (statuts, entrées d'audit, confirmations flash) fonctionne toujours.
L'approbation publie et reconstruit. Approuver n'est pas un tampon encreur sur un état de brouillon précédent : cela bascule l'élément en publié et déclenche le build du site pour ce contenu.

Réutilisation des révisions partout

Les autres types de contenu réutilisent la même mécanique : les blocks et les stacks gardent leurs propres pistes de révisions avec la même interface de diff-et-restauration, les éléments de média font un instantané à chaque enregistrement, et chaque action de restauration est auditée avec le nom de son auteur.