petitspas/docs/archive/temporaires/TEMP_131-back-fiche-parent-co-parent.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 — 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)

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