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
+8
-19
@@ -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.
|
||||
|
||||
@@ -0,0 +1,37 @@
|
||||
# Ticket #14 – Note pour modifications backend
|
||||
|
||||
**Contexte :** Première connexion admin → panneau Paramètres, déblocage après clic sur « Sauvegarder ». Le front appelle `POST /api/v1/configuration/setup/complete` au clic sur Sauvegarder.
|
||||
|
||||
## Problème
|
||||
|
||||
Erreur renvoyée par le back :
|
||||
`invalid input syntax for type uuid: "system"`
|
||||
|
||||
- Le controller fait `const userId = req.user?.id || 'system'` puis `markSetupCompleted(userId)`.
|
||||
- Le service `set()` fait `config.modifiePar = { id: userId }` ; la colonne `modifie_par` est une FK UUID vers `users`.
|
||||
- La chaîne `"system"` n’est pas un UUID valide → erreur PostgreSQL.
|
||||
|
||||
## Modifications à apporter au backend
|
||||
|
||||
**Option A – Accepter l’absence d’utilisateur (recommandé si la route peut être appelée sans JWT)**
|
||||
|
||||
1. **`config.controller.ts`** (route `completeSetup`)
|
||||
- Remplacer :
|
||||
`const userId = req.user?.id || 'system';`
|
||||
- Par :
|
||||
`const userId = req.user?.id ?? null;`
|
||||
|
||||
2. **`config.service.ts`** (`markSetupCompleted`)
|
||||
- Changer la signature :
|
||||
`async markSetupCompleted(userId: string | null): Promise<void>`
|
||||
- Et appeler :
|
||||
`await this.set('setup_completed', 'true', userId ?? undefined);`
|
||||
- Dans `set()`, ne pas remplir `modifiePar` quand `userId` est absent (déjà le cas si `if (userId)`).
|
||||
|
||||
**Option B – Imposer un utilisateur authentifié**
|
||||
|
||||
- Activer le guard JWT (et éventuellement RolesGuard) sur `POST /configuration/setup/complete` pour que `req.user` soit toujours défini, et garder `userId = req.user.id` (plus de fallback `'system'`).
|
||||
|
||||
---
|
||||
|
||||
Une fois le back modifié, le flux « Sauvegarder » → déblocage des panneaux fonctionne sans erreur.
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,433 @@
|
||||
# 📋 Backlog Phase 2 - P'titsPas
|
||||
|
||||
**Version** : 1.0
|
||||
**Date** : 25 Novembre 2025
|
||||
**Auteur** : Équipe PtitsPas
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Objectif de ce document
|
||||
|
||||
Ce document liste toutes les **fonctionnalités reportées en Phase 2**. Ces fonctionnalités ne sont pas bloquantes pour le MVP (Phase 1), mais apportent de la valeur ajoutée pour la production intensive.
|
||||
|
||||
---
|
||||
|
||||
## 📊 Vue d'ensemble
|
||||
|
||||
| Catégorie | Nombre de tickets | Estimation |
|
||||
|-----------|-------------------|------------|
|
||||
| **RGPD avancé** | 3 tickets | ~8h |
|
||||
| **Monitoring avancé** | 2 tickets | ~6h |
|
||||
| **Statistiques & Reporting** | 4 tickets | ~16h |
|
||||
| **Sauvegarde & Restauration** | 2 tickets | ~6h |
|
||||
| **Documentation utilisateur** | 3 tickets | ~12h |
|
||||
| **Améliorations UX** | 3 tickets | ~10h |
|
||||
| **TOTAL** | **17 tickets** | **~58h** |
|
||||
|
||||
---
|
||||
|
||||
## 🔒 RGPD avancé
|
||||
|
||||
### Ticket P2-01 : [Backend] API Suppression compte (soft delete)
|
||||
**Estimation** : 3h
|
||||
**Labels** : `backend`, `phase-2`, `rgpd`
|
||||
|
||||
**Description** :
|
||||
Implémenter le droit à l'oubli (RGPD Article 17) avec suppression logique des comptes.
|
||||
|
||||
**Tâches** :
|
||||
- [ ] Endpoint `DELETE /api/v1/users/:id` (soft delete)
|
||||
- [ ] Ajout champ `supprime_le` TIMESTAMPTZ dans `utilisateurs`
|
||||
- [ ] Anonymisation données personnelles (email, téléphone, adresse)
|
||||
- [ ] Conservation données légales (acceptations CGU)
|
||||
- [ ] Guards (super_admin only)
|
||||
- [ ] Tests unitaires
|
||||
|
||||
**Justification report Phase 2** :
|
||||
- Peu de demandes en phase test
|
||||
- Suppression manuelle possible en attendant
|
||||
|
||||
---
|
||||
|
||||
### Ticket P2-02 : [Backend] API Export données personnelles (RGPD)
|
||||
**Estimation** : 3h
|
||||
**Labels** : `backend`, `phase-2`, `rgpd`
|
||||
|
||||
**Description** :
|
||||
Implémenter le droit à la portabilité (RGPD Article 20) avec export JSON des données personnelles.
|
||||
|
||||
**Tâches** :
|
||||
- [ ] Endpoint `GET /api/v1/users/:id/export` (JSON)
|
||||
- [ ] Export données utilisateur + enfants + acceptations
|
||||
- [ ] Format JSON structuré
|
||||
- [ ] Guards (utilisateur lui-même ou admin)
|
||||
- [ ] Tests unitaires
|
||||
|
||||
**Justification report Phase 2** :
|
||||
- Export manuel SQL possible en phase test
|
||||
- Peu de demandes attendues
|
||||
|
||||
---
|
||||
|
||||
### Ticket P2-03 : [Backend] Cron anonymisation comptes inactifs
|
||||
**Estimation** : 2h
|
||||
**Labels** : `backend`, `phase-2`, `rgpd`, `cron`
|
||||
|
||||
**Description** :
|
||||
Anonymiser automatiquement les comptes inactifs après X mois (configurable).
|
||||
|
||||
**Tâches** :
|
||||
- [ ] Cron job quotidien
|
||||
- [ ] Détection comptes inactifs (dernière connexion > X mois)
|
||||
- [ ] Anonymisation automatique
|
||||
- [ ] Notification admin
|
||||
- [ ] Configuration durée inactivité (table `configuration`)
|
||||
- [ ] Tests
|
||||
|
||||
**Justification report Phase 2** :
|
||||
- Pas de comptes inactifs en phase test
|
||||
- Peut être fait manuellement
|
||||
|
||||
---
|
||||
|
||||
## 📊 Monitoring avancé
|
||||
|
||||
### Ticket P2-04 : [Backend] API Métriques système
|
||||
**Estimation** : 3h
|
||||
**Labels** : `backend`, `phase-2`, `monitoring`
|
||||
|
||||
**Description** :
|
||||
Exposer des métriques système (CPU, RAM, disque, BDD) pour monitoring.
|
||||
|
||||
**Tâches** :
|
||||
- [ ] Endpoint `GET /api/v1/metrics` (super_admin only)
|
||||
- [ ] Métriques système (CPU, RAM, disque)
|
||||
- [ ] Métriques BDD (connexions, taille, requêtes lentes)
|
||||
- [ ] Métriques application (requêtes/s, temps réponse)
|
||||
- [ ] Format Prometheus (optionnel)
|
||||
- [ ] Tests
|
||||
|
||||
**Justification report Phase 2** :
|
||||
- Pas critique pour MVP
|
||||
- Logs suffisent pour debugging initial
|
||||
|
||||
---
|
||||
|
||||
### Ticket P2-05 : [Frontend] Dashboard Monitoring
|
||||
**Estimation** : 3h
|
||||
**Labels** : `frontend`, `phase-2`, `monitoring`, `admin`
|
||||
|
||||
**Description** :
|
||||
Créer un dashboard de monitoring pour le super admin.
|
||||
|
||||
**Tâches** :
|
||||
- [ ] Page `/admin/monitoring` (super_admin only)
|
||||
- [ ] Graphiques temps réel (CPU, RAM, disque)
|
||||
- [ ] Alertes (seuils configurables)
|
||||
- [ ] Historique métriques (7 jours)
|
||||
|
||||
**Justification report Phase 2** :
|
||||
- Pas critique pour MVP
|
||||
- Monitoring serveur possible via outils système
|
||||
|
||||
---
|
||||
|
||||
## 📈 Statistiques & Reporting
|
||||
|
||||
### Ticket P2-06 : [Backend] API Statistiques dashboard
|
||||
**Estimation** : 4h
|
||||
**Labels** : `backend`, `phase-2`, `statistiques`
|
||||
|
||||
**Description** :
|
||||
Créer les endpoints pour récupérer les statistiques de l'application.
|
||||
|
||||
**Tâches** :
|
||||
- [ ] Endpoint `GET /api/v1/stats/overview`
|
||||
- [ ] Statistiques globales (comptes, enfants, AM, validations)
|
||||
- [ ] Statistiques temporelles (inscriptions par mois, validations par semaine)
|
||||
- [ ] Statistiques géographiques (par ville)
|
||||
- [ ] Cache (rafraîchissement toutes les heures)
|
||||
- [ ] Tests
|
||||
|
||||
**Justification report Phase 2** :
|
||||
- Pas de données = pas de statistiques
|
||||
- Nécessite application en production
|
||||
|
||||
---
|
||||
|
||||
### Ticket P2-07 : [Frontend] Widgets statistiques dashboard
|
||||
**Estimation** : 4h
|
||||
**Labels** : `frontend`, `phase-2`, `statistiques`, `gestionnaire`
|
||||
|
||||
**Description** :
|
||||
Afficher les statistiques dans le dashboard gestionnaire.
|
||||
|
||||
**Tâches** :
|
||||
- [ ] Widget "Comptes en attente" (nombre)
|
||||
- [ ] Widget "Comptes validés ce mois" (graphique)
|
||||
- [ ] Widget "Enfants inscrits" (nombre)
|
||||
- [ ] Widget "AM disponibles" (nombre)
|
||||
- [ ] Graphique évolution inscriptions (6 derniers mois)
|
||||
|
||||
**Justification report Phase 2** :
|
||||
- Besoin d'utilisateurs réels pour avoir des données
|
||||
- Fonctionnalité importante pour vente, mais pas bloquante pour MVP
|
||||
|
||||
---
|
||||
|
||||
### Ticket P2-08 : [Backend] API Export rapports (CSV/PDF)
|
||||
**Estimation** : 4h
|
||||
**Labels** : `backend`, `phase-2`, `reporting`
|
||||
|
||||
**Description** :
|
||||
Permettre l'export de rapports pour les gestionnaires.
|
||||
|
||||
**Tâches** :
|
||||
- [ ] Endpoint `GET /api/v1/reports/users` (CSV)
|
||||
- [ ] Endpoint `GET /api/v1/reports/validations` (CSV)
|
||||
- [ ] Endpoint `GET /api/v1/reports/summary` (PDF)
|
||||
- [ ] Génération PDF (librairie PDFKit)
|
||||
- [ ] Filtres (date, statut, rôle)
|
||||
- [ ] Tests
|
||||
|
||||
**Justification report Phase 2** :
|
||||
- Export manuel SQL possible en phase test
|
||||
- Nécessite données réelles
|
||||
|
||||
---
|
||||
|
||||
### Ticket P2-09 : [Frontend] Écran Rapports
|
||||
**Estimation** : 4h
|
||||
**Labels** : `frontend`, `phase-2`, `reporting`, `gestionnaire`
|
||||
|
||||
**Description** :
|
||||
Créer un écran de génération de rapports pour les gestionnaires.
|
||||
|
||||
**Tâches** :
|
||||
- [ ] Page `/admin/rapports` (gestionnaire/admin)
|
||||
- [ ] Sélection type de rapport (utilisateurs, validations, synthèse)
|
||||
- [ ] Filtres (date, statut, rôle)
|
||||
- [ ] Prévisualisation
|
||||
- [ ] Téléchargement (CSV/PDF)
|
||||
|
||||
**Justification report Phase 2** :
|
||||
- Pas prioritaire pour MVP
|
||||
- Nécessite données réelles
|
||||
|
||||
---
|
||||
|
||||
## 💾 Sauvegarde & Restauration
|
||||
|
||||
### Ticket P2-10 : [Infra] Script backup PostgreSQL automatique
|
||||
**Estimation** : 3h
|
||||
**Labels** : `infra`, `phase-2`, `backup`
|
||||
|
||||
**Description** :
|
||||
Créer un script de sauvegarde automatique de la base de données.
|
||||
|
||||
**Tâches** :
|
||||
- [ ] Script `backup.sh` avec `pg_dump`
|
||||
- [ ] Compression (gzip)
|
||||
- [ ] Rotation (garder 30 derniers jours)
|
||||
- [ ] Cron job quotidien (3h du matin)
|
||||
- [ ] Notification email en cas d'échec
|
||||
- [ ] Tests restauration
|
||||
|
||||
**Justification report Phase 2** :
|
||||
- Pas bloquant pour développement
|
||||
- Backup manuel possible en phase test
|
||||
- À faire avant mise en production
|
||||
|
||||
---
|
||||
|
||||
### Ticket P2-11 : [Doc] Guide sauvegarde & restauration
|
||||
**Estimation** : 3h
|
||||
**Labels** : `documentation`, `phase-2`, `backup`
|
||||
|
||||
**Description** :
|
||||
Documenter les procédures de sauvegarde et restauration pour les admins sys.
|
||||
|
||||
**Tâches** :
|
||||
- [ ] Procédure sauvegarde manuelle
|
||||
- [ ] Procédure restauration
|
||||
- [ ] Configuration cron
|
||||
- [ ] Troubleshooting
|
||||
- [ ] Exemples de commandes
|
||||
- [ ] Checklist pré-restauration
|
||||
|
||||
**Justification report Phase 2** :
|
||||
- Documentation technique, pas bloquante pour MVP
|
||||
- À faire avant mise en production
|
||||
|
||||
---
|
||||
|
||||
## 📚 Documentation utilisateur
|
||||
|
||||
### Ticket P2-12 : [Doc] Guide utilisateur Gestionnaire
|
||||
**Estimation** : 4h
|
||||
**Labels** : `documentation`, `phase-2`, `formation`
|
||||
|
||||
**Description** :
|
||||
Rédiger le guide utilisateur pour les gestionnaires.
|
||||
|
||||
**Tâches** :
|
||||
- [ ] Connexion et première utilisation
|
||||
- [ ] Consultation des demandes
|
||||
- [ ] Validation/Refus de comptes
|
||||
- [ ] Gestion des paramètres
|
||||
- [ ] FAQ gestionnaire
|
||||
- [ ] Captures d'écran
|
||||
|
||||
**Justification report Phase 2** :
|
||||
- Formation présentiel prioritaire pour premiers utilisateurs
|
||||
- Documentation nécessaire pour scalabilité
|
||||
|
||||
---
|
||||
|
||||
### Ticket P2-13 : [Doc] Guide utilisateur Parent/AM
|
||||
**Estimation** : 4h
|
||||
**Labels** : `documentation`, `phase-2`, `formation`
|
||||
|
||||
**Description** :
|
||||
Rédiger le guide utilisateur pour les parents et assistantes maternelles.
|
||||
|
||||
**Tâches** :
|
||||
- [ ] Inscription étape par étape
|
||||
- [ ] Création du mot de passe
|
||||
- [ ] Connexion
|
||||
- [ ] Utilisation de l'application
|
||||
- [ ] FAQ parent/AM
|
||||
- [ ] Captures d'écran
|
||||
|
||||
**Justification report Phase 2** :
|
||||
- Formation présentiel prioritaire
|
||||
- Documentation nécessaire pour scalabilité
|
||||
|
||||
---
|
||||
|
||||
### Ticket P2-14 : [Doc] Vidéos tutoriels
|
||||
**Estimation** : 4h
|
||||
**Labels** : `documentation`, `phase-2`, `formation`, `video`
|
||||
|
||||
**Description** :
|
||||
Créer des vidéos tutoriels pour les utilisateurs.
|
||||
|
||||
**Tâches** :
|
||||
- [ ] Vidéo "Inscription parent" (3-5 min)
|
||||
- [ ] Vidéo "Inscription AM" (3-5 min)
|
||||
- [ ] Vidéo "Validation comptes gestionnaire" (3-5 min)
|
||||
- [ ] Vidéo "Configuration initiale admin" (5-7 min)
|
||||
- [ ] Hébergement (YouTube privé ou serveur)
|
||||
|
||||
**Justification report Phase 2** :
|
||||
- Pas bloquant pour MVP
|
||||
- Utile pour scalabilité et autonomie utilisateurs
|
||||
|
||||
---
|
||||
|
||||
## 🎨 Améliorations UX
|
||||
|
||||
### Ticket P2-15 : [Frontend] Mode sombre
|
||||
**Estimation** : 3h
|
||||
**Labels** : `frontend`, `phase-2`, `ux`
|
||||
|
||||
**Description** :
|
||||
Ajouter un mode sombre à l'application.
|
||||
|
||||
**Tâches** :
|
||||
- [ ] Thème sombre (couleurs, contrastes)
|
||||
- [ ] Toggle mode clair/sombre
|
||||
- [ ] Sauvegarde préférence utilisateur
|
||||
- [ ] Adaptation tous les écrans
|
||||
|
||||
**Justification report Phase 2** :
|
||||
- Nice-to-have, pas bloquant
|
||||
- Améliore confort utilisateur
|
||||
|
||||
---
|
||||
|
||||
### Ticket P2-16 : [Frontend] Notifications push (optionnel)
|
||||
**Estimation** : 4h
|
||||
**Labels** : `frontend`, `phase-2`, `ux`, `notifications`
|
||||
|
||||
**Description** :
|
||||
Ajouter des notifications push pour les événements importants.
|
||||
|
||||
**Tâches** :
|
||||
- [ ] Service Worker (PWA)
|
||||
- [ ] Notification "Compte validé"
|
||||
- [ ] Notification "Nouveau message" (si messagerie)
|
||||
- [ ] Gestion permissions
|
||||
- [ ] Paramètres notifications
|
||||
|
||||
**Justification report Phase 2** :
|
||||
- Nice-to-have, pas bloquant
|
||||
- Nécessite PWA ou app mobile
|
||||
|
||||
---
|
||||
|
||||
### Ticket P2-17 : [Frontend] Accessibilité (WCAG 2.1)
|
||||
**Estimation** : 3h
|
||||
**Labels** : `frontend`, `phase-2`, `ux`, `a11y`
|
||||
|
||||
**Description** :
|
||||
Améliorer l'accessibilité de l'application (conformité WCAG 2.1).
|
||||
|
||||
**Tâches** :
|
||||
- [ ] Audit accessibilité (Lighthouse, axe)
|
||||
- [ ] Correction contrastes
|
||||
- [ ] Attributs ARIA
|
||||
- [ ] Navigation clavier
|
||||
- [ ] Lecteur d'écran (test)
|
||||
|
||||
**Justification report Phase 2** :
|
||||
- Amélioration continue
|
||||
- Pas bloquant pour MVP
|
||||
- Important pour collectivités (obligation légale)
|
||||
|
||||
---
|
||||
|
||||
## 📋 Priorisation Phase 2
|
||||
|
||||
### Priorité Haute (à faire en premier)
|
||||
1. **Sauvegarde & Restauration** (Tickets P2-10, P2-11) → Avant mise en production
|
||||
2. **Statistiques** (Tickets P2-06, P2-07) → Argument de vente
|
||||
3. **Documentation utilisateur** (Tickets P2-12, P2-13) → Scalabilité
|
||||
|
||||
### Priorité Moyenne
|
||||
4. **RGPD avancé** (Tickets P2-01, P2-02, P2-03) → Conformité
|
||||
5. **Reporting** (Tickets P2-08, P2-09) → Utile pour gestionnaires
|
||||
|
||||
### Priorité Basse
|
||||
6. **Monitoring avancé** (Tickets P2-04, P2-05) → Nice-to-have
|
||||
7. **Améliorations UX** (Tickets P2-15, P2-16, P2-17) → Confort
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Critères de passage en Phase 2
|
||||
|
||||
La Phase 2 peut commencer quand :
|
||||
- ✅ Phase 1 terminée (61 tickets)
|
||||
- ✅ Application déployée en production (au moins 1 collectivité)
|
||||
- ✅ Utilisateurs réels (au moins 10 comptes validés)
|
||||
- ✅ Feedback terrain collecté
|
||||
- ✅ Bugs critiques corrigés
|
||||
|
||||
---
|
||||
|
||||
## 📊 Estimation globale Phase 2
|
||||
|
||||
**Total** : 17 tickets
|
||||
**Estimation** : ~58h de développement
|
||||
|
||||
**Planning suggéré** :
|
||||
- Sprint 1 (2 semaines) : Sauvegarde + Statistiques (26h)
|
||||
- Sprint 2 (2 semaines) : Documentation + RGPD (24h)
|
||||
- Sprint 3 (1 semaine) : Reporting + Améliorations UX (8h)
|
||||
|
||||
---
|
||||
|
||||
**Dernière mise à jour** : 25 Novembre 2025
|
||||
**Version** : 1.0
|
||||
**Statut** : ✅ Backlog Phase 2 défini
|
||||
|
||||
@@ -0,0 +1,63 @@
|
||||
# Note Backend - Activation du module Gestionnaires (Ticket #92)
|
||||
|
||||
## Problème
|
||||
L'endpoint `GET /api/v1/gestionnaires` renvoie une erreur **404 Not Found**.
|
||||
Cela est dû au fait que le `GestionnairesModule` n'est pas importé dans l'arbre des modules de l'application (via `UserModule` ou `AppModule`).
|
||||
|
||||
## Solution de contournement actuelle (Frontend)
|
||||
Le frontend utilise actuellement l'endpoint générique `/api/v1/users` et filtre les résultats côté client pour ne garder que les utilisateurs ayant le rôle `gestionnaire`.
|
||||
*Fichier concerné : `frontend/lib/services/user_service.dart`*
|
||||
|
||||
## Correctif Backend à appliquer
|
||||
Pour activer proprement l'endpoint dédié, il faut effectuer les modifications suivantes dans le backend :
|
||||
|
||||
### 1. Importer le module dans `UserModule`
|
||||
Fichier : `backend/src/routes/user/user.module.ts`
|
||||
|
||||
Ajouter `GestionnairesModule` dans les imports.
|
||||
|
||||
```typescript
|
||||
import { GestionnairesModule } from './gestionnaires/gestionnaires.module';
|
||||
|
||||
@Module({
|
||||
imports: [
|
||||
// ... autres imports
|
||||
GestionnairesModule, // <--- AJOUTER ICI
|
||||
],
|
||||
// ...
|
||||
})
|
||||
export class UserModule { }
|
||||
```
|
||||
|
||||
### 2. Ajouter AuthModule dans `GestionnairesModule`
|
||||
Fichier : `backend/src/routes/user/gestionnaires/gestionnaires.module.ts`
|
||||
|
||||
Le contrôleur utilise `AuthGuard`, qui dépend de `JwtService` fourni par `AuthModule`.
|
||||
|
||||
```typescript
|
||||
import { AuthModule } from 'src/routes/auth/auth.module';
|
||||
|
||||
@Module({
|
||||
imports: [
|
||||
TypeOrmModule.forFeature([Users]),
|
||||
AuthModule // <--- AJOUTER ICI
|
||||
],
|
||||
controllers: [GestionnairesController],
|
||||
providers: [GestionnairesService],
|
||||
})
|
||||
export class GestionnairesModule { }
|
||||
```
|
||||
|
||||
## Après application du correctif
|
||||
Une fois ces modifications backend effectuées :
|
||||
1. Redémarrer le serveur backend.
|
||||
2. Modifier le frontend (`frontend/lib/services/user_service.dart`) pour utiliser à nouveau l'endpoint dédié :
|
||||
```dart
|
||||
static Future<List<AppUser>> getGestionnaires() async {
|
||||
final response = await http.get(
|
||||
Uri.parse('${ApiConfig.baseUrl}${ApiConfig.gestionnaires}'),
|
||||
headers: await _headers(),
|
||||
);
|
||||
// ...
|
||||
}
|
||||
```
|
||||
@@ -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).
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,116 @@
|
||||
# SuperNounou – SSS-001
|
||||
## Spécification technique & opérationnelle unifiée
|
||||
_Version 0.3 – 27 janvier 2026_
|
||||
|
||||
---
|
||||
|
||||
## 1. Objet
|
||||
Centraliser tous les aspects **techniques et opérationnels** de la plateforme SuperNounou :
|
||||
- Sauvegarde & Plan de Reprise d’Activité (PRA)
|
||||
- Spécifications des API & intégrations
|
||||
- Directives de déploiement, d’observabilité, de CI/CD
|
||||
|
||||
## 2. Portée
|
||||
Instances de production, pré-production et recette (Frontend, Backend, PostgreSQL, stockage objets), scripts d’installation, pipelines CI/CD, journaux et métriques.
|
||||
|
||||
## 3. Références
|
||||
- CDC SuperNounou V1.1
|
||||
- ISO 27001 / ISO 22301 bonnes pratiques
|
||||
- Politique sécurité DSI Enedis #SEC-POL-2024
|
||||
- RGPD (2016/679)
|
||||
|
||||
---
|
||||
|
||||
# A – Sauvegarde & Plan de Reprise d’Activité
|
||||
|
||||
### A.1 Architecture de sauvegarde
|
||||
Schéma bloc, chiffrement AES-256 (KMS), réplication hors-site « Object Storage B ».
|
||||
|
||||
### A.2 Stratégie de sauvegarde
|
||||
|
||||
| Type | Fréquence | Rétention | Support |
|
||||
|-------------------|-------------|-----------|--------------------|
|
||||
| Incrémentale | Quotidienne | 30 j | Object Storage A |
|
||||
| Complète | Hebdomadaire| 6 mois | Object Storage B |
|
||||
| Export logique DB | Mensuelle | 5 ans | Stockage Glacier |
|
||||
|
||||
### A.3 PRA
|
||||
RPO 24 h / RTO 4 h – scénarios : panne VM, corruption DB, sinistre DC – procédure détaillée + escalade.
|
||||
|
||||
### A.4 Tests de restauration
|
||||
Intégrale semestrielle, partielle trimestrielle – rapport d’audit et actions correctives.
|
||||
|
||||
### A.5 Monitoring & alertes
|
||||
Endpoint Prometheus `/metrics`, tableau Grafana « Backup status », alerte > 26 h sans backup.
|
||||
|
||||
### A.6 Rôles
|
||||
DevOps Lead (implémentation), DBA (tests restore), RSSI (audit).
|
||||
|
||||
---
|
||||
|
||||
# B – API & Intégrations
|
||||
|
||||
### B.1 Conventions
|
||||
OpenAPI 3 livré (`openapi.yaml`), version URL `/api/v1`, ISO 8601 dates.
|
||||
|
||||
### B.2 Sécurité API
|
||||
JWT Bearer (ou OAuth 2), TLS 1.3, rate-limit 100 req/min/IP, signature HMAC pour webhooks.
|
||||
|
||||
### B.3 Exemples
|
||||
Collection Postman, scripts cURL, guide « Appeler l’API ».
|
||||
|
||||
### B.4 Intégrations futures
|
||||
SSO LDAP/SAML, webhook `contract.validated`, export statistiques CSV.
|
||||
|
||||
### B.5 Contrat de gestion des comptes d'administration
|
||||
- Création d'un administrateur avec un contrat minimal stable : `nom`, `prenom`, `email`, `password`, `telephone`.
|
||||
- Le rôle n'est jamais fourni par le frontend pour ce flux ; le backend impose `ADMINISTRATEUR`.
|
||||
- Les champs hors périmètre (adresse complète, photo, métadonnées métier non nécessaires) ne sont pas requis.
|
||||
- Les protections d'autorisation restent actives : un `SUPER_ADMIN` n'est pas supprimable et son identité (`nom`, `prenom`) est non modifiable.
|
||||
- Côté interface d'administration, les actions d'édition sont conditionnées aux droits ; les entrées non éditables restent consultables en lecture seule.
|
||||
|
||||
---
|
||||
|
||||
# C – Déploiement, CI/CD et Observabilité *(nouveau)*
|
||||
|
||||
### C.1 Déploiement communal (on-premise)
|
||||
- **Objectif** : installation complète sur un serveur Linux ou VM en moins d’1 h.
|
||||
- **Livrable** : solution de packaging **au choix** (Docker Compose, image VM, paquet .deb/.rpm).
|
||||
- **Script update / rollback** : `update.sh` ou équivalent (backup ➜ pull ➜ migrate ➜ vérif ; rollback ≤ 5 min).
|
||||
- **Config** : fichier `.env.sample` décrivant toutes les variables.
|
||||
|
||||
### C.2 Environnements
|
||||
- Developpement local (Docker Compose).
|
||||
- Recette & Production (serveur communal).
|
||||
- Les étudiants doivent décrire la procédure de bascule Recette → Prod.
|
||||
|
||||
### C.3 Pipeline CI/CD
|
||||
- Pipeline automatisé (tests unitaires + build image + scan CVE) déclenché à chaque merge.
|
||||
- L’école fournit son propre dépôt Git/runner.
|
||||
- Artifacts : images taguées, notes de version (`CHANGELOG.md`).
|
||||
|
||||
### C.4 Observabilité & logs
|
||||
- Journaux applicatifs JSON (timestamp UTC, level, traceId).
|
||||
- Rotation/retention : 7 jours sur disque, 30 jours sur archive compressée.
|
||||
- Export métriques Prometheus (`/metrics`) : latence API, nombre de sessions, files d’attente hors-ligne.
|
||||
- Tableaux Grafana d’exemple inclus (`grafana_dashboard.json`).
|
||||
|
||||
### C.5 SLA et performances (indicatifs)
|
||||
- Disponibilité mensuelle cible : **≥ 98 %**.
|
||||
- Temps de réponse P95 des opérations courantes : **< 500 ms**.
|
||||
- Capacité test : **≈ 50 sessions simultanées** sans dégradation (> 1 s).
|
||||
|
||||
---
|
||||
|
||||
# D – Glossaire
|
||||
AES-256, JWT, KMS, OpenAPI, RPO, RTO, rate-limit, HMAC, Compose, CI/CD…
|
||||
|
||||
---
|
||||
|
||||
# E – Historique des versions
|
||||
|
||||
| Version | Date | Auteur | Commentaire |
|
||||
|---------|------------|------------------|---------------------------------|
|
||||
| 0.1-draft | 2025-04-24 | Équipe projet | Création du SSS unifié |
|
||||
| 0.2 | 2025-04-24 | ChatGPT & Julien | Ajout déploiement / CI/CD / logs |
|
||||
| 0.3 | 2026-01-27 | Équipe projet | Contrat admin harmonisé et règles d'autorisation |
|
||||
@@ -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