petitspas/docs/archive/temporaires/131-fiche-parent-co-parent-header.md

#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)

{
  "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 :

• GET /parents/:id renvoie co_parent peuplé quand id_co_parent est non null
• GET /parents (liste) inclut co_parent
• prenom / nom du co-parent présents
• 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