jmartin/petitspas
1
0
Fork 0
Code Issues 46 Pull Requests Actions Packages Projects Releases Wiki Activity

[Full-stack] Inscription AM — photo, API et UX alignés sur les parents (suite #91) #120

New Issue
Closed
opened 2026-04-12 19:37:06 +00:00 by jmartin · 2 comments
jmartin commented 2026-04-12 19:37:06 +00:00
Owner
Copy Link

Contexte

Le ticket #91 a fermé le branchement de POST /api/v1/auth/register/am, mais la chaîne photo reste fragile :

  • Backend : la photo n’est persistée que si photo_base64 et photo_filename sont tous deux présents (auth.service.ts, inscrireAMComplet). Or le front n’envoie pas photo_filename.
  • Frontend : registerAM n’envoie pas photo_filename ; l’étape 2 AM fournit un onPickPhoto vide (am_register_step2_screen.dart) ; le récap étape 4 force photoPath: null pour l’affichage ; sur le web, s’appuyer uniquement sur dart:io + File(path) est insuffisant (même approche que parents : ImagePicker + readAsBytes, kIsWeb).

Objectif global : une assistante peut soumettre une inscription avec photo réelle ; le gestionnaire voit la photo dans le flux de validation ; comportement équivalent au parcours parents (base64 + nom de fichier + robustesse).

Partie A — Backend

Fichiers indicatifs : backend/src/routes/auth/auth.service.ts, backend/src/routes/auth/dto/register-am-complet.dto.ts, backend/src/routes/auth/auth.controller.ts

À faire

  • Si photo_base64 est présent et valide (data-URL data:image/...;base64,...) : persister la photo même si photo_filename est absent → utiliser un nom par défaut (ex. photo_am.jpg) ; l’extension effective doit rester cohérente avec sauvegarderPhotoDepuisBase64 (déjà dérivée du type dans le data-URL).
  • Si les deux champs sont présents : comportement actuel conservé (pas de régression).
  • Mettre à jour les descriptions Swagger / @ApiProperty : photo_filename optionnel lorsque photo_base64 est fourni ; préciser le défaut serveur.

Critères d’acceptation (back)

  • Requête avec photo_base64 valide sans photo_filename → utilisateur créé, photo_url renseigné, fichier présent côté stockage configuré.
  • Requête avec les deux champs → inchangé ou amélioré, pas de régression.
  • Document OpenAPI à jour.

Partie B — Frontend

Fichiers indicatifs : frontend/lib/services/auth_service.dart (registerAM), frontend/lib/models/am_registration_data.dart, frontend/lib/screens/auth/am_register_step2_screen.dart, frontend/lib/screens/auth/am_register_step4_screen.dart, frontend/lib/widgets/professional_info_form_screen.dart, référence parents : parent_register_step3_screen.dart, parent_registration_payload.dart

À faire

  • Picker : choix photo galerie (qualité / redimensionnement raisonnables, comme les enfants parents) ; Web : lire les octets via XFile.readAsBytes() ; ne pas dépendre uniquement de File(path) sur web.
  • Modèle : transporter les octets (ex. Uint8List?) ou équivalent jusqu’à registerAM.
  • Payload : envoyer photo_base64 et photo_filename lorsqu’une photo est présente (nom dérivé du fichier ou valeur fixe cohérente, alignée parents).
  • Récap étape 4 : afficher la photo choisie (pas un placeholder systématique).
  • UX erreurs : message exploitable en cas d’échec (taille, réseau, 4xx), niveau comparable à registerParent si possible.
  • Métier : si le CDC impose la photo AM obligatoire, bloquer l’étape sans photo + consentement ; sinon documenter dans le ticket le cas « sans photo ».

Critères d’acceptation (front)

  • Parcours complet Web (build type Docker Flutter 3.19) : photo visible récap + envoyée ; photo_url côté serveur non vide après inscription (vérification admin / BDD).
  • Parcours mobile ou desktop : idem si applicable à l’équipe.

Partie C — QA / recette globale

  • Inscription AM avec photo : dossier visible À valider côté gestionnaire avec photo affichable (selon implémentation actuelle des listes / wizard AM).
  • Pas de régression sur inscription sans photo si toujours supportée.

Références

  • Suite logique du #91
  • Spec locale optionnelle (équipe) : tmp/inscription-am-photo-backend.md — section backend rappel
## Contexte Le ticket **#91** a fermé le branchement de **POST /api/v1/auth/register/am**, mais la chaîne **photo** reste fragile : - **Backend** : la photo n’est persistée que si `photo_base64` **et** `photo_filename` sont tous deux présents (`auth.service.ts`, `inscrireAMComplet`). Or le front n’envoie pas `photo_filename`. - **Frontend** : `registerAM` n’envoie pas `photo_filename` ; l’étape 2 AM fournit un `onPickPhoto` vide (`am_register_step2_screen.dart`) ; le récap étape 4 force `photoPath: null` pour l’affichage ; sur le web, s’appuyer uniquement sur `dart:io` + `File(path)` est insuffisant (même approche que parents : `ImagePicker` + `readAsBytes`, `kIsWeb`). **Objectif global** : une assistante peut soumettre une inscription avec photo réelle ; le gestionnaire voit la photo dans le flux de validation ; comportement équivalent au parcours **parents** (base64 + nom de fichier + robustesse). --- ## Partie A — Backend **Fichiers indicatifs** : `backend/src/routes/auth/auth.service.ts`, `backend/src/routes/auth/dto/register-am-complet.dto.ts`, `backend/src/routes/auth/auth.controller.ts` ### À faire - [ ] Si `photo_base64` est présent et valide (data-URL `data:image/...;base64,...`) : **persister la photo** même si `photo_filename` est absent → utiliser un nom par défaut (ex. `photo_am.jpg`) ; l’extension effective doit rester cohérente avec `sauvegarderPhotoDepuisBase64` (déjà dérivée du type dans le data-URL). - [ ] Si les deux champs sont présents : comportement actuel conservé (pas de régression). - [ ] Mettre à jour les descriptions **Swagger** / `@ApiProperty` : `photo_filename` optionnel lorsque `photo_base64` est fourni ; préciser le défaut serveur. ### Critères d’acceptation (back) - [ ] Requête avec `photo_base64` valide **sans** `photo_filename` → utilisateur créé, `photo_url` renseigné, fichier présent côté stockage configuré. - [ ] Requête avec les deux champs → inchangé ou amélioré, pas de régression. - [ ] Document OpenAPI à jour. --- ## Partie B — Frontend **Fichiers indicatifs** : `frontend/lib/services/auth_service.dart` (`registerAM`), `frontend/lib/models/am_registration_data.dart`, `frontend/lib/screens/auth/am_register_step2_screen.dart`, `frontend/lib/screens/auth/am_register_step4_screen.dart`, `frontend/lib/widgets/professional_info_form_screen.dart`, référence parents : `parent_register_step3_screen.dart`, `parent_registration_payload.dart` ### À faire - [ ] **Picker** : choix photo galerie (qualité / redimensionnement raisonnables, comme les enfants parents) ; **Web** : lire les octets via `XFile.readAsBytes()` ; ne pas dépendre uniquement de `File(path)` sur web. - [ ] **Modèle** : transporter les octets (ex. `Uint8List?`) ou équivalent jusqu’à `registerAM`. - [ ] **Payload** : envoyer `photo_base64` **et** `photo_filename` lorsqu’une photo est présente (nom dérivé du fichier ou valeur fixe cohérente, alignée parents). - [ ] **Récap étape 4** : afficher la photo choisie (pas un placeholder systématique). - [ ] **UX erreurs** : message exploitable en cas d’échec (taille, réseau, 4xx), niveau comparable à `registerParent` si possible. - [ ] **Métier** : si le CDC impose la photo AM obligatoire, bloquer l’étape sans photo + consentement ; sinon documenter dans le ticket le cas « sans photo ». ### Critères d’acceptation (front) - [ ] Parcours complet **Web** (build type Docker Flutter 3.19) : photo visible récap + envoyée ; `photo_url` côté serveur non vide après inscription (vérification admin / BDD). - [ ] Parcours **mobile ou desktop** : idem si applicable à l’équipe. --- ## Partie C — QA / recette globale - [ ] Inscription AM avec photo : dossier visible **À valider** côté gestionnaire avec photo affichable (selon implémentation actuelle des listes / wizard AM). - [ ] Pas de régression sur inscription **sans** photo si toujours supportée. ## Références - Suite logique du **#91** - Spec locale optionnelle (équipe) : `tmp/inscription-am-photo-backend.md` — section backend rappel
jmartin added the
frontend
backend
p3
auth
cdc
 labels 2026-04-12 19:37:06 +00:00
jmartin commented 2026-04-12 19:41:34 +00:00
Author
Owner
Copy Link

Livraison code : parties A (back) et B (front) merg�es dans develop.

  • Back : feature/120-inscription-am-photo-backend (d�faut photo_filename, persistance si base64 seul).
  • Front : feature/120-inscription-am-photo-frontend (ImagePicker, photo_bytes / filename, r�cap).

� faire c�t� �quipe : cocher les cases QA (Partie C) sur environnement de test.

**Livraison code** : parties A (back) et B (front) merg�es dans `develop`. - Back : `feature/120-inscription-am-photo-backend` (d�faut `photo_filename`, persistance si base64 seul). - Front : `feature/120-inscription-am-photo-frontend` (ImagePicker, `photo_bytes` / filename, r�cap). � faire c�t� �quipe : cocher les cases QA (Partie C) sur environnement de test.
jmartin commented 2026-04-13 15:40:49 +00:00
Author
Owner
Copy Link

Fermeture ticket #120 — livré sur develop

Branche feature/120-inscription-am-photo mergée dans develop (livraison : inscription AM alignée parents + panneau validation gestionnaire).

Inscription AM (alignement parents)

  • Photo, consentement, lieux de naissance : parcours et API alignés sur le modèle parents (DTO, entité user, migration SQL, écrans inscription AM, registration_photo_slot, scripts de test Node).

Panneau gestionnaire — onglet « À valider »

  • Bouton Ouvrir : visible au survol (même principe que les cartes admin), icône centrée sur la ligne et taille doublée (iconSize 34).

Wizard validation dossier AM

  • Titres : Identité et coordonnées · Dossier professionnel (au-dessus des champs à droite, pas de la photo) · Présentation.
  • Photo à gauche (ratio identité 35×45) ; grille droite [2,2,2,2] : NIR | date de naissance, ville | pays de naissance, n° agrément | date d'agrément, capacité | places.
  • AppUser : date_naissance, lieu_naissance_ville, lieu_naissance_pays ; affichage dates dd/MM/yyyy (formatIsoDateFr).
  • ValidationDetailSection : titre optionnel (wizard AM).

Wizard validation famille

  • Étape 4 : titre « Présentation » (plus « Présentation / Motivation »).

Nettoyage

  • Suppression des debugPrint liés aux médias / images / chargement dossier (api_config, auth_network_image, dossier_unifie, user_service, carte enfant validation).

Issue fermée après merge sur develop et recette.

## Fermeture ticket #120 — livré sur `develop` Branche **`feature/120-inscription-am-photo`** mergée dans **`develop`** (livraison : inscription AM alignée parents + panneau validation gestionnaire). ### Inscription AM (alignement parents) - Photo, consentement, lieux de naissance : parcours et API alignés sur le modèle parents (DTO, entité user, migration SQL, écrans inscription AM, `registration_photo_slot`, scripts de test Node). ### Panneau gestionnaire — onglet « À valider » - Bouton **Ouvrir** : visible au **survol** (même principe que les cartes admin), **icône centrée** sur la ligne et **taille doublée** (`iconSize` 34). ### Wizard validation dossier AM - Titres : **Identité et coordonnées** · **Dossier professionnel** (au-dessus des champs à droite, pas de la photo) · **Présentation**. - **Photo** à gauche (ratio identité 35×45) ; **grille droite** `[2,2,2,2]` : NIR | date de naissance, ville | pays de naissance, n° agrément | date d'agrément, capacité | places. - **`AppUser`** : `date_naissance`, `lieu_naissance_ville`, `lieu_naissance_pays` ; affichage dates **`dd/MM/yyyy`** (`formatIsoDateFr`). - **`ValidationDetailSection`** : titre **optionnel** (wizard AM). ### Wizard validation famille - Étape 4 : titre **« Présentation »** (plus « Présentation / Motivation »). ### Nettoyage - Suppression des **`debugPrint`** liés aux médias / images / chargement dossier (`api_config`, `auth_network_image`, `dossier_unifie`, `user_service`, carte enfant validation). --- *Issue fermée après merge sur `develop` et recette.*
jmartin added this to the 0.1.0 milestone 2026-04-16 08:23:03 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
a11y
Accessibilité
admin
Administration
api
auth
Authentification
backend
Backend NestJS
bug
Something isn't working
cdc
Cahier des charges
cleanup
Nettoyage/Refactoring
critique
Critique
database
Base de données PostgreSQL
documentation
Improvements or additions to documentation
duplicate
This issue or pull request already exists
email
Email/Notifications
enhancement
New feature or request
frontend
Frontend Flutter/Web
gestionnaire
Gestionnaire
good first issue
Good for newcomers
help wanted
Extra attention is needed
infra
Infrastructure Docker/CI-CD
invalid
This doesn't seem right
juridique
Juridique/Légal
monitoring
Monitoring/Logs
on-premise
Configuration on-premise
p0-bloquant
Priorité 0 - BLOQUANT
p1-bloquant
Priorité 1 - BLOQUANT
p2
Priorité 2
p3
Priorité 3
p4
Priorité 4
phase-1
Phase 1
question
Further information is requested
rgpd
RGPD/Conformité
security
Sécurité
tests
Tests unitaires/E2E
ui
upload
Upload fichiers
ux
UX/UI
v0.1.0
Issue rattachée au périmètre release 0.1.0
wontfix
This will not be worked on
No Label
auth
backend
cdc
frontend
p3
Milestone
No items
No Milestone 0.1.0
Projects
Clear projects
No project
Assignees
Clear assignees
nnasarre jmartin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: jmartin/petitspas#120
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?