jmartin/petitspas
1
0
Fork 0
Code Issues 28 Pull Requests Actions Packages Projects Releases Wiki Activity

feat(#140): dashboard admin ch.6 — fiche parent, enfants, affiliation

Browse Source 
Back: PATCH /parents/:id/fiche, attach/detach enfant, GET /enfants enrichi.
Front: modale parent éditable, onglet Enfants, fiche enfant, UserService.

Couvre doc 28 §6.1–6.2 ; tickets liés #115 #116 #130 #131 #137 #138.
Hors scope: fiche AM (#131), création admin (#129).

Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
jmartin
2026-06-17 00:35:00 +02:00
co-authored by Cursor
parent df776d8200
commit 1dddc67933
20 changed files with 1818 additions and 68 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/EVOLUTIONS_CDC.md
+28 -1
View File
@@ -2,6 +2,8 @@
Ce document liste les modifications à apporter au cahier des charges original pour le rendre conforme à l'application développée.
> **Document complémentaire (juin 2026)** — réflexions sur le **modèle famille / numéro de dossier**, familles recomposées, tuteurs et responsables légaux : voir **[28 - Évolution famille et responsables](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md)**.
## 1. Gestion des Enfants
### Modifications à apporter dans la section "Création de compte parent"
@@ -275,4 +277,29 @@ Pour chaque évolution identifiée, ce document suivra la structure suivante :
- Évolution du modèle de données vers un RBAC intra-RPE.
- Adaptation des écrans d'administration pour gérer les rôles locaux.
- Renforcement des contrôles d'accès backend et des règles métier.
- Clarification des workflows décisionnels dans l'application.
- Clarification des workflows décisionnels dans l'application.
## 9. Modèle famille, numéro de dossier et responsables légaux
### 9.1 Situation actuelle (v1.0.0)
- Un **numéro de dossier** par inscription (`AAAA-NNNNNN`), fortement utilisé dans les workflows (validation, refus, reprise).
- **Un co-parent** par fiche `parents` ; affiliation réelle via `enfants_parents`.
- La « famille » est **déduite** du graphe (co-parent + enfants partagés) — fusion parfois trop large en cas de recompositions.
### 9.2 Limitation v1.0.0 — familles recomposées
Cas type : même responsable M avec co-responsable A (enfant α) puis co-responsable B (enfant β). Le modèle actuel ne permet pas de séparer proprement **deux unités familiales** pour une même personne.
**Contournement accepté pour la release 1.0.0** : second compte avec **email distinct** et second numéro de dossier (procédure gestionnaire). S'applique aussi aux couples HH/FF, tuteurs, grands-parents, etc.
### 9.3 Évolutions post-1.0.0 (pistes)
| Sujet | Piste |
|-------|--------|
| **Unité de dossier** | Numéro **optionnel** ; plusieurs unités par personne |
| **Affiliation** | Gestion admin des liens parent↔enfant (#115, #116, #138) |
| **Qualification** | Combobox « lien responsable–enfant » (tuteur, GP, parent…) sur `enfants_parents` |
| **UI admin** | Fiche parent éditable (#131), liste enfants en bas de fiche |
**Détail complet, scénarios, tickets et formulation release notes** : [28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md).