[Epic] Gestion de la suppression des utilisateurs / dossiers / enfants / AM #154

New Issue

jmartin · 2026-07-17T15:05:00Z

jmartin commented

2026-07-17 15:05:00 +00:00

Rôle

Epic 0.1.0 — cadrer et livrer la gestion de la suppression des utilisateurs / dossiers / enfants / AM, avec garde-fous métier et règles de cascade.

Jusqu’ici la 0.1.0 a surtout couvert création et modification. La suppression (et ses implications) reste largement ouverte : un mauvais delete peut orpheliner des enfants, casser un dossier, ou supprimer trop large.

Problématique

Exemples de questions à trancher puis implémenter :

Action	Questions
Supprimer un parent	Et s’il est le seul responsable d’un enfant ? Et s’il y a un co-parent ? Supprime-t-on le dossier ? Les enfants ? Ou seulement le compte user + liens ?
Supprimer un enfant	Détacher parents / AM d’abord ? Placement actif chez une AM ?
Supprimer une AM	Placements enfants actifs ? Repasser les enfants en `sans_garde` ?
Supprimer un dossier (`numero_dossier`)	Soft refuse vs hard delete ? Impact validation / reprise ?
Supprimer un gestionnaire	Déjà partiellement géré (#143 auto-suppression) — cascade relais ?

Rappel doc : détacher ≠ supprimer (enfants_parents) — au moins un responsable par enfant (#115).

État actuel (constat)

Zone	État
`DELETE /users/:id`	Existe (super_admin) — cascade métier peu cadrée
`DELETE /enfants/:id`	Existe — garde-fous à renforcer
`DELETE /assistantes-maternelles/:id`	Existe
Attach/detach parent↔enfant / AM↔enfant	Livré (#115/#131) — pas équivalent à delete compte
Front dashboard	#133 ouvert — suppression compte parent + AM (UI)
Auto-suppression gestionnaire	Corrigé (#143)

Objectifs de l’epic

Matrice de décisions produit (que fait-on dans chaque cas ?)
API alignée : erreurs métier explicites (409/400), pas de delete silencieux dangereux
UI : confirmations claires, messages d’impact (« X enfants resteraient sans responsable »)
Découper en tickets enfants (back / front / BDD si besoin)

Sous-tickets à créer (brouillon)

Spec / matrice règles de suppression (parent, enfant, AM, dossier, gestionnaire)
Backend — suppression parent + garde-fous co-parent / dernier responsable
Backend — suppression enfant (liens parents, placements AM)
Backend — suppression AM (clôture placements, statuts enfants)
Backend — suppression / clôture dossier (si distinct du user)
Frontend — confirmations + branchement dashboard (étend #133)
Tests cas limites (dernier parent, enfant en garde, fratrie multi-parents)

Ticket déjà lié : #133 [Frontend] Suppression compte parent + AM (dashboard).

Hors scope (sauf décision contraire)

Soft-delete / archivage RGPD long terme (peut être phase 2)
Audit trail complet → plutôt #128
Famille complexe N responsables → #139

Critères d'acceptation (epic)

Matrice produit écrite et validée
Impossible de laisser un enfant sans responsable via une suppression
Suppression AM ne laisse pas de placements actifs orphelins
UI : confirmation + message d’erreur métier compréhensible
Tickets enfants créés et assignés milestone 0.1.0

Milestone

0.1.0

## Rôle **Epic 0.1.0** — cadrer et livrer la **gestion de la suppression** des utilisateurs / dossiers / enfants / AM, avec **garde-fous métier** et règles de cascade. Jusqu’ici la 0.1.0 a surtout couvert **création** et **modification**. La suppression (et ses implications) reste **largement ouverte** : un mauvais delete peut orpheliner des enfants, casser un dossier, ou supprimer trop large. --- ## Problématique Exemples de questions à trancher puis implémenter : | Action | Questions | |--------|-----------| | Supprimer un **parent** | Et s’il est le **seul** responsable d’un enfant ? Et s’il y a un co-parent ? Supprime-t-on le **dossier** ? Les **enfants** ? Ou seulement le compte user + liens ? | | Supprimer un **enfant** | Détacher parents / AM d’abord ? Placement actif chez une AM ? | | Supprimer une **AM** | Placements enfants actifs ? Repasser les enfants en `sans_garde` ? | | Supprimer un **dossier** (`numero_dossier`) | Soft refuse vs hard delete ? Impact validation / reprise ? | | Supprimer un **gestionnaire** | Déjà partiellement géré (#143 auto-suppression) — cascade relais ? | Rappel doc : **détacher ≠ supprimer** (`enfants_parents`) — au moins un responsable par enfant (#115). --- ## État actuel (constat) | Zone | État | |------|------| | `DELETE /users/:id` | Existe (super_admin) — cascade métier **peu cadrée** | | `DELETE /enfants/:id` | Existe — garde-fous à renforcer | | `DELETE /assistantes-maternelles/:id` | Existe | | Attach/detach parent↔enfant / AM↔enfant | Livré (#115/#131) — **pas** équivalent à delete compte | | Front dashboard | **#133** ouvert — suppression compte parent + AM (UI) | | Auto-suppression gestionnaire | Corrigé (#143) | --- ## Objectifs de l’epic 1. **Matrice de décisions produit** (que fait-on dans chaque cas ?) 2. **API** alignée : erreurs métier explicites (409/400), pas de delete silencieux dangereux 3. **UI** : confirmations claires, messages d’impact (« X enfants resteraient sans responsable ») 4. Découper en **tickets enfants** (back / front / BDD si besoin) --- ## Sous-tickets à créer (brouillon) - [ ] Spec / matrice règles de suppression (parent, enfant, AM, dossier, gestionnaire) - [ ] Backend — suppression **parent** + garde-fous co-parent / dernier responsable - [ ] Backend — suppression **enfant** (liens parents, placements AM) - [ ] Backend — suppression **AM** (clôture placements, statuts enfants) - [ ] Backend — suppression / clôture **dossier** (si distinct du user) - [ ] Frontend — confirmations + branchement dashboard (**étend #133**) - [ ] Tests cas limites (dernier parent, enfant en garde, fratrie multi-parents) Ticket déjà lié : **#133** `[Frontend] Suppression compte parent + AM (dashboard)`. --- ## Hors scope (sauf décision contraire) - Soft-delete / archivage RGPD long terme (peut être phase 2) - Audit trail complet → plutôt **#128** - Famille complexe N responsables → **#139** --- ## Critères d'acceptation (epic) - [ ] Matrice produit écrite et validée - [ ] Impossible de laisser un enfant **sans responsable** via une suppression - [ ] Suppression AM ne laisse pas de placements actifs orphelins - [ ] UI : confirmation + message d’erreur métier compréhensible - [ ] Tickets enfants créés et assignés milestone **0.1.0** ## Milestone **0.1.0**

jmartin added this to the 0.1.0 milestone 2026-07-17 15:05:00 +00:00

jmartin added the