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