Replies: 3 comments 1 reply
-
|
Afin d'apporter du concret, voici ce qui doit être mis en place pour gérer les pages infos :
On retrouve du coup le découpage entre l'édition avec des tables relationnelles avec du contenu que l'on peut modifier sans impacter la prod et la publication avec la table document. Ici on n'a pas d'impacte sur la publication, le code actuel continuera de fonctionner comme avant. On a déjà ce principe présent sur les contributions et les modèles de courrier. |
Beta Was this translation helpful? Give feedback.
-
|
Pour la nouvelle version des contributions, l'idée est la même car l'on a déjà la table séparée où l'on peut éditer les contributions sans impacter la prod. L'idée est de réaliser l'étape 4 ci dessus qui va s'occuper de venir mettre à jour le json de la contribution dans la table |
Beta Was this translation helpful? Give feedback.
-
|
Yes ! |
Beta Was this translation helpful? Give feedback.
-
|
Prochaine étape : passer le modèle de courrier 😎 |
Beta Was this translation helpful? Give feedback.
-
Le métier a remonté le besoin de modifier du contenu mais de ne pas le publier de suite.
Par exemple :
Dans ces cas là, soit on dépublie le contenu, on le modifie puis au moment venu on va le publier à nouveau (cela demande à ce que le contenu ne soit plus disponible pendant cette période). Soit on modifie mais on ne publie plus sur la prod (cela demande un freeze de la mise à jour des données en prod). Soit on modifie dans un fichier à part et le jour j, on vient reporter les modifications dans l'admin.
Ces solutions ne sont pas idéales.
Avec l'arrivé de l'outil de contrib dans l'admin, une idée émerge (venu de Catherine). On a actuellement 3 grandes fonctionnalités dans l'administration : Alerting, Edition, Publication. La première est bien découpé et n'interfère pas sur le reste. Les deux suivantes (edition et publication) sont fortement liées. L'idée est de délier ces deux fonctionnalités pour avoir une partie édition et une partie publication.
La première étape consiste à décoreller en base de données, la partie édition et publication. Aujourd'hui, si j'édite une page information, je vais sauvegarder mes modifications directement dans la table
documentsqui gère également la publication. On va donc créer une table information qui va contenir les données d'édition. Lorsque l'édition est terminée (lu et appouvé), on va pouvoir mettre son contenu dans la tabledocuments. Cette dernière contiendra alors les contenus à jour et prêt pour la publication.Voici un schéma expliquant la logique :
Pour les contributions, c'est le même principe. Cela permet d'avoir toujours une version que l'on peut modifier sans bloquer la prod et une version valider en prod.
On retrouve en même temps l'idée d'avoir des tables consistantes pour chaque contenu sans devoir casser la logique actuelle de mise en prod de l'admin.
On retrouve aussi l'idée d'avoir la possibilité d'avoir une table de suivi des mises à jour en prod. En effet, à chaque fois qu'un document est mis à jour, on va pouvoir alimenter une table qui indique que ce document a été mis à jour avec le diff.
On aura ainsi ce découpage dans l'admin :
L'alerting contient : Code du travail, Convention collective, Fiches service-public et Fiches travail-emploi
L'édition : les pages infos, le glossaire, Blocs KALI, Fichers, Fiches SP
Publication : Contenus, Thèmes, Requêtes préqualifiés, Mise à jour
Beta Was this translation helpful? Give feedback.
All reactions