- API visitable_tiers (provider DBAL bbox/q/type, paginé) pour les pins de la carte
- POST /tours/{id}/reorder (drag & drop) : renumérotation atomique + recompute
- Layer front field-sales : TourMap (pins, popup, polyline, sélection rectangle),
liste d'étapes draggable (vuedraggable), composable de planification + Vitest
- Pages /tours, /tours/new, /tours/[id]/plan (split responsive, point custom géocodé)
- i18n FR, deep links Waze/Google/Apple, état 100% local
- Module FieldSales (ID field_sales, REQUIRED false) avec 2 permissions
field_sales.tours.view / .manage (scope V0.2, pas de reports.*), active
dans config/modules.php.
- Contrat partage VisitableInterface (getId/getDisplayName/getVisitableType)
implemente par Client (client) et Supplier (supplier) sans import inter-module.
Note doctrine.yaml : contrat polymorphe (2 implementations) donc resolu par
service via (tier_type, tier_id), pas via resolve_target_entities.
- 3 miroirs RBAC alignes : sidebar.php (section Tournées, item /tours, i18n
sidebar.field_sales.*), personas.ts et SeedE2ECommand.php (user-full) ;
matrice metier RbacSeeder (Commerciale = view+manage, Bureau = view, Compta
exclue, Admin bypass).
Ajoute la géolocalisation aux adresses Client et Fournisseur, socle de la
tournée commerciale (M6 field-sales).
Back :
- migration : latitude/longitude NUMERIC(10,7), geo_manual BOOLEAN, geocoded_at
TIMESTAMPTZ sur client_address et supplier_address (+ COMMENT ON COLUMN FR)
- GeolocatableAddressInterface (Shared/Domain/Contract) implémenté par les deux
entités ; bornes WGS84 validées (Range -90/90, -180/180, messages FR)
- GeocoderInterface + BanGeocoder (api-adresse.data.gouv.fr), branché via
AddressGeocoder dans les processors ; géocodage auto au create/update
- RG-6.08 : geo_manual=true fige les coordonnées (pas de réécriture auto)
- symfony/http-client passe en dépendance de production
Front :
- AddressGeoPin (Leaflet + OSM) : marqueur déplaçable -> PATCH lat/lng +
geoManual=true, bouton Re-géocoder, badges « à géolocaliser » / « pin manuel »
- intégration dans les blocs adresse Client et Fournisseur
Tests : PHPUnit (géocodage create, non-réécriture RG-6.08, mapping BAN, bornes) +
Vitest (drag du pin, badges, re-géocodage).
## Contexte
Résout **ERP-107** — pendant back du mapping d'erreur par champ front (ERP-101). Le front (`useFormErrors` / `mapViolationsToRecord`) affiche sous chaque champ le `message` renvoyé par le back. Ce ticket garantit que ces messages existent, sont en FR et rattachés au bon champ.
## Changements
- **Messages FR explicites** sur toutes les contraintes `#[Assert\*]` des entités métier : `Client`, `ClientContact`, `ClientAddress`, `ClientRib`, `Category`, `Role`, `User` (Email, NotBlank, Length, Bic, Iban, PositiveOrZero, Count…).
- **Contraintes `Assert\Length` manquantes ajoutées**, calées sur le `length` de la colonne ORM (téléphones `VARCHAR(20)`, `siren`, `nTva`, `accountNumber`, `username`…). Évite une erreur Postgres 500 non rattachée au champ → 422 propre.
- **Locale FR globale** (`symfony/translation` + `default_locale: fr`) comme filet pour les messages natifs Symfony non surchargés.
- **Garde-fou** `tests/Architecture/EntityConstraintsHaveFrenchMessageTest` : échoue si une contrainte n'a pas de message FR explicite (comparaison au défaut Symfony) ou si `Assert\Length.max` diverge du `length` ORM. Whitelist justifiée pour les formats auto-bornés (Bic/Iban/Regex CP/couleur hex).
- **Test fonctionnel** du JSON 422 réel : message FR + `propertyPath` consommable par le front.
- **Convention documentée** dans `.claude/rules/backend.md`.
## Décisions
- Stratégie retenue : message FR **explicite sur toutes** les contraintes + locale FR en filet (les deux leviers du ticket).
- Garde-fou `Length == ORM length` : **test bloquant** (anti-dérive).
- RG-1.03 (distributor/broker) : pas de `Assert\Callback` ajouté — le `ClientProcessor` gère **déjà** l'exclusivité (422 + `propertyPath`). Pas de doublon.
## Hors périmètre / à suivre
- **Alignement `nullable`(DB) / `NotBlank`(back) / `required`(front)** : les champs obligatoires existants ont été confirmés, mais aucun changement de nullabilité DB n'a été fait sans arbitrage métier. À recroiser avec les astérisques front (ERP-101 / PR #58) si divergence constatée.
## Vérifications
- `make test` : **469 tests verts** (1793 assertions), 0 échec/erreur.
- `php-cs-fixer` : 0 fichier à corriger.
---------
Co-authored-by: admin malio <malio@yuno.malio.fr>
Co-authored-by: Matthieu <contact@malio.fr>
Reviewed-on: #59
Co-authored-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr>
Co-committed-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr>
## ERP-71 — Sidebar : remonter le groupe « Commerciale » tout en haut
Réorganise `config/sidebar.php` (source de vérité backend de la sidebar) pour placer le groupe **« Commerciale »** en première position, devant « Administration » et « Mon compte ».
### Changement
- Déplacement du bloc de section `sidebar.commercial.section` en tête du tableau retourné par `config/sidebar.php`.
- **Aucune** modification des items, des `module` ni des `permission` à l'intérieur du bloc : ordre interne des onglets et RBAC strictement préservés.
### Vérifications
- `php -l config/sidebar.php` OK.
- Front : `useSidebar` / `default.vue` mappent les sections dans l'ordre reçu de `/api/sidebar` ; l'état actif/sélection et le repli/dépli sont pilotés par `MalioSidebar` selon la route courante — aucune dépendance à un index/ordre fixe. Le déplacement est donc sans effet de bord.
- Aucun test back ne porte sur la sidebar ; le test front `useSidebar.test.ts` ne fait aucune hypothèse d'ordre.
### Critères d'acceptation
- [x] Groupe « Commerciale » en première position
- [x] Ordre interne des onglets et permissions inchangés
- [x] Pas de dépendance front à l'ordre (actif/sélection/repli pilotés par la route)
Reviewed-on: #60
Co-authored-by: tristan <tristan@yuno.malio.fr>
Co-committed-by: tristan <tristan@yuno.malio.fr>
## Probleme (ERP-98)
Suite PHPUnit flaky ~1 run sur 2 -> hook pre-commit qui plante, recours au `--no-verify` sur des commits sains.
## Cause racine
Une seule cause commune : l'horloge `CLOCK_REALTIME` du conteneur n'est pas monotone sous WSL2/Docker (saut arriere sous charge), alors que le code et les tests supposaient une horloge stable.
- **401 « Invalid JWT Token »** : lexik validait `iat`/`nbf`/`exp` avec `clock_skew: 0` (`LooseValidAt(.., PT0S)` cote lcobucci). Un recul d'horloge apres `/login_check` rend le token « dans le futur » -> rejet.
- **Horodatages « meme seconde »** (`1780402904 > 1780402904`) : colonnes `TIMESTAMP(0)` + `sleep(1)` reel. L'ecart floor-seconde n'est nul que si l'horloge recule.
## Correctifs
| Fichier | Modif |
|---|---|
| `config/packages/lexik_jwt_authentication.yaml` | `clock_skew: 15` -> tolere la derive (benefice prod aussi) |
| `TimestampableBlamableSubscriber` | injection `ClockInterface` (prod inchange via NativeClock) |
| `CategoryTimestampableBlamableTest` | `ClockSensitiveTrait` + MockClock fige/avance, suppression des `sleep(1)` |
| `TimestampableBlamableSubscriberTest` | MockClock injecte dans les 4 instanciations |
**Subtilite** : `mockTime()` cree un MockClock en UTC ; les colonnes `TIMESTAMP WITHOUT TIME ZONE` round-trippent via le fuseau PHP (Europe/Paris) -> decalage 2h. Le mock est seede dans le fuseau par defaut (comme le NativeClock prod).
## Verifications
- `make test` : **464 tests verts**, 0 echec / 0 erreur
- Test timestamp cible : **5/5 deterministe** (et plus rapide, sleeps reels supprimes)
- `make php-cs-fixer-allow-risky` : 0 fichier a corriger
- Deprecations/notices PHPUnit preexistantes (hors perimetre)
Pas de migration, pas de changement front, RBAC intact.
---------
Co-authored-by: admin malio <malio@yuno.malio.fr>
Co-authored-by: Matthieu <contact@malio.fr>
Reviewed-on: #47
Co-authored-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr>
Co-committed-by: THOLOT DECHENE Matthieu <matthieu@yuno.malio.fr>
matthieu
Matthieu
tristan