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 -```