Workflow d'alertes configurable du backlog

⚠️ OBSOLÈTE (2026-07-23) — Le module « Alertes » V1 a été supprimé (table project_backlog_alert_rule droppée, UI et moteur retirés). Il est entièrement remplacé par le builder de workflow V2 : voir backlog-workflow-builder. Ce document est conservé pour l'historique uniquement.

Doc fonctionnelle : décrit le quoi et le pourquoi (point de vue utilisateur / chef de projet).

À quoi ça sert

Le backlog d'un projet évolue sans notification : pour savoir qu'un item a changé de statut ou a été assigné, il fallait surveiller le kanban ou relayer l'info à la main sur Teams. Cette fonctionnalité permet à chaque projet de définir ses propres règles d'alertes — façon « automation » Jira — qui poussent une notification dans la cloche in-app quand un événement précis se produit sur un item.

Comment ça marche (côté utilisateur)

Un sous-onglet « Alertes » est disponible dans l'onglet Backlog de chaque projet (à côté de « Statistiques »). Il liste les règles du projet et permet d'en créer, éditer, activer/désactiver ou supprimer.

Une règle se lit : QUAND [événement] SI [statut cible optionnel] ALORS notifier [cible(s)].

• Événement déclencheur (au choix) :
  • Changement de statut — l'item passe d'un statut à un autre (ex. vers « Bloqué ») ;
  • Assignation — la liste des personnes assignées à l'item change.
• Statut cible (uniquement pour l'événement « changement de statut », optionnel) : restreint la règle à une transition précise (ex. déclencher seulement quand l'item passe en « Bloqué »). Laissé vide, la règle se déclenche sur tout changement de statut.
• Cibles à notifier (au moins une) :
  • L'assigné de l'item — cible dynamique, résolue au moment du déclenchement (supporte les multi-assignés) ;
  • et/ou une sélection d'utilisateurs parmi les membres du projet.
• Actif : une règle peut être désactivée sans être supprimée (bascule dans la liste).

Quand une règle se déclenche, chaque destinataire reçoit une notification dans la cloche (« L'item "…" est passé en Bloqué », « L'item "…" vous a été assigné ») avec un lien vers l'item.

Anti-spam : la personne qui réalise l'action ne reçoit jamais la notification qu'elle a elle-même provoquée — même si elle figure dans les destinataires explicites.

Règles d'accès

• Module projet requis (hardEnsureHasModule:projet).
• Consultation de l'onglet : droit de lecture du projet (manageAccessRights('R', …, 16000101)).
• Création / édition / activation / suppression des règles : réservées aux utilisateurs pouvant modifier le projet (canUpdateProject). Sans ce droit, la liste reste consultable en lecture seule.

Points d'attention

• Modifications de masse non couvertes (V1) : un changement appliqué en lot (ex. changement de sprint en masse sur plusieurs items) ne déclenche pas de règle. Seules les actions unitaires (kanban, formulaire d'édition) sont prises en compte.
• Assignation à la création non couverte (V1) : assigner quelqu'un au moment de créer un item ne déclenche pas d'alerte. Seules les (ré)assignations ultérieures notifient.
• Hors périmètre V1 (repoussé) : multi-canal (mail / Teams), préférences de notification par utilisateur, moteur de conditions complexe (ET/OU), déclencheurs « item créé », « priorité changée », « échéance dépassée ».

Voir aussi

• Doc technique : ../../.claude/technical-docs/projects/backlog-alert-workflow.md