Skip to content

Exposer POST /routes/:id/reports pour signaler un parcours #437

Closed

Description

@PaulThiberville

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 : reason parmi les motifs utilisateur (userRouteReportReasons, sans low_rating) ; stepId attendu pour place_changed et appartenant au parcours ; comment en texte brut (plainText), 80 caractères, obligatoire pour other.
  • Un signalement par utilisateur et par parcours sur 7 jours glissants : 409 avec reportedAt sinon.
  • 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_reports au statut open et 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_changed sans étape, ou avec une étape d'un autre parcours, renvoie 422 validation_error ; other sans 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é)
  • route_reported est émis avec route_id, reason, step_index : é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-21
  • 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).

Activity

  1. added this to the v0.5 milestone on Oct 14, 2026
  2. Nascimento95 commented on Oct 21, 2026

    @Nascimento95
    Collaborator

    🔨 Démarrage (CODE, 2026-10-21) — branche issue/437-route-reports, depuis main (506e287), base main, sans empilement, niveau 2 annoncé (nouveau endpoint authentifié qui écrit, entrée non fiable ; pas de migration : route_reports et createRouteReport existent, #184).

    Plan : (1) shared : corps strict { reason, stepId?, comment? } avec les règles croisées de reports.ts (étape pour place_changed seulement, commentaire de 80 caractères pour place_changed et other, obligatoire pour other, jamais low_rating) et accusé du signalement ; (2) api : POST /routes/:id/reports (authentifié, jamais en cache) qui répond 201, 409 conflict avec reportedAt sous 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_changed sans étape … renvoie 400 » : la convention de l'API (D-071) répond 422 validation_error à un corps invalide, 400 à une query ou des params invalides. Je suis la convention ; les cas du ticket renvoient donc 422.
    • « route_reported est émis avec route_id, reason, step_index » : l'API n'émet aucun événement PostHog aujourd'hui (aucun client PostHog serveur) et Analytics ne range pas route_reported parmi 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.
  3. Nascimento95 commented on Oct 21, 2026

    @Nascimento95
    Collaborator

    PR ouverte : #592 (CODE, 2026-10-21), base main, sans empilement, niveau 2 (label level:2).

    POST /v1/routes/:id/reports : 201 avec le signalement ouvert, 409 avec reportedAt sous 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 sur createRouteReport (#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_reported est é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 parcours needs_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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions