Julien Martin
479a32b4bf
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>
133 lines
4.5 KiB
Markdown
133 lines
4.5 KiB
Markdown
# #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`
|