Garder un historique des actions prises sur un arrêté

[florimondmanca]

User story

ETQ responsable de DiaLog, je peux mener une investigation si un utilisateur me pose une question relative aux modifications apportées à un arrêté, notamment en cas de situation suspecte / inattendue

Exemples :

• Cet arrêté a disparu, qui l'a supprimé ?
• Cet arrêté n'existe pas en réalité, qui l'a créé ?
• Cet arrêté est publié mais il n'a pas encore été validé en interne, qui l'a publié ?

Critères d'acceptation

Design

Implémentation

Utiliser une table comme ceci

RegulationOrderHistory
uuid (pk)
regulation_order_uuid (i)
user_uuid (i)
action ('create', 'update', 'publish', 'delete')
date

(i) = index à créer explicitement (Doctrine ne le fera pas de lui-même)

Cliquer pour voir l'ancienne discussion

Approche générale

Plusieurs options

1. "Sur étagère" : recourir à un bundle "tout fait" tel que EntityAuditBundle

Avantages

• La solution existe déjà, on peut trouver de l'aide en ligne

Inconvénients

• EntityAuditBundle stocke une copie de tous les champs d'une entité à chaque modification => génère énormément de données inutiles => pas écoconçu
• Moins de contrôle sur ce qui est stocké, moins de personnalisation (ou personnalisation plus complexe)
• Rajoute une dépendance => problématiques de mise à jour, obsolescence, compatibilité avec les futures versions de Doctrine / Symfony, beaucoup de code inutile pour notre besoin...

2. "Fait maison" Implémenter nous-mêmes une solution simple taillée pour notre besoin

Avantages

• On fait et stocke exactement ce qu'on veut, ni plus ni moins

Inconvénients

• Nécessite un travail de conception (objet de ce ticket)

Recommandation : option 2 ?

Approche de stockage

@Lealefoulon a proposé dans #1147 la table suivante

RegulationOrderHistory
uuid (pk)
regulation_order_uuid (fk, CASCADE)
user_uuid (fk, CASCADE)
action ('create', 'update', 'delete')
date

pk = primary key (clé primaire), fk = foreign key (clé étrangère)

Problème

• si l'arrêté ou l'utilisateur sont supprimés, que se passe-t-il ?
• Un on-delete="CASCADE" supprimerait tout l'historique, mais on veut le garder.
• Mais un on-delete="SET NULL" ferait perdre les UUID, alors qu'on en aurait besoin pour mener l'enquête dans des sauvegardes de la DB

Option 1 : stockage JSON

Proposé par @florimondmanca en MP, à challenger avec @mmarchois :

RegulationOrderHistory
uuid (pk)
regulation_order_uuid (fk, SET NULL)
user_uuid (fk, SET NULL)
action ('create', 'publish', 'delete')
date
data (json)

À noter 'update' qui devient 'publish'. A-t-on envie de stocker la date de toutes les modifications (pas très utile sans savoir ce qui a été modifié précisément?), ou pour l'instant seulement quand ça a été publié et par qui ?

La colonne data permet d'ajouter des infos non-structurées en JSON, qu'on peut faire évoluer au fil du temps sans devoir se poser la question des migrations

On y stockerait par exemple :

• Copie du regulation_order_uuid
• Copie du user_uuid

Pour le requêtage, on pourra faire ça

SELECT * FROM regulation_order_history
WHERE data->>'regulation_order_uuid' = '0ea76af7-c1dd-4207-9ed9-a7121261b5e9';

Mais ça pose la question de si au final on a besoin de la colonne regulation_order_uuid. Ce qui transformerait RegulationOrderHistory en une table très générique, finalement...

Option 2 : pas de FK

Autre possibilité : ne pas créer de FK, et traiter regulation_order_uuid et user_uuid comme des champs texte... (Donc en PHP, on donnerait explicitement les UUIDs et pas les entités RegulationOrder ou User)

Contexte supplémentaire

• Relatif à cette carte dans la roadmap : Traçabilité des modifications sur un arrêté dialog-roadmap#50

[florimondmanca]

@mmarchois J'ai créé ce ticket à partir de discussions qu'on a eu avec Léa en MP cet aprem, elle m'a demandé de l'aide sur le traitement du problème de cascade...

Que penses-tu de l'approche présentée ? On pourra en discuter post-daily

[florimondmanca]

@Lealefoulon J'ai màj la description du ticket avec l'option discutée aujourd'hui