Julien Martin
003fe6b762
Squash merge develop → master. - Fiche parent éditable (co-parent, PATCH fiche, GET /parents) - Fiche AM 3 onglets (PATCH fiche, rattacher/détacher enfants) - Table enfants_assistantes_maternelles + enum garde/sans_garde - Migration SQL + BDD.sql canonique - Correctifs recette : @Get() parents, DTO fiche AM, fix NIR Co-authored-by: Cursor <cursoragent@cursor.com>
128 lines
4.4 KiB
Markdown
128 lines
4.4 KiB
Markdown
# #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 fonctionnelle** — ce document fixe le contrat attendu ; le back valide `co_parent` et masque les champs sensibles.
|
||
|
||
---
|
||
|
||
## 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
|
||
|
||
### Relations (déjà en place)
|
||
|
||
- `findAll()` et `findOne(user_id)` chargent **`co_parent`** ;
|
||
- FK : `parents.id_co_parent` → `utilisateurs.id` ;
|
||
- inscription couple : les deux sens renseignés en principe (`auth.service.ts`).
|
||
|
||
### Livraison back (#131)
|
||
|
||
- `mapParentForApi` / `sanitizeUserForApi` : réponses `GET/PATCH/POST/DELETE` parents **sans** `password`, `token_creation_mdp`, `password_reset_*` sur `user` et `co_parent`.
|
||
|
||
**Checklist validation :**
|
||
|
||
- [x] `GET /parents/:id` renvoie `co_parent` peuplé quand `id_co_parent` est non null
|
||
- [x] `GET /parents` (liste) inclut `co_parent`
|
||
- [x] `prenom` / `nom` du co-parent présents
|
||
- [x] Pas de fuite `password` / tokens sur `user` ni `co_parent`
|
||
|
||
---
|
||
|
||
## 5. Points d’attention (hors périmètre immédiat)
|
||
|
||
| Sujet | Détail |
|
||
|-------|--------|
|
||
| **Lien inverse** | Si B est co-parent de A (`A.id_co_parent = B`) mais `B.id_co_parent` est `null`, le sous-titre **ne s’affichera pas** sur la fiche de B. Pas de résolution inverse côté front. |
|
||
| **Familles > 2 adultes** | Sous-titre = co-parent direct (`id_co_parent`) uniquement. |
|
||
| **Trou AM ↔ enfants en garde** | Pas de lien AM–enfant aujourd’hui (à documenter / traiter plus tard). |
|
||
|
||
---
|
||
|
||
## 6. Fichiers back concernés
|
||
|
||
| Fichier | Rôle |
|
||
|---------|------|
|
||
| `backend/src/routes/parents/parents.service.ts` | `findOne`, `findAll` + relations |
|
||
| `backend/src/routes/parents/parents.controller.ts` | `mapParentForApi` sur les réponses |
|
||
| `backend/src/routes/parents/parents.mapper.ts` | Sérialisation API |
|
||
| `backend/src/common/utils/sanitize-user-for-api.ts` | Masquage secrets |
|
||
| `backend/src/entities/parents.entity.ts` | relation `co_parent` |
|
||
|
||
---
|
||
|
||
## 7. Références
|
||
|
||
- `docs/28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md` §6.1
|
||
- Ticket Gitea **#131**
|