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_base64etphoto_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).
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 sansphoto_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.
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_base64etphoto_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.
## 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
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.
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.
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.*
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Contexte
Le ticket #91 a fermé le branchement de POST /api/v1/auth/register/am, mais la chaîne photo reste fragile :
photo_base64etphoto_filenamesont tous deux présents (auth.service.ts,inscrireAMComplet). Or le front n’envoie pasphoto_filename.registerAMn’envoie pasphoto_filename; l’étape 2 AM fournit unonPickPhotovide (am_register_step2_screen.dart) ; le récap étape 4 forcephotoPath: nullpour l’affichage ; sur le web, s’appuyer uniquement surdart: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
photo_base64est présent et valide (data-URLdata:image/...;base64,...) : persister la photo même siphoto_filenameest absent → utiliser un nom par défaut (ex.photo_am.jpg) ; l’extension effective doit rester cohérente avecsauvegarderPhotoDepuisBase64(déjà dérivée du type dans le data-URL).@ApiProperty:photo_filenameoptionnel lorsquephoto_base64est fourni ; préciser le défaut serveur.Critères d’acceptation (back)
photo_base64valide sansphoto_filename→ utilisateur créé,photo_urlrenseigné, fichier présent côté stockage configuré.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
XFile.readAsBytes(); ne pas dépendre uniquement deFile(path)sur web.Uint8List?) ou équivalent jusqu’àregisterAM.photo_base64etphoto_filenamelorsqu’une photo est présente (nom dérivé du fichier ou valeur fixe cohérente, alignée parents).registerParentsi possible.Critères d’acceptation (front)
photo_urlcôté serveur non vide après inscription (vérification admin / BDD).Partie C — QA / recette globale
Références
tmp/inscription-am-photo-backend.md— section backend rappelLivraison code : parties A (back) et B (front) merg�es dans
develop.feature/120-inscription-am-photo-backend(d�fautphoto_filename, persistance si base64 seul).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.
Fermeture ticket #120 — livré sur
developBranche
feature/120-inscription-am-photomergée dansdevelop(livraison : inscription AM alignée parents + panneau validation gestionnaire).Inscription AM (alignement parents)
registration_photo_slot, scripts de test Node).Panneau gestionnaire — onglet « À valider »
iconSize34).Wizard validation dossier AM
[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 datesdd/MM/yyyy(formatIsoDateFr).ValidationDetailSection: titre optionnel (wizard AM).Wizard validation famille
Nettoyage
debugPrintlié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
developet recette.