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

Reprise après refus – frontend #112

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

Parcours utilisateur

  • Lien e-mail (/reprise?token=…) ou page de connexion : lien « J’ai un numéro de dossier » → modale numéro + e-mail → appel reprise-identify → entrée dans le même wizard que l’inscription (parent ou AM) avec champs préremplis (données issues de reprise-dossier / équivalent).

Technique (alignement #111)

  • Même UI que la création ; distingo côté app : route / présence du token reprise / flag d’état → à la fin du parcours, appeler l’endpoint de resoumission reprise dédié (et pas uniquement register/parent ou register/am « création »).
  • Cohérence avec le backend : DTO séparés + logique métier partagée (apply…) — détail dans #111.
## Parcours utilisateur - Lien e-mail (`/reprise?token=…`) **ou** page de connexion : lien **« J’ai un numéro de dossier »** → modale **numéro + e-mail** → appel **`reprise-identify`** → entrée dans le **même wizard** que l’inscription (parent ou AM) avec **champs préremplis** (données issues de `reprise-dossier` / équivalent). ## Technique (alignement #111) - **Même UI** que la création ; **distingo côté app** : route / présence du **token reprise** / flag d’état → à la **fin du parcours**, appeler l’**endpoint de resoumission reprise** dédié (et **pas** uniquement `register/parent` ou `register/am` « création »). - Cohérence avec le backend : **DTO séparés** + logique métier partagée (`apply…`) — détail dans **#111**.
jmartin added the
frontend
ui
 labels 2026-03-11 21:02:17 +00:00
jmartin added this to the 0.1.0 milestone 2026-04-13 22:04:24 +00:00
jmartin added the
v0.1.0
 label 2026-04-13 22:04:47 +00:00
jmartin commented 2026-06-16 14:45:33 +00:00
Author
Owner
Copy Link

Mise à jour branche feature/112-reprise-apres-refus-front (déployée)

Commits récents :

  • d70577b1 — back : GET/PATCH reprise dossier complet (parents[], enfants[], motivation, fiche AM)
  • 25c10c88 — doc alignement front : docs/tmp/112-back-reprise-alignement-front.md

Écarts par rapport au périmètre ticket #112

Point ticket État réel
Ticket intitulé « frontend » Une évolution back était nécessaire (#111 fermé mais GET/PATCH incomplets). Implémentée sur la même branche que le front.
Parcours lien e-mail /reprise?token= ✅ Front : route + chargement dossier + wizard (identité). Back enrichi pour dossier complet.
Parcours login : modale « J'ai un numéro de dossier » → reprise-identify ❌ Non livré côté front (back POST /auth/reprise-identify inchangé et prêt).
Préremplissage wizard complet (enfants, co-parent, motivation, AM) ⚠️ Partiel : le GET back renvoie tout ; le front parse encore surtout l'identité (RepriseDossier + resoumettreReprise limités). Suite à faire (voir doc tmp).
Resoumission = même niveau qu'inscription ✅ Back ; front n'envoie pas encore co-parent / enfants[] / motivation / champs AM au PATCH.
PUT reprise-resoumettre (#111) Implémentation reste en PATCH (déjà en prod avant cette évolution).
Réponse resoumission Nouveau JSON { message, statut, user_id, numero_dossier } — plus l'entité Users brute.
Co-parent Update champs existants ; co_parent_email non modifiable (pas de changement d'email co-parent en v1).
Enfants en reprise Update par id uniquement — pas de création/suppression en v1 ; 400 si id inconnu.
RIB / IBAN / CAF (étape 5 parent) Hors scope back (non stockés à l'inscription) — rien à charger ni persister.
est_multiple sur enfants GET ✅ Exposé (est_multiple aligné colonne enfants.est_multiple).
Resoumission famille ✅ Tous les parents du numero_dossier → en_attente + invalidation token_reprise groupée (symétrique refus #110).

Prochaine étape front (bloquée tant que non branchée)

  1. Étendre RepriseDossier.fromJson + RepriseSession.applyToParent/applyToAm
  2. Étendre AuthService.resoumettreReprise (body complet)
  3. parent_register_step5 / am_register_step4 — envoyer tous les champs
  4. (Optionnel ticket) modale reprise-identify depuis le login

Détail contrat API : docs/tmp/112-back-reprise-alignement-front.md sur la branche.

## Mise à jour branche `feature/112-reprise-apres-refus-front` (déployée) Commits récents : - `d70577b1` — **back** : GET/PATCH reprise dossier complet (parents[], enfants[], motivation, fiche AM) - `25c10c88` — doc alignement front : `docs/tmp/112-back-reprise-alignement-front.md` --- ### Écarts par rapport au périmètre ticket #112 | Point ticket | État réel | |--------------|-----------| | Ticket intitulé **« frontend »** | Une **évolution back** était nécessaire (#111 fermé mais GET/PATCH incomplets). Implémentée **sur la même branche** que le front. | | Parcours **lien e-mail** `/reprise?token=` | ✅ Front : route + chargement dossier + wizard (identité). Back enrichi pour dossier complet. | | Parcours **login** : modale « J'ai un numéro de dossier » → `reprise-identify` | ❌ **Non livré** côté front (back `POST /auth/reprise-identify` inchangé et prêt). | | Préremplissage **wizard complet** (enfants, co-parent, motivation, AM) | ⚠️ **Partiel** : le GET back renvoie tout ; le front parse encore surtout l'**identité** (`RepriseDossier` + `resoumettreReprise` limités). Suite à faire (voir doc tmp). | | Resoumission = même niveau qu'inscription | ✅ Back ; front n'envoie pas encore co-parent / enfants[] / motivation / champs AM au PATCH. | | `PUT` reprise-resoumettre (#111) | Implémentation reste en **`PATCH`** (déjà en prod avant cette évolution). | | Réponse resoumission | Nouveau JSON `{ message, statut, user_id, numero_dossier }` — plus l'entité `Users` brute. | | Co-parent | Update champs existants ; **`co_parent_email` non modifiable** (pas de changement d'email co-parent en v1). | | Enfants en reprise | **Update par `id` uniquement** — pas de création/suppression en v1 ; `400` si id inconnu. | | RIB / IBAN / CAF (étape 5 parent) | Hors scope back (non stockés à l'inscription) — rien à charger ni persister. | | `est_multiple` sur enfants GET | ✅ Exposé (`est_multiple` aligné colonne `enfants.est_multiple`). | | Resoumission famille | ✅ Tous les parents du `numero_dossier` → `en_attente` + invalidation `token_reprise` groupée (symétrique refus #110). | --- ### Prochaine étape front (bloquée tant que non branchée) 1. Étendre `RepriseDossier.fromJson` + `RepriseSession.applyToParent/applyToAm` 2. Étendre `AuthService.resoumettreReprise` (body complet) 3. `parent_register_step5` / `am_register_step4` — envoyer tous les champs 4. (Optionnel ticket) modale `reprise-identify` depuis le login Détail contrat API : **`docs/tmp/112-back-reprise-alignement-front.md`** sur la branche.
jmartin commented 2026-06-16 17:20:34 +00:00
Author
Owner
Copy Link

Livr� � branche feature/112-reprise-apres-refus-front

Front reprise apr�s refus op�rationnel (back #111 d�j� en place). Dernier commit : df776d8.

Parcours

  • Entr�e /reprise?token= (lien e-mail) : charge GET /auth/reprise-dossier, pr�remplit le wizard parent ou AM, resoumission via PATCH /auth/reprise-resoumettre.
  • Page login : lien � J'ai un num�ro de dossier � (sous � Cr�er un compte �) ? modale num�ro + e-mail ? POST /auth/reprise-identify ? m�me flux reprise.

Parent

  • Pr�remplissage parents, co-parent, enfants, motivation.
  • Photos enfants en reprise (existingPhotoUrl) + consentement photo coh�rent si photo en base.
  • PATCH complet � l��tape 5 (enfants avec id, motivation, etc.).
  • Recette : resoumission + validation admin famille OK.

AM

  • Pr�remplissage fiche pro compl�te (identit�, photo, NIR, agr�ment, capacit�, places, biographie).
  • Correctif resetForReprise : dates de naissance / d�agr�ment et places disponibles bien inject�es dans le mod�le (bug d�ombre de param�tres).
  • Parsing reprise-dossier renforc� + test frontend/test/reprise_am_parse_test.dart.

D�ploiement

Le back prend en charge le d�ploiement ; le front est pr�t sur la branche feature ci-dessus.

Issue ferm�e c�t� front apr�s recette.

## Livr� � branche `feature/112-reprise-apres-refus-front` Front **reprise apr�s refus** op�rationnel (back #111 d�j� en place). Dernier commit : `df776d8`. ### Parcours - Entr�e **`/reprise?token=`** (lien e-mail) : charge `GET /auth/reprise-dossier`, pr�remplit le wizard parent ou AM, resoumission via `PATCH /auth/reprise-resoumettre`. - Page login : lien **� J'ai un num�ro de dossier �** (sous � Cr�er un compte �) ? modale num�ro + e-mail ? `POST /auth/reprise-identify` ? m�me flux reprise. ### Parent - Pr�remplissage parents, co-parent, enfants, motivation. - Photos enfants en reprise (`existingPhotoUrl`) + consentement photo coh�rent si photo en base. - PATCH complet � l��tape 5 (enfants avec `id`, motivation, etc.). - Recette : resoumission + validation admin famille OK. ### AM - Pr�remplissage fiche pro compl�te (identit�, photo, NIR, agr�ment, capacit�, places, biographie). - Correctif **`resetForReprise`** : dates de naissance / d�agr�ment et places disponibles bien inject�es dans le mod�le (bug d�ombre de param�tres). - Parsing `reprise-dossier` renforc� + test `frontend/test/reprise_am_parse_test.dart`. ### D�ploiement Le **back prend en charge le d�ploiement** ; le front est pr�t sur la branche feature ci-dessus. --- *Issue ferm�e c�t� front apr�s recette.*
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 Label
frontend
ui
v0.1.0
Milestone
No items
No Milestone 0.1.0
Projects
Clear projects
No project
Assignees
Clear assignees
nnasarre jmartin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: jmartin/petitspas#112
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?