feat(#131): en-tête fiche parent avec nom et co-parent.

Affiche le prénom/nom du parent en titre et le co-parent en sous-titre ; note handoff back dans archive/temporaires. Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-24 23:37:04 +02:00
parent d55f240f56
commit ebf794e1ac
4 changed files with 188 additions and 7 deletions
@@ -0,0 +1,244 @@
+# #112 — Alignement front après évolution back (reprise dossier complet)
+
+**Branche déployée :** `feature/112-reprise-apres-refus-front`  
+**Commit back :** `d70577b1` — `feat(#112): reprise après refus — dossier complet GET/PATCH`  
+**Date :** 2026-06-16
+
+Ce document décrit le **contrat API réel** après extension du back, et ce que le front doit encore brancher pour exploiter le dossier complet (au-delà de l’identité seule).
+
+---
+
+## 1. Endpoints (inchangés côté URL)
+
+| Méthode | Route | Auth |
+|---------|-------|------|
+| `GET` | `/api/v1/auth/reprise-dossier?token={uuid}` | Public |
+| `PATCH` | `/api/v1/auth/reprise-resoumettre` | Public |
+| `POST` | `/api/v1/auth/reprise-identify` | Public (inchangé) |
+
+> **Note :** le ticket #111 parlait de `PUT` ; l’implémentation reste en **`PATCH`** (comme avant).
+
+---
+
+## 2. `GET /auth/reprise-dossier` — réponse enrichie
+
+### Champs communs (toujours présents)
+
+Identiques à avant : `id`, `email`, `prenom`, `nom`, `telephone`, `adresse`, `ville`, `code_postal`, `numero_dossier`, `role`, `photo_url`, `genre`, `situation_familiale`.
+
+### Rôle `parent` (+ champs #119)
+
+Alignés sur `DossierFamilleCompletDto` :
+
+```json
+{
+  "parents": [
+    {
+      "user_id": "uuid",
+      "email": "…",
+      "prenom": "…",
+      "nom": "…",
+      "telephone": "…",
+      "adresse": "…",
+      "ville": "…",
+      "code_postal": "…",
+      "statut": "refuse",
+      "co_parent_id": "uuid-parent-entity"
+    }
+  ],
+  "enfants": [
+    {
+      "id": "uuid-enfant",
+      "first_name": "Emma",
+      "last_name": "MARTIN",
+      "genre": "F",
+      "status": "actif",
+      "birth_date": "2023-02-15T00:00:00.000Z",
+      "due_date": null,
+      "photo_url": "/uploads/photos/…",
+      "consent_photo": true,
+      "est_multiple": false
+    }
+  ],
+  "texte_motivation": "Nous recherchons…"
+}
+```
+
+**Mapping front suggéré :**
+
+| JSON back | Modèle / wizard parent |
+|-----------|-------------------------|
+| `parents[]` | `UserRegistrationData.parent1` + `parent2` (matcher par `email` ou ordre : titulaire = `id` du GET racine) |
+| `enfants[].first_name` / `last_name` | `ChildData.firstName` / `lastName` |
+| `enfants[].birth_date` | `ChildData.birthDate` (ISO → `DateTime`) |
+| `enfants[].due_date` | `ChildData.dueDate` (enfant `a_naitre`) |
+| `enfants[].status` | `actif` = né, `a_naitre` = à naître |
+| `enfants[].photo_url` | `ApiConfig.absoluteMediaUrl()` + conserver pour reprise sans re-upload |
+| `enfants[].id` | **Obligatoire** pour le PATCH (update par id) |
+| `enfants[].est_multiple` | `grossesse_multiple` si utilisé |
+| `texte_motivation` | étape présentation / motivation |
+
+Si `numero_dossier` absent : pas de `parents[]` / `enfants[]` / `texte_motivation` (identité seule).
+
+### Rôle `assistante_maternelle`
+
+Champs racine + fiche pro (structure **aplatie**, pas de sous-objet `user`) :
+
+```json
+{
+  "consentement_photo": true,
+  "date_naissance": "1985-03-12T00:00:00.000Z",
+  "lieu_naissance_ville": "Paris",
+  "lieu_naissance_pays": "France",
+  "numero_agrement": "AGR-2024-12345",
+  "nir": "123456789012345",
+  "date_agrement": "2024-06-01T00:00:00.000Z",
+  "nb_max_enfants": 4,
+  "place_disponible": 2,
+  "biographie": "…"
+}
+```
+
+**Mapping `AmRegistrationData` :**
+
+| JSON back | Champ front |
+|-----------|-------------|
+| `nb_max_enfants` | `capaciteAccueil` |
+| `place_disponible` | `placesDisponibles` |
+| `numero_agrement` | `numeroAgrement` |
+| `biographie` | `biographie` / présentation |
+| `photo_url` | déjà géré via `RepriseSession.photoUrl` |
+
+---
+
+## 3. `PATCH /auth/reprise-resoumettre` — body étendu
+
+### Commun
+
+```json
+{ "token": "uuid-reprise" }
+```
+
+### Parent — champs à envoyer depuis le wizard
+
+| Champ PATCH | Source wizard | Notes |
+|-------------|---------------|-------|
+| `prenom`, `nom`, `telephone`, `adresse`, `ville`, `code_postal` | Parent 1 (titulaire token) | Champs racine |
+| `co_parent_prenom`, `co_parent_nom`, `co_parent_telephone` | Parent 2 | |
+| `co_parent_meme_adresse`, `co_parent_adresse`, `co_parent_code_postal`, `co_parent_ville` | Parent 2 adresse | |
+| `texte_motivation` **ou** `presentation_dossier` | Étape motivation | Les deux alias acceptés |
+| `enfants[]` | Liste enfants | Voir ci-dessous |
+
+**Structure `enfants[]` (miroir inscription + `id` obligatoire) :**
+
+```json
+{
+  "id": "uuid-enfant-existant",
+  "prenom": "Emma",
+  "nom": "MARTIN",
+  "date_naissance": "2023-02-15",
+  "date_previsionnelle_naissance": null,
+  "genre": "F",
+  "photo_base64": "data:image/jpeg;base64,…",
+  "photo_filename": "emma.jpg",
+  "grossesse_multiple": false
+}
+```
+
+- **v1 back :** update par `id` uniquement — pas de création/suppression d’enfant.
+- Si `id` inconnu pour ce dossier → **400** `Enfant inconnu pour ce dossier : {id}`.
+- Sans nouvelle photo : ne pas envoyer `photo_base64` (l’existant est conservé).
+
+### AM — champs à envoyer
+
+| Champ PATCH | Source |
+|-------------|--------|
+| Identité + `photo_url` ou `photo_base64` + `photo_filename` | Étapes 1–2 |
+| `consentement_photo`, `date_naissance`, `lieu_naissance_ville`, `lieu_naissance_pays` | Identité |
+| `numero_agrement`, `nir`, `date_agrement` | Pro |
+| `capacite_accueil`, `places_disponibles` | Pro |
+| `biographie` | Présentation |
+
+Validation NIR identique à l’inscription si `nir` fourni.
+
+### Réponse succès (nouveau format)
+
+```json
+{
+  "message": "Dossier resoumis avec succès. Il est de nouveau en attente de validation.",
+  "statut": "en_attente",
+  "user_id": "uuid",
+  "numero_dossier": "2026-000021"
+}
+```
+
+Code HTTP : **200** (pas de corps `Users` brut comme l’ancien back).
+
+### Effet métier
+
+- **Parent :** tous les users `role=parent` avec le même `numero_dossier` passent en `en_attente` ; `token_reprise` invalidé sur **tous** (symétrique refus #110).
+- **AM :** un seul user.
+
+### E-mail accusé resoumission (parent)
+
+Après `PATCH` réussi, un e-mail est envoyé à **chaque parent** du dossier (`sendResoumissionPendingEmail`) :
+- confirmation de resoumission ;
+- rappel du **numéro de dossier** ;
+- mention « en attente de validation ».
+
+Échec SMTP : logué, **ne bloque pas** la resoumission (même règle que l'inscription initiale).
+
+---
+
+## 4. Fichiers front à modifier (checklist)
+
+### Modèles
+
+- [ ] `lib/models/reprise_dossier.dart` — parser `parents[]`, `enfants[]`, `texte_motivation`, champs AM
+- [ ] Réutiliser ou mapper vers `DossierFamilleEnfant` / structures existantes (#119 admin) si possible
+
+### Session / préremplissage
+
+- [ ] `lib/services/reprise_session.dart`
+  - `applyToParent` : remplir parent1/parent2 depuis `parents[]`, enfants, motivation
+  - `applyToAm` : remplir tous les champs AM
+
+### API
+
+- [ ] `lib/services/auth_service.dart` — `resoumettreReprise()` : accepter body complet (parent + AM), pas seulement identité
+- [ ] Étendre `UserRegistrationData` / `AmRegistrationData` helpers `toReprisePatchBody()` si utile
+
+### Écrans fin de parcours
+
+- [ ] `parent_register_step5_screen.dart` — PATCH avec co-parent, enfants, motivation
+- [ ] `am_register_step4_screen.dart` — PATCH avec fiche AM complète
+
+### Hors scope back (inchangé)
+
+RIB / IBAN / attestation CAF (étape 5 wizard parent) : **non persistés** — rien à envoyer en reprise.
+
+### Non implémenté front (ticket #112 initial)
+
+- [ ] Modale login « J’ai un numéro de dossier » → `POST /auth/reprise-identify` (back prêt, front absent)
+
+---
+
+## 5. Tests manuels suggérés
+
+1. Refuser un dossier parent complet (≥1 enfant + co-parent + motivation).
+2. Ouvrir le lien mail `/reprise?token=…`.
+3. Vérifier dans DevTools que le GET contient `enfants[]` et `texte_motivation`.
+4. Après branchement front : wizard prérempli sur toutes les étapes.
+5. Resoumettre → statut `en_attente` pour les deux parents ; dossier visible file validation admin (#119).
+
+---
+
+## 6. Références code back
+
+```
+backend/src/routes/auth/dto/reprise-dossier.dto.ts
+backend/src/routes/auth/dto/resoumettre-reprise.dto.ts
+backend/src/routes/auth/dto/enfant-reprise.dto.ts
+backend/src/routes/auth/auth.service.ts  → getRepriseDossier, resoumettreReprise
+backend/src/routes/parents/dto/dossier-famille-complet.dto.ts
+```
@@ -0,0 +1,124 @@
+# #131 — En-tête fiche parent : co-parent (note front → back)
+
+**Ticket :** #131 (fiche parent dashboard, doc `28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md` §6.1)  
+**Date :** 2026-06-01  
+**Statut front :** livré (en-tête dynamique)  
+**Modif backend demandée :** **aucune** — ce document fixe le contrat attendu et invite à valider que l’existant le couvre.
+
+---
+
+## 1. Comportement UI (front)
+
+Dans la modale **fiche parent** (`AdminParentEditModal`) :
+
+| Zone | Contenu |
+|------|---------|
+| **Titre** | `prenom` + `nom` du parent affiché (plus le libellé fixe « Fiche parent ») |
+| **Sous-titre** | `Co-parent : {prenom} {nom}` — affiché **uniquement** si un co-parent est connu |
+
+Le titre se met à jour en direct pendant l’édition des champs nom/prénom.  
+Le sous-titre provient du co-parent **chargé depuis l’API** (pas saisi à la main dans la modale).
+
+---
+
+## 2. Endpoints consommés
+
+| Méthode | Route | Usage front |
+|---------|-------|-------------|
+| `GET` | `/api/v1/parents` | Liste parents (onglet Parents) |
+| `GET` | `/api/v1/parents/:userId` | Rechargement fiche après rattachement/détachement enfant |
+| `PATCH` | `/api/v1/parents/:userId/fiche` | Sauvegarde identité + statut (inchangé) |
+
+Rôles : `super_admin`, `gestionnaire`, `administrateur` (selon route).
+
+---
+
+## 3. Contrat JSON attendu pour `co_parent`
+
+Le front parse `ParentModel.fromJson` avec la clé **`co_parent`** (snake_case), objet utilisateur imbriqué.
+
+### Champs minimum utilisés pour le sous-titre
+
+| Clé JSON | Usage |
+|----------|--------|
+| `co_parent` | Objet ou absent/`null` |
+| `co_parent.id` | Identifiant (futur lien cliquable éventuel) |
+| `co_parent.prenom` | Affichage |
+| `co_parent.nom` | Affichage |
+
+Affichage front : `'{prenom} {nom}'.trim()` → libellé `Co-parent : …`.
+
+### Exemple de fragment de réponse (`GET /parents/:id`)
+
+```json
+{
+  "user_id": "33333333-3333-3333-3333-333333333333",
+  "numero_dossier": "2026-000042",
+  "user": {
+    "id": "33333333-3333-3333-3333-333333333333",
+    "email": "parent1@example.com",
+    "prenom": "Paul",
+    "nom": "PARENT",
+    "statut": "actif",
+    "telephone": "0601020304"
+  },
+  "co_parent": {
+    "id": "44444444-4444-4444-4444-444444444444",
+    "email": "coparent1@example.com",
+    "prenom": "Clara",
+    "nom": "COPARENT",
+    "role": "parent",
+    "statut": "actif"
+  },
+  "parentChildren": []
+}
+```
+
+> **Note :** le front lit `user` (pas `utilisateur`). La doc `11_API.md` § Parents mentionne encore `utilisateur` / `id_co_parent` seul — le contrat **effectif** côté Nest/TypeORM est l’entité `Parents` sérialisée (`user`, `co_parent`, `parentChildren`, …).
+
+---
+
+## 4. État backend (à valider, pas à refaire)
+
+D’après le code actuel (`parents.service.ts`) :
+
+- `findAll()` et `findOne(user_id)` chargent déjà la relation **`co_parent`** ;
+- la FK métier est `parents.id_co_parent` → `utilisateurs.id` ;
+- à l’inscription couple, les deux sens sont en principe renseignés (`auth.service.ts`).
+
+**Checklist validation back :**
+
+- [ ] `GET /parents/:id` renvoie bien `co_parent` peuplé quand `id_co_parent` est non null
+- [ ] `GET /parents` (liste) inclut aussi `co_parent` (sous-titre disponible dès l’ouverture sans re-fetch)
+- [ ] Les champs `prenom` / `nom` du co-parent sont présents dans la réponse JSON
+
+Si ces trois points passent en recette, **aucun changement backend n’est nécessaire** pour cette fonctionnalité.
+
+---
+
+## 5. Points d’attention (hors périmètre immédiat)
+
+| Sujet | Détail |
+|-------|--------|
+| **Lien inverse** | Si le parent B est le co-parent de A (`A.id_co_parent = B`) mais que `B.id_co_parent` est `null`, le sous-titre **ne s’affichera pas** sur la fiche de B. Le front ne fait pas de résolution inverse. À traiter côté back **seulement si** des données legacy ont un lien à sens unique. |
+| **Familles > 2 adultes** | Le sous-titre n’affiche que le co-parent direct (`id_co_parent`). Les autres responsables liés uniquement via `enfants_parents` ne sont pas listés ici (cf. doc 28 §6). |
+| **Données sensibles** | Vérifier que la sérialisation de `co_parent` n’expose pas `password` / tokens (même remarque que pour `user`). |
+
+---
+
+## 6. Fichiers front concernés
+
+| Fichier | Rôle |
+|---------|------|
+| `frontend/lib/models/parent_model.dart` | Parse `co_parent` → `AppUser? coParent` |
+| `frontend/lib/widgets/admin/common/admin_parent_edit_modal.dart` | Titre + sous-titre |
+| `frontend/lib/services/user_service.dart` | `getParents()` / `getParent()` |
+
+---
+
+## 7. Références
+
+- `docs/28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md` §6.1
+- `backend/src/routes/parents/parents.service.ts` — `findOne`, `findAll`
+- `backend/src/entities/parents.entity.ts` — relation `co_parent`
+- Ticket Gitea **#131**