MadJax/SchotzIAD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: réutilisation des coordonnées déjà géocodées (domicile, insertion de trajets)

Browse Source 
Expose les coordonnées déjà géocodées dans ProfilDto
(DomicileLatitude/Longitude) et TrajetDto (DepartLatitude/Longitude,
ArriveeLatitude/Longitude) afin que le Frontend les réutilise sans
déclencher un nouveau géocodage BAN :

- Bouton « Utiliser mon domicile » (trajet-form) : utilise désormais
  les coordonnées du Profil au lieu de forcer un re-géocodage.
- Actions « insérer avant/après » (trajet-list) : transmettent les
  coordonnées déjà connues du point de fin repris au formulaire
  d'insertion.

Le résumé mensuel (ResumeService) résout les coordonnées via le
Cache_Adresses pour chaque trajet (nouvelle méthode
ConstruireResumeMensuelAvecCoordonneesAsync) ; le résumé annuel reste
inchangé pour éviter des lookups de cache inutiles sur une vue qui
n'affiche pas le détail des trajets.

Met à jour design.md et design-requirements.md (Requirements 10 et 11)
pour refléter le nouveau contrat d'API.
This commit is contained in:
MadJax
2026-10-13 20:52:04 +02:00
parent 7695deae10
commit d015ca1c98
13 changed files with 170 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.kiro/specs/schotziad-km-tracker/design-requirements.md
+2
View File
@@ -151,6 +151,7 @@ Le document est organisé **en miroir** des exigences de `requirements.md` : cha
1. IF le matricule reçu dépasse 8 caractères, THEN THE Backend SHALL rejeter le matricule avec une erreur HTTP 400.
2. WHEN l'utilisateur sauvegarde une Adresse_Domicile, THE Backend SHALL géocoder l'adresse via l'API BAN pour obtenir ses coordonnées et les stocker dans le Profil ainsi que dans le Cache_Adresses ; si le géocodage BAN échoue, THE Backend SHALL persister l'Adresse_Domicile textuelle sans coordonnées.
3. WHEN l'utilisateur modifie l'Adresse_Domicile dans le Profil et sauvegarde, THE Backend SHALL re-géocoder la nouvelle adresse via l'API BAN pour mettre à jour les coordonnées dans le Profil et dans le Cache_Adresses.
4. WHEN le Backend expose le Profil via `GET /api/profil` ou `PUT /api/profil`, THE Backend SHALL inclure dans le `ProfilDto` les coordonnées déjà géocodées de l'Adresse_Domicile (`DomicileLatitude`, `DomicileLongitude`, null si non résolues), afin que le bouton « Utiliser mon domicile » du Frontend les réutilise sans déclencher un nouveau géocodage BAN.
---
@@ -162,6 +163,7 @@ Le document est organisé **en miroir** des exigences de `requirements.md` : cha
1. WHEN l'utilisateur sélectionne une Adresse_Nommee dans le formulaire d'insertion pour un champ adresse, THE Frontend SHALL associer les coordonnées géographiques (latitude, longitude) de l'Adresse_Nommee pour transmission au Backend.
2. WHERE l'insertion utilise l'autocomplétion pour une nouvelle adresse, THE Frontend SHALL s'appuyer sur l'API BAN pour proposer les suggestions et récupérer les coordonnées, selon les mêmes modalités techniques que le formulaire de saisie (voir Requirement 1).
3. WHEN le Backend expose un Trajet via `TrajetDto`, THE Backend SHALL inclure les coordonnées déjà géocodées de ses adresses de départ et d'arrivée (`DepartLatitude`, `DepartLongitude`, `ArriveeLatitude`, `ArriveeLongitude`, null si non résolues), afin que les actions « insérer avant » et « insérer après » du Frontend reprenant le point de fin d'un Trajet existant transmettent ces coordonnées au formulaire d'insertion sans déclencher de nouveau géocodage BAN.
---