jmartin/petitspas
1
0
Fork 0
Code Issues 28 Pull Requests Actions Packages Projects Releases Wiki Activity

Reprise après refus – backend #111

New Issue
Closed
opened 2026-03-11 21:02:16 +00:00 by jmartin · 4 comments
jmartin commented 2026-03-11 21:02:16 +00:00
Owner
Copy Link
Copy Source

Objectif (alignement workflow produit)

Après refus par le gestionnaire (message + e-mail, cf. #110), le parent ou l'AM doit pouvoir reprendre son dossier soit via le lien dans le mail (token), soit depuis la page de connexion (saisie numéro de dossier + e-mail).

Une fois identifié·e, l'utilisateur entre dans le même parcours d'inscription (parent ou AM selon le rôle), déjà prérempli avec les données du dossier refusé, corrige ce qui doit l'être, valide jusqu'au bout, puis le dossier retombe en « à valider » (en_attente) pour le gestionnaire.

Périmètre backend (#111)

  1. Identification

    • Conserver / finaliser POST /auth/reprise-identify : numero_dossier + email → type (parent | assistante_maternelle) + token (lien perdu, entrée login).
    • Conserver GET /auth/reprise-dossier?token= : retourner un jeu de données suffisant pour préremplir tout le parcours d'inscription (équivalent métier à ce qui est collecté à la création : identité, coordonnées, pièces / consentements pertinents, enfants pour le parcours parent, champs AM pour le parcours AM, etc. — à cadrer avec les DTO d'inscription existants).

  2. Resoumission

    • La resoumission ne doit pas se limiter à une mise à jour « profil light » : exposer un flux cohérent avec le même contrat que la création initiale (ex. réutiliser / aligner les payloads register/parent et register/am en mode reprise, ou un endpoint dédié équivalent qui :
      • valide les mêmes règles que l'inscription ;
      • met à jour toutes les entités concernées ;
      • repasse le compte en en_attente ;
      • invalide token_reprise / token_reprise_expire_le.

  3. Cohérence données — numéro de dossier

    • Prérequis : pour reprise-identify, le numero_dossier doit être déjà connu côté dossier (affectation gestionnaire avant ou au refus, selon règle métier) ; sinon message d'erreur explicite côté API / spec.
    • Conservation : au-delà du workflow décrit, le numero_dossier est à conserver tel quel pendant toute la reprise — pas de nouvelle attribution, pas de modification par le parcours utilisateur ; c'est l'ancre stable du dossier refusé jusqu'à la nouvelle validation gestionnaire (y compris cohérence sur utilisateurs, parents, assistantes_maternelles si applicable).

  4. Sécurité / anti-énumération (optionnel mais souhaitable)

    • Réponses neutres si couple numéro + e-mail invalide ou dossier non en reprise (alignement possible avec les autres flux auth).

Hors périmètre

  • UI / routes Flutter : #112 (lien mail, modale login, redirection vers parcours parent ou AM prérempli).

Dépendances

  • #110 (refus + token + mail)
  • #103 / #104 (numéro de dossier : génération, format, affichage mails / listes si besoin pour la cohérence des messages)

Critères de done (backend)

  • GET reprise-dossier expose les données nécessaires au préremplissage complet du parcours parent ou AM (spec jointe aux DTO).
  • Resoumission = même niveau fonctionnel qu'une inscription complète (pas seulement nom / adresse / téléphone).
  • Après resoumission réussie : statut en_attente, token reprise consommé, dossier visible dans la file de vérification gestionnaire.
  • Le numero_dossier reste strictement inchangé sur tout le flux (chargement → corrections → resoumission) ; tests de non-régression.
  • reprise-identify + reprise-dossier + resoumission documentés (OpenAPI) et couverts par tests ciblés.

Issue mise à jour pour être alignée avec le workflow « refus → mail ou login (n° + e-mail) → parcours inscription prérempli → nouvelle validation gestionnaire ».

Note d'implémentation (architecture)

  • DTO distincts pour création vs reprise (éviter un seul DTO avec mode + nombreux ValidateIf), tout en réutilisant les sous-DTO imbriqués (enfants, co-parent, etc.) pour limiter le doublon.
  • Logique métier unique : les deux flux alimentent une même couche applicative du type applyParentDossier(dto, context) / équivalent AM, où context porte création vs reprise, le EntityManager transactionnel, identifiants existants, numero_dossier inchangé en reprise, invalidation token_reprise, etc.
  • Côté front : parcours identique, deux appels API (création vs reprise) selon le contexte (route / token) — détail dans #112.
## Objectif (alignement workflow produit) Après **refus** par le gestionnaire (message + e-mail, cf. **#110**), le parent ou l'AM doit pouvoir **reprendre son dossier** soit via le **lien dans le mail** (token), soit depuis la **page de connexion** (saisie **numéro de dossier + e-mail**). Une fois identifié·e, l'utilisateur **entre dans le même parcours d'inscription** (parent **ou** AM selon le rôle), **déjà prérempli** avec les données du dossier refusé, corrige ce qui doit l'être, **valide jusqu'au bout**, puis le dossier **retombe en « à valider »** (`en_attente`) pour le gestionnaire. ## Périmètre backend (#111) 1. **Identification** - Conserver / finaliser **`POST /auth/reprise-identify`** : `numero_dossier` + `email` → `type` (`parent` | `assistante_maternelle`) + `token` (lien perdu, entrée login). - Conserver **`GET /auth/reprise-dossier?token=`** : retourner un **jeu de données suffisant** pour **préremplir tout le parcours** d'inscription (équivalent métier à ce qui est collecté à la création : identité, coordonnées, pièces / consentements pertinents, **enfants** pour le parcours parent, champs **AM** pour le parcours AM, etc. — à cadrer avec les DTO d'inscription existants). 2. **Resoumission** - La **resoumission** ne doit pas se limiter à une mise à jour « profil light » : exposer un flux cohérent avec le **même contrat** que la création initiale (ex. réutiliser / aligner les payloads **`register/parent`** et **`register/am`** en mode reprise, ou un endpoint dédié **équivalent** qui : - valide les mêmes règles que l'inscription ; - met à jour toutes les entités concernées ; - repasse le compte en **`en_attente`** ; - **invalide** `token_reprise` / `token_reprise_expire_le`. 3. **Cohérence données — numéro de dossier** - **Prérequis** : pour **`reprise-identify`**, le **`numero_dossier`** doit être **déjà connu** côté dossier (affectation gestionnaire avant ou au refus, selon règle métier) ; sinon message d'erreur explicite côté API / spec. - **Conservation** : au-delà du workflow décrit, le **`numero_dossier` est à conserver tel quel** pendant toute la reprise — **pas** de nouvelle attribution, **pas** de modification par le parcours utilisateur ; c'est l'**ancre stable** du dossier refusé jusqu'à la nouvelle validation gestionnaire (y compris cohérence sur `utilisateurs`, `parents`, `assistantes_maternelles` si applicable). 4. **Sécurité / anti-énumération (optionnel mais souhaitable)** - Réponses neutres si couple numéro + e-mail invalide ou dossier non en reprise (alignement possible avec les autres flux auth). ## Hors périmètre - **UI / routes Flutter** : **#112** (lien mail, modale login, redirection vers parcours parent ou AM prérempli). ## Dépendances - **#110** (refus + token + mail) - **#103** / **#104** (numéro de dossier : génération, format, affichage mails / listes si besoin pour la cohérence des messages) ## Critères de done (backend) - [ ] `GET reprise-dossier` expose les données nécessaires au **préremplissage complet** du parcours parent ou AM (spec jointe aux DTO). - [ ] Resoumission = **même niveau fonctionnel** qu'une inscription complète (pas seulement nom / adresse / téléphone). - [ ] Après resoumission réussie : statut **`en_attente`**, token reprise **consommé**, dossier visible dans la **file de vérification** gestionnaire. - [ ] Le **`numero_dossier` reste strictement inchangé** sur tout le flux (chargement → corrections → resoumission) ; tests de non-régression. - [ ] `reprise-identify` + `reprise-dossier` + resoumission **documentés** (OpenAPI) et couverts par **tests** ciblés. --- *Issue mise à jour pour être alignée avec le workflow « refus → mail ou login (n° + e-mail) → parcours inscription prérempli → nouvelle validation gestionnaire ».* ## Note d'implémentation (architecture) - **DTO distincts** pour **création** vs **reprise** (éviter un seul DTO avec `mode` + nombreux `ValidateIf`), tout en **réutilisant les sous-DTO** imbriqués (enfants, co-parent, etc.) pour limiter le doublon. - **Logique métier unique** : les deux flux alimentent une même couche applicative du type `applyParentDossier(dto, context)` / équivalent AM, où `context` porte création vs reprise, le `EntityManager` transactionnel, identifiants existants, **`numero_dossier` inchangé en reprise**, invalidation `token_reprise`, etc. - **Côté front** : parcours **identique**, **deux appels API** (création vs reprise) selon le contexte (route / token) — détail dans **#112**.
jmartin added the backendapi labels 2026-03-11 21:02:16 +00:00
jmartin commented 2026-03-12 22:05:01 +00:00
Author
Owner
Copy Link
Copy Source

Livré : GET /auth/reprise-dossier?token= (dossier pour préremplir), PATCH /auth/reprise-resoumettre (token + champs → en_attente, token invalidé), POST /auth/reprise-identify (numero_dossier + email → type + token).

Livré : GET /auth/reprise-dossier?token= (dossier pour préremplir), PATCH /auth/reprise-resoumettre (token + champs → en_attente, token invalidé), POST /auth/reprise-identify (numero_dossier + email → type + token).
jmartin commented 2026-05-04 20:53:49 +00:00
Author
Owner
Copy Link
Copy Source

Description #111 mise à jour : périmètre backend = parcours inscription complet (préremplissage + resoumission équivalente création), aligné avec le workflow produit et #112.

Description #111 mise à jour : périmètre backend = parcours inscription complet (préremplissage + resoumission équivalente création), aligné avec le workflow produit et #112.
jmartin commented 2026-05-04 20:55:49 +00:00
Author
Owner
Copy Link
Copy Source

Précision ajoutée : conserver le numero_dossier tout au long de la reprise (pas de régénération / pas de changement côté parcours utilisateur) + critère de done associé.

Précision ajoutée : **conserver le `numero_dossier`** tout au long de la reprise (pas de régénération / pas de changement côté parcours utilisateur) + critère de done associé.
jmartin commented 2026-05-04 21:12:02 +00:00
Author
Owner
Copy Link
Copy Source

Alignement #111 : ajout section Note d’implémentation — 2 DTO (création / reprise) + / équivalent AM + front = 2 endpoints selon contexte (cf. #112).

**Alignement #111** : ajout section *Note d’implémentation* — 2 DTO (création / reprise) + / équivalent AM + front = 2 endpoints selon contexte (cf. #112).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
a11y
Accessibilité
 admin
Administration
 api
auth
Authentification
 backend
Backend NestJS
 bug
Something isn't working
 cdc
Cahier des charges
 cleanup
Nettoyage/Refactoring
 critique
Critique
 database
Base de données PostgreSQL
 documentation
Improvements or additions to documentation
 duplicate
This issue or pull request already exists
 email
Email/Notifications
 enhancement
New feature or request
 frontend
Frontend Flutter/Web
 gestionnaire
Gestionnaire
 good first issue
Good for newcomers
 help wanted
Extra attention is needed
 infra
Infrastructure Docker/CI-CD
 invalid
This doesn't seem right
 juridique
Juridique/Légal
 monitoring
Monitoring/Logs
 on-premise
Configuration on-premise
 p0-bloquant
Priorité 0 - BLOQUANT
 p1-bloquant
Priorité 1 - BLOQUANT
 p2
Priorité 2
 p3
Priorité 3
 p4
Priorité 4
 phase-1
Phase 1
 question
Further information is requested
 rgpd
RGPD/Conformité
 security
Sécurité
 tests
Tests unitaires/E2E
 ui
upload
Upload fichiers
 ux
UX/UI
 v0.1.0
Issue rattachée au périmètre release 0.1.0
 wontfix
This will not be worked on
No labels api backend
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
nnasarre jmartin (MARTIN Julien)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: jmartin/petitspas#111