docs: rationalisation post-0.1.0 (bilan, purge tmp, archives).
- Bilan 29 + index versions 05 ; suivi tickets pointeur Gitea - Purge docs/tmp et archive/temporaires livrés - Archive SuperNounou, liste tickets figée, backlog Phase 2, notes 14/92 - Suppression stubs PROCEDURE/22 ; INDEX et roadmap alignés Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
Cursor
@@ -1,244 +0,0 @@
|
||||
# #112 — Alignement front après évolution back (reprise dossier complet)
|
||||
|
||||
**Branche déployée :** `feature/112-reprise-apres-refus-front`
|
||||
**Commit back :** `d70577b1` — `feat(#112): reprise après refus — dossier complet GET/PATCH`
|
||||
**Date :** 2026-06-16
|
||||
|
||||
Ce document décrit le **contrat API réel** après extension du back, et ce que le front doit encore brancher pour exploiter le dossier complet (au-delà de l’identité seule).
|
||||
|
||||
---
|
||||
|
||||
## 1. Endpoints (inchangés côté URL)
|
||||
|
||||
| Méthode | Route | Auth |
|
||||
|---------|-------|------|
|
||||
| `GET` | `/api/v1/auth/reprise-dossier?token={uuid}` | Public |
|
||||
| `PATCH` | `/api/v1/auth/reprise-resoumettre` | Public |
|
||||
| `POST` | `/api/v1/auth/reprise-identify` | Public (inchangé) |
|
||||
|
||||
> **Note :** le ticket #111 parlait de `PUT` ; l’implémentation reste en **`PATCH`** (comme avant).
|
||||
|
||||
---
|
||||
|
||||
## 2. `GET /auth/reprise-dossier` — réponse enrichie
|
||||
|
||||
### Champs communs (toujours présents)
|
||||
|
||||
Identiques à avant : `id`, `email`, `prenom`, `nom`, `telephone`, `adresse`, `ville`, `code_postal`, `numero_dossier`, `role`, `photo_url`, `genre`, `situation_familiale`.
|
||||
|
||||
### Rôle `parent` (+ champs #119)
|
||||
|
||||
Alignés sur `DossierFamilleCompletDto` :
|
||||
|
||||
```json
|
||||
{
|
||||
"parents": [
|
||||
{
|
||||
"user_id": "uuid",
|
||||
"email": "…",
|
||||
"prenom": "…",
|
||||
"nom": "…",
|
||||
"telephone": "…",
|
||||
"adresse": "…",
|
||||
"ville": "…",
|
||||
"code_postal": "…",
|
||||
"statut": "refuse",
|
||||
"co_parent_id": "uuid-parent-entity"
|
||||
}
|
||||
],
|
||||
"enfants": [
|
||||
{
|
||||
"id": "uuid-enfant",
|
||||
"first_name": "Emma",
|
||||
"last_name": "MARTIN",
|
||||
"genre": "F",
|
||||
"status": "actif",
|
||||
"birth_date": "2023-02-15T00:00:00.000Z",
|
||||
"due_date": null,
|
||||
"photo_url": "/uploads/photos/…",
|
||||
"consent_photo": true,
|
||||
"est_multiple": false
|
||||
}
|
||||
],
|
||||
"texte_motivation": "Nous recherchons…"
|
||||
}
|
||||
```
|
||||
|
||||
**Mapping front suggéré :**
|
||||
|
||||
| JSON back | Modèle / wizard parent |
|
||||
|-----------|-------------------------|
|
||||
| `parents[]` | `UserRegistrationData.parent1` + `parent2` (matcher par `email` ou ordre : titulaire = `id` du GET racine) |
|
||||
| `enfants[].first_name` / `last_name` | `ChildData.firstName` / `lastName` |
|
||||
| `enfants[].birth_date` | `ChildData.birthDate` (ISO → `DateTime`) |
|
||||
| `enfants[].due_date` | `ChildData.dueDate` (enfant `a_naitre`) |
|
||||
| `enfants[].status` | `actif` = né, `a_naitre` = à naître |
|
||||
| `enfants[].photo_url` | `ApiConfig.absoluteMediaUrl()` + conserver pour reprise sans re-upload |
|
||||
| `enfants[].id` | **Obligatoire** pour le PATCH (update par id) |
|
||||
| `enfants[].est_multiple` | `grossesse_multiple` si utilisé |
|
||||
| `texte_motivation` | étape présentation / motivation |
|
||||
|
||||
Si `numero_dossier` absent : pas de `parents[]` / `enfants[]` / `texte_motivation` (identité seule).
|
||||
|
||||
### Rôle `assistante_maternelle`
|
||||
|
||||
Champs racine + fiche pro (structure **aplatie**, pas de sous-objet `user`) :
|
||||
|
||||
```json
|
||||
{
|
||||
"consentement_photo": true,
|
||||
"date_naissance": "1985-03-12T00:00:00.000Z",
|
||||
"lieu_naissance_ville": "Paris",
|
||||
"lieu_naissance_pays": "France",
|
||||
"numero_agrement": "AGR-2024-12345",
|
||||
"nir": "123456789012345",
|
||||
"date_agrement": "2024-06-01T00:00:00.000Z",
|
||||
"nb_max_enfants": 4,
|
||||
"place_disponible": 2,
|
||||
"biographie": "…"
|
||||
}
|
||||
```
|
||||
|
||||
**Mapping `AmRegistrationData` :**
|
||||
|
||||
| JSON back | Champ front |
|
||||
|-----------|-------------|
|
||||
| `nb_max_enfants` | `capaciteAccueil` |
|
||||
| `place_disponible` | `placesDisponibles` |
|
||||
| `numero_agrement` | `numeroAgrement` |
|
||||
| `biographie` | `biographie` / présentation |
|
||||
| `photo_url` | déjà géré via `RepriseSession.photoUrl` |
|
||||
|
||||
---
|
||||
|
||||
## 3. `PATCH /auth/reprise-resoumettre` — body étendu
|
||||
|
||||
### Commun
|
||||
|
||||
```json
|
||||
{ "token": "uuid-reprise" }
|
||||
```
|
||||
|
||||
### Parent — champs à envoyer depuis le wizard
|
||||
|
||||
| Champ PATCH | Source wizard | Notes |
|
||||
|-------------|---------------|-------|
|
||||
| `prenom`, `nom`, `telephone`, `adresse`, `ville`, `code_postal` | Parent 1 (titulaire token) | Champs racine |
|
||||
| `co_parent_prenom`, `co_parent_nom`, `co_parent_telephone` | Parent 2 | |
|
||||
| `co_parent_meme_adresse`, `co_parent_adresse`, `co_parent_code_postal`, `co_parent_ville` | Parent 2 adresse | |
|
||||
| `texte_motivation` **ou** `presentation_dossier` | Étape motivation | Les deux alias acceptés |
|
||||
| `enfants[]` | Liste enfants | Voir ci-dessous |
|
||||
|
||||
**Structure `enfants[]` (miroir inscription + `id` obligatoire) :**
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "uuid-enfant-existant",
|
||||
"prenom": "Emma",
|
||||
"nom": "MARTIN",
|
||||
"date_naissance": "2023-02-15",
|
||||
"date_previsionnelle_naissance": null,
|
||||
"genre": "F",
|
||||
"photo_base64": "data:image/jpeg;base64,…",
|
||||
"photo_filename": "emma.jpg",
|
||||
"grossesse_multiple": false
|
||||
}
|
||||
```
|
||||
|
||||
- **v1 back :** update par `id` uniquement — pas de création/suppression d’enfant.
|
||||
- Si `id` inconnu pour ce dossier → **400** `Enfant inconnu pour ce dossier : {id}`.
|
||||
- Sans nouvelle photo : ne pas envoyer `photo_base64` (l’existant est conservé).
|
||||
|
||||
### AM — champs à envoyer
|
||||
|
||||
| Champ PATCH | Source |
|
||||
|-------------|--------|
|
||||
| Identité + `photo_url` ou `photo_base64` + `photo_filename` | Étapes 1–2 |
|
||||
| `consentement_photo`, `date_naissance`, `lieu_naissance_ville`, `lieu_naissance_pays` | Identité |
|
||||
| `numero_agrement`, `nir`, `date_agrement` | Pro |
|
||||
| `capacite_accueil`, `places_disponibles` | Pro |
|
||||
| `biographie` | Présentation |
|
||||
|
||||
Validation NIR identique à l’inscription si `nir` fourni.
|
||||
|
||||
### Réponse succès (nouveau format)
|
||||
|
||||
```json
|
||||
{
|
||||
"message": "Dossier resoumis avec succès. Il est de nouveau en attente de validation.",
|
||||
"statut": "en_attente",
|
||||
"user_id": "uuid",
|
||||
"numero_dossier": "2026-000021"
|
||||
}
|
||||
```
|
||||
|
||||
Code HTTP : **200** (pas de corps `Users` brut comme l’ancien back).
|
||||
|
||||
### Effet métier
|
||||
|
||||
- **Parent :** tous les users `role=parent` avec le même `numero_dossier` passent en `en_attente` ; `token_reprise` invalidé sur **tous** (symétrique refus #110).
|
||||
- **AM :** un seul user.
|
||||
|
||||
### E-mail accusé resoumission (parent)
|
||||
|
||||
Après `PATCH` réussi, un e-mail est envoyé à **chaque parent** du dossier (`sendResoumissionPendingEmail`) :
|
||||
- confirmation de resoumission ;
|
||||
- rappel du **numéro de dossier** ;
|
||||
- mention « en attente de validation ».
|
||||
|
||||
Échec SMTP : logué, **ne bloque pas** la resoumission (même règle que l'inscription initiale).
|
||||
|
||||
---
|
||||
|
||||
## 4. Fichiers front à modifier (checklist)
|
||||
|
||||
### Modèles
|
||||
|
||||
- [ ] `lib/models/reprise_dossier.dart` — parser `parents[]`, `enfants[]`, `texte_motivation`, champs AM
|
||||
- [ ] Réutiliser ou mapper vers `DossierFamilleEnfant` / structures existantes (#119 admin) si possible
|
||||
|
||||
### Session / préremplissage
|
||||
|
||||
- [ ] `lib/services/reprise_session.dart`
|
||||
- `applyToParent` : remplir parent1/parent2 depuis `parents[]`, enfants, motivation
|
||||
- `applyToAm` : remplir tous les champs AM
|
||||
|
||||
### API
|
||||
|
||||
- [ ] `lib/services/auth_service.dart` — `resoumettreReprise()` : accepter body complet (parent + AM), pas seulement identité
|
||||
- [ ] Étendre `UserRegistrationData` / `AmRegistrationData` helpers `toReprisePatchBody()` si utile
|
||||
|
||||
### Écrans fin de parcours
|
||||
|
||||
- [ ] `parent_register_step5_screen.dart` — PATCH avec co-parent, enfants, motivation
|
||||
- [ ] `am_register_step4_screen.dart` — PATCH avec fiche AM complète
|
||||
|
||||
### Hors scope back (inchangé)
|
||||
|
||||
RIB / IBAN / attestation CAF (étape 5 wizard parent) : **non persistés** — rien à envoyer en reprise.
|
||||
|
||||
### Non implémenté front (ticket #112 initial)
|
||||
|
||||
- [ ] Modale login « J’ai un numéro de dossier » → `POST /auth/reprise-identify` (back prêt, front absent)
|
||||
|
||||
---
|
||||
|
||||
## 5. Tests manuels suggérés
|
||||
|
||||
1. Refuser un dossier parent complet (≥1 enfant + co-parent + motivation).
|
||||
2. Ouvrir le lien mail `/reprise?token=…`.
|
||||
3. Vérifier dans DevTools que le GET contient `enfants[]` et `texte_motivation`.
|
||||
4. Après branchement front : wizard prérempli sur toutes les étapes.
|
||||
5. Resoumettre → statut `en_attente` pour les deux parents ; dossier visible file validation admin (#119).
|
||||
|
||||
---
|
||||
|
||||
## 6. Références code back
|
||||
|
||||
```
|
||||
backend/src/routes/auth/dto/reprise-dossier.dto.ts
|
||||
backend/src/routes/auth/dto/resoumettre-reprise.dto.ts
|
||||
backend/src/routes/auth/dto/enfant-reprise.dto.ts
|
||||
backend/src/routes/auth/auth.service.ts → getRepriseDossier, resoumettreReprise
|
||||
backend/src/routes/parents/dto/dossier-famille-complet.dto.ts
|
||||
```
|
||||
@@ -1,89 +0,0 @@
|
||||
# Mini-spec API — POST /parents/dossier (#129)
|
||||
|
||||
Contrat pour le **plan front** (wizard création dossier famille staff).
|
||||
|
||||
Miroir de **#156** (`POST /assistantes-maternelles/dossier`).
|
||||
|
||||
## Endpoint
|
||||
|
||||
| | |
|
||||
|--|--|
|
||||
| **Méthode** | `POST` |
|
||||
| **URL** | `{base}/parents/dossier` |
|
||||
| **Auth** | Bearer JWT |
|
||||
| **Rôles** | `gestionnaire`, `administrateur`, `super_admin` |
|
||||
| **Content-Type** | `application/json` |
|
||||
|
||||
Ne **pas** appeler `POST /auth/register/parent` depuis le dashboard.
|
||||
|
||||
## Body (JSON)
|
||||
|
||||
Aligné `RegisterParentCompletDto`, **sans** CGU/privacy obligatoires (acceptées serveur).
|
||||
|
||||
### Parent 1 (obligatoire)
|
||||
|
||||
| Champ | Type | Obligatoire | Notes |
|
||||
|-------|------|-------------|--------|
|
||||
| `email` | string | oui | unique |
|
||||
| `prenom` | string | oui | |
|
||||
| `nom` | string | oui | |
|
||||
| `telephone` | string | oui | `0X…` ou `+33…` |
|
||||
| `adresse` | string | non | |
|
||||
| `code_postal` | string | non | |
|
||||
| `ville` | string | non | |
|
||||
|
||||
### Co-parent (optionnel)
|
||||
|
||||
`co_parent_email`, `co_parent_prenom`, `co_parent_nom`, `co_parent_telephone`,
|
||||
`co_parent_meme_adresse`, `co_parent_adresse`, `co_parent_code_postal`, `co_parent_ville`.
|
||||
|
||||
Si co-parent fourni : e-mail distinct ; mêmes règles téléphone / adresse que register.
|
||||
|
||||
### Enfants (≥ 1)
|
||||
|
||||
| Champ | Type | Notes |
|
||||
|-------|------|--------|
|
||||
| `enfants` | `EnfantInscriptionDto[]` | `prenom`, `nom`, `date_naissance` / `date_previsionnelle_naissance`, `genre`, `photo_base64`, `photo_filename`, etc. |
|
||||
|
||||
### Présentation
|
||||
|
||||
| Champ | Type | Obligatoire |
|
||||
|-------|------|-------------|
|
||||
| `presentation_dossier` | string | non (max 2000) |
|
||||
|
||||
## Réponses
|
||||
|
||||
### 201 Created
|
||||
|
||||
```json
|
||||
{
|
||||
"message": "Dossier famille créé et validé. Un e-mail de création de mot de passe a été envoyé.",
|
||||
"numero_dossier": "2026-000043",
|
||||
"parent_user_id": "uuid-pivot",
|
||||
"co_parent_user_id": "uuid-ou-null",
|
||||
"statut": "actif",
|
||||
"enfant_ids": ["uuid", "..."]
|
||||
}
|
||||
```
|
||||
|
||||
Effets serveur : user(s) parent **actif**, fiches `parents`, enfants + foyer, n° dossier,
|
||||
**e-mail création MDP** pour chaque compte sans MDP (pas d’accusé « en attente »).
|
||||
|
||||
### Erreurs
|
||||
|
||||
| Code | Cas |
|
||||
|------|-----|
|
||||
| 400 | Validation DTO / métier (enfants vides, dates, etc.) |
|
||||
| 401 | Token manquant / invalide |
|
||||
| 403 | Rôle non staff |
|
||||
| 409 | Conflit e-mail (pivot et/ou co-parent) |
|
||||
|
||||
## Front
|
||||
|
||||
- `UserService.createParentDossier(body)` → cet endpoint
|
||||
- Wizard create basé sur `ValidationFamilyWizard`
|
||||
- Ne pas envoyer `acceptation_cgu` / `acceptation_privacy` (optionnels)
|
||||
|
||||
## Branche
|
||||
|
||||
`feature/129-creation-dossier-parent`
|
||||
@@ -1,73 +0,0 @@
|
||||
# Mini-spec API — POST /parents/:id/co-parent (#135)
|
||||
|
||||
Contrat back pour l’ajout d’un **2ᵉ parent** sur un foyer mono-parent (staff).
|
||||
|
||||
## Endpoint
|
||||
|
||||
| | |
|
||||
|--|--|
|
||||
| **Méthode** | `POST` |
|
||||
| **URL** | `{base}/api/v1/parents/{parentUserId}/co-parent` |
|
||||
| **Auth** | Bearer JWT |
|
||||
| **Rôles** | `gestionnaire`, `administrateur`, `super_admin` |
|
||||
| **Succès** | **201** |
|
||||
|
||||
`parentUserId` = UUID du **parent pivot** (déjà dans le dossier).
|
||||
|
||||
Ne **pas** appeler `POST /auth/register/parent` ni `POST /parents/dossier`.
|
||||
|
||||
---
|
||||
|
||||
## Body (JSON)
|
||||
|
||||
| Champ | Type | Obligatoire | Notes |
|
||||
|-------|------|-------------|--------|
|
||||
| `email` | string | oui | unique |
|
||||
| `prenom` | string | oui | |
|
||||
| `nom` | string | oui | |
|
||||
| `telephone` | string | oui | `0X…` ou `+33…` |
|
||||
| `meme_adresse` | bool | non | défaut **true** → copie adresse du pivot |
|
||||
| `adresse` | string | si `meme_adresse=false` | |
|
||||
| `code_postal` | string | si `meme_adresse=false` | |
|
||||
| `ville` | string | si `meme_adresse=false` | |
|
||||
|
||||
---
|
||||
|
||||
## Comportement 201
|
||||
|
||||
- User co-parent **actif** + token création MDP
|
||||
- Fiche `parents` + liens pivot ↔ co-parent + même `numero_dossier`
|
||||
- Enfants du foyer rattachés au co-parent
|
||||
- E-mail **création MDP** (pas mail « en attente »)
|
||||
|
||||
```json
|
||||
{
|
||||
"message": "Co-parent ajouté au foyer. Un e-mail de création de mot de passe a été envoyé.",
|
||||
"numero_dossier": "2026-000043",
|
||||
"parent_user_id": "uuid-pivot",
|
||||
"co_parent_user_id": "uuid-co",
|
||||
"statut": "actif"
|
||||
}
|
||||
```
|
||||
|
||||
## Erreurs
|
||||
|
||||
| Code | Cas |
|
||||
|------|-----|
|
||||
| 400 | Déjà un co-parent / 2 responsables / validation adresse |
|
||||
| 401 | Token invalide |
|
||||
| 403 | Rôle non staff |
|
||||
| 404 | Pivot introuvable |
|
||||
| 409 | Email déjà pris |
|
||||
|
||||
## Réemploi édition identité
|
||||
|
||||
| Endpoint | Usage |
|
||||
|----------|--------|
|
||||
| `GET /dossiers/:numero` | Préremplir wizard edit |
|
||||
| `PATCH /parents/:id/fiche` | Sauver identité pivot / co-parent existant |
|
||||
| `PATCH /assistantes-maternelles/:id/fiche` | Édition AM |
|
||||
|
||||
## Branche
|
||||
|
||||
`feature/135-edition-dossier`
|
||||
@@ -1,83 +0,0 @@
|
||||
# Mini-spec front — Mode édition dossier + ajout 2ᵉ parent (#135)
|
||||
|
||||
Branche : `feature/135-edition-dossier`
|
||||
Ticket : **#135** (full-stack)
|
||||
|
||||
Prérequis : **#153** (liste Dossiers) livré.
|
||||
|
||||
---
|
||||
|
||||
## Objectif
|
||||
|
||||
1. Clic sur un dossier (liste #153) → ouvrir le wizard en mode **`edit`**
|
||||
2. Foyer **mono-parent** : page co-parent → **switch** ajouter un 2ᵉ parent
|
||||
3. Sauvegarder les champs via APIs existantes + nouvel endpoint co-parent
|
||||
|
||||
---
|
||||
|
||||
## Modes wizard
|
||||
|
||||
| Mode | Famille | AM |
|
||||
|------|---------|-----|
|
||||
| `review` | déjà | déjà |
|
||||
| `create` | déjà (#129) | déjà (#156) |
|
||||
| **`edit`** | **à faire** | **à faire** |
|
||||
|
||||
Factories : `ParentDossierWizard.edit(...)` / `AmDossierWizard.edit(...)`
|
||||
Préremplir via `UserService.getDossierByNumero(numero)`.
|
||||
|
||||
---
|
||||
|
||||
## APIs
|
||||
|
||||
| Action | Endpoint |
|
||||
|--------|----------|
|
||||
| Charger | `GET /dossiers/:numero` |
|
||||
| Sauver parent | `PATCH /parents/:id/fiche` |
|
||||
| Sauver AM | `PATCH /assistantes-maternelles/:id/fiche` |
|
||||
| **Ajouter co-parent** | **`POST /parents/:pivotUserId/co-parent`** — voir `docs/tmp/135-contrat-api-ajout-co-parent.md` |
|
||||
|
||||
Body co-parent :
|
||||
|
||||
```json
|
||||
{
|
||||
"email": "thomas@…",
|
||||
"prenom": "Thomas",
|
||||
"nom": "MARTIN",
|
||||
"telephone": "0678456789",
|
||||
"meme_adresse": true
|
||||
}
|
||||
```
|
||||
|
||||
`UserService.addCoParent(pivotUserId, body)` → cet endpoint.
|
||||
|
||||
---
|
||||
|
||||
## UX
|
||||
|
||||
- Depuis `DossiersManagementWidget` / carte liste : clic → edit (plus seulement review pending)
|
||||
- Pending : garder validation (review) ; dossiers actifs → edit
|
||||
- Mono-parent : switch « Ajouter un co-parent » (comme create) → au save, `POST …/co-parent` si nouveau
|
||||
- Déjà 2 parents : éditer les deux fiches ; pas de 3ᵉ
|
||||
- Pas de bouton créer dans l’onglet Dossiers
|
||||
|
||||
---
|
||||
|
||||
## Hors scope
|
||||
|
||||
- Famille N responsables (#139)
|
||||
- Suppressions (#154)
|
||||
- Création dossier initial (#129 / #156)
|
||||
|
||||
---
|
||||
|
||||
## Critères d’acceptation
|
||||
|
||||
- [ ] Clic dossier actif → wizard edit prérempli
|
||||
- [ ] PATCH fiche enregistre les modifs
|
||||
- [ ] Mono-parent + switch → co-parent créé (actif + mail MDP)
|
||||
- [ ] review / create inchangés
|
||||
|
||||
## Branche
|
||||
|
||||
`feature/135-edition-dossier`
|
||||
@@ -1,65 +0,0 @@
|
||||
# Mini-spec — Suppression complète grossesse multiple / `est_multiple`
|
||||
|
||||
**Ticket** : **#152** — https://git.ptits-pas.fr/jmartin/petitspas/issues/152
|
||||
**Branche** : `feature/152-remove-est-multiple` (depuis `develop`)
|
||||
**Périmètre** : **full stack** — BDD + back + front + scripts + docs. **Aucun fantôme.**
|
||||
|
||||
---
|
||||
|
||||
## Décision
|
||||
|
||||
On **supprime tout**. Pas de DTO « ignorés », pas de compat payload.
|
||||
|
||||
`forbidNonWhitelisted: true` ⇒ back et front **partent ensemble** (même feature / même déploiement).
|
||||
|
||||
---
|
||||
|
||||
## Alias retirés
|
||||
|
||||
`est_multiple` · `is_multiple` · `grossesse_multiple` · `multipleBirth` · `estMultiple` · `isMultiple` · `jumeau_multiple`
|
||||
|
||||
---
|
||||
|
||||
## Back / BDD (fait sur la branche)
|
||||
|
||||
- [x] Migration `database/migrations/2026_drop_enfants_est_multiple.sql`
|
||||
- [x] `BDD.sql`, seeds, CSV test
|
||||
- [x] Entity `Children` sans colonne
|
||||
- [x] DTO create/inscription/réponse/dossier famille **sans** le champ
|
||||
- [x] Services auth / enfants / parents : plus de mapping
|
||||
- [x] Prisma legacy `isMultiple` retiré
|
||||
|
||||
## Front (fait sur la branche)
|
||||
|
||||
- [x] Modèles admin / dossier / inscription
|
||||
- [x] Payloads inscription + reprise
|
||||
- [x] Modale enfant + wizard dossier famille
|
||||
- [x] Step3 inscription parent
|
||||
|
||||
## Scripts / docs
|
||||
|
||||
- [x] `tests/scripts/register-parent-*.mjs`
|
||||
- [x] `docs/10_DATABASE.md`, `docs/99_REGLES-CODAGE.md`
|
||||
- Docs tmp/archive #112 : mentions historiques OK (archive)
|
||||
|
||||
---
|
||||
|
||||
## Déploiement
|
||||
|
||||
1. Appliquer la migration SQL sur la BDD vivante
|
||||
2. Deploy back **et** front de cette branche
|
||||
3. Smoke : création enfant staff, inscription parent, reprise, wizard famille
|
||||
|
||||
## Vérif
|
||||
|
||||
```bash
|
||||
rg -n 'est_multiple|is_multiple|grossesse_multiple|multipleBirth|estMultiple|isMultiple|jumeau_multiple' \
|
||||
backend/src frontend/lib database tests/scripts docs/10_DATABASE.md docs/99_REGLES-CODAGE.md
|
||||
```
|
||||
→ **0** hit (hors ce fichier mini-spec / archives).
|
||||
|
||||
## Hors scope
|
||||
|
||||
- Métier futur « fratrie / jumeaux » → nouveau ticket
|
||||
- #155 rename Admin*
|
||||
- Ticket modales staff
|
||||
@@ -1,77 +0,0 @@
|
||||
# Mini-spec API — GET /dossiers (#153)
|
||||
|
||||
Contrat pour le **plan front** (onglet permanent Dossiers).
|
||||
|
||||
## Endpoint
|
||||
|
||||
| | |
|
||||
|--|--|
|
||||
| **Méthode** | `GET` |
|
||||
| **URL** | `{base}/api/v1/dossiers` |
|
||||
| **Auth** | Bearer JWT |
|
||||
| **Rôles** | `gestionnaire`, `administrateur`, `super_admin` |
|
||||
| **Query** | `q` (optionnel) — recherche n° / libellé / email |
|
||||
|
||||
Complète `GET /dossiers/:numeroDossier` (#119) déjà existant.
|
||||
|
||||
---
|
||||
|
||||
## Réponse 200
|
||||
|
||||
Tableau de lignes (1 entrée = 1 `numero_dossier`) :
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"type": "famille",
|
||||
"numero_dossier": "2026-000043",
|
||||
"libelle": "Claire MARTIN & Thomas MARTIN",
|
||||
"emails": ["claire@test.fr", "thomas@test.fr"],
|
||||
"user_ids": ["uuid-pivot", "uuid-co"],
|
||||
"statut": "actif",
|
||||
"a_valider": false,
|
||||
"date_reference": "2026-01-12T10:00:00.000Z"
|
||||
},
|
||||
{
|
||||
"type": "assistante_maternelle",
|
||||
"numero_dossier": "2026-000042",
|
||||
"libelle": "Marie DUPONT",
|
||||
"emails": ["marie@test.fr"],
|
||||
"user_ids": ["uuid-am"],
|
||||
"statut": "en_attente",
|
||||
"a_valider": true,
|
||||
"date_reference": "2026-02-01T08:00:00.000Z"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
### Champs
|
||||
|
||||
| Champ | Notes |
|
||||
|-------|--------|
|
||||
| `type` | `famille` \| `assistante_maternelle` |
|
||||
| `numero_dossier` | Clé d’unité |
|
||||
| `libelle` | Noms formatés (foyer : `A & B`) |
|
||||
| `emails` / `user_ids` | Membres du foyer ou AM |
|
||||
| `statut` | Agrégé : `en_attente` si au moins un user pending |
|
||||
| `a_valider` | `true` si pending → section haute UI |
|
||||
| `date_reference` | `MIN(cree_le)` des users |
|
||||
|
||||
**Tri** : `a_valider` d’abord, puis `numero_dossier` décroissant.
|
||||
|
||||
**Famille** : dédupliquée par `numero_dossier` (pivot + co-parent = 1 ligne).
|
||||
|
||||
---
|
||||
|
||||
## Front
|
||||
|
||||
- `UserService.getDossiers({ q? })` → cet endpoint
|
||||
- Section haute : filtrer `a_valider == true` **ou** continuer pending APIs existantes
|
||||
- Section basse : liste complète (ou hors pending selon règle UX)
|
||||
- Clic → `GET /dossiers/:numero` (détail) / validation review
|
||||
|
||||
Composition client `getParents`+`getAM` **plus nécessaire** si cet endpoint est déployé.
|
||||
|
||||
## Branche
|
||||
|
||||
`feature/153-onglet-dossiers`
|
||||
@@ -1,167 +0,0 @@
|
||||
# Mini-spec front — Onglet permanent « Dossiers » (#153)
|
||||
|
||||
Branche Git (front + back) : `feature/153-onglet-dossiers`
|
||||
Ticket Gitea : **#153** (ticket normal, plus epic)
|
||||
|
||||
> Suite prévue : **#135** = au clic, mode **édition** wizard + ajout 2ᵉ parent.
|
||||
> **#153** = onglet + listes + navigation / validation pending. **Pas** de création, **pas** d’édition complète.
|
||||
|
||||
---
|
||||
|
||||
## Contexte / objectif
|
||||
|
||||
Remplacer l’onglet conditionnel **« À valider »** (apparaît/disparaît selon pending) par un onglet **permanent « Dossiers »** dans le dashboard admin/gestionnaire.
|
||||
|
||||
Quand on ouvre **Dossiers** :
|
||||
|
||||
1. **En haut** — section **Dossiers à valider** (AM + familles pending)
|
||||
2. **En dessous** — liste de **tous les dossiers** (familles **et** AM), 1 ligne = 1 `numero_dossier`
|
||||
3. Différenciation visuelle famille vs AM : **couleur + icône**
|
||||
4. **Barre de recherche** (n° dossier, nom, email…)
|
||||
|
||||
**Pas** de bouton « Créer un dossier » ici (création via **+ Parents** #129 / **+ Asmat** #156).
|
||||
|
||||
---
|
||||
|
||||
## UX cible
|
||||
|
||||
### Onglets dashboard (`UserManagementPanel`)
|
||||
|
||||
| Avant (#107) | Après (#153) |
|
||||
|--------------|--------------|
|
||||
| « À valider » **conditionnel** si pending | **« Dossiers » toujours visible** (admin + gestionnaire) |
|
||||
| Contenu = seulement pending | Pending **en haut** + liste complète **en bas** |
|
||||
|
||||
Ordre suggéré des onglets :
|
||||
|
||||
`Dossiers` | `Parents` | `Enfants` | `Assistantes maternelles` | `Gestionnaires` | (`Administrateurs`)
|
||||
|
||||
### Section haute — À valider
|
||||
|
||||
- Réutiliser / adapter `PendingValidationWidget` (ou extraire la liste dans un sous-widget).
|
||||
- Sources déjà branchées :
|
||||
- `UserService.getPendingUsers(role: 'assistante_maternelle')`
|
||||
- `UserService.getPendingFamilies()`
|
||||
- Clic ligne pending → **`ValidationDossierModal`** / wizards `.review` (inchangé).
|
||||
- Si section vide : ne pas afficher de gros vide ; masquer la section ou message court « Aucun dossier en attente ».
|
||||
|
||||
### Section basse — Tous les dossiers
|
||||
|
||||
1 ligne = **1 dossier** (`numero_dossier`), type :
|
||||
|
||||
| Type | Libellé UI | Couleur (suggestion) |
|
||||
|------|------------|----------------------|
|
||||
| `famille` | Famille / Parents | teinte existante parents (ex. violet / rose dashboard) |
|
||||
| `assistante_maternelle` | AM | teinte existante AM (ex. teal / bleu) |
|
||||
|
||||
Colonnes / infos utiles (cartes style `AdminUserCard` ou lignes type pending) :
|
||||
|
||||
- n° dossier
|
||||
- type (pastille couleur + icône)
|
||||
- libellé (noms parents ou AM)
|
||||
- email(s) principal(aux)
|
||||
- statut user / dossier si dispo (`actif`, `en_attente`, …)
|
||||
- date utile si dispo
|
||||
|
||||
**Déduplication** : un foyer (pivot + co-parent) = **une** ligne famille (même `numero_dossier`). Idem AM.
|
||||
|
||||
### Recherche
|
||||
|
||||
- La search bar du panel (aujourd’hui désactivée / hint « pas de recherche » sur À valider) doit **filtrer la liste unifiée** (et idéalement aussi le pending affiché).
|
||||
- Critères **minimum** : `numero_dossier`, nom, prénom, email.
|
||||
- Harmoniser le hint : `Rechercher un dossier (n°, nom, email)…`
|
||||
|
||||
### État vide liste complète
|
||||
|
||||
Aide optionnelle : *« Pour créer un dossier → onglet Parents (+ Parents) ou Assistantes maternelles (+ Asmat) »*.
|
||||
|
||||
### Clic sur un dossier de la liste complète (#153)
|
||||
|
||||
| Cas | Comportement #153 |
|
||||
|-----|-------------------|
|
||||
| Pending | Ouvrir validation (review) — déjà en place |
|
||||
| Dossier **actif** / non pending | Ouvrir consultation via `GET /dossiers/:numeroDossier` (`UserService.getDossierByNumero`) en **lecture / review** si possible **sans** save édition |
|
||||
|
||||
**Ne pas** implémenter le mode `edit` ni le switch 2ᵉ parent → **#135**.
|
||||
|
||||
Si l’ouverture « review » d’un dossier actif est trop lourde pour ce ticket : clic peut temporairement no-op / snackbar *« Édition dossier : prochainement (#135) »* — **à éviter** si `getDossierByNumero` + wizard review marche déjà pour les deux types.
|
||||
|
||||
---
|
||||
|
||||
## Données / APIs (front)
|
||||
|
||||
### Déjà disponibles (préférer composer côté front pour #153)
|
||||
|
||||
| Besoin | API / service |
|
||||
|--------|----------------|
|
||||
| Pending AM | `getPendingUsers(role: assistante_maternelle)` |
|
||||
| Pending familles | `getPendingFamilies()` |
|
||||
| Parents (avec `numero_dossier`) | `getParents()` |
|
||||
| AM (avec `numero_dossier`) | `getAssistantesMaternelles()` |
|
||||
| Détail unifié | `getDossierByNumero(numero)` → `GET /dossiers/:numeroDossier` |
|
||||
|
||||
**Pas d’endpoint `GET /dossiers` liste** aujourd’hui. Pour #153 :
|
||||
|
||||
- Construire la liste unifiée **côté client** à partir de `getParents()` + `getAssistantesMaternelles()` (group by `numero_dossier`).
|
||||
- Exclure ou marquer les pending déjà dans la section haute (éviter doublons visuels, ou les laisser dans les deux avec badge « à valider » — **préférence** : pending **uniquement** en haut ; liste basse = tous **hors** pending **ou** tous avec badge ; choisir une règle claire et documenter dans le PR).
|
||||
|
||||
**Règle recommandée** :
|
||||
- Haut = pending only
|
||||
- Bas = **tous** les dossiers ayant un `numero_dossier` (y compris pending) **OU** bas = non-pending only
|
||||
→ **Recommandation produit** : bas = **tous** (vision complète), pending aussi en haut pour action rapide. Si doublon gênant : bas = non-pending only.
|
||||
|
||||
### Si le back ajoute plus tard `GET /dossiers`
|
||||
|
||||
Brancher `UserService.getDossiers()` — hors scope bloquant #153 front si composition client OK.
|
||||
|
||||
---
|
||||
|
||||
## Fichiers front probables
|
||||
|
||||
| Fichier | Rôle |
|
||||
|---------|------|
|
||||
| `frontend/lib/widgets/admin/user_management_panel.dart` | Onglet permanent **Dossiers** ; retirer logique conditionnelle À valider ; search sur cet onglet |
|
||||
| `frontend/lib/widgets/admin/pending_validation_widget.dart` | Réemploi section haute (ou refactor léger) |
|
||||
| **Nouveau** `…/dossiers_management_widget.dart` (nom libre) | Shell onglet : pending + liste unifiée + refresh |
|
||||
| **Nouveau** modèle léger `DossierListItem` (type, numero, libelle, emails, statut…) | Mapping parents/AM → ligne |
|
||||
| `user_service.dart` / `api_config.dart` | Seulement si helper `getDossiersUnified()` côté client (pas forcément nouvel endpoint) |
|
||||
| `validation_dossier_modal.dart` | Réemploi ouverture pending / détail |
|
||||
|
||||
Réutiliser look & feel cartes / hover « Ouvrir » de `_PendingValidationRow` / `AdminUserCard`.
|
||||
|
||||
---
|
||||
|
||||
## Hors scope (#153)
|
||||
|
||||
- Bouton créer dossier
|
||||
- Mode `edit` wizard + ajout 2ᵉ parent → **#135**
|
||||
- Suppressions → **#154**
|
||||
- Famille N responsables → **#139**
|
||||
- Changer les onglets Parents / AM / Enfants (restent)
|
||||
|
||||
---
|
||||
|
||||
## Critères d’acceptation front
|
||||
|
||||
- [ ] Onglet **Dossiers** toujours visible (même 0 pending)
|
||||
- [ ] Plus d’onglet conditionnel **« À valider »**
|
||||
- [ ] Section haute pending si non vide ; validation au clic OK
|
||||
- [ ] Liste unifiée familles + AM en dessous ; 1 ligne / `numero_dossier`
|
||||
- [ ] Couleur + icône différencient famille / AM
|
||||
- [ ] Recherche filtre (n° + nom + email minimum)
|
||||
- [ ] **Aucun** bouton créer dans cet onglet
|
||||
- [ ] Pas de régression validation pending (valider / refuser)
|
||||
|
||||
---
|
||||
|
||||
## Back (info — Cursor back séparé si besoin)
|
||||
|
||||
- Liste unifiée : **pas bloquante** si composition front
|
||||
- Optionnel : `GET /api/v1/dossiers` (liste) pour perf / pagination plus tard
|
||||
- `GET /dossiers/:numero` déjà là (#119)
|
||||
|
||||
---
|
||||
|
||||
## Branche
|
||||
|
||||
`feature/153-onglet-dossiers` (depuis `develop`)
|
||||
@@ -1,35 +0,0 @@
|
||||
# Matrice suppression — #154 / back **#159** / front **#160**
|
||||
|
||||
**Statut** : cadrage PO validé (sept. 2026)
|
||||
**Milestone** : 0.1.0
|
||||
**Email** : pas d’email de suppression (cas rare)
|
||||
|
||||
## Droits
|
||||
|
||||
| Cible | Qui peut supprimer |
|
||||
|-------|-------------------|
|
||||
| Dossier / parent / enfant / AM | `GESTIONNAIRE`, `ADMINISTRATEUR`, `SUPER_ADMIN` |
|
||||
| Gestionnaire (user) | `ADMINISTRATEUR`, `SUPER_ADMIN` |
|
||||
| Administrateur (user) | Autre admin OK ; **self interdit** ; **dernier admin** = `SUPER_ADMIN` only ; `SUPER_ADMIN` non supprimable |
|
||||
|
||||
## Matrice métier
|
||||
|
||||
| Point d’entrée | Action | Effet |
|
||||
|----------------|--------|--------|
|
||||
| Dossiers | Delete dossier **famille** | Tous **parents** + tous **enfants** ; clore placements AM des enfants |
|
||||
| Dossiers / AM | Delete dossier **AM** ou compte AM | **Compte AM + dossier AM** ; enfants **conservés** ; placements **clos** |
|
||||
| Parents | Co-parent (autre parent reste) | Compte parent seul ; dossier + enfants restent |
|
||||
| Parents | Dernier parent | Parent + **enfants** rattachés |
|
||||
| Enfants | Pas dernier | Enfant seul (retiré du dossier) |
|
||||
| Enfants | Dernier + `deleteDossier=true` | Cascade dossier famille (parents + enfants) |
|
||||
| Enfants | Dernier + `deleteDossier=false` | Enfant seul ; dossier peut apparaître **`sans_enfant`** |
|
||||
| Pending / validé | — | **Mêmes règles** (pas de différenciation) |
|
||||
|
||||
## Warning
|
||||
|
||||
- `sans_enfant` sur liste `GET /dossiers` (dossier famille sans enfant lié).
|
||||
- Miroir de `sans_responsable` (#157) côté enfants.
|
||||
|
||||
## Hors scope
|
||||
|
||||
Soft-delete RGPD, audit (#128), famille N (#139), restriction admin-only métier (plus tard).
|
||||
@@ -1,169 +0,0 @@
|
||||
# Mini-spec front — Suppressions dashboard
|
||||
|
||||
**Ticket front** : **#160** — https://git.ptits-pas.fr/jmartin/petitspas/issues/160
|
||||
**Ticket back** : **#159** — https://git.ptits-pas.fr/jmartin/petitspas/issues/159
|
||||
**Epic** : #154 (complète #133)
|
||||
**Branche back** : `feature/159-suppressions-backend`
|
||||
**Doc matrice** : [154-matrice-suppression.md](./154-matrice-suppression.md)
|
||||
|
||||
Travail **en parallèle** : ce contrat est la source de vérité UI ↔ API.
|
||||
|
||||
---
|
||||
|
||||
## UX commune
|
||||
|
||||
Sur chaque ligne / carte des listes :
|
||||
|
||||
- Icône **poubelle** en bout de ligne
|
||||
- Clic → **dialog de confirmation** (texte d’impact) → DELETE → **refresh** liste
|
||||
- Pending = **mêmes** règles que validés
|
||||
- **Pas** d’email
|
||||
|
||||
| Liste | Poubelle visible si |
|
||||
|-------|---------------------|
|
||||
| Dossiers, Parents, Enfants, AM | gestionnaire **ou** admin |
|
||||
| Gestionnaires | **admin** only |
|
||||
| Administrateurs | admin+ ; **pas** sur sa propre ligne ; dernier admin : UI warning + réservé super_admin |
|
||||
|
||||
---
|
||||
|
||||
## Contrat API
|
||||
|
||||
Base : auth Bearer. Erreurs : `400` / `403` / `404` / `409` avec `message` FR.
|
||||
|
||||
### 1. `DELETE /dossiers/:numeroDossier`
|
||||
|
||||
- **Famille** → supprime tous parents + enfants du n° ; clos placements AM des enfants.
|
||||
- **AM** → compte AM + dossier AM ; enfants gardés ; placements clos.
|
||||
|
||||
**Réponse 200** (exemple) :
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "famille",
|
||||
"numero_dossier": "2026-000043",
|
||||
"deleted_user_ids": ["…"],
|
||||
"deleted_enfant_ids": ["…"],
|
||||
"message": "Dossier famille supprimé."
|
||||
}
|
||||
```
|
||||
|
||||
ou
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "assistante_maternelle",
|
||||
"numero_dossier": "2026-000015",
|
||||
"deleted_user_ids": ["…"],
|
||||
"deleted_enfant_ids": [],
|
||||
"message": "Dossier assistante maternelle supprimé."
|
||||
}
|
||||
```
|
||||
|
||||
**Dialog UI** : lister libellé + n° + « X parent(s), Y enfant(s) » (ou « compte AM, enfants conservés »).
|
||||
|
||||
---
|
||||
|
||||
### 2. `DELETE /users/:id`
|
||||
|
||||
Comportement selon le **rôle** de la cible :
|
||||
|
||||
| Cible | Effet |
|
||||
|-------|--------|
|
||||
| Parent **co-parent** | Delete ce user seul |
|
||||
| Parent **dernier** du dossier | Delete user + enfants du foyer |
|
||||
| AM | Delete user AM + dossier AM ; enfants conservés ; placements clos |
|
||||
| Gestionnaire | Admin only ; self → 403 |
|
||||
| Administrateur | Self → 403 ; dernier admin → super_admin only sinon 403 ; super_admin → 403 |
|
||||
|
||||
**Réponse 200** :
|
||||
|
||||
```json
|
||||
{
|
||||
"deleted_user_ids": ["…"],
|
||||
"deleted_enfant_ids": ["…"],
|
||||
"message": "…"
|
||||
}
|
||||
```
|
||||
|
||||
**Dialogs** :
|
||||
|
||||
- Co-parent : « Ce parent sera retiré / supprimé du dossier {n°}. Les enfants restent avec le co-parent. »
|
||||
- Dernier parent : « Dernier parent du dossier {n°}. Les enfants rattachés seront aussi supprimés. »
|
||||
- AM : « Le compte et le dossier AM seront supprimés. Les enfants accueillis ne seront pas supprimés. »
|
||||
|
||||
Optionnel (si exposé) : `GET /users/:id/suppression-impact` — sinon calculer depuis données déjà en liste / détail dossier.
|
||||
|
||||
---
|
||||
|
||||
### 3. `DELETE /enfants/:id?deleteDossier=true|false`
|
||||
|
||||
- Pas dernier enfant → delete enfant (`deleteDossier` ignoré ou false).
|
||||
- Dernier enfant + `deleteDossier=false` → delete enfant ; dossier famille peut passer `sans_enfant`.
|
||||
- Dernier enfant + `deleteDossier=true` → cascade dossier famille (parents + enfants).
|
||||
|
||||
**Réponse 200** :
|
||||
|
||||
```json
|
||||
{
|
||||
"deleted_enfant_ids": ["…"],
|
||||
"deleted_user_ids": ["…"],
|
||||
"dossier_supprime": false,
|
||||
"message": "…"
|
||||
}
|
||||
```
|
||||
|
||||
**Dialog** :
|
||||
|
||||
- Standard : « L’enfant sera supprimé du dossier de {famille} ({n°}). »
|
||||
- Dernier : proposer **deux actions** :
|
||||
1. Supprimer l’enfant seulement (`deleteDossier=false`)
|
||||
2. Supprimer aussi le dossier / parents (`deleteDossier=true`)
|
||||
|
||||
Pour savoir si dernier : compter enfants du `numero_dossier` (détail dossier ou champ impact API).
|
||||
|
||||
---
|
||||
|
||||
### 4. `GET /dossiers` — flag `sans_enfant`
|
||||
|
||||
Chaque item famille peut exposer :
|
||||
|
||||
```json
|
||||
"sans_enfant": true
|
||||
```
|
||||
|
||||
- `true` si dossier **famille** sans enfant lié.
|
||||
- AM : `false` ou omis.
|
||||
|
||||
**UI** : badge / warning vigilance (comme `sans_responsable` / alertes AM).
|
||||
|
||||
---
|
||||
|
||||
## UserService (Flutter) — signatures cibles
|
||||
|
||||
```dart
|
||||
Future<void> deleteDossier(String numeroDossier);
|
||||
Future<Map<String, dynamic>> deleteUser(String userId);
|
||||
Future<Map<String, dynamic>> deleteEnfant(String enfantId, {bool deleteDossier = false});
|
||||
```
|
||||
|
||||
(Adapter le parsing au JSON réel une fois le back mergé ; en parallèle, stubber sur ce contrat.)
|
||||
|
||||
---
|
||||
|
||||
## Fichiers front probables
|
||||
|
||||
- Cartes listes : `admin_user_card.dart`, `admin_enfant_user_card.dart`, cartes dossiers
|
||||
- Listes : `dossiers_management_widget.dart`, `parent_managmant_widget.dart`, `enfant_management_widget.dart`, `assistante_maternelle_management_widget.dart`, `gestionnaire_management_widget.dart`, `admin_management_widget.dart`
|
||||
- `user_service.dart`
|
||||
|
||||
---
|
||||
|
||||
## Critères front (#160)
|
||||
|
||||
- [ ] Poubelle selon droits
|
||||
- [ ] Confirmations avec impact
|
||||
- [ ] Refresh après succès
|
||||
- [ ] Dernier enfant : choix dossier oui/non
|
||||
- [ ] Warning `sans_enfant`
|
||||
- [ ] Self-admin / dernier admin gérés côté UI (masquer ou message 403)
|
||||
@@ -1,54 +0,0 @@
|
||||
# Mini-spec — Rename préfixe `Admin*` dashboard partagé (#155)
|
||||
|
||||
**Ticket** : **#155**
|
||||
**Branche** : `feature/155-rename-admin-prefix-dashboard` (depuis `develop`)
|
||||
**Décision naming** : **option C** — dossier neutre `widgets/dashboard/` + noms **sans** préfixe `Admin`.
|
||||
|
||||
---
|
||||
|
||||
## Principe
|
||||
|
||||
Les widgets partagés **admin + gestionnaire** ne doivent plus s’appeler `Admin*`.
|
||||
On garde `Admin*` seulement là où c’est vraiment le rôle administrateur.
|
||||
|
||||
## Gardé `Admin*` (hors rename)
|
||||
|
||||
| Élément | Raison |
|
||||
|---------|--------|
|
||||
| `AdminManagementWidget` | Onglet **Administrateurs** |
|
||||
| `screens/administrateurs/*` | `AdminDashboardScreen`, `AdminCreateDialog`, `AdminUserFormDialog` |
|
||||
| `EnfantAdminModel` | Modèle API (pas un widget) — hors scope ticket |
|
||||
|
||||
## Renames faits
|
||||
|
||||
| Avant | Après |
|
||||
|-------|--------|
|
||||
| `widgets/admin/common/admin_child_detail_modal.dart` → `AdminChildDetailModal` | `widgets/dashboard/child_detail_modal.dart` → `ChildDetailModal` |
|
||||
| `admin_am_edit_modal` → `AdminAmEditModal` | `am_edit_modal` → `AmEditModal` |
|
||||
| `admin_parent_edit_modal` → `AdminParentEditModal` | `parent_edit_modal` → `ParentEditModal` |
|
||||
| `admin_user_card` → `AdminUserCard` | `user_card` → `UserCard` |
|
||||
| `admin_enfant_user_card` → `AdminEnfantUserCard` | `enfant_user_card` → `EnfantUserCard` |
|
||||
| `admin_am_photo_frame` → `AdminAmPhotoFrame` | `am_photo_frame` → `AmPhotoFrame` |
|
||||
| `admin_am_children_capacity_grid` | `am_children_capacity_grid` → `AmChildrenCapacityGrid` |
|
||||
| `admin_children_affiliation_panel` | `children_affiliation_panel` → `ChildrenAffiliationPanel` |
|
||||
| `admin_select_*` / `AdminSelect*` / `AdminFamilleFoyer` | `select_*` / `Select*` / `FamilleFoyer` |
|
||||
| `admin_status_capsule` | `status_capsule` → `StatusCapsule` |
|
||||
| `admin_list_state` → `AdminListState` | `user_list_state` → `UserListState` |
|
||||
| `admin_detail_modal` → `AdminDetailModal` / `AdminDetailField` | `detail_modal` → `DetailModal` / `DetailField` |
|
||||
| `dashboard_admin.dart` | `user_management_sub_bar.dart` (`DashboardUserManagementSubBar` inchangé) |
|
||||
|
||||
Dossier `widgets/admin/` conserve encore les panels métier (`user_management_panel`, wizards, etc.) + `AdminManagementWidget`.
|
||||
|
||||
**Phase 2** (même ticket #155) : déplacer ces panels → `widgets/dashboard/` — voir [155-suite-move-admin-panels-to-dashboard.md](./155-suite-move-admin-panels-to-dashboard.md).
|
||||
|
||||
## Hors scope
|
||||
|
||||
- Refonte UX modales (ticket dédié)
|
||||
- Rename API / back
|
||||
- Déplacer tout `widgets/admin/` → `widgets/dashboard/` (panels) — possible follow-up
|
||||
|
||||
## Critères
|
||||
|
||||
- [x] Plus de préfixe `Admin` sur les composants **partagés** listés
|
||||
- [ ] Build Flutter / recette dashboard admin + gestionnaire OK
|
||||
- [x] Pas de changement comportemental (rename mécanique)
|
||||
@@ -1,203 +0,0 @@
|
||||
# Mini-spec — Déplacer les panels `widgets/admin/` → `widgets/dashboard/`
|
||||
|
||||
**Ticket** : **#155** (phase 2 — même ticket que le rename `Admin*`)
|
||||
**Phase 1** : widgets `Admin*` → `widgets/dashboard/` (déjà sur `feature/155-rename-admin-prefix-dashboard`)
|
||||
**Branche** : poursuivre / rebaser `feature/155-rename-admin-prefix-dashboard` (ou nouvelle branche depuis `develop` après merge phase 1)
|
||||
**Nature** : rename / move mécanique — **zéro** changement UX / métier
|
||||
|
||||
---
|
||||
|
||||
## Contexte
|
||||
|
||||
Après la phase 1 (#155), la situation est **hybride** :
|
||||
|
||||
| Emplacement | Contenu |
|
||||
|-------------|---------|
|
||||
| `widgets/dashboard/` | Composants partagés sans préfixe `Admin*` (modales, cartes, selects, sub-bar…) |
|
||||
| `widgets/admin/` | **Panels** du dashboard staff (listes, wizards, validation, shell `UserManagementPanel`…) + `AdminManagementWidget` |
|
||||
|
||||
Le dossier `admin/` laisse encore croire « réservé administrateur », alors que **gestionnaire** consomme les mêmes panels (`GestionnaireDashboardScreen` → `UserManagementPanel`).
|
||||
|
||||
Ce ticket **termine l’option C** au niveau dossier : tout le dashboard staff vit sous `widgets/dashboard/`, sauf ce qui est **vraiment** rôle admin.
|
||||
|
||||
---
|
||||
|
||||
## Objectif
|
||||
|
||||
```
|
||||
frontend/lib/widgets/admin/<panels & common partagés>
|
||||
↓ git mv + update imports
|
||||
frontend/lib/widgets/dashboard/…
|
||||
```
|
||||
|
||||
Critère : un nouveau dev ne doit plus ouvrir `widgets/admin/` pour du code partagé admin+gestionnaire.
|
||||
|
||||
---
|
||||
|
||||
## Cible d’arborescence (proposée)
|
||||
|
||||
```
|
||||
widgets/dashboard/
|
||||
├── (déjà là #155) child_detail_modal.dart, am_edit_modal.dart, user_card.dart, …
|
||||
├── user_management_panel.dart ← shell onglets
|
||||
├── user_management_sub_bar.dart ← déjà déplacé #155
|
||||
├── dossiers_management_widget.dart
|
||||
├── dossier_list_card.dart
|
||||
├── parent_management_widget.dart ← corriger le typo managmant au passage ?
|
||||
├── enfant_management_widget.dart
|
||||
├── assistante_maternelle_management_widget.dart
|
||||
├── gestionnaire_management_widget.dart
|
||||
├── pending_validation_widget.dart
|
||||
├── parent_dossier_create_modal.dart
|
||||
├── parent_dossier_wizard.dart
|
||||
├── am_dossier_create_modal.dart
|
||||
├── am_dossier_wizard.dart
|
||||
├── validation_*.dart ← family/am wizards, refus, theme, confirm
|
||||
├── parametres_panel.dart ← utilisé par écran admin (OK dans dashboard)
|
||||
├── relais_management_panel.dart
|
||||
├── common/ ← sous-dossier optionnel
|
||||
│ ├── suppression_confirm_dialog.dart
|
||||
│ ├── user_list.dart
|
||||
│ └── validation_detail_section.dart
|
||||
└── …
|
||||
|
||||
widgets/admin/ ← mince, rôle admin seulement
|
||||
└── admin_management_widget.dart ← onglet Administrateurs
|
||||
```
|
||||
|
||||
### Variante B (plus stricte)
|
||||
|
||||
`AdminManagementWidget` + éventuels helpers purement admin →
|
||||
`screens/administrateurs/widgets/`
|
||||
et **suppression** du dossier `widgets/admin/`.
|
||||
|
||||
**Reco** : **variante A** (garder `widgets/admin/` minimal avec seulement `AdminManagementWidget`) — moins de churn screens, clair.
|
||||
|
||||
---
|
||||
|
||||
## Inventaire à déplacer (état actuel)
|
||||
|
||||
### Racine `widgets/admin/` → `widgets/dashboard/`
|
||||
|
||||
| Fichier actuel | Notes |
|
||||
|----------------|--------|
|
||||
| `user_management_panel.dart` | Shell partagé admin + gestionnaire |
|
||||
| `dossiers_management_widget.dart` | |
|
||||
| `dossier_list_card.dart` | |
|
||||
| `parent_managmant_widget.dart` | Typo historique `managmant` — **option** : renommer → `parent_management_widget.dart` dans le même ticket ou ticket typo séparé |
|
||||
| `enfant_management_widget.dart` | |
|
||||
| `assistante_maternelle_management_widget.dart` | |
|
||||
| `gestionnaire_management_widget.dart` | |
|
||||
| `pending_validation_widget.dart` | |
|
||||
| `parent_dossier_create_modal.dart` | |
|
||||
| `parent_dossier_wizard.dart` | |
|
||||
| `am_dossier_create_modal.dart` | |
|
||||
| `am_dossier_wizard.dart` | |
|
||||
| `validation_am_wizard.dart` | |
|
||||
| `validation_family_wizard.dart` | |
|
||||
| `validation_dossier_modal.dart` | |
|
||||
| `validation_modal_theme.dart` | |
|
||||
| `validation_refus_form.dart` | |
|
||||
| `validation_valider_confirm_dialog.dart` | |
|
||||
| `parametres_panel.dart` | Écran admin seulement, mais pas préfixé Admin — OK dashboard |
|
||||
| `relais_management_panel.dart` | |
|
||||
|
||||
### `widgets/admin/common/` → `widgets/dashboard/common/` (ou plat)
|
||||
|
||||
| Fichier | Notes |
|
||||
|---------|--------|
|
||||
| `suppression_confirm_dialog.dart` | Partagé (y compris `screens/administrateurs/creation/*`) |
|
||||
| `user_list.dart` | |
|
||||
| `validation_detail_section.dart` | |
|
||||
|
||||
### **Ne pas** déplacer
|
||||
|
||||
| Fichier | Destination |
|
||||
|---------|-------------|
|
||||
| `admin_management_widget.dart` | Reste `widgets/admin/` (ou variante B → screens) |
|
||||
|
||||
### Déjà fait (#155) — ne pas retraiter
|
||||
|
||||
Tout ce qui est déjà sous `widgets/dashboard/` (`child_detail_modal`, `am_edit_modal`, `user_card`, `select_*`, `user_management_sub_bar`, …).
|
||||
|
||||
---
|
||||
|
||||
## Consommateurs d’imports (à mettre à jour)
|
||||
|
||||
### Screens
|
||||
- `screens/administrateurs/admin_dashboardScreen.dart` — `UserManagementPanel`, `ParametresPanel`
|
||||
- `screens/gestionnaire/gestionnaire_dashboard_screen.dart` — `UserManagementPanel`
|
||||
- `screens/administrateurs/creation/admin_create.dart` — `suppression_confirm_dialog`
|
||||
- `screens/administrateurs/creation/gestionnaires_create.dart` — idem
|
||||
|
||||
### Widgets déjà en `dashboard/`
|
||||
- `am_edit_modal`, `child_detail_modal`, `parent_edit_modal`, `select_*` — imports vers `widgets/admin/common/*` ou panels
|
||||
|
||||
### Divers
|
||||
- `widgets/common/identity_block.dart` (si import admin)
|
||||
- Tous les fichiers **déplacés** entre eux (imports relatifs / package)
|
||||
|
||||
### Hors scope rename classes
|
||||
Sauf décision explicite sur le typo `parent_managmant_widget` → pas de rename de **classes** métier dans ce ticket (seulement chemins de fichiers + imports).
|
||||
`AdminManagementWidget` **conserve** son nom.
|
||||
|
||||
---
|
||||
|
||||
## Plan d’exécution
|
||||
|
||||
1. Partir de `feature/155-rename-admin-prefix-dashboard` (phase 1) **ou** `develop` si phase 1 déjà mergée
|
||||
2. `git mv` fichiers selon inventaire
|
||||
3. Remplacer globalement
|
||||
`package:p_tits_pas/widgets/admin/` → `package:p_tits_pas/widgets/dashboard/`
|
||||
**sauf** `…/widgets/admin/admin_management_widget.dart`
|
||||
4. Corriger imports relatifs cassés
|
||||
5. Grep de contrôle (ci-dessous)
|
||||
6. Build Flutter web (Docker) + smoke dashboard admin **et** gestionnaire
|
||||
7. Merge → squash master si flux habituel
|
||||
|
||||
---
|
||||
|
||||
## Vérifs
|
||||
|
||||
```bash
|
||||
# Plus de panels partagés sous admin (seul AdminManagement attendu)
|
||||
find frontend/lib/widgets/admin -name '*.dart'
|
||||
|
||||
# Plus d’imports panels vers l’ancien chemin (sauf AdminManagement)
|
||||
rg -n "widgets/admin/(user_management|dossiers_|parent_|enfant_|assistante|gestionnaire|pending|validation_|parametres|relais|am_dossier|parent_dossier|dossier_list|common/)" frontend/lib
|
||||
|
||||
# Screens OK
|
||||
rg -n "widgets/admin/" frontend/lib/screens
|
||||
```
|
||||
|
||||
Attendu screens : **0** hit vers panels ; éventuellement plus aucun hit `widgets/admin/` sauf si import explicite `AdminManagementWidget` depuis `user_management_panel` (chemin `widgets/admin/admin_management_widget.dart`).
|
||||
|
||||
---
|
||||
|
||||
## Hors scope
|
||||
|
||||
- Refonte UX des modales / panels (ticket dédié annoncé)
|
||||
- Rename `EnfantAdminModel`
|
||||
- Rename `screens/administrateurs/`
|
||||
- Rename `AdminUserFormDialog` / `AdminCreateDialog`
|
||||
- Changement API / back
|
||||
- #152 (`est_multiple`) — autre branche
|
||||
|
||||
---
|
||||
|
||||
## Critères d’acceptation
|
||||
|
||||
- [ ] Inventaire déplacé selon tableau
|
||||
- [ ] `widgets/admin/` ne contient plus que `admin_management_widget.dart` (variante A)
|
||||
- [ ] Imports screens + widgets à jour
|
||||
- [ ] Build Flutter OK
|
||||
- [ ] Recette : dashboard **administrateur** et **gestionnaire** (listes, ouverture fiches, validation, création dossier) sans régression
|
||||
- [ ] Aucun changement comportemental volontaire
|
||||
|
||||
---
|
||||
|
||||
## Risques / notes
|
||||
|
||||
- **Conflits de merge** si d’autres features touchent les panels → faire ce ticket quand la surface dashboard est calme (fin 0.1.0 OK)
|
||||
- Typo `parent_managmant_widget` : soit inclus (bonus), soit ticket cleanup 1-ligne séparé
|
||||
- Docs d’archive citant `widgets/admin/…` : pas obligatoire de mettre à jour ; `docs/27_BRIEFING-FRONTEND.md` oui si encore listé
|
||||
@@ -1,75 +0,0 @@
|
||||
# Mini-spec API — POST /assistantes-maternelles/dossier (#156)
|
||||
|
||||
Contrat pour le **plan front** (wizard création AM staff).
|
||||
|
||||
## Endpoint
|
||||
|
||||
| | |
|
||||
|--|--|
|
||||
| **Méthode** | `POST` |
|
||||
| **URL** | `{base}/assistantes-maternelles/dossier` |
|
||||
| **Auth** | Bearer JWT |
|
||||
| **Rôles** | `gestionnaire`, `administrateur`, `super_admin` |
|
||||
| **Content-Type** | `application/json` |
|
||||
|
||||
Ne **pas** appeler `POST /auth/register/am` depuis le dashboard.
|
||||
|
||||
## Body (JSON)
|
||||
|
||||
Aligné inscription AM publique, **sans** CGU/privacy obligatoires (acceptées serveur).
|
||||
|
||||
| Champ | Type | Obligatoire | Notes |
|
||||
|-------|------|-------------|--------|
|
||||
| `email` | string | oui | unique |
|
||||
| `prenom` | string | oui | |
|
||||
| `nom` | string | oui | |
|
||||
| `telephone` | string | oui | `0X…` ou `+33…` |
|
||||
| `adresse` | string | non | |
|
||||
| `code_postal` | string | non | |
|
||||
| `ville` | string | non | |
|
||||
| `photo_base64` | string | non | data-URL `data:image/…;base64,…` |
|
||||
| `photo_filename` | string | non | hint nom fichier |
|
||||
| `consentement_photo` | bool | oui | |
|
||||
| `date_naissance` | date ISO | non | `YYYY-MM-DD` |
|
||||
| `lieu_naissance_ville` | string | oui | |
|
||||
| `lieu_naissance_pays` | string | oui | |
|
||||
| `nir` | string | oui | 15 car. (Corse 2A/2B OK) |
|
||||
| `numero_agrement` | string | oui | unique |
|
||||
| `date_agrement` | date ISO | non | |
|
||||
| `capacite_accueil` | int | oui | 1–10 |
|
||||
| `places_disponibles` | int | oui | 0–10, ≤ capacité |
|
||||
| `biographie` | string | non | max 2000 |
|
||||
|
||||
## Réponses
|
||||
|
||||
### 201 Created
|
||||
|
||||
```json
|
||||
{
|
||||
"message": "Dossier AM créé et validé. Un e-mail de création de mot de passe a été envoyé.",
|
||||
"user_id": "uuid",
|
||||
"statut": "actif",
|
||||
"numero_dossier": "2026-000042"
|
||||
}
|
||||
```
|
||||
|
||||
Effets serveur : user AM **actif**, fiche `assistantes_maternelles`, n° dossier, **e-mail création MDP** (pas d’accusé « en attente »).
|
||||
|
||||
### Erreurs
|
||||
|
||||
| Code | Cas |
|
||||
|------|-----|
|
||||
| 400 | Validation / NIR / places > capacité |
|
||||
| 403 | Rôle non staff |
|
||||
| 409 | Email, NIR ou agrément déjà pris |
|
||||
| 401 | Token manquant / invalide |
|
||||
|
||||
## Front
|
||||
|
||||
- `UserService.createAmDossier(body)` → cet endpoint
|
||||
- Après 201 : refresh liste AM ; snackbar OK
|
||||
- Wizard create : ne pas envoyer `acceptation_cgu` / `acceptation_privacy` (optionnels)
|
||||
|
||||
## Branche
|
||||
|
||||
`feature/156-creation-dossier-am`
|
||||
@@ -1,14 +0,0 @@
|
||||
# Mini-spec — Uniformisation modale staff (Gestionnaire / Administrateur)
|
||||
|
||||
**Ticket** : **#164** — https://git.ptits-pas.fr/jmartin/petitspas/issues/164
|
||||
**Branche** : `feature/164-staff-modal-uniformisation` (depuis `develop`)
|
||||
**Périmètre** : **front only** — pas d’API / BDD
|
||||
**Milestone** : **0.1.0**
|
||||
|
||||
Voir le corps du ticket #164 pour la spec complète.
|
||||
|
||||
## Livré
|
||||
|
||||
- `frontend/lib/widgets/dashboard/staff_user_form_modal.dart` → `StaffUserFormModal`
|
||||
- Ancien `AdminUserFormDialog` / `gestionnaires_create.dart` retiré
|
||||
- Imports : `user_management_panel`, `gestionnaire_management_widget`, `admin_management_widget`
|
||||
Reference in New Issue
Block a user