From 71b1897678df1e69d4c3c2649d707fea935590eb Mon Sep 17 00:00:00 2001 From: Julien Martin Date: Mon, 14 Sep 2026 17:45:43 +0200 Subject: [PATCH] docs: rationalisation post-0.1.0 (bilan, purge tmp, archives). MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 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 --- docs/00_INDEX.md | 123 ++++----- docs/04_ROADMAP-GENERALE.md | 30 +-- docs/05_VERSIONS-ET-MILESTONES.md | 56 ++++ docs/22_DOCUMENTS-LEGAUX.md | 8 - docs/23_SUIVI-TICKETS.md | 12 + docs/24_DECISIONS-PROJET.md | 27 +- docs/28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md | 2 +- docs/29_BILAN-VERSION-0.1.0.md | 197 ++++++++++++++ docs/EVOLUTIONS_CDC.md | 12 +- docs/PROCEDURE-API-GITEA.md | 8 - docs/archive/README.md | 27 +- .../obsolete}/14_NOTE-BACKEND-CONFIG-SETUP.md | 0 .../obsolete}/23_LISTE-TICKETS.md | 0 .../obsolete}/25_PHASE-2-BACKLOG.md | 0 .../92_NOTE-BACKEND-GESTIONNAIRES.md | 0 docs/archive/obsolete/README.md | 16 +- ...rNounou_Cahier_Des_Charges_Complet_V1.1.md | 0 .../obsolete}/SuperNounou_SSS-001.md | 0 .../131-fiche-parent-co-parent-header.md | 127 --------- .../temporaires/POINT_TICKETS_FRONT_API.txt | 36 --- docs/archive/temporaires/README.md | 15 +- .../TEMP_112-back-reprise-alignement-front.md | 244 ------------------ .../TEMP_131-back-fiche-am-enfants.md | 132 ---------- .../TEMP_131-back-fiche-parent-co-parent.md | 124 --------- .../temporaires/TEMP_FRONT_alignement_AM.md | 46 ---- docs/tmp/112-back-reprise-alignement-front.md | 244 ------------------ docs/tmp/129-contrat-api-staff-parent.md | 89 ------- docs/tmp/135-contrat-api-ajout-co-parent.md | 73 ------ .../135-mini-spec-front-edition-dossier.md | 83 ------ docs/tmp/152-mini-spec-front-est-multiple.md | 65 ----- docs/tmp/153-contrat-api-liste-dossiers.md | 77 ------ docs/tmp/153-mini-spec-front-dossiers.md | 167 ------------ docs/tmp/154-matrice-suppression.md | 35 --- docs/tmp/154-mini-spec-front-suppression.md | 169 ------------ docs/tmp/155-mini-spec-rename-admin-prefix.md | 54 ---- ...55-suite-move-admin-panels-to-dashboard.md | 203 --------------- docs/tmp/156-contrat-api-staff-am.md | 75 ------ ...64-staff-modal-uniformisation-mini-spec.md | 14 - 38 files changed, 379 insertions(+), 2211 deletions(-) create mode 100644 docs/05_VERSIONS-ET-MILESTONES.md delete mode 100644 docs/22_DOCUMENTS-LEGAUX.md create mode 100644 docs/23_SUIVI-TICKETS.md create mode 100644 docs/29_BILAN-VERSION-0.1.0.md delete mode 100644 docs/PROCEDURE-API-GITEA.md rename docs/{ => archive/obsolete}/14_NOTE-BACKEND-CONFIG-SETUP.md (100%) rename docs/{ => archive/obsolete}/23_LISTE-TICKETS.md (100%) rename docs/{ => archive/obsolete}/25_PHASE-2-BACKLOG.md (100%) rename docs/{ => archive/obsolete}/92_NOTE-BACKEND-GESTIONNAIRES.md (100%) rename docs/{ => archive/obsolete}/SuperNounou_Cahier_Des_Charges_Complet_V1.1.md (100%) rename docs/{ => archive/obsolete}/SuperNounou_SSS-001.md (100%) delete mode 100644 docs/archive/temporaires/131-fiche-parent-co-parent-header.md delete mode 100644 docs/archive/temporaires/POINT_TICKETS_FRONT_API.txt delete mode 100644 docs/archive/temporaires/TEMP_112-back-reprise-alignement-front.md delete mode 100644 docs/archive/temporaires/TEMP_131-back-fiche-am-enfants.md delete mode 100644 docs/archive/temporaires/TEMP_131-back-fiche-parent-co-parent.md delete mode 100644 docs/archive/temporaires/TEMP_FRONT_alignement_AM.md delete mode 100644 docs/tmp/112-back-reprise-alignement-front.md delete mode 100644 docs/tmp/129-contrat-api-staff-parent.md delete mode 100644 docs/tmp/135-contrat-api-ajout-co-parent.md delete mode 100644 docs/tmp/135-mini-spec-front-edition-dossier.md delete mode 100644 docs/tmp/152-mini-spec-front-est-multiple.md delete mode 100644 docs/tmp/153-contrat-api-liste-dossiers.md delete mode 100644 docs/tmp/153-mini-spec-front-dossiers.md delete mode 100644 docs/tmp/154-matrice-suppression.md delete mode 100644 docs/tmp/154-mini-spec-front-suppression.md delete mode 100644 docs/tmp/155-mini-spec-rename-admin-prefix.md delete mode 100644 docs/tmp/155-suite-move-admin-panels-to-dashboard.md delete mode 100644 docs/tmp/156-contrat-api-staff-am.md delete mode 100644 docs/tmp/164-staff-modal-uniformisation-mini-spec.md diff --git a/docs/00_INDEX.md b/docs/00_INDEX.md index 7e5b9f6..6d96158 100644 --- a/docs/00_INDEX.md +++ b/docs/00_INDEX.md @@ -1,94 +1,77 @@ -# 📚 Index de la Documentation - PtitsPas App +# Index de la documentation — P'titsPas -Bienvenue dans la documentation complète de l'application PtitsPas. +Index de navigation du dépôt. Dernière révision : **septembre 2026** (clôture doc 0.1.0). -Ce fichier sert d'index pour naviguer dans toute la documentation du projet. +## Produit & versions -## 📖 Table des matières +| Doc | Contenu | +|-----|---------| +| [01 — Cahier des charges](./01_CAHIER-DES-CHARGES.md) | CDC actuel (V1.3) — amendement via **#117** | +| [EVOLUTIONS_CDC.md](./EVOLUTIONS_CDC.md) | Écarts CDC → app (intrant amendement) | +| [05 — Versions & milestones](./05_VERSIONS-ET-MILESTONES.md) | Semver Gitea + bilans | +| [29 — Bilan version 0.1.0](./29_BILAN-VERSION-0.1.0.md) | Tickets livrés 0.1.0 + thèmes | +| [04 — Roadmap générale](./04_ROADMAP-GENERALE.md) | Vision phases long terme | +| [28 — Évolution famille / responsables](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md) | Modèle dossier / foyer | -### 📋 Cahier des Charges -- [**01 - Cahier des Charges**](./01_CAHIER-DES-CHARGES.md) - Cahier des charges complet du projet P'titsPas (V1.3 - 24/11/2025) +## Architecture & infra -### Architecture & Infrastructure -- [**02 - Architecture**](./02_ARCHITECTURE.md) - Vue d'ensemble de l'architecture mono-repo et multi-conteneurs -- [**03 - Déploiement**](./03_DEPLOYMENT.md) - Guide complet de déploiement et configuration CI/CD +| Doc | Contenu | +|-----|---------| +| [02 — Architecture](./02_ARCHITECTURE.md) | Mono-repo, conteneurs | +| [03 — Déploiement](./03_DEPLOYMENT.md) | Deploy / CI-CD | +| [10 — Database](./10_DATABASE.md) | Schéma BDD | +| [11 — API](./11_API.md) | Endpoints REST | +| [21 — Configuration système](./21_CONFIGURATION-SYSTEME.md) | Config on-premise | +| [99 — Règles de codage](./99_REGLES-CODAGE.md) | Conventions | -### Planification -- [**04 - Roadmap Générale**](./04_ROADMAP-GENERALE.md) - Roadmap complète du projet (Phases 1 à 5+) +## Workflows & métier -### Développement -- [**10 - Database Schema**](./10_DATABASE.md) - Schéma de la base de données et modèles -- [**11 - API Documentation**](./11_API.md) - Documentation complète des endpoints REST -- [**14 - Note backend config setup**](./14_NOTE-BACKEND-CONFIG-SETUP.md) - Setup configuration -- [**92 - Note backend gestionnaires**](./92_NOTE-BACKEND-GESTIONNAIRES.md) - Gestionnaires -- [**99 - Règles de codage**](./99_REGLES-CODAGE.md) - Conventions de code +| Doc | Contenu | +|-----|---------| +| [20 — Workflow création de compte](./20_WORKFLOW-CREATION-COMPTE.md) | Inscription / validation | +| [juridique/](./juridique/README.md) | CGU / CGC / privacy + [22 technique](./juridique/22_DOCUMENTS-LEGAUX.md) | +| [CHARTE_GRAPHIQUE.md](./CHARTE_GRAPHIQUE.md) | Charte UI | -### Workflows Fonctionnels -- [**20 - Workflow Création de Compte**](./20_WORKFLOW-CREATION-COMPTE.md) - Workflow complet de création et validation des comptes utilisateurs -- [**21 - Configuration Système**](./21_CONFIGURATION-SYSTEME.md) - Configuration on-premise dynamique -- [**22 - Documents Légaux**](./juridique/22_DOCUMENTS-LEGAUX.md) - Gestion CGU/Privacy avec versioning +## Projet & outillage -### Juridique (sources & technique) -- [**Dossier juridique**](./juridique/README.md) - Index : CGU/CGC en Markdown, - export PDF, lien vers la doc technique n°22 +| Doc | Contenu | +|-----|---------| +| [23 — Suivi tickets](./23_SUIVI-TICKETS.md) | Pointeur Gitea (plus de liste figée) | +| [24 — Décisions projet](./24_DECISIONS-PROJET.md) | ADR / décisions | +| [26 — API Gitea](./26_GITEA-API.md) | Issues, PR, milestones | +| [27 — Briefing frontend](./27_BRIEFING-FRONTEND.md) | Accès Git, priorités | -### Projet & suivi (Gitea / tickets) -- [**23 - Liste des Tickets**](./23_LISTE-TICKETS.md) - 61 tickets Phase 1 détaillés -- [**24 - Décisions Projet**](./24_DECISIONS-PROJET.md) - Décisions architecturales et fonctionnelles -- [**25 - Backlog Phase 2**](./25_PHASE-2-BACKLOG.md) - Fonctionnalités techniques reportées -- [**28 - Évolution famille et responsables**](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md) - Modèle dossier/famille, recompositions, v1.0.0 vs post-1.0.0 -- [**26 - API Gitea**](./26_GITEA-API.md) - Procédure d'utilisation de l'API Gitea (issues, PR, branches, labels) -- [**27 - Briefing frontend**](./27_BRIEFING-FRONTEND.md) - Accès Git, priorités, scripts Gitea (token) +## Audit -### Archive & convention de nommage -- [**Dossier archive**](./archive/README.md) - Fichiers **sans** `NN_` déplacés - (temporaires, obsolètes) ; règles de rangement et suppression -- Pointeur : [PROCEDURE-API-GITEA.md](./PROCEDURE-API-GITEA.md) → voir **26** +| Doc | Contenu | +|-----|---------| +| [90 — Audit YNOV](./90_AUDIT.md) | Analyse code étudiant | -### Exceptions de nommage (racine `docs/`) -Fichiers **sans préfixe numérique** encore à la racine par **héritage** ou -références outils (`.cursorrules`, etc.) — **à renommer** en `NN_` quand -possible : -- `CHARTE_GRAPHIQUE.md` -- [`EVOLUTIONS_CDC.md`](./EVOLUTIONS_CDC.md) — écarts CDC / app ; voir aussi [**28 - Évolution famille**](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md) -- `SuperNounou_Cahier_Des_Charges_Complet_V1.1.md` -- `SuperNounou_SSS-001.md` +## Archive -### Administration (À créer) -- [**30 - Guide d'administration**](./30_ADMIN.md) - Gestion des utilisateurs, accès PgAdmin, logs -- [**31 - Troubleshooting**](./31_TROUBLESHOOTING.md) - Résolution des problèmes courants +| Emplacement | Usage | +|-------------|--------| +| [archive/](./archive/README.md) | Obsolete / temporaires | +| [archive/obsolete/](./archive/obsolete/) | CDC SuperNounou, ancienne liste tickets, backlog Phase 2 figé, notes ponctuelles | -### Frontend (À créer) -- [**40 - Frontend Flutter**](./40_FRONTEND.md) - Structure de l'application mobile/web +## Données de test -### Audit & Analyse -- [**90 - Audit du projet YNOV**](./90_AUDIT.md) - Analyse complète du code étudiant et fonctionnalités +| Doc | Contenu | +|-----|---------| +| [test-data/](./test-data/README.md) | Jeux utilisateurs test | -## 🚀 Quick Start +## Quick start ```bash -# Cloner le projet -git clone ssh://gitea-jmartin/jmartin/app.git ptitspas-app - -# Lancer l'environnement de développement +git clone … ptitspas-app cd ptitspas-app docker compose up -d - -# Accéder aux services -Frontend: https://app.ptits-pas.fr -API: https://app.ptits-pas.fr/api -PgAdmin: https://app.ptits-pas.fr/pgadmin +# Front https://app.ptits-pas.fr — API /api — PgAdmin /pgadmin ``` -## 🔗 Liens utiles +## Liens -- **Gitea** : https://git.ptits-pas.fr -- **Production** : https://app.ptits-pas.fr -- **Mail** : https://mail.ptits-pas.fr - -## 📝 Maintenance - -Cette documentation est maintenue par Julien Martin (julien.martin@ptits-pas.fr). - -Dernière mise à jour : Juin 2026 +- Gitea : https://git.ptits-pas.fr/jmartin/petitspas +- Prod : https://app.ptits-pas.fr +Mainteneur : Julien Martin (julien.martin@ptits-pas.fr). diff --git a/docs/04_ROADMAP-GENERALE.md b/docs/04_ROADMAP-GENERALE.md index 35c587d..2a00c50 100644 --- a/docs/04_ROADMAP-GENERALE.md +++ b/docs/04_ROADMAP-GENERALE.md @@ -44,22 +44,21 @@ Les **Phases 2, 3, 4+** sont des **ébauches indicatives** qui seront affinées - ✅ Logging & Monitoring - ✅ Tests & Documentation -### Versions incrémentales +### Versions incrémentales (semver / Gitea) -| Version | Objectif | Tickets | Estimation | -|---------|----------|---------|------------| -| **0.1.0** | MVP Fonctionnel | ~21 | ~45h | -| **0.2.0** | Sécurité & RGPD | ~10 | ~35h | -| **0.3.0** | Interfaces Complètes | ~17 | ~52h | -| **0.4.0** | Tests & Documentation | ~6 | ~24h | -| **0.5.0** | Monitoring & Optimisations | ~7 | ~17h | -| **1.0.0** | 🎉 **Release Phase 1** | **61** | **~173h** | +La table historique « ~21 tickets / 0.1.0 » est **obsolète**. +État réel des milestones, bilans et tag : **[05_VERSIONS-ET-MILESTONES.md](./05_VERSIONS-ET-MILESTONES.md)**. -### Livrable +| Version | Statut (sept. 2026) | +|---------|---------------------| +| **0.1.0** | **Terminée** — [bilan](./29_BILAN-VERSION-0.1.0.md) (48 tickets fermés) | +| **0.2.0+** | Ouvertes — voir Gitea + doc 05 | -Application installable avec création et validation de comptes utilisateurs. +### Livrable Phase 1 (visée) -**Référence** : [23_LISTE-TICKETS.md](./23_LISTE-TICKETS.md) +Application installable avec création et validation de comptes utilisateurs, puis enrichissements dashboard / dossiers (0.1.0 livré). + +**Tickets** : Gitea — pointeur [23_SUIVI-TICKETS.md](./23_SUIVI-TICKETS.md). --- @@ -216,7 +215,7 @@ Suivi quotidien des enfants + Fonctionnalités complémentaires. Application mature, optimisée et riche en fonctionnalités. -**Référence** : [25_PHASE-2-BACKLOG.md](./25_PHASE-2-BACKLOG.md) (anciennes fonctionnalités techniques) +**Référence** : [archive/obsolete/25_PHASE-2-BACKLOG.md](./archive/obsolete/25_PHASE-2-BACKLOG.md) (figé) + [05_VERSIONS-ET-MILESTONES.md](./05_VERSIONS-ET-MILESTONES.md) --- @@ -317,9 +316,10 @@ Exemples : - [00_INDEX.md](./00_INDEX.md) - Index général de la documentation - [01_CAHIER-DES-CHARGES.md](./01_CAHIER-DES-CHARGES.md) - Cahier des charges v1.3 - [20_WORKFLOW-CREATION-COMPTE.md](./20_WORKFLOW-CREATION-COMPTE.md) - Workflow création de comptes -- [23_LISTE-TICKETS.md](./23_LISTE-TICKETS.md) - Liste des 61 tickets Phase 1 +- [23_SUIVI-TICKETS.md](./23_SUIVI-TICKETS.md) / [29_BILAN-VERSION-0.1.0.md](./29_BILAN-VERSION-0.1.0.md) — suivi Gitea + bilan 0.1.0 - [24_DECISIONS-PROJET.md](./24_DECISIONS-PROJET.md) - Décisions architecturales -- [25_PHASE-2-BACKLOG.md](./25_PHASE-2-BACKLOG.md) - Anciennes fonctionnalités techniques +- [05_VERSIONS-ET-MILESTONES.md](./05_VERSIONS-ET-MILESTONES.md) — milestones Gitea +- [archive/obsolete/25_PHASE-2-BACKLOG.md](./archive/obsolete/25_PHASE-2-BACKLOG.md) — backlog Phase 2 figé --- diff --git a/docs/05_VERSIONS-ET-MILESTONES.md b/docs/05_VERSIONS-ET-MILESTONES.md new file mode 100644 index 0000000..1855284 --- /dev/null +++ b/docs/05_VERSIONS-ET-MILESTONES.md @@ -0,0 +1,56 @@ +# Versions & milestones — P'titsPas + +**Source de vérité tickets** : Gitea [`jmartin/petitspas`](https://git.ptits-pas.fr/jmartin/petitspas) +**Bilans de version** : documents `29_BILAN-…` (et suivants) + +Ce fichier remplace, pour le **semver / milestones**, les anciennes tables figées de la roadmap Phase 1. + +--- + +## État des milestones + +| Milestone | Rôle | Statut | +|-----------|------|--------| +| **0.1.0** | MVP opérable (auth, inscription, dashboard dossiers/fiches, suppressions, cleanups) | **Terminée** — [bilan](./29_BILAN-VERSION-0.1.0.md) | +| **0.2.0** | Suite produit (ex. recherche / échanges — sans contrat) | Ouverte | +| **0.3.0** | Contrat + planning | Ouverte | +| **0.4.0** | Carnet de liaison | Ouverte | +| **0.9.0** | Hors périmètre cleanup 0.1.0 (doublons, upload, tech auth/photos, UX erreurs…) | Ouverte | +| **1.0.0** | Release majeure Phase 1 (critères PO) | Réserve | +| **Backlog transverse** | Doc étendue, CI/tests, RGPD avancé, monitoring — hors semver dédié | Ouverte | + +Liens Gitea : [milestones](https://git.ptits-pas.fr/jmartin/petitspas/milestones). + +--- + +## Bilans + +| Version | Document | +|---------|----------| +| 0.1.0 | [29_BILAN-VERSION-0.1.0.md](./29_BILAN-VERSION-0.1.0.md) | + +--- + +## Relation avec la roadmap phases + +La vision long terme (Phases 2–5 : mise en relation, contrats, carnet…) reste dans [04_ROADMAP-GENERALE.md](./04_ROADMAP-GENERALE.md). +Les **jalons livrables** se gèrent ici + dans Gitea. + +Ancien backlog « Phase 2 » technique ([archive](./archive/obsolete/25_PHASE-2-BACKLOG.md)) : à croiser avec les milestones ci-dessus ; ne plus maintenir en double. + +--- + +## Suivi des tickets + +- **Création / état** : Gitea uniquement. +- **Mémoire d’une version livrée** : bilan `29_…` (pas de re-copie exhaustive dans un fichier tickets). +- Ancienne liste figée Phase 1 : [archive/obsolete/23_LISTE-TICKETS.md](./archive/obsolete/23_LISTE-TICKETS.md). +- Pointeur court : [23_SUIVI-TICKETS.md](./23_SUIVI-TICKETS.md). + +--- + +## Tag Git + +| Tag | Condition | +|-----|-----------| +| `v0.1.0` | Milestone 0.1.0 fermée + bilan mergé sur `master` | diff --git a/docs/22_DOCUMENTS-LEGAUX.md b/docs/22_DOCUMENTS-LEGAUX.md deleted file mode 100644 index c213372..0000000 --- a/docs/22_DOCUMENTS-LEGAUX.md +++ /dev/null @@ -1,8 +0,0 @@ -# Fichier déplacé - -La documentation **Documents légaux** a été déplacée vers : - -**[juridique/22_DOCUMENTS-LEGAUX.md](./juridique/22_DOCUMENTS-LEGAUX.md)** - -Voir aussi le dossier **[juridique/](./juridique/)** pour les sources **CGU** -et **CGC** en Markdown. diff --git a/docs/23_SUIVI-TICKETS.md b/docs/23_SUIVI-TICKETS.md new file mode 100644 index 0000000..6ad743b --- /dev/null +++ b/docs/23_SUIVI-TICKETS.md @@ -0,0 +1,12 @@ +# Suivi des tickets — P'titsPas + +**Source de vérité** : [Gitea — issues](https://git.ptits-pas.fr/jmartin/petitspas/issues) +**Milestones / versions** : [05_VERSIONS-ET-MILESTONES.md](./05_VERSIONS-ET-MILESTONES.md) +**API Gitea** : [26_GITEA-API.md](./26_GITEA-API.md) + +Ne plus maintenir de catalogue exhaustif des tickets dans le dépôt : l’état (ouvert / fermé / milestone) change dans Gitea. + +Pour une **version livrée**, lire le bilan correspondant (ex. [29_BILAN-VERSION-0.1.0.md](./29_BILAN-VERSION-0.1.0.md)). + +Archive historique (liste Phase 1 figée, avril 2026) : +[archive/obsolete/23_LISTE-TICKETS.md](./archive/obsolete/23_LISTE-TICKETS.md). diff --git a/docs/24_DECISIONS-PROJET.md b/docs/24_DECISIONS-PROJET.md index cf38376..32d16ae 100644 --- a/docs/24_DECISIONS-PROJET.md +++ b/docs/24_DECISIONS-PROJET.md @@ -423,31 +423,30 @@ ptitspas-app/ - Maintenance (tout au même endroit) - Versioning (Git) -**Structure** : +**Structure** (sept. 2026) : ``` docs/ ├── 00_INDEX.md ├── 01_CAHIER-DES-CHARGES.md ├── 02_ARCHITECTURE.md ├── 03_DEPLOYMENT.md +├── 04_ROADMAP-GENERALE.md +├── 05_VERSIONS-ET-MILESTONES.md ├── 10_DATABASE.md ├── 11_API.md ├── 20_WORKFLOW-CREATION-COMPTE.md ├── 21_CONFIGURATION-SYSTEME.md -├── 22_DOCUMENTS-LEGAUX.md # pointeur → juridique/ -├── 27_BRIEFING-FRONTEND.md -├── PROCEDURE-API-GITEA.md # pointeur → 26_GITEA-API.md -├── juridique/ -│ ├── README.md -│ ├── cgu.md -│ ├── cgc.md -│ └── 22_DOCUMENTS-LEGAUX.md -├── archive/ -│ ├── README.md -│ ├── temporaires/ -│ └── obsolete/ -├── 23_LISTE-TICKETS.md +├── 23_SUIVI-TICKETS.md ├── 24_DECISIONS-PROJET.md (ce document) +├── 26_GITEA-API.md +├── 27_BRIEFING-FRONTEND.md +├── 28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md +├── 29_BILAN-VERSION-0.1.0.md +├── 99_REGLES-CODAGE.md +├── EVOLUTIONS_CDC.md +├── CHARTE_GRAPHIQUE.md +├── juridique/ # CGU + 22_DOCUMENTS-LEGAUX.md +├── archive/ # obsolete / temporaires ├── 90_AUDIT.md └── test-data/ ``` diff --git a/docs/28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md b/docs/28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md index b8cbfbe..170bc93 100644 --- a/docs/28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md +++ b/docs/28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md @@ -3,7 +3,7 @@ **Version** : 1.1 **Date** : 16 juin 2026 **Statut** : Réflexions produit / architecture — complément au [CDC](./01_CAHIER-DES-CHARGES.md) -**Documents liés** : [EVOLUTIONS_CDC.md](./EVOLUTIONS_CDC.md), [24_DECISIONS-PROJET.md](./24_DECISIONS-PROJET.md), [23_LISTE-TICKETS.md](./23_LISTE-TICKETS.md) +**Documents liés** : [EVOLUTIONS_CDC.md](./EVOLUTIONS_CDC.md), [24_DECISIONS-PROJET.md](./24_DECISIONS-PROJET.md), [23_SUIVI-TICKETS.md](./23_SUIVI-TICKETS.md), [29_BILAN-VERSION-0.1.0.md](./29_BILAN-VERSION-0.1.0.md) --- diff --git a/docs/29_BILAN-VERSION-0.1.0.md b/docs/29_BILAN-VERSION-0.1.0.md new file mode 100644 index 0000000..2d831e6 --- /dev/null +++ b/docs/29_BILAN-VERSION-0.1.0.md @@ -0,0 +1,197 @@ +# Bilan — Version 0.1.0 + +**Statut** : terminée +**Milestone Gitea** : [0.1.0](https://git.ptits-pas.fr/jmartin/petitspas/milestone/10) +**Dépôt** : `jmartin/petitspas` +**Tag prévu** : `v0.1.0` (sur `master` après merge de cette doc) + +Ce document est la **mémoire produit** de la version 0.1.0 : ce qui a été livré, ticket par ticket, et ce qui a été reporté. + +--- + +## 1. Périmètre produit livré + +La 0.1.0 couvre le **MVP opérable** pour une collectivité : + +- Authentification, création / oubli de mot de passe, e-mails associés +- Inscription parent & AM, validation / refus gestionnaire, reprise après refus +- Dashboard staff (admin + gestionnaire) : listes, fiches, rattachements +- Onglet **Dossiers** + wizards création / édition (famille & AM) +- Suppressions métier (droits, confirms, cascades API) +- Cleanups structurels (préfixe `Admin*`, panels dashboard, modale staff, retrait `est_multiple`) + +**Hors 0.1.0** (reporté) : doublons avancés, famille N responsables, statut enfant gardé/sans garde, combobox RPE AM, chantier CDC (#117), tickets tech/observabilité — voir §4 et [05_VERSIONS-ET-MILESTONES.md](./05_VERSIONS-ET-MILESTONES.md). + +--- + +## 2. Thèmes livrés + +### 2.1 Auth, mot de passe, e-mails + +| # | Titre | Livré | +|---|-------|--------| +| 24 | API Création mot de passe | Endpoints token → création MDP post-validation | +| 28 | Templates Email — Validation | Mails validation avec lien MDP | +| 30 | Connexion — Vérification statut | Blocage comptes pending / suspendus à la connexion | +| 43 | Écran Création Mot de Passe | UI lien e-mail création MDP | +| 47 | Écran Changement MDP Obligatoire | Première connexion staff | +| 50 | Affichage dynamique CGU | CGU/Privacy versionnées à l’inscription | +| 118 | Page création mot de passe (Front + API) | Alignement front/API du flux lien e-mail | +| 123 | Durcissement token création MDP | TTL, usage unique, contrôles API | +| 127 | Mot de passe oublié | Demande → e-mail → réinitialisation (flux distinct de #24/#43) | + +### 2.2 Inscription, numéros de dossier, reprise + +| # | Titre | Livré | +|---|-------|--------| +| 104 | Numéro de dossier — frontend | Affichage listes / mails / modales ; format AAAA-… | +| 112 | Reprise après refus — frontend | Lien e-mail `/reprise` + reprise par n° dossier | +| 120 | Inscription AM — photo & UX | Chaîne photo / API / UX alignée parents | +| 144 | Consentement photo enfant | Persistance du consentement à l’inscription | + +### 2.3 Dashboard — fiches, listes, rattachements + +| # | Titre | Livré | +|---|-------|--------| +| 115 | Rattachement enfants — backend | Attach/detach parent↔enfant et AM↔enfant | +| 116 | Rattachement enfants — frontend | UI fiches parent / AM | +| 130 | UserService — APIs métier | Branchement parents / AM / enfants côté front | +| 131 | Édition fiche parent + AM | Modales édition dashboard | +| 132 | Création enfant (onglet Enfants) | Création + rattachement foyer | +| 136 | API enfants — droits & liste | Droits gestionnaire + enrichissement liste | +| 137 | Onglet Enfants — liste globale | Panneau liste dashboard | +| 138 | Fiche enfant + liste dans parent | Fiche enfant ; enfants dans fiche parent | +| 140 | Epic fiche parent / affiliation | Livraison regroupée dashboard admin/gestionnaire | +| 142 | Clic carte → modale | Ouverture fiche depuis les listes | +| 145 | Lien co-parent cliquable | Navigation fiche parent → co-parent | +| 146 | Modale sélection enfant | UX rattacher enfant (AM + parent) | +| 147 | Modale sélection AM | UX rattacher AM depuis fiche enfant | +| 148 | Capacité max AM | Désactivation rattachement si capacité atteinte | +| 149 | Case libre AM → rattacher | Clic emplacement vide pour rattacher | +| 151 | GET /relais pour gestionnaire | Combo relais dans modale staff | +| 157 | Enfant sans responsable | Détachement dernier parent + alerte liste | +| 158 | Affiliation foyer (pivot + co-parent) | Attach/detach cohérents sur le foyer | + +### 2.4 Dossiers staff (création, édition, liste) + +| # | Titre | Livré | +|---|-------|--------| +| 129 | Création dossier parent | Wizard + API staff famille | +| 135 | Édition dossier + 2ᵉ parent | Mode edit wizards + `POST …/co-parent` | +| 153 | Onglet Dossiers | Liste unifiée + à valider (sans création dans l’onglet) | +| 156 | Création dossier AM | Wizard + API staff AM | + +### 2.5 Suppressions & droits staff + +| # | Titre | Livré | +|---|-------|--------| +| 133 | Suppression parent + AM (UI) | Première vague UI (complétée par #160) | +| 134 | Droits « Ajouter gestionnaire » | Visibilité / API selon rôle | +| 143 | Bug supprimer sa propre fiche | Masquage / interdiction auto-suppression | +| 154 | Epic suppressions | Cadrage règles métier suppressions | +| 159 | Suppressions métier — backend | Cascades, garde-fous, droits API | +| 160 | Suppressions dashboard — frontend | Poubelles + dialogues de confirmation | +| 161 | Admin création staff 403 | Admin peut créer gestionnaire et administrateur | + +### 2.6 Cleanups structure & UX + +| # | Titre | Livré | +|---|-------|--------| +| 25 | API Liste comptes en attente | Historique ; couvert par flux dossiers / validation | +| 26 | API Validation / Refus | Historique ; couvert par flux dossiers / validation | +| 152 | Retrait `est_multiple` | Suppression full stack (BDD, API, front, docs) | +| 155 | Rename préfixe `Admin*` | Widgets partagés sans préfixe Admin (option C) | +| 162 | Panels → `widgets/dashboard/` | Suite #155 — panels staff sous dashboard | +| 164 | Modale staff uniformisée | `StaffUserFormModal` (shell 930, champs contrôlés) | + +--- + +## 3. Inventaire exhaustif (48 tickets fermés, milestone 0.1.0) + +| # | Titre | +|---|-------| +| 24 | [Backend] API Création mot de passe | +| 25 | [Backend] API Liste comptes en attente | +| 26 | [Backend] API Validation/Refus comptes | +| 28 | [Backend] Templates Email - Validation | +| 30 | [Backend] Connexion - Vérification statut | +| 43 | [Frontend] Écran Création Mot de Passe | +| 47 | [Frontend] Écran Changement MDP Obligatoire | +| 50 | [Frontend] Affichage dynamique CGU lors inscription | +| 104 | Numéro de dossier – frontend | +| 112 | Reprise après refus – frontend | +| 115 | [Backend] Rattachement enfants — parent et AM | +| 116 | [Frontend] Rattachement enfants — parent et AM | +| 118 | Page création mot de passe (lien email) – Front + API | +| 120 | [Full-stack] Inscription AM — photo, API et UX alignés sur les parents | +| 123 | [Tech] Durcissement token création MDP | +| 127 | [Full-stack] Mot de passe oublié — flux complet | +| 129 | Création dossier parent (wizard + API staff) | +| 130 | [Frontend] UserService — brancher APIs parents, AM et enfants | +| 131 | [Frontend] Édition fiche parent + AM | +| 132 | Création enfant depuis l’onglet Enfants | +| 133 | [Frontend] Suppression compte parent + AM | +| 134 | Droits bouton « Ajouter gestionnaire » | +| 135 | Mode édition dossier (+ ajout 2ᵉ parent) | +| 136 | [Backend] API enfants — droits gestionnaire + enrichissement liste | +| 137 | [Frontend] Onglet Enfants — liste globale | +| 138 | [Frontend] Fiche enfant + liste enfants dans fiche parent | +| 140 | Dashboard admin — fiche parent, enfants et affiliation | +| 142 | Clic sur carte → ouvrir la modale | +| 143 | Bug — Gestionnaire Supprimer sur sa propre fiche | +| 144 | Bug — Consentement photo enfant non sauvegardé | +| 145 | Lien co-parent cliquable | +| 146 | UX — modale sélection d'enfant | +| 147 | UX — modale sélection d'AM | +| 148 | Bug — capacité max AM | +| 149 | Fiche AM — clic case libre pour rattacher | +| 151 | Bug — GET /relais gestionnaire | +| 152 | Cleanup — supprimer `est_multiple` | +| 153 | Onglet permanent « Dossiers » | +| 154 | Epic — suppressions utilisateurs / dossiers / enfants / AM | +| 155 | Cleanup — renommer préfixe Admin* | +| 156 | Création dossier AM (wizard + API staff) | +| 157 | Enfant sans responsable | +| 158 | Affiliation enfant au foyer (pivot + co-parent) | +| 159 | Backend suppressions métier (#154) | +| 160 | Frontend suppressions dashboard (#154) | +| 161 | Bug — Admin création gestionnaire / administrateur | +| 162 | Cleanup — panels vers `widgets/dashboard/` | +| 164 | Uniformisation modale staff + champs contrôlés | + +Issues : https://git.ptits-pas.fr/jmartin/petitspas/issues?q=&type=all&state=closed&labels=&milestone=10&assignee=0 + +--- + +## 4. Reporté hors 0.1.0 + +| # | Titre | Destination typique | +|---|-------|---------------------| +| 113 / 114 | Doublons inscription / alerte gestionnaire | 0.9.0 | +| 117 | Évolution du cahier des charges | Doc (amendement CDC post-0.1.0) | +| 121–122, 124–125 | Tech auth / photos / DB | 0.9.0 | +| 126 | Upload documents légaux 500 | 0.9.0 | +| 128 | Audit / traçabilité modifications | 0.9.0 | +| 139 | Famille complexe N responsables | Post-0.1.0 / epic | +| 141 | Statut enfant gardé / sans garde | Post-0.1.0 | +| 150 | Combobox rattachement RPE (AM) | 0.2.0 | + +Voir aussi [05_VERSIONS-ET-MILESTONES.md](./05_VERSIONS-ET-MILESTONES.md). + +--- + +## 5. Suite documentaire + +1. **Amendement CDC** — ticket **#117** : intégrer les écarts réellement livrés (dossiers staff, onglet Enfants, suppressions, retrait naissance multiple, etc.) à partir de ce bilan, [EVOLUTIONS_CDC.md](./EVOLUTIONS_CDC.md) et [28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md). +2. **Tag** `v0.1.0` sur `master` lorsque milestone fermée + ce bilan mergé. +3. Enchaîner les milestones **0.2.0+** selon [05_VERSIONS-ET-MILESTONES.md](./05_VERSIONS-ET-MILESTONES.md). + +--- + +## 6. Références code (points d’entrée) + +- Modale staff : `frontend/lib/widgets/dashboard/staff_user_form_modal.dart` +- Fiches : `parent_edit_modal.dart`, `am_edit_modal.dart`, `child_detail_modal.dart` +- Wizards dossiers : `parent_dossier_wizard.dart`, `am_dossier_wizard.dart` +- Règles suppressions : tickets #154 / #159 / #160 +- Cleanup `est_multiple` : #152 diff --git a/docs/EVOLUTIONS_CDC.md b/docs/EVOLUTIONS_CDC.md index 98b57b6..75b7b42 100644 --- a/docs/EVOLUTIONS_CDC.md +++ b/docs/EVOLUTIONS_CDC.md @@ -2,7 +2,9 @@ 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)**. +> **Intrant pour #117** (amendement CDC post-0.1.0). Compléter avec le [bilan 0.1.0](./29_BILAN-VERSION-0.1.0.md) et **[28 - Évolution famille et responsables](./28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md)**. + +> **Obsolète depuis #152** : ne plus proposer de champ « naissance multiple / `est_multiple` » — retiré de l’app (BDD, API, front). ## 1. Gestion des Enfants @@ -11,7 +13,6 @@ Ce document liste les modifications à apporter au cahier des charges original p #### Situation actuelle dans le CDC : - Mentionne uniquement la collecte d'informations sur l'enfant - Ne précise pas la possibilité d'ajouter plusieurs enfants -- Ne mentionne pas la gestion des naissances multiples - Ne mentionne pas la gestion des enfants à naître #### Modifications proposées : @@ -22,17 +23,18 @@ Ajouter le paragraphe suivant après la description de la collecte d'information Les parents peuvent ajouter autant d'enfants que nécessaire. Pour chaque enfant, les informations suivantes sont collectées : - Prénom - Date de naissance (ou date prévue pour les enfants à naître) +- Genre - Photo (optionnelle) - Consentement pour l'utilisation de la photo -- Indication si l'enfant fait partie d'une naissance multiple (jumeaux, triplés, etc.) Les parents peuvent : - Ajouter un nouvel enfant à tout moment - Supprimer un enfant ajouté - Modifier les informations d'un enfant existant - Indiquer si l'enfant est à naître -- Indiquer si l'enfant fait partie d'une naissance multiple - Donner ou retirer leur consentement pour l'utilisation de la photo de l'enfant + +Note : le concept de « naissance multiple » / jumeaux n'est pas géré par un champ dédié (retiré en 0.1.0, #152). ``` ### Modifications à apporter dans la section "Workflow de création de compte" @@ -50,9 +52,9 @@ Remplacer l'étape 3 par : - Pour chaque enfant : * Saisie du prénom * Saisie de la date de naissance (ou date prévue) + * Genre * Option d'ajout d'une photo * Option de consentement photo - * Indication si naissance multiple * Indication si enfant à naître - Possibilité de modifier ou supprimer un enfant ``` diff --git a/docs/PROCEDURE-API-GITEA.md b/docs/PROCEDURE-API-GITEA.md deleted file mode 100644 index fcae5a0..0000000 --- a/docs/PROCEDURE-API-GITEA.md +++ /dev/null @@ -1,8 +0,0 @@ -# Fichier déplacé / fusionné - -La procédure **API Gitea** est désormais documentée sous : - -**[26_GITEA-API.md](./26_GITEA-API.md)** - -L’ancienne copie `PROCEDURE-API-GITEA.md` est archivée dans -`docs/archive/obsolete/` (doublon). diff --git a/docs/archive/README.md b/docs/archive/README.md index 794b038..674fdbc 100644 --- a/docs/archive/README.md +++ b/docs/archive/README.md @@ -1,30 +1,19 @@ # Archive documentation · P'titsPas -Ce dossier regroupe les fichiers **sans préfixe numérique** à la racine de -`docs/` qui ne sont plus des **références actives**, ou qui sont des -**brouillons / temporaires**. +Fichiers **hors références actives** : brouillons livrés, CDC historiques, listes figées. ## Règle de nommage (racine `docs/`) -- Les documents **normatifs** à la racine portent un préfixe **`NN_`** - (deux chiffres), ex. `23_LISTE-TICKETS.md`. -- **Exceptions** (héritage ou outillage) listées dans - [**00_INDEX.md**](../00_INDEX.md#exceptions-de-nommage) : charte, CDC - historique, évolutions — **cible** : les renommer progressivement en `NN_` - et mettre à jour `.cursorrules` / liens. +- Documents **normatifs** : préfixe **`NN_`**. +- Exceptions héritage listées dans [00_INDEX.md](../00_INDEX.md) (`CHARTE_GRAPHIQUE.md`, `EVOLUTIONS_CDC.md`). -## Sous-dossiers ici +## Sous-dossiers | Dossier | Usage | |---------|--------| -| [**temporaires/**](./temporaires/) | Notes jetables, exports de travail. - **Supprimables** quand la tâche associée est close. | -| [**obsolete/**](./obsolete/) | Ancienne doc **remplacée** ou **doublon** - (conservée un temps pour historique). **Supprimer** après bascule confirmée - si plus aucune référence. | +| [**temporaires/**](./temporaires/) | Brouillons jetables. **Vider** dès livraison. | +| [**obsolete/**](./obsolete/) | Doc remplacée (CDC SuperNounou, ancienne liste tickets, notes ponctuelles, backlog Phase 2 figé). | -## Hors `docs/` racine +## Politique `tmp/` -Les dossiers thématiques (**`juridique/`**, **`test-data/`**, etc.) peuvent -contenir des fichiers sans `NN_` : la règle `NN_` s’applique surtout aux -fichiers **directement** sous `docs/`. +Le dossier `docs/tmp/` **n’est plus utilisé**. Les mini-specs de tickets livrés sont purgés ; la mémoire produit = bilans de version (`29_…`) + tickets Gitea. diff --git a/docs/14_NOTE-BACKEND-CONFIG-SETUP.md b/docs/archive/obsolete/14_NOTE-BACKEND-CONFIG-SETUP.md similarity index 100% rename from docs/14_NOTE-BACKEND-CONFIG-SETUP.md rename to docs/archive/obsolete/14_NOTE-BACKEND-CONFIG-SETUP.md diff --git a/docs/23_LISTE-TICKETS.md b/docs/archive/obsolete/23_LISTE-TICKETS.md similarity index 100% rename from docs/23_LISTE-TICKETS.md rename to docs/archive/obsolete/23_LISTE-TICKETS.md diff --git a/docs/25_PHASE-2-BACKLOG.md b/docs/archive/obsolete/25_PHASE-2-BACKLOG.md similarity index 100% rename from docs/25_PHASE-2-BACKLOG.md rename to docs/archive/obsolete/25_PHASE-2-BACKLOG.md diff --git a/docs/92_NOTE-BACKEND-GESTIONNAIRES.md b/docs/archive/obsolete/92_NOTE-BACKEND-GESTIONNAIRES.md similarity index 100% rename from docs/92_NOTE-BACKEND-GESTIONNAIRES.md rename to docs/archive/obsolete/92_NOTE-BACKEND-GESTIONNAIRES.md diff --git a/docs/archive/obsolete/README.md b/docs/archive/obsolete/README.md index ade8bb1..707373b 100644 --- a/docs/archive/obsolete/README.md +++ b/docs/archive/obsolete/README.md @@ -4,11 +4,13 @@ Ancienne documentation **déplacée** depuis `docs/` : | Fichier | Motif | |---------|--------| -| `PROCEDURE-API-GITEA.md` | Doublon fonctionnel de - [**26_GITEA-API.md**](../../26_GITEA-API.md). | -| `ARCHITECTURE_TECHNIQUE.md` | Non référencé ; la vue d’ensemble est dans - [**02_ARCHITECTURE.md**](../../02_ARCHITECTURE.md). | -| `STATUS-APPLICATION.md` | Instantané daté ; non tenu comme doc vivante. | +| `PROCEDURE-API-GITEA.md` | Doublon de [26_GITEA-API.md](../../26_GITEA-API.md) | +| `ARCHITECTURE_TECHNIQUE.md` | Remplacé par [02_ARCHITECTURE.md](../../02_ARCHITECTURE.md) | +| `STATUS-APPLICATION.md` | Instantané daté | +| `23_LISTE-TICKETS.md` | Liste Phase 1 figée (avr. 2026) — suivi = Gitea + bilans | +| `25_PHASE-2-BACKLOG.md` | Backlog technique figé — voir [05_VERSIONS…](../../05_VERSIONS-ET-MILESTONES.md) | +| `SuperNounou_*` | CDC / SSS historiques | +| `14_NOTE-BACKEND-CONFIG-SETUP.md` | Note ticket ponctuelle | +| `92_NOTE-BACKEND-GESTIONNAIRES.md` | Note ticket ponctuelle | -Après vérification qu’aucun lien externe ne pointe encore vers ces chemins, on -peut **supprimer** ce sous-dossier ou ne garder que des pointeurs minimalistes. +Mémoire produit des versions livrées : [29_BILAN-VERSION-0.1.0.md](../../29_BILAN-VERSION-0.1.0.md). diff --git a/docs/SuperNounou_Cahier_Des_Charges_Complet_V1.1.md b/docs/archive/obsolete/SuperNounou_Cahier_Des_Charges_Complet_V1.1.md similarity index 100% rename from docs/SuperNounou_Cahier_Des_Charges_Complet_V1.1.md rename to docs/archive/obsolete/SuperNounou_Cahier_Des_Charges_Complet_V1.1.md diff --git a/docs/SuperNounou_SSS-001.md b/docs/archive/obsolete/SuperNounou_SSS-001.md similarity index 100% rename from docs/SuperNounou_SSS-001.md rename to docs/archive/obsolete/SuperNounou_SSS-001.md diff --git a/docs/archive/temporaires/131-fiche-parent-co-parent-header.md b/docs/archive/temporaires/131-fiche-parent-co-parent-header.md deleted file mode 100644 index 6f8a3c8..0000000 --- a/docs/archive/temporaires/131-fiche-parent-co-parent-header.md +++ /dev/null @@ -1,127 +0,0 @@ -# #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 fonctionnelle** — ce document fixe le contrat attendu ; le back valide `co_parent` et masque les champs sensibles. - ---- - -## 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 - -### Relations (déjà en place) - -- `findAll()` et `findOne(user_id)` chargent **`co_parent`** ; -- FK : `parents.id_co_parent` → `utilisateurs.id` ; -- inscription couple : les deux sens renseignés en principe (`auth.service.ts`). - -### Livraison back (#131) - -- `mapParentForApi` / `sanitizeUserForApi` : réponses `GET/PATCH/POST/DELETE` parents **sans** `password`, `token_creation_mdp`, `password_reset_*` sur `user` et `co_parent`. - -**Checklist validation :** - -- [x] `GET /parents/:id` renvoie `co_parent` peuplé quand `id_co_parent` est non null -- [x] `GET /parents` (liste) inclut `co_parent` -- [x] `prenom` / `nom` du co-parent présents -- [x] Pas de fuite `password` / tokens sur `user` ni `co_parent` - ---- - -## 5. Points d’attention (hors périmètre immédiat) - -| Sujet | Détail | -|-------|--------| -| **Lien inverse** | Si B est co-parent de A (`A.id_co_parent = B`) mais `B.id_co_parent` est `null`, le sous-titre **ne s’affichera pas** sur la fiche de B. Pas de résolution inverse côté front. | -| **Familles > 2 adultes** | Sous-titre = co-parent direct (`id_co_parent`) uniquement. | -| **Trou AM ↔ enfants en garde** | Pas de lien AM–enfant aujourd’hui (à documenter / traiter plus tard). | - ---- - -## 6. Fichiers back concernés - -| Fichier | Rôle | -|---------|------| -| `backend/src/routes/parents/parents.service.ts` | `findOne`, `findAll` + relations | -| `backend/src/routes/parents/parents.controller.ts` | `mapParentForApi` sur les réponses | -| `backend/src/routes/parents/parents.mapper.ts` | Sérialisation API | -| `backend/src/common/utils/sanitize-user-for-api.ts` | Masquage secrets | -| `backend/src/entities/parents.entity.ts` | relation `co_parent` | - ---- - -## 7. Références - -- `docs/28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md` §6.1 -- Ticket Gitea **#131** diff --git a/docs/archive/temporaires/POINT_TICKETS_FRONT_API.txt b/docs/archive/temporaires/POINT_TICKETS_FRONT_API.txt deleted file mode 100644 index fac0b2d..0000000 --- a/docs/archive/temporaires/POINT_TICKETS_FRONT_API.txt +++ /dev/null @@ -1,36 +0,0 @@ -# Archivé docs/archive/temporaires/ — export jetable, supprimer si inutile. -Point tickets frontend (API Gitea) - 27/01/2026 -================================================ - -Issues avec label "frontend" : 20 (ouvertes: 12, fermees: 8) - -Num | Etat | Titre -----+--------+-------------------------------------------------------- - 35 | open | [Frontend] Écran Création Gestionnaire - 36 | closed | [Frontend] Inscription Parent - Étape 1 (Parent 1) - 37 | closed | [Frontend] Inscription Parent - Étape 2 (Parent 2) - 38 | closed | [Frontend] Inscription Parent - Étape 3 (Enfants) - 39 | closed | [Frontend] Inscription Parent - Étapes 4-6 (Finalisatio - 40 | closed | [Frontend] Inscription AM - Panneau 1 (Identité) - 41 | closed | [Frontend] Inscription AM - Panneau 2 (Infos pro) - 42 | closed | [Frontend] Inscription AM - Finalisation - 43 | open | [Frontend] Écran Création Mot de Passe - 44 | closed | [Frontend] Dashboard Gestionnaire - Structure - 45 | open | [Frontend] Dashboard Gestionnaire - Liste Parents - 46 | open | [Frontend] Dashboard Gestionnaire - Liste AM - 47 | open | [Frontend] Écran Changement MDP Obligatoire - 48 | open | [Frontend] Gestion Erreurs & Messages - 49 | open | [Frontend] Écran Gestion Documents Légaux (Admin) - 50 | open | [Frontend] Affichage dynamique CGU lors inscription - 51 | open | [Frontend] Écran Logs Admin (optionnel v1.1) - 54 | open | [Tests] Tests E2E Frontend - 82 | closed | [Frontend] Adapter �cran Login pour mobile - 83 | closed | [Frontend] Adapter �cran Choix Inscription pour mobile - -Suivi doc 23_LISTE-TICKETS (Gitea #73,78,79,81,82,83): - #73 closed labels=[] - #78 closed labels=[] - #79 closed labels=[] - #81 closed labels=[] - #82 closed (écran Login mobile) - #83 closed labels=['frontend', 'p3', 'phase-1', 'ux'] diff --git a/docs/archive/temporaires/README.md b/docs/archive/temporaires/README.md index bde6fa3..ecc5dc2 100644 --- a/docs/archive/temporaires/README.md +++ b/docs/archive/temporaires/README.md @@ -1,10 +1,11 @@ # Temporaires -Fichiers **non numérotés** de travail (brouillons, listes de tickets exportées, -alignements UI en cours, etc.). +Dossier **vide** après clôture 0.1.0 (purge sept. 2026). -- Préfixe conseillé pour les nouveaux fichiers jetables : **`TEMP_`** ou - **`WIP_`** dans ce dossier. -- **Suppression** : dès que la fonctionnalité est livrée ou le sujet clos, - supprimer le fichier (ou le déplacer vers `obsolete/` si une trace utile - reste nécessaire). +Si un brouillon de travail est nécessaire un temps : + +- le placer ici avec préfixe `TEMP_` / `WIP_` ; +- le **supprimer** dès livraison (ne pas laisser pourrir) ; +- pour une trace utile durable → bilan de version ou archive `obsolete/`. + +Ne plus utiliser `docs/tmp/`. diff --git a/docs/archive/temporaires/TEMP_112-back-reprise-alignement-front.md b/docs/archive/temporaires/TEMP_112-back-reprise-alignement-front.md deleted file mode 100644 index 65eff55..0000000 --- a/docs/archive/temporaires/TEMP_112-back-reprise-alignement-front.md +++ /dev/null @@ -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 -``` diff --git a/docs/archive/temporaires/TEMP_131-back-fiche-am-enfants.md b/docs/archive/temporaires/TEMP_131-back-fiche-am-enfants.md deleted file mode 100644 index 870ef51..0000000 --- a/docs/archive/temporaires/TEMP_131-back-fiche-am-enfants.md +++ /dev/null @@ -1,132 +0,0 @@ -# #131 — Fiche AM éditable + affiliation enfants (note front → back) - -**Ticket :** #131 (partie AM, doc `28_EVOLUTION-FAMILLE-ET-RESPONSABLES.md` §6.1) -**Date :** 2026-06-01 -**Statut front :** modale livrée (2 onglets) — **API affiliation AM↔enfant à implémenter** - ---- - -## 1. Comportement UI (front) - -Modale `AdminAmEditModal` — même shell que la fiche parent (~930 px) : - -| Onglet | Contenu | -|--------|---------| -| **Identité & professionnel** | `IdentityBlock` éditable + grille pro (agrément, ville résidence, capacité, places, NIR/agrément date en lecture seule, biographie, switch disponible) + gélule statut | -| **Enfants accueillis** | Liste cartes enfants (réutilise `AdminChildrenAffiliationPanel` / `AdminEnfantUserCard`) + rattacher / détacher | - -En-tête : prénom nom · sous-titre `Zone · Agrément · Dossier`. - ---- - -## 2. Endpoints consommés - -### Déjà existants (partiels) - -| Méthode | Route | Usage | -|---------|-------|-------| -| `GET` | `/api/v1/assistantes-maternelles` | Liste AM | -| `GET` | `/api/v1/assistantes-maternelles/:userId` | Détail (403 possible pour `administrateur` → fallback liste) | -| `PATCH` | `/api/v1/users/:userId` | Identité + statut (admin / super_admin uniquement) | -| `PATCH` | `/api/v1/assistantes-maternelles/:userId` | Champs pro (gestionnaire / super_admin) | - -### À créer (recommandé — miroir parent #131 / #115) - -| Méthode | Route | Rôle | -|---------|-------|------| -| `PATCH` | `/api/v1/assistantes-maternelles/:userId/fiche` | Mise à jour unifiée identité + pro + statut (`super_admin`, `gestionnaire`, `administrateur`) | -| `POST` | `/api/v1/assistantes-maternelles/:userId/enfants/:enfantId` | Rattacher un enfant | -| `DELETE` | `/api/v1/assistantes-maternelles/:userId/enfants/:enfantId` | Détacher un enfant | -| `GET` | `/api/v1/assistantes-maternelles/:userId` | Inclure `amChildren[]` (relation enfant) | - -Le front appelle déjà ces routes ; en l’absence de `PATCH …/fiche`, il tente un fallback `PATCH users` + `PATCH assistantes-maternelles` (échoue selon le rôle connecté). - ---- - -## 3. Modèle de données affiliation AM ↔ enfant - -**À définir côté BDD** (pas de table dédiée aujourd’hui, contrairement à `enfants_parents`) : - -Proposition alignée parent : - -```sql --- Piste : enfants_assistantes_maternelles -CREATE TABLE enfants_assistantes_maternelles ( - id_am UUID NOT NULL REFERENCES utilisateurs(id) ON DELETE CASCADE, - id_enfant UUID NOT NULL REFERENCES enfants(id) ON DELETE CASCADE, - PRIMARY KEY (id_am, id_enfant) -); -``` - -Réponse API attendue sur `GET /assistantes-maternelles/:id` : - -```json -{ - "user_id": "uuid-am", - "user": { "id": "…", "prenom": "Claire", "nom": "MARTIN", "statut": "actif" }, - "approval_number": "AGR-2024-12345", - "residence_city": "Bezons", - "max_children": 4, - "places_available": 2, - "available": true, - "amChildren": [ - { - "child": { - "id": "uuid-enfant", - "first_name": "Emma", - "last_name": "MARTIN", - "status": "actif", - "birth_date": "2023-02-15" - } - } - ] -} -``` - -Le front parse `amChildren` / `am_children` / `assistanteChildren` (même logique que `parentChildren`). - ---- - -## 4. Body `PATCH …/fiche` suggéré - -```json -{ - "nom": "MARTIN", - "prenom": "Claire", - "email": "claire@example.com", - "telephone": "0612345678", - "adresse": "5 place Bellecour", - "ville": "Lyon", - "code_postal": "69002", - "statut": "actif", - "approval_number": "AGR-2024-12345", - "residence_city": "Lyon", - "max_children": 4, - "places_available": 2, - "biography": "…", - "available": true -} -``` - -NIR et date d’agrément : lecture seule dans la modale (modification hors périmètre admin v1). - ---- - -## 5. Fichiers front concernés - -| Fichier | Rôle | -|---------|------| -| `frontend/lib/widgets/admin/common/admin_am_edit_modal.dart` | Modale 2 onglets | -| `frontend/lib/widgets/admin/common/admin_children_affiliation_panel.dart` | Liste enfants partagée parent/AM | -| `frontend/lib/widgets/admin/common/admin_status_capsule.dart` | Gélule statut partagée | -| `frontend/lib/models/assistante_maternelle_model.dart` | Parse champs pro + `amChildren` | -| `frontend/lib/services/user_service.dart` | `getAssistanteMaternelle`, `updateAmFiche`, `attachEnfantToAm`, `detachEnfantFromAm` | -| `frontend/lib/widgets/admin/assistante_maternelle_management_widget.dart` | Ouverture modale au clic Modifier | - ---- - -## 6. Références - -- Fiche parent : `PATCH /parents/:id/fiche`, `POST|DELETE /parents/:id/enfants/:enfantId` -- Ticket Gitea **#131**, **#115** -- `docs/archive/temporaires/TEMP_131-back-fiche-parent-co-parent.md` diff --git a/docs/archive/temporaires/TEMP_131-back-fiche-parent-co-parent.md b/docs/archive/temporaires/TEMP_131-back-fiche-parent-co-parent.md deleted file mode 100644 index 43ac761..0000000 --- a/docs/archive/temporaires/TEMP_131-back-fiche-parent-co-parent.md +++ /dev/null @@ -1,124 +0,0 @@ -# #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** diff --git a/docs/archive/temporaires/TEMP_FRONT_alignement_AM.md b/docs/archive/temporaires/TEMP_FRONT_alignement_AM.md deleted file mode 100644 index 21f2eed..0000000 --- a/docs/archive/temporaires/TEMP_FRONT_alignement_AM.md +++ /dev/null @@ -1,46 +0,0 @@ -# TEMP — Alignement front / API (inscription AM & validation gestionnaire) - -> **Archivé** (`docs/archive/temporaires/`) — **fichier temporaire** ; à -> **supprimer** une fois le front livré ou le sujet clos (voir -> `docs/archive/temporaires/README.md`). - -Ce document décrit les changements **côté API** et ce que **Flutter** doit faire pour rester aligné. Aucune modification front n’a été faite dans le chantier backend associé. - -## 1. `POST /auth/register/am` — lieu de naissance obligatoire - -- **`lieu_naissance_ville`** et **`lieu_naissance_pays`** sont **obligatoires** (non vides après trim, min. **2 caractères** chacun, max 100). -- Réponses **400** si manquants ou invalides (messages class-validator). -- **Action front** : champs obligatoires dans le parcours AM (étapes identité / naissance), validation UI avant envoi ; afficher les erreurs renvoyées par l’API. - -## 2. Réponse `GET /dossiers/:numeroDossier` (type `am`) - -Sous `dossier.user`, l’API peut inclure : - -| Clé JSON | Description | -|----------|-------------| -| `date_naissance` | Date (si renseignée à l’inscription) | -| `lieu_naissance_ville` | Ville de naissance | -| `lieu_naissance_pays` | Pays de naissance | -| `consentement_photo` | Booléen (exposé dans `dossier.user`) | - -À la **racine** de `dossier` (objet AM), champs déjà renvoyés par le backend : `disponible`, `annees_experience`, `specialite`, `nb_max_enfants`, `place_disponible`, etc. - -**Action front** : - -- Étendre **`AppUser.fromJson` / `toJson`** (`lib/models/user.dart`) pour mapper `date_naissance`, `lieu_naissance_ville`, `lieu_naissance_pays`, `consentement_photo`. -- Étendre **`DossierAM.fromJson`** (`lib/models/dossier_unifie.dart`) pour parser `disponible`, `annees_experience`, `specialite` à la racine du dossier (noms snake_case comme dans la réponse JSON Nest). - -## 3. `ValidationAmWizard` (admin) - -Afficher pour cohérence avec le formulaire d’inscription : - -- **Informations personnelles** : date de naissance, ville / pays de naissance, consentement photo (Oui/Non). -- **Informations professionnelles** : disponibilité, années d’expérience, spécialité (afficher « – » si `null`). - -## 4. `place_disponible` à l’inscription - -- Le backend initialise **`place_disponible`** sur la fiche AM à la **même valeur** que **`capacite_accueil`** à la création. Le wizard peut donc afficher une valeur cohérente avec la capacité sans champ séparé côté public. - ---- - -*Dernière mise à jour : alignement backend branche `feature/120-inscription-am-photo-backend`.* diff --git a/docs/tmp/112-back-reprise-alignement-front.md b/docs/tmp/112-back-reprise-alignement-front.md deleted file mode 100644 index 65eff55..0000000 --- a/docs/tmp/112-back-reprise-alignement-front.md +++ /dev/null @@ -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 -``` diff --git a/docs/tmp/129-contrat-api-staff-parent.md b/docs/tmp/129-contrat-api-staff-parent.md deleted file mode 100644 index b07e681..0000000 --- a/docs/tmp/129-contrat-api-staff-parent.md +++ /dev/null @@ -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` diff --git a/docs/tmp/135-contrat-api-ajout-co-parent.md b/docs/tmp/135-contrat-api-ajout-co-parent.md deleted file mode 100644 index dd47421..0000000 --- a/docs/tmp/135-contrat-api-ajout-co-parent.md +++ /dev/null @@ -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` diff --git a/docs/tmp/135-mini-spec-front-edition-dossier.md b/docs/tmp/135-mini-spec-front-edition-dossier.md deleted file mode 100644 index f20113b..0000000 --- a/docs/tmp/135-mini-spec-front-edition-dossier.md +++ /dev/null @@ -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` diff --git a/docs/tmp/152-mini-spec-front-est-multiple.md b/docs/tmp/152-mini-spec-front-est-multiple.md deleted file mode 100644 index 0576312..0000000 --- a/docs/tmp/152-mini-spec-front-est-multiple.md +++ /dev/null @@ -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 diff --git a/docs/tmp/153-contrat-api-liste-dossiers.md b/docs/tmp/153-contrat-api-liste-dossiers.md deleted file mode 100644 index b427a7f..0000000 --- a/docs/tmp/153-contrat-api-liste-dossiers.md +++ /dev/null @@ -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` diff --git a/docs/tmp/153-mini-spec-front-dossiers.md b/docs/tmp/153-mini-spec-front-dossiers.md deleted file mode 100644 index 9e4f8f6..0000000 --- a/docs/tmp/153-mini-spec-front-dossiers.md +++ /dev/null @@ -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`) diff --git a/docs/tmp/154-matrice-suppression.md b/docs/tmp/154-matrice-suppression.md deleted file mode 100644 index fc1da2f..0000000 --- a/docs/tmp/154-matrice-suppression.md +++ /dev/null @@ -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). diff --git a/docs/tmp/154-mini-spec-front-suppression.md b/docs/tmp/154-mini-spec-front-suppression.md deleted file mode 100644 index 271b26d..0000000 --- a/docs/tmp/154-mini-spec-front-suppression.md +++ /dev/null @@ -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 deleteDossier(String numeroDossier); -Future> deleteUser(String userId); -Future> 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) diff --git a/docs/tmp/155-mini-spec-rename-admin-prefix.md b/docs/tmp/155-mini-spec-rename-admin-prefix.md deleted file mode 100644 index afe3c4f..0000000 --- a/docs/tmp/155-mini-spec-rename-admin-prefix.md +++ /dev/null @@ -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) diff --git a/docs/tmp/155-suite-move-admin-panels-to-dashboard.md b/docs/tmp/155-suite-move-admin-panels-to-dashboard.md deleted file mode 100644 index e5a86db..0000000 --- a/docs/tmp/155-suite-move-admin-panels-to-dashboard.md +++ /dev/null @@ -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/ - ↓ 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é diff --git a/docs/tmp/156-contrat-api-staff-am.md b/docs/tmp/156-contrat-api-staff-am.md deleted file mode 100644 index 312e148..0000000 --- a/docs/tmp/156-contrat-api-staff-am.md +++ /dev/null @@ -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` diff --git a/docs/tmp/164-staff-modal-uniformisation-mini-spec.md b/docs/tmp/164-staff-modal-uniformisation-mini-spec.md deleted file mode 100644 index f035ca8..0000000 --- a/docs/tmp/164-staff-modal-uniformisation-mini-spec.md +++ /dev/null @@ -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`