feat(#131): fiche AM éditable en 3 onglets et widgets admin partagés.

Modale admin AM (identité, dossier pro, enfants), API front avec repli, note back affiliation, et extraction gélule statut / liste enfants pour la fiche parent. Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-25 17:33:41 +02:00
parent 2fd97ddecb
commit 479a32b4bf
10 changed files with 1417 additions and 181 deletions
@@ -0,0 +1,132 @@
+# #131 — Fiche AM éditable + affiliation enfants (note front → back)
+
+**Ticket :** #131 (partie AM, doc `28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md` §6.1)  
+**Date :** 2026-06-01  
+**Statut front :** modale livrée (2 onglets) — **API affiliation AM↔enfant à implémenter**
+
+---
+
+## 1. Comportement UI (front)
+
+Modale `AdminAmEditModal` — même shell que la fiche parent (~930 px) :
+
+| Onglet | Contenu |
+|--------|---------|
+| **Identité & professionnel** | `IdentityBlock` éditable + grille pro (agrément, ville résidence, capacité, places, NIR/agrément date en lecture seule, biographie, switch disponible) + gélule statut |
+| **Enfants accueillis** | Liste cartes enfants (réutilise `AdminChildrenAffiliationPanel` / `AdminEnfantUserCard`) + rattacher / détacher |
+
+En-tête : prénom nom · sous-titre `Zone · Agrément · Dossier`.
+
+---
+
+## 2. Endpoints consommés
+
+### Déjà existants (partiels)
+
+| Méthode | Route | Usage |
+|---------|-------|-------|
+| `GET` | `/api/v1/assistantes-maternelles` | Liste AM |
+| `GET` | `/api/v1/assistantes-maternelles/:userId` | Détail (403 possible pour `administrateur` → fallback liste) |
+| `PATCH` | `/api/v1/users/:userId` | Identité + statut (admin / super_admin uniquement) |
+| `PATCH` | `/api/v1/assistantes-maternelles/:userId` | Champs pro (gestionnaire / super_admin) |
+
+### À créer (recommandé — miroir parent #131 / #115)
+
+| Méthode | Route | Rôle |
+|---------|-------|------|
+| `PATCH` | `/api/v1/assistantes-maternelles/:userId/fiche` | Mise à jour unifiée identité + pro + statut (`super_admin`, `gestionnaire`, `administrateur`) |
+| `POST` | `/api/v1/assistantes-maternelles/:userId/enfants/:enfantId` | Rattacher un enfant |
+| `DELETE` | `/api/v1/assistantes-maternelles/:userId/enfants/:enfantId` | Détacher un enfant |
+| `GET` | `/api/v1/assistantes-maternelles/:userId` | Inclure `amChildren[]` (relation enfant) |
+
+Le front appelle déjà ces routes ; en l’absence de `PATCH …/fiche`, il tente un fallback `PATCH users` + `PATCH assistantes-maternelles` (échoue selon le rôle connecté).
+
+---
+
+## 3. Modèle de données affiliation AM ↔ enfant
+
+**À définir côté BDD** (pas de table dédiée aujourd’hui, contrairement à `enfants_parents`) :
+
+Proposition alignée parent :
+
+```sql
+-- Piste : enfants_assistantes_maternelles
+CREATE TABLE enfants_assistantes_maternelles (
+  id_am UUID NOT NULL REFERENCES utilisateurs(id) ON DELETE CASCADE,
+  id_enfant UUID NOT NULL REFERENCES enfants(id) ON DELETE CASCADE,
+  PRIMARY KEY (id_am, id_enfant)
+);
+```
+
+Réponse API attendue sur `GET /assistantes-maternelles/:id` :
+
+```json
+{
+  "user_id": "uuid-am",
+  "user": { "id": "…", "prenom": "Claire", "nom": "MARTIN", "statut": "actif" },
+  "approval_number": "AGR-2024-12345",
+  "residence_city": "Bezons",
+  "max_children": 4,
+  "places_available": 2,
+  "available": true,
+  "amChildren": [
+    {
+      "child": {
+        "id": "uuid-enfant",
+        "first_name": "Emma",
+        "last_name": "MARTIN",
+        "status": "actif",
+        "birth_date": "2023-02-15"
+      }
+    }
+  ]
+}
+```
+
+Le front parse `amChildren` / `am_children` / `assistanteChildren` (même logique que `parentChildren`).
+
+---
+
+## 4. Body `PATCH …/fiche` suggéré
+
+```json
+{
+  "nom": "MARTIN",
+  "prenom": "Claire",
+  "email": "claire@example.com",
+  "telephone": "0612345678",
+  "adresse": "5 place Bellecour",
+  "ville": "Lyon",
+  "code_postal": "69002",
+  "statut": "actif",
+  "approval_number": "AGR-2024-12345",
+  "residence_city": "Lyon",
+  "max_children": 4,
+  "places_available": 2,
+  "biography": "…",
+  "available": true
+}
+```
+
+NIR et date d’agrément : lecture seule dans la modale (modification hors périmètre admin v1).
+
+---
+
+## 5. Fichiers front concernés
+
+| Fichier | Rôle |
+|---------|------|
+| `frontend/lib/widgets/admin/common/admin_am_edit_modal.dart` | Modale 2 onglets |
+| `frontend/lib/widgets/admin/common/admin_children_affiliation_panel.dart` | Liste enfants partagée parent/AM |
+| `frontend/lib/widgets/admin/common/admin_status_capsule.dart` | Gélule statut partagée |
+| `frontend/lib/models/assistante_maternelle_model.dart` | Parse champs pro + `amChildren` |
+| `frontend/lib/services/user_service.dart` | `getAssistanteMaternelle`, `updateAmFiche`, `attachEnfantToAm`, `detachEnfantFromAm` |
+| `frontend/lib/widgets/admin/assistante_maternelle_management_widget.dart` | Ouverture modale au clic Modifier |
+
+---
+
+## 6. Références
+
+- Fiche parent : `PATCH /parents/:id/fiche`, `POST|DELETE /parents/:id/enfants/:enfantId`
+- Ticket Gitea **#131**, **#115**
+- `docs/archive/temporaires/TEMP_131-back-fiche-parent-co-parent.md`