docs: rationalisation post-0.1.0 (bilan, purge tmp, archives).
- Bilan 29 + index versions 05 ; suivi tickets pointeur Gitea - Purge docs/tmp et archive/temporaires livrés - Archive SuperNounou, liste tickets figée, backlog Phase 2, notes 14/92 - Suppression stubs PROCEDURE/22 ; INDEX et roadmap alignés Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
Cursor
@@ -1,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**
|
||||
@@ -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']
|
||||
@@ -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/`.
|
||||
|
||||
@@ -1,244 +0,0 @@
|
||||
# #112 — Alignement front après évolution back (reprise dossier complet)
|
||||
|
||||
**Branche déployée :** `feature/112-reprise-apres-refus-front`
|
||||
**Commit back :** `d70577b1` — `feat(#112): reprise après refus — dossier complet GET/PATCH`
|
||||
**Date :** 2026-06-16
|
||||
|
||||
Ce document décrit le **contrat API réel** après extension du back, et ce que le front doit encore brancher pour exploiter le dossier complet (au-delà de l’identité seule).
|
||||
|
||||
---
|
||||
|
||||
## 1. Endpoints (inchangés côté URL)
|
||||
|
||||
| Méthode | Route | Auth |
|
||||
|---------|-------|------|
|
||||
| `GET` | `/api/v1/auth/reprise-dossier?token={uuid}` | Public |
|
||||
| `PATCH` | `/api/v1/auth/reprise-resoumettre` | Public |
|
||||
| `POST` | `/api/v1/auth/reprise-identify` | Public (inchangé) |
|
||||
|
||||
> **Note :** le ticket #111 parlait de `PUT` ; l’implémentation reste en **`PATCH`** (comme avant).
|
||||
|
||||
---
|
||||
|
||||
## 2. `GET /auth/reprise-dossier` — réponse enrichie
|
||||
|
||||
### Champs communs (toujours présents)
|
||||
|
||||
Identiques à avant : `id`, `email`, `prenom`, `nom`, `telephone`, `adresse`, `ville`, `code_postal`, `numero_dossier`, `role`, `photo_url`, `genre`, `situation_familiale`.
|
||||
|
||||
### Rôle `parent` (+ champs #119)
|
||||
|
||||
Alignés sur `DossierFamilleCompletDto` :
|
||||
|
||||
```json
|
||||
{
|
||||
"parents": [
|
||||
{
|
||||
"user_id": "uuid",
|
||||
"email": "…",
|
||||
"prenom": "…",
|
||||
"nom": "…",
|
||||
"telephone": "…",
|
||||
"adresse": "…",
|
||||
"ville": "…",
|
||||
"code_postal": "…",
|
||||
"statut": "refuse",
|
||||
"co_parent_id": "uuid-parent-entity"
|
||||
}
|
||||
],
|
||||
"enfants": [
|
||||
{
|
||||
"id": "uuid-enfant",
|
||||
"first_name": "Emma",
|
||||
"last_name": "MARTIN",
|
||||
"genre": "F",
|
||||
"status": "actif",
|
||||
"birth_date": "2023-02-15T00:00:00.000Z",
|
||||
"due_date": null,
|
||||
"photo_url": "/uploads/photos/…",
|
||||
"consent_photo": true,
|
||||
"est_multiple": false
|
||||
}
|
||||
],
|
||||
"texte_motivation": "Nous recherchons…"
|
||||
}
|
||||
```
|
||||
|
||||
**Mapping front suggéré :**
|
||||
|
||||
| JSON back | Modèle / wizard parent |
|
||||
|-----------|-------------------------|
|
||||
| `parents[]` | `UserRegistrationData.parent1` + `parent2` (matcher par `email` ou ordre : titulaire = `id` du GET racine) |
|
||||
| `enfants[].first_name` / `last_name` | `ChildData.firstName` / `lastName` |
|
||||
| `enfants[].birth_date` | `ChildData.birthDate` (ISO → `DateTime`) |
|
||||
| `enfants[].due_date` | `ChildData.dueDate` (enfant `a_naitre`) |
|
||||
| `enfants[].status` | `actif` = né, `a_naitre` = à naître |
|
||||
| `enfants[].photo_url` | `ApiConfig.absoluteMediaUrl()` + conserver pour reprise sans re-upload |
|
||||
| `enfants[].id` | **Obligatoire** pour le PATCH (update par id) |
|
||||
| `enfants[].est_multiple` | `grossesse_multiple` si utilisé |
|
||||
| `texte_motivation` | étape présentation / motivation |
|
||||
|
||||
Si `numero_dossier` absent : pas de `parents[]` / `enfants[]` / `texte_motivation` (identité seule).
|
||||
|
||||
### Rôle `assistante_maternelle`
|
||||
|
||||
Champs racine + fiche pro (structure **aplatie**, pas de sous-objet `user`) :
|
||||
|
||||
```json
|
||||
{
|
||||
"consentement_photo": true,
|
||||
"date_naissance": "1985-03-12T00:00:00.000Z",
|
||||
"lieu_naissance_ville": "Paris",
|
||||
"lieu_naissance_pays": "France",
|
||||
"numero_agrement": "AGR-2024-12345",
|
||||
"nir": "123456789012345",
|
||||
"date_agrement": "2024-06-01T00:00:00.000Z",
|
||||
"nb_max_enfants": 4,
|
||||
"place_disponible": 2,
|
||||
"biographie": "…"
|
||||
}
|
||||
```
|
||||
|
||||
**Mapping `AmRegistrationData` :**
|
||||
|
||||
| JSON back | Champ front |
|
||||
|-----------|-------------|
|
||||
| `nb_max_enfants` | `capaciteAccueil` |
|
||||
| `place_disponible` | `placesDisponibles` |
|
||||
| `numero_agrement` | `numeroAgrement` |
|
||||
| `biographie` | `biographie` / présentation |
|
||||
| `photo_url` | déjà géré via `RepriseSession.photoUrl` |
|
||||
|
||||
---
|
||||
|
||||
## 3. `PATCH /auth/reprise-resoumettre` — body étendu
|
||||
|
||||
### Commun
|
||||
|
||||
```json
|
||||
{ "token": "uuid-reprise" }
|
||||
```
|
||||
|
||||
### Parent — champs à envoyer depuis le wizard
|
||||
|
||||
| Champ PATCH | Source wizard | Notes |
|
||||
|-------------|---------------|-------|
|
||||
| `prenom`, `nom`, `telephone`, `adresse`, `ville`, `code_postal` | Parent 1 (titulaire token) | Champs racine |
|
||||
| `co_parent_prenom`, `co_parent_nom`, `co_parent_telephone` | Parent 2 | |
|
||||
| `co_parent_meme_adresse`, `co_parent_adresse`, `co_parent_code_postal`, `co_parent_ville` | Parent 2 adresse | |
|
||||
| `texte_motivation` **ou** `presentation_dossier` | Étape motivation | Les deux alias acceptés |
|
||||
| `enfants[]` | Liste enfants | Voir ci-dessous |
|
||||
|
||||
**Structure `enfants[]` (miroir inscription + `id` obligatoire) :**
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "uuid-enfant-existant",
|
||||
"prenom": "Emma",
|
||||
"nom": "MARTIN",
|
||||
"date_naissance": "2023-02-15",
|
||||
"date_previsionnelle_naissance": null,
|
||||
"genre": "F",
|
||||
"photo_base64": "data:image/jpeg;base64,…",
|
||||
"photo_filename": "emma.jpg",
|
||||
"grossesse_multiple": false
|
||||
}
|
||||
```
|
||||
|
||||
- **v1 back :** update par `id` uniquement — pas de création/suppression d’enfant.
|
||||
- Si `id` inconnu pour ce dossier → **400** `Enfant inconnu pour ce dossier : {id}`.
|
||||
- Sans nouvelle photo : ne pas envoyer `photo_base64` (l’existant est conservé).
|
||||
|
||||
### AM — champs à envoyer
|
||||
|
||||
| Champ PATCH | Source |
|
||||
|-------------|--------|
|
||||
| Identité + `photo_url` ou `photo_base64` + `photo_filename` | Étapes 1–2 |
|
||||
| `consentement_photo`, `date_naissance`, `lieu_naissance_ville`, `lieu_naissance_pays` | Identité |
|
||||
| `numero_agrement`, `nir`, `date_agrement` | Pro |
|
||||
| `capacite_accueil`, `places_disponibles` | Pro |
|
||||
| `biographie` | Présentation |
|
||||
|
||||
Validation NIR identique à l’inscription si `nir` fourni.
|
||||
|
||||
### Réponse succès (nouveau format)
|
||||
|
||||
```json
|
||||
{
|
||||
"message": "Dossier resoumis avec succès. Il est de nouveau en attente de validation.",
|
||||
"statut": "en_attente",
|
||||
"user_id": "uuid",
|
||||
"numero_dossier": "2026-000021"
|
||||
}
|
||||
```
|
||||
|
||||
Code HTTP : **200** (pas de corps `Users` brut comme l’ancien back).
|
||||
|
||||
### Effet métier
|
||||
|
||||
- **Parent :** tous les users `role=parent` avec le même `numero_dossier` passent en `en_attente` ; `token_reprise` invalidé sur **tous** (symétrique refus #110).
|
||||
- **AM :** un seul user.
|
||||
|
||||
### E-mail accusé resoumission (parent)
|
||||
|
||||
Après `PATCH` réussi, un e-mail est envoyé à **chaque parent** du dossier (`sendResoumissionPendingEmail`) :
|
||||
- confirmation de resoumission ;
|
||||
- rappel du **numéro de dossier** ;
|
||||
- mention « en attente de validation ».
|
||||
|
||||
Échec SMTP : logué, **ne bloque pas** la resoumission (même règle que l'inscription initiale).
|
||||
|
||||
---
|
||||
|
||||
## 4. Fichiers front à modifier (checklist)
|
||||
|
||||
### Modèles
|
||||
|
||||
- [ ] `lib/models/reprise_dossier.dart` — parser `parents[]`, `enfants[]`, `texte_motivation`, champs AM
|
||||
- [ ] Réutiliser ou mapper vers `DossierFamilleEnfant` / structures existantes (#119 admin) si possible
|
||||
|
||||
### Session / préremplissage
|
||||
|
||||
- [ ] `lib/services/reprise_session.dart`
|
||||
- `applyToParent` : remplir parent1/parent2 depuis `parents[]`, enfants, motivation
|
||||
- `applyToAm` : remplir tous les champs AM
|
||||
|
||||
### API
|
||||
|
||||
- [ ] `lib/services/auth_service.dart` — `resoumettreReprise()` : accepter body complet (parent + AM), pas seulement identité
|
||||
- [ ] Étendre `UserRegistrationData` / `AmRegistrationData` helpers `toReprisePatchBody()` si utile
|
||||
|
||||
### Écrans fin de parcours
|
||||
|
||||
- [ ] `parent_register_step5_screen.dart` — PATCH avec co-parent, enfants, motivation
|
||||
- [ ] `am_register_step4_screen.dart` — PATCH avec fiche AM complète
|
||||
|
||||
### Hors scope back (inchangé)
|
||||
|
||||
RIB / IBAN / attestation CAF (étape 5 wizard parent) : **non persistés** — rien à envoyer en reprise.
|
||||
|
||||
### Non implémenté front (ticket #112 initial)
|
||||
|
||||
- [ ] Modale login « J’ai un numéro de dossier » → `POST /auth/reprise-identify` (back prêt, front absent)
|
||||
|
||||
---
|
||||
|
||||
## 5. Tests manuels suggérés
|
||||
|
||||
1. Refuser un dossier parent complet (≥1 enfant + co-parent + motivation).
|
||||
2. Ouvrir le lien mail `/reprise?token=…`.
|
||||
3. Vérifier dans DevTools que le GET contient `enfants[]` et `texte_motivation`.
|
||||
4. Après branchement front : wizard prérempli sur toutes les étapes.
|
||||
5. Resoumettre → statut `en_attente` pour les deux parents ; dossier visible file validation admin (#119).
|
||||
|
||||
---
|
||||
|
||||
## 6. Références code back
|
||||
|
||||
```
|
||||
backend/src/routes/auth/dto/reprise-dossier.dto.ts
|
||||
backend/src/routes/auth/dto/resoumettre-reprise.dto.ts
|
||||
backend/src/routes/auth/dto/enfant-reprise.dto.ts
|
||||
backend/src/routes/auth/auth.service.ts → getRepriseDossier, resoumettreReprise
|
||||
backend/src/routes/parents/dto/dossier-famille-complet.dto.ts
|
||||
```
|
||||
@@ -1,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`
|
||||
@@ -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**
|
||||
@@ -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`.*
|
||||
Reference in New Issue
Block a user