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>
125 lines
4.7 KiB
Markdown
125 lines
4.7 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** — 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**
|