feat(commercial) : messages de validation FR sur les contraintes back + garde-fou (ERP-107) #59

Merged
malio merged 5 commits from feat/erp-107-validation-messages-fr into develop 2026-06-04 09:27:33 +00:00
Owner

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.
## 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.
matthieu added 1 commit 2026-06-04 08:11:59 +00:00
feat(commercial) : messages de validation FR sur les contraintes back + garde-fou (ERP-107)
Pull Request — Quality gate / Backend (PHP CS + PHPUnit) (pull_request) Successful in 1m45s
Pull Request — Quality gate / Frontend (lint + Vitest + build) (pull_request) Successful in 1m12s
9202d2ee6f
Audit et complete les messages des contraintes #[Assert\*] des entites metier
(pendant back du mapping d'erreur par champ front ERP-101) :

- Message FR explicite sur toutes les contraintes (Email, NotBlank, Length,
  Bic, Iban, PositiveOrZero, Count...) des entites Client, ClientContact,
  ClientAddress, ClientRib, Category, Role, User.
- Ajout des Assert\Length manquantes calees sur le length de la colonne ORM
  (telephones VARCHAR(20), siren, nTva, accountNumber, username...) : evite
  une erreur Postgres 500 non rattachee au champ au profit d'une 422 propre.
- Locale FR globale (symfony/translation + default_locale: fr) comme filet
  pour les messages natifs non surcharges.
- Garde-fou tests/Architecture/EntityConstraintsHaveFrenchMessageTest : echoue
  si une contrainte n'a pas de message FR explicite ou si Assert\Length.max
  diverge du length ORM (whitelist justifiee pour les formats Bic/Iban/Regex).
- Test fonctionnel du JSON 422 reel (message FR + propertyPath consommable
  par useFormErrors cote front).
- Convention documentee dans .claude/rules/backend.md.

Tests : 469 verts (1793 assertions).
matthieu added 1 commit 2026-06-04 08:18:46 +00:00
merge: integrate origin/develop into ERP-107
Pull Request — Quality gate / Backend (PHP CS + PHPUnit) (pull_request) Successful in 1m48s
Pull Request — Quality gate / Frontend (lint + Vitest + build) (pull_request) Successful in 1m17s
27489c777b
Resout les conflits avec la suppression du contact inline du Client (#57,
ERP-104) : les champs firstName/lastName/phones/email ne sont plus portes par
Client. Les messages de validation FR correspondants vivent desormais sur
ClientContact. Le test fonctionnel du message email FR est recible sur la
sous-ressource POST /clients/{id}/contacts.
matthieu added the backM1-Clienttype/feat labels 2026-06-04 08:19:16 +00:00
malio added 1 commit 2026-06-04 08:41:40 +00:00
Merge branch 'develop' into feat/erp-107-validation-messages-fr
Pull Request — Quality gate / Backend (PHP CS + PHPUnit) (pull_request) Successful in 1m38s
Pull Request — Quality gate / Frontend (lint + Vitest + build) (pull_request) Successful in 1m7s
f6ae49e258
matthieu added 1 commit 2026-06-04 09:21:35 +00:00
docs(commercial) : spec + plan validation tous-blocs collections client (500 NonUniqueResult + collecte erreurs par bloc)
Pull Request — Quality gate / Backend (PHP CS + PHPUnit) (pull_request) Has been cancelled
Pull Request — Quality gate / Frontend (lint + Vitest + build) (pull_request) Has been cancelled
a17723cb1c
malio added 1 commit 2026-06-04 09:23:14 +00:00
Merge branch 'develop' into feat/erp-107-validation-messages-fr
Pull Request — Quality gate / Backend (PHP CS + PHPUnit) (pull_request) Successful in 1m48s
Pull Request — Quality gate / Frontend (lint + Vitest + build) (pull_request) Successful in 1m15s
16e376a0d0
malio merged commit 597101262d into develop 2026-06-04 09:27:33 +00:00
malio deleted branch feat/erp-107-validation-messages-fr 2026-06-04 09:27:33 +00:00
Sign in to join this conversation.