Repository navigation
Exposer POST /routes/:id/reports pour signaler un parcours #437
Copy link
Copy link
Closed
Labels
area:apiapps/apiapps/apiprio:P1HauteHautestatus:readySpec complète, prêt à coderSpec complète, prêt à codertype:featureNouvelle fonctionnalitéNouvelle fonctionnalité
Milestone
Description
Contexte
Epic : #15
API › Lieux (POST /routes/:id/reports) · Creation-et-Moderation › Vérification communautaire · Modele-de-Donnees › route_reports · Analytics (route_reported) · E-05 · D-056 · D-057
Maquette : sans objet — route d'API ; l'écran (E-05, « Signaler ce parcours ») est porté par #50
Découverte de CODE pendant #184 (PR #432, Inbox, 2026-10-14) : la route n'a pas de ticket. #50 en est le côté mobile, #54 l'admin, #36 myReport. La PR #432 fournit createRouteReport (règle des 7 jours, 409 avec reportedAt, étape du parcours) et runningRouteReport.
Comportement attendu
POST /routes/:id/reports, authentifié, corps{ reason, stepId?, comment? }validé par Zod :reasonparmi les motifs utilisateur (userRouteReportReasons, sanslow_rating) ;stepIdattendu pourplace_changedet appartenant au parcours ;commenten texte brut (plainText), 80 caractères, obligatoire pourother.- Un signalement par utilisateur et par parcours sur 7 jours glissants : 409 avec
reportedAtsinon. - 403 sur ses propres parcours ; 404 sur un parcours non publié ou inconnu.
- Événement
route_reported(route_id,reason,step_index) : émis par l'app, avec Afficher et saisir la vérification des lieux dans la fiche et le parcours en cours #50. - Réponse : le signalement créé (sans donnée du signaleur au-delà de ce que le wiki expose).
Critères d'acceptation
- Un signalement valide crée une ligne
route_reportsau statutopenet renvoie 201 - Un second signalement du même utilisateur sous 7 jours renvoie 409 avec
reportedAt - Signaler son propre parcours renvoie 403 ; un parcours non publié renvoie 404
-
place_changedsans étape, ou avec une étape d'un autre parcours, renvoie 422validation_error;othersans commentaire renvoie 422 (corps invalide : 422, D-071 ; corrigé par MANAGER le 2026-10-21, la PR feat(api): signaler un parcours en ligne (POST /routes/:id/reports) #592 l'avait relevé) : événement de l'app (l'API n'émet aucun événement PostHog, Analytics ne le range pas parmi les événements serveur) ; déplacé dans Afficher et saisir la vérification des lieux dans la fiche et le parcours en cours #50 par MANAGER le 2026-10-21route_reportedest émis avecroute_id,reason,step_index- Tests d'intégration de la route
Notes techniques
Revue OWASP attendue (nouveau endpoint authentifié, entrée non fiable) : niveau 2 probable. L'envoi différé hors connexion est côté app (#50).
Metadata
Metadata
Assignees
Labels
area:apiapps/apiapps/apiprio:P1HauteHautestatus:readySpec complète, prêt à coderSpec complète, prêt à codertype:featureNouvelle fonctionnalitéNouvelle fonctionnalité
Activity
Nascimento95 commentedon Oct 21, 2026
🔨 Démarrage (CODE, 2026-10-21) — branche
issue/437-route-reports, depuismain(506e287), basemain, sans empilement, niveau 2 annoncé (nouveau endpoint authentifié qui écrit, entrée non fiable ; pas de migration :route_reportsetcreateRouteReportexistent, #184).Plan : (1)
shared: corps strict{ reason, stepId?, comment? }avec les règles croisées dereports.ts(étape pourplace_changedseulement, commentaire de 80 caractères pourplace_changedetother, obligatoire pourother, jamaislow_rating) et accusé du signalement ; (2)api:POST /routes/:id/reports(authentifié, jamais en cache) qui répond 201, 409conflictavecreportedAtsous 7 jours, 403 sur son propre parcours, 404 sur un parcours non publié ou inconnu ; tests d'intégration.Deux critères que je ne tiendrai pas à la lettre, pour que MANAGER les voie dès le début :
place_changedsans étape … renvoie 400 » : la convention de l'API (D-071) répond 422validation_errorà un corps invalide, 400 à une query ou des params invalides. Je suis la convention ; les cas du ticket renvoient donc 422.route_reportedest émis avecroute_id,reason,step_index» : l'API n'émet aucun événement PostHog aujourd'hui (aucun client PostHog serveur) et Analytics ne range pasroute_reportedparmi les événements « (serveur) » ; le ticket dit lui-même que l'envoi hors connexion est côté app (Afficher et saisir la vérification des lieux dans la fiche et le parcours en cours #50). Cet événement est celui de l'app : je ne l'émets pas depuis l'API et je le dis dans la PR.Nascimento95 commentedon Oct 21, 2026
PR ouverte : #592 (CODE, 2026-10-21), base
main, sans empilement, niveau 2 (labellevel:2).POST /v1/routes/:id/reports: 201 avec le signalement ouvert, 409 avecreportedAtsous 7 jours, 403 sur son propre parcours, 404 pour un parcours non en ligne ou inconnu, 401 sans jeton, 422 pour un corps invalide. Elle repose surcreateRouteReport(#432). Pas de migration.Critères non tenus à la lettre (détail dans la PR) : (1) « 400 » pour l'étape ou le commentaire manquant : la convention D-071 répond 422 à un corps invalide ; (2) «
route_reportedest émis » : l'API n'émet aucun événement PostHog et le ticket place l'envoi côté app (#50), l'événement n'est donc pas émis ici ; (3) un parcoursneeds_fix, toujours en ligne, reste signalable.Vérification humaine : aucune. Marco n'a pas rejoué les requêtes à la main (décision du 2026-10-21) ; l'agent a relevé les réponses des mêmes requêtes contre l'API locale (201, 409, 403, 404 et trois 422) et s'appuie sur les 13 tests d'intégration.