Contexte : Actuellement, le journal des modifications enregistre l’ensemble des modifications apportées aux objets métiers de manière séquentielle, en y associant l’identifiant de l’utilisateur technique ou applicatif à l’origine de l’action.
Besoin : Dans le cadre de l’audit des données et du suivi de l’activité, il devient crucial de pouvoir identifier le mode d’exécution d’une modification utilisateur. Nous souhaitons pouvoir dissocier visuellement et fonctionnellement, au sein du journal des modifications :
Les modifications unitaires effectuées directement par un utilisateur depuis l’interface (IHM, formulaire).
Les modifications unitaires réalisées via des actions de masse.
Évolution demandée :
Ajout d’un tag de contexte : Introduire un champ ou un attribut de contexte (exemple : type de modification ou contexte d’exécution) dans la table de log des modifications.
Filtrage dans l’IHM : Permettre de filtrer l’historique d’un objet selon ce critère (unitaire vs masse) pour faciliter les analyses de régression ou les audits de données.
Bonne idée, ça permettrait aussi de grouper visuellement les mises à jour d’un même “lot” de traitement.
Une action de masse est un abus de langage, ce n’est pas un ‘update’ en masse, c’est un groupement de mises à jour unitaires via la couche logique des objets (usage des hooks…).
On parle de tache cron ? d’import des fichiers ? de mise à jour en masse d’un objet via la UI ?
A court terme sans évolution, le plus simple est de lancer les traitements de masse avec un utilisateur/login dédié au suivi demandé. Il sera alors très simple de filtrer sur chaque login et sur la date de traitement.
A moyen terme, l’évolution consistera à ajouter un champ “origine” : UI / API / Import, voir le nom du batch lui-même.
Bonjour François,
Notre besoin concerne la modification en masse d’un objet depuis l’interface utilisateur. Est-ce que tu peux ajouter ce point à la roadmap ?