MALIO-DEV/Starseed
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[ERP-76 + ERP-68] Validations d'adresse client (RG → 422) + fixtures démo Catalog/Commercial #41

Merged
malio merged 4 commits from feature/ERP-76-68-client-address-validations-fixtures into develop 2026-06-01 22:14:24 +00:00
Conversation 1 Commits 4 Files Changed 6
+1005 -57
matthieu commented 2026-06-01 21:49:11 +00:00
Owner
Copy Link
Copy Source

Stack de 2 tickets sur une branche (squash sur develop).

ERP-76 (#500) — Validations d'adresse Client → 422

Les règles d'intégrité de l'onglet Adresse étaient soit non implémentées (RG-1.29), soit rejetées en 500 par les CHECK Postgres (RG-1.06/07/08/11). Elles sont désormais portées par des Assert\Callback applicatifs sur ClientAddress, qui remontent une 422 Hydra avant la base ; les CHECK BDD restent en filet de sécurité.

  • validateProspectExclusivity — isProspect exclusif de isDelivery/isBilling (RG-1.06/07/08).
  • validateBillingEmailPresence — billingEmail obligatoire ssi isBilling (RG-1.11).
  • validateCategoryTypes — refuse une catégorie de type DISTRIBUTEUR/COURTIER sur une adresse (RG-1.29, violation categories), via CategoryInterface (règle n°1 respectée).

Tests ClientAddressTest durcis (≥400 → 422 explicite) + 4 cas RG-1.29. Cahier de test M1 mis à jour.

ERP-68 (#486) — Fixtures démo Catalog + Commercial (dev only)

  • CategoryFixtures (Catalog) : 12 catégories sur les 4 types.
  • ClientFixtures (Commercial) : 14 clients couvrant les cas RG (dépendant distributeur/courtier RG-1.03, LCR + 2 RIB RG-1.13, Chèque sans RIB, multi-adresses Prospect/Livraison/Facturation RG-1.06/07/08/11, prospect seul, 3 contacts + tél. secondaire RG-1.05/1.02, archivé RG-1.22, onglet Information complet, multi-catégories M2M).

Résolution inter-modules via les seuls contrats Shared (CategoryInterface, SiteProviderInterface). Valeurs brutes normalisées par ClientFieldNormalizer. Données conformes aux CHECK BDD et aux validators ERP-76. Idempotentes (lookup companyName/name). Garde-fou : les deux fixtures sont no-op en environnement test (la base de test reste un socle minimal ; pas de pollution des comptages ni des cleanups FK).

Bonus — idempotence fixtures

AppFixtures (admin/alice/bob) rendu idempotent via lookup par username : doctrine:fixtures:load --append est désormais rejouable sans erreur sur tout le jeu de fixtures.

Vérifications

  • make test : 436/436 vert (0 échec/erreur).
  • make php-cs-fixer-allow-risky OK.
  • make db-reset charge sans erreur ; 2 runs --append consécutifs = idempotent (0 doublon ; 7 users / 14 clients / 12 catégories stables).
  • admin/admin intact.
Stack de 2 tickets sur une branche (squash sur `develop`). ## ERP-76 (#500) — Validations d'adresse Client → 422 Les règles d'intégrité de l'onglet Adresse étaient soit non implémentées (RG-1.29), soit rejetées en 500 par les CHECK Postgres (RG-1.06/07/08/11). Elles sont désormais portées par des `Assert\Callback` applicatifs sur `ClientAddress`, qui remontent une **422 Hydra avant la base** ; les CHECK BDD restent en filet de sécurité. - `validateProspectExclusivity` — `isProspect` exclusif de `isDelivery`/`isBilling` (RG-1.06/07/08). - `validateBillingEmailPresence` — `billingEmail` obligatoire ssi `isBilling` (RG-1.11). - `validateCategoryTypes` — refuse une catégorie de type DISTRIBUTEUR/COURTIER sur une adresse (RG-1.29, violation `categories`), via `CategoryInterface` (règle n°1 respectée). Tests `ClientAddressTest` durcis (≥400 → **422 explicite**) + 4 cas RG-1.29. Cahier de test M1 mis à jour. ## ERP-68 (#486) — Fixtures démo Catalog + Commercial (dev only) - `CategoryFixtures` (Catalog) : 12 catégories sur les 4 types. - `ClientFixtures` (Commercial) : 14 clients couvrant les cas RG (dépendant distributeur/courtier RG-1.03, LCR + 2 RIB RG-1.13, Chèque sans RIB, multi-adresses Prospect/Livraison/Facturation RG-1.06/07/08/11, prospect seul, 3 contacts + tél. secondaire RG-1.05/1.02, archivé RG-1.22, onglet Information complet, multi-catégories M2M). Résolution inter-modules via les seuls contrats Shared (`CategoryInterface`, `SiteProviderInterface`). Valeurs brutes normalisées par `ClientFieldNormalizer`. Données conformes aux CHECK BDD **et** aux validators ERP-76. Idempotentes (lookup `companyName`/`name`). **Garde-fou** : les deux fixtures sont no-op en environnement `test` (la base de test reste un socle minimal ; pas de pollution des comptages ni des cleanups FK). ## Bonus — idempotence fixtures `AppFixtures` (admin/alice/bob) rendu idempotent via lookup par username : `doctrine:fixtures:load --append` est désormais rejouable sans erreur sur tout le jeu de fixtures. ## Vérifications - `make test` : **436/436 vert** (0 échec/erreur). - `make php-cs-fixer-allow-risky` OK. - `make db-reset` charge sans erreur ; 2 runs `--append` consécutifs = idempotent (0 doublon ; 7 users / 14 clients / 12 catégories stables). - `admin/admin` intact.
matthieu added 3 commits 2026-06-01 21:49:12 +00:00
feat(commercial) : enforce address validations RG-1.06/07/08/11/29 → 422 fa20482393 
Mirror applicatif des CHECK Postgres d'adresse via Assert\Callback sur
ClientAddress, joue avant la base pour remonter une 422 Hydra au lieu d'une
500 DBAL, et durcit RG-1.29 (categorie d'adresse limitee a SECTEUR/AUTRE) :

- validateProspectExclusivity : isProspect exclusif de isDelivery/isBilling
  (RG-1.06/07/08, mirror chk_client_address_prospect_exclusive).
- validateBillingEmailPresence : billingEmail obligatoire ssi isBilling
  (RG-1.11, mirror chk_client_address_billing_email).
- validateCategoryTypes : refuse une categorie DISTRIBUTEUR/COURTIER sur une
  adresse (RG-1.29, violation 'categories'), via CategoryInterface.

Les CHECK BDD restent en filet de securite. Tests ClientAddressTest durcis de
>= 400 vers 422 explicite + 4 cas RG-1.29. Cahier de test M1 mis a jour.
chore(fixtures) : add Catalog categories + Commercial demo clients fixtures 6981dec5b3 
Donnees de demonstration dev (no-op en environnement test) couvrant les cas
metier du repertoire clients M1 :

- CategoryFixtures (Catalog) : 12 categories sur les 4 types DISTRIBUTEUR /
  COURTIER / SECTEUR / AUTRE. Depend de CategoryTypeFixtures. Idempotent
  (lookup name + type, hors soft-deleted).
- ClientFixtures (Commercial) : 14 clients couvrant RG-1.03 (dependant
  distributeur/courtier), RG-1.13 (LCR + 2 RIB), Cheque sans RIB,
  RG-1.06/07/08/11 (multi-adresses prospect/livraison/facturation), prospect
  seul, RG-1.05/1.02 (3 contacts + tel secondaire), RG-1.22 (archive), onglet
  Information complet, multi-categories M2M. Depend de CategoryFixtures /
  SitesFixtures / CommercialReferentialFixtures. Idempotent (lookup companyName
  normalise).

Resolution inter-modules via les seuls contrats Shared (CategoryInterface,
SiteProviderInterface) — regle n°1 respectee. Valeurs fournies brutes et
normalisees par ClientFieldNormalizer (companyName UPPERCASE, etc.). Donnees
conformes aux CHECK BDD et aux validators ERP-76. Garde-fou test : les deux
fixtures no-op en env test pour ne pas polluer comptages et cleanups FK.
chore(fixtures) : make AppFixtures idempotent on --append
Pull Request — Quality gate / Backend (PHP CS + PHPUnit) (pull_request) Successful in 1m42s
Details
Pull Request — Quality gate / Frontend (lint + Vitest + build) (pull_request) Successful in 1m2s
Details
039d4c6391 
admin / alice / bob sont desormais resolus via un lookup par username
(ensureUser) avant creation, sur le modele de ensureSystemRole (meme fichier)
et RbacDemoFixtures::ensureDemoUsers. Sans ce lookup, doctrine:fixtures:load
--append (sans purge) violait l'unicite de username en recreant ces comptes.

Resultat : tout le jeu de fixtures est rejouable en --append sans erreur ni
doublon (verifie : 2 runs consecutifs -> 7 users stables). Le flow canonical
make db-reset (purge + load) est inchange.
matthieu added the backM0-CategorieM1-Clienttype/choretype/feat labels 2026-06-01 21:49:42 +00:00
matthieu added 1 commit 2026-06-01 22:10:57 +00:00
fix(commercial) : billingEmail vide rejete en 422 et non en 500 (RG-1.11)
Pull Request — Quality gate / Backend (PHP CS + PHPUnit) (pull_request) Successful in 1m55s
Details
Pull Request — Quality gate / Frontend (lint + Vitest + build) (pull_request) Successful in 1m18s
Details
e6188535fd 
Le callback validateBillingEmailPresence testait null === billingEmail. Une
chaine vide "" (champ vide envoye par le client) passait donc les validators ;
le ClientAddressProcessor la normalisait ensuite en null APRES la validation,
puis la persistance d'une adresse is_billing=true avec billing_email=null
violait le CHECK chk_client_address_billing_email -> 500 DBAL au lieu du 422
attendu. Symetriquement, "" sur une adresse non facturable etait rejete a tort
en 422 alors qu'un champ vide equivaut a une absence d'email.

Le callback raisonne desormais sur la presence effective (null OU chaine vide
apres trim = absent), coheremment avec la normalisation du processor. Deux cas
de test ajoutes : adresse facturable + "" -> 422, adresse non facturable +
"" -> 201.
matthieu commented 2026-06-01 22:11:39 +00:00
Author
Owner
Copy Link
Copy Source

Review MR #41 — ERP-76 + ERP-68

Verdict : MR de très bonne qualité, bien documentée, tests solides. Un bug de correctness a été trouvé et corrigé directement sur la branche (commit e618853). Le reste n'est qu'observations mineures non bloquantes.

🔴 Majeur — corrigé dans e618853 : billingEmail vide → 500 au lieu de 422 (RG-1.11)

validateBillingEmailPresence (ClientAddress.php) testait null === $this->billingEmail. Une chaîne vide "" (cas courant d'un champ de formulaire vidé) passait donc les validators :

  1. #[Assert\Email] accepte "" (valide sans NotBlank) ;
  2. le callback ne déclenchait pas de violation car null === "" est faux ;
  3. le ClientAddressProcessor normalise ensuite "" → null après la validation (RG-1.21) ;
  4. la persistance d'une adresse is_billing=true + billing_email=null viole le CHECK chk_client_address_billing_email → 500 DBAL.

C'est précisément la régression « 500 au lieu de 422 » que ce ticket entend supprimer. Symétriquement, "" sur une adresse non facturable était rejeté à tort en 422 alors qu'un champ vide équivaut à une absence d'email.

Fix : le callback raisonne désormais sur la présence effective (null ou chaîne vide après trim = absent), cohéremment avec la normalisation du processor. Deux cas de test ajoutés (ClientAddressTest) :

  • adresse facturable + "" → 422 ;
  • adresse non facturable + "" → 201.

🟡 Mineur (observation, non corrigé) — règle n°1 dans ClientFixtures::getDependencies()

getDependencies() référence CategoryFixtures::class (Catalog) et SitesFixtures::class (Sites), soit un couplage inter-modules au sens strict de la règle n°1. En pratique c'est purement de l'ordonnancement de fixtures (FQCN, aucune logique métier cross-module ; la résolution métier passe bien par les contrats CategoryInterface / SiteProviderInterface). Acceptable, mais mériterait soit une exception explicitement documentée, soit — si on veut être puriste — un marqueur d'ordonnancement dans Shared/. Non bloquant.

🟢 Points vérifiés sans réserve

  • RG-1.29 fixtures : aucune adresse ne reçoit de catégorie DISTRIBUTEUR/COURTIER (uniquement SECTEUR/AUTRE). Conforme.
  • Résolution catégorie par name seul : non ambiguë (les noms sont uniques inter-types dans CategoryFixtures). À garder en tête si des noms dupliqués apparaissent un jour entre types.
  • Idempotence --append : AppFixtures::ensureUser + addSite/addRbacRole dédupliquent via contains() → pas de doublon en table de jointure. ensureClient/ensureCategory lookup aligné sur les index uniques partiels. OK.
  • Garde-fou env test : CategoryFixtures et ClientFixtures no-op en test. OK.
  • validateProspectExclusivity / validateCategoryTypes : logique sans trou.

Vérifications post-fix

  • make test : 438/438 vert (436 d'origine + 2 nouveaux cas).
  • make php-cs-fixer-allow-risky : 0 fichier à corriger.

Une fois le CI revert, la MR est mergeable en l'état.

## Review MR #41 — ERP-76 + ERP-68 **Verdict : MR de très bonne qualité, bien documentée, tests solides.** Un bug de correctness a été trouvé et **corrigé directement sur la branche** (commit `e618853`). Le reste n'est qu'observations mineures non bloquantes. --- ### 🔴 Majeur — corrigé dans `e618853` : `billingEmail` vide → 500 au lieu de 422 (RG-1.11) `validateBillingEmailPresence` (`ClientAddress.php`) testait `null === $this->billingEmail`. Une **chaîne vide `""`** (cas courant d'un champ de formulaire vidé) passait donc les validators : 1. `#[Assert\Email]` accepte `""` (valide sans `NotBlank`) ; 2. le callback ne déclenchait pas de violation car `null === "" ` est faux ; 3. le `ClientAddressProcessor` normalise ensuite `""` → `null` **après** la validation (RG-1.21) ; 4. la persistance d'une adresse `is_billing=true` + `billing_email=null` viole le CHECK `chk_client_address_billing_email` → **500 DBAL**. C'est précisément la régression « 500 au lieu de 422 » que ce ticket entend supprimer. Symétriquement, `""` sur une adresse **non** facturable était rejeté à tort en 422 alors qu'un champ vide équivaut à une absence d'email. **Fix** : le callback raisonne désormais sur la présence effective (`null` **ou** chaîne vide après `trim` = absent), cohéremment avec la normalisation du processor. Deux cas de test ajoutés (`ClientAddressTest`) : - adresse facturable + `""` → 422 ; - adresse non facturable + `""` → 201. --- ### 🟡 Mineur (observation, non corrigé) — règle n°1 dans `ClientFixtures::getDependencies()` `getDependencies()` référence `CategoryFixtures::class` (Catalog) et `SitesFixtures::class` (Sites), soit un couplage inter-modules au sens strict de la règle n°1. En pratique c'est purement de l'**ordonnancement de fixtures** (FQCN, aucune logique métier cross-module ; la résolution métier passe bien par les contrats `CategoryInterface` / `SiteProviderInterface`). Acceptable, mais mériterait soit une exception explicitement documentée, soit — si on veut être puriste — un marqueur d'ordonnancement dans `Shared/`. Non bloquant. --- ### 🟢 Points vérifiés sans réserve - **RG-1.29 fixtures** : aucune adresse ne reçoit de catégorie `DISTRIBUTEUR`/`COURTIER` (uniquement SECTEUR/AUTRE). Conforme. - **Résolution catégorie par `name` seul** : non ambiguë (les noms sont uniques inter-types dans `CategoryFixtures`). À garder en tête si des noms dupliqués apparaissent un jour entre types. - **Idempotence `--append`** : `AppFixtures::ensureUser` + `addSite`/`addRbacRole` dédupliquent via `contains()` → pas de doublon en table de jointure. `ensureClient`/`ensureCategory` lookup aligné sur les index uniques partiels. OK. - **Garde-fou env `test`** : `CategoryFixtures` et `ClientFixtures` no-op en `test`. OK. - **`validateProspectExclusivity` / `validateCategoryTypes`** : logique sans trou. --- ### Vérifications post-fix - `make test` : **438/438 vert** (436 d'origine + 2 nouveaux cas). - `make php-cs-fixer-allow-risky` : 0 fichier à corriger. Une fois le CI revert, la MR est **mergeable en l'état**.
malio merged commit a52e3bec34 into develop 2026-06-01 22:14:24 +00:00
malio deleted branch feature/ERP-76-68-client-address-validations-fixtures 2026-06-01 22:14:26 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
back
Backend PHP / Symfony / API Platform
 blocked
Bloqué par une dépendance externe
 breaking
Breaking change — impact API / contrat
 db
Migrations Doctrine / schéma BDD
 front
Frontend Nuxt / Vue / @malio/layer-ui
 infra
Docker / nginx / config infra
 M0-Categorie
M0 — Catégories
 M1-Client
M1 — Clients
 M2-Fournisseur
M2 — Fournisseurs
 M3-Prestataire
M3 — Prestataires
 M4-Transporteur
M4 — Transporteurs
 M5-Ticket-pesee
M5 — Tickets de pesée
 type/chore
Tâche de maintenance (bump, conf, etc.)
 type/ci
CI / pipeline / workflows
 type/docs
Documentation
 type/feat
Nouvelle fonctionnalité
 type/fix
Correction de bug
 type/perf
Amélioration de performance
 type/refactor
Refacto sans changement fonctionnel
 type/test
Ajout ou modification de tests
 wip
Work in progress — ne pas merger
No Label back M0-Categorie M1-Client type/chore type/feat
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
malio (admin malio) matthieu (THOLOT DECHENE Matthieu) tristan (Autin )
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: MALIO-DEV/Starseed#41
Delete Branch "feature/ERP-76-68-client-address-validations-fixtures"

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?