Problème / Contexte
Le système de ticketing est partiellement fonctionnel : la création de tickets côté utilisateur fonctionne, mais la page de détail d'un ticket (/tickets/:id) est cassée. Les données du ticket (titre, auteur, description…) ne s'affichent pas, et les actions principales sont inutilisables : impossible d'envoyer un message dans le ticket, de changer son statut, ou d'interagir avec. Cela rend le support utilisateur totalement inopérant côté admin et bloque le suivi des bugs remontés par les utilisateurs.
Solution proposée
Investiguer et corriger les dysfonctionnements de la page /tickets/:id afin de rétablir l'affichage complet des données du ticket et toutes les interactions associées (messagerie, changement de statut, etc.).
Critères d'acceptation
La page /tickets/:id affiche correctement toutes les informations du ticket : titre, description, auteur (nom + email), date de création, statut actuel, priorité
L'utilisateur/admin peut envoyer un message dans le fil de conversation du ticket
L'admin peut changer le statut du ticket (ex: open → in progress → resolved → closed)
Les messages envoyés apparaissent en temps réel ou après refresh sans erreur
Les changements de statut sont persistés en base et reflétés immédiatement dans l'UI
Aucune régression sur la création de ticket côté utilisateur
Tests couverts pour : le fetch et l'affichage des données du ticket, l'envoi de message, le changement de statut, les cas d'erreur (ticket inexistant, permissions insuffisantes)
Maquettes / Références
Se baser sur l'UI existante de la page /tickets/:id — pas de refonte visuelle, uniquement du fix fonctionnel
Impact estimé
Complexité: M
Pages concernées: /tickets/:id (détail ticket), API routes associées (GET ticket, POST message, PATCH status)
Notes techniques
Vérifier en priorité le fetch côté serveur/client sur /tickets/:id : est-ce que l'API renvoie bien les données ? Le problème peut venir du query (mauvais paramètre id, mauvaise relation incluse) ou du mapping côté front
Checker les relations en base : le ticket est-il bien lié à son auteur et ses messages ? (include/populate manquant côté ORM)
Vérifier les API routes pour l'envoi de message et le changement de statut : existent-elles ? Sont-elles correctement protégées et fonctionnelles ?
Tester les permissions : un problème d'auth middleware pourrait bloquer silencieusement les actions (403 non remonté au client)
Utiliser les DevTools réseau pour identifier rapidement si le problème est côté API (réponse vide/erreur) ou côté rendu (données reçues mais non affichées)
Si les routes API n'existent pas encore, les créer en suivant le pattern REST existant du projet
Problème / Contexte
Le système de ticketing est partiellement fonctionnel : la création de tickets côté utilisateur fonctionne, mais la page de détail d'un ticket (/tickets/:id) est cassée. Les données du ticket (titre, auteur, description…) ne s'affichent pas, et les actions principales sont inutilisables : impossible d'envoyer un message dans le ticket, de changer son statut, ou d'interagir avec. Cela rend le support utilisateur totalement inopérant côté admin et bloque le suivi des bugs remontés par les utilisateurs.
Solution proposée
Investiguer et corriger les dysfonctionnements de la page /tickets/:id afin de rétablir l'affichage complet des données du ticket et toutes les interactions associées (messagerie, changement de statut, etc.).
Critères d'acceptation
La page /tickets/:id affiche correctement toutes les informations du ticket : titre, description, auteur (nom + email), date de création, statut actuel, priorité
L'utilisateur/admin peut envoyer un message dans le fil de conversation du ticket
L'admin peut changer le statut du ticket (ex: open → in progress → resolved → closed)
Les messages envoyés apparaissent en temps réel ou après refresh sans erreur
Les changements de statut sont persistés en base et reflétés immédiatement dans l'UI
Aucune régression sur la création de ticket côté utilisateur
Tests couverts pour : le fetch et l'affichage des données du ticket, l'envoi de message, le changement de statut, les cas d'erreur (ticket inexistant, permissions insuffisantes)
Maquettes / Références
Se baser sur l'UI existante de la page /tickets/:id — pas de refonte visuelle, uniquement du fix fonctionnel
Impact estimé
Complexité: M
Pages concernées: /tickets/:id (détail ticket), API routes associées (GET ticket, POST message, PATCH status)
Notes techniques
Vérifier en priorité le fetch côté serveur/client sur /tickets/:id : est-ce que l'API renvoie bien les données ? Le problème peut venir du query (mauvais paramètre id, mauvaise relation incluse) ou du mapping côté front
Checker les relations en base : le ticket est-il bien lié à son auteur et ses messages ? (include/populate manquant côté ORM)
Vérifier les API routes pour l'envoi de message et le changement de statut : existent-elles ? Sont-elles correctement protégées et fonctionnelles ?
Tester les permissions : un problème d'auth middleware pourrait bloquer silencieusement les actions (403 non remonté au client)
Utiliser les DevTools réseau pour identifier rapidement si le problème est côté API (réponse vide/erreur) ou côté rendu (données reçues mais non affichées)
Si les routes API n'existent pas encore, les créer en suivant le pattern REST existant du projet