Workflow d'approbation

Quand l'édition est une activité d'équipe, la publication devrait inclure un second regard. Le workflow d'approbation de Chinaski (désactivé par défaut, activé dans Settings → Workflow) oblige les éditeurs à soumettre leur travail pour relecture au lieu de publier directement ; un admin l'approuve, ce qui le publie en ligne, ou le renvoie avec une note. Cette page explique le cycle de relecture pour les pages et les posts.

L'activer

Sous Settings → Workflow :

• Cochez Require approval before editors can publish.
• Définissez éventuellement un review notification email : l'adresse qui reçoit une note à chaque soumission (avec le nom du soumetteur, le titre et un lien d'édition direct).

Les admins sont exemptés par définition : ils publient toujours en leur nom propre.

La vie d'une page ou d'un post en relecture

1. L'éditeur écrit. Chaque élément commence comme brouillon avec l'éditeur et l'aperçu habituels.
2. Soumission pour relecture. Quand un éditeur clique sur Publish (avec approbation requise), ou appuie sur le bouton Submit for Review, l'élément passe en Pending review. Il n'est pas encore en ligne sur le site, et le message flash dit exactement ce qui s'est passé : « Your changes have been submitted for admin review before publishing. » Tout élément précédemment rejeté peut être resoumis après modifications.
3. L'admin décide. Sur l'écran d'édition, l'admin voit les boutons Approve et Reject (affichés uniquement là où ils s'appliquent) :
   • Approve publie réellement l'élément : le badge de relecture passe au vert (Approved), le contenu passe en ligne, et le site est reconstruit automatiquement. Pour les posts, une date de première publication est estampillée au moment de l'approbation. Un éventuel calendrier future périmé attaché à l'élément est effacé pour qu'il ne subsiste pas ensuite.
   • Reject renvoie l'élément à l'auteur en Returned, avec un motif facultatif. Il reste non publié et apparaît sur l'écran d'édition de l'auteur comme rejeté, prêt à être révisé et resoumis.
4. Tout le monde est prévenu. Le créateur reçoit un e-mail dans les deux cas (« approuvé » ou « renvoyé pour révision » avec le motif), pourvu que son compte ait une adresse e-mail (géré par la configuration SMTP du paramètre de notification). Chaque soumission/approbation/rejet est consigné dans le journal d'audit avec qui, quoi et quel élément.

Ce que vivent les éditeurs

• Rien à installer : le bouton Publish lui-même devient « soumettre pour relecture » ; l'éditeur voit immédiatement la confirmation de soumission.
• La publication immédiate éditoriale depuis le calendrier ou une publication en masse se comporte de la même façon (soumission pour relecture) ; les éditeurs ne contournent jamais le verrou.
• Les opérations en masse respectent la règle aussi : sélectionner plusieurs pages et cliquer sur publier soumet chaque page en attente/rejetée pour relecture (et les admins, eux, publient toujours directement).
• La boîte Statut de l'éditeur affiche la puce de workflow à côté du badge live/draft : Draft · Pending review · Approved · Returned ; d'un coup d'œil, on sait où en est un élément.
• La protection « déjà en attente de relecture » : un élément ne peut pas être soumis deux fois ; les admins approuvent une fois et le badge se stabilise. La resoumission depuis un élément rejeté est bien sûr permise après modifications.

Ce que reçoivent les relecteurs

• Le lien d'édition direct dans l'e-mail de soumission : un clic ouvre l'élément.
• Les contrôles d'aperçu habituels (historique, brouillons) s'appliquent avant l'approbation.
• Approve = mise en ligne : le bouton publie et déclenche la reconstruction du site en une seule action, donc « approuvé » signifie que les lecteurs peuvent le voir.
• Reject prend le titre plus un motif facultatif (qui est envoyé par e-mail et consigné) et rend l'élément à son auteur.

Qui relit qui

• Les admins relisent tout : il y a une seule couche de décision (pas de rôles de relecteur intermédiaires).
• Les éléments en relecture ne sont pas rangés dans la file de quelqu'un d'autre : tout admin voit l'élément en attente dans les listes normales de pages/posts et dans le calendrier de contenu, donc la question « qui attend ? » trouve sa réponse sur les écrans de contenu standards, pas sur un tableau de bord séparé.
• Planifications : un éditeur qui soumet un élément qui avait une date de publication future conserve ce plan intact, mais si une approbation arrive après que l'heure de publication planifiée a été effacée pendant la relecture, l'approbation publie immédiatement (le code efface tout calendrier périmé pour que l'approbation n'attache pas une date future surprise).

Les petites lignes

• L'interrupteur s'applique aux pages et posts ; les blocks, snippets et autres éléments structurels ont leurs propres règles de publication (ils sont moins visibles à la surface du site). Les versions de documents ont un pipeline de relecture séparé et indépendant dans le module Documents.
• Le workflow protège contre la publication accidentelle ou non autorisée, pas contre la censure : les admins conservent la pleine capacité de publication directe, et chaque décision est consignée dans le journal d'audit dans les deux cas.
• Les e-mails de notification des relecteurs sont facultatifs ; le workflow fonctionne sans eux (l'admin voit les éléments en attente dans les listes ; « soumis pour relecture » apparaît dans le journal d'audit).
• Si vous approuvez une page qui a été soumise alors qu'une date de publication future était encore définie, la publication se produit à l'approbation ; la date future est effacée plutôt que laissée derrière elle.

La version courte

Activez l'interrupteur, et « publier » devient pour les éditeurs « soumettre pour relecture » : les admins approuvent (publication + reconstruction en une étape) ou rejettent avec une note, le journal d'audit enregistre les deux sens, et personne n'a à se fier uniquement aux bonnes intentions.