AcadeNice/corentin_wakdo
10
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

fix: l'import CSV compare noms et unités sans tenir compte des accents, comme la base #178

Merged
Corentin merged 1 commit from fix/import-accent-insensitive into dev 2026-09-27 18:06:12 +02:00
Conversation 0 Commits 1 Files changed 4 +96 -6
Corentin commented 2026-09-27 17:56:49 +02:00
Owner
Copy link

Trouvé par le comparatif attendu / réel du 2026-09-27 : le test navigateur officiel tests/e2e/admin-product-recipe-import.spec.js était rouge sur la version déployée (11271f7).

Le défaut

Télécharger le modèle CSV puis le réimporter sans y toucher bloquait l'import : « Unité "piece" différente de l'unité existante ("pièce") pour l'ingrédient "Pain burger" » (et « Steak hache »).

Cause : depuis la migration 0016 (#166), les données de démonstration portent leurs accents (« pièce », « Steak haché »). La base retrouve bien l'ingrédient, car sa collation utf8mb4_unicode_ci ignore les accents ; mais la comparaison d'unité, faite en PHP par normalize(), en tenait compte.

La correction

  • ProductImportService::normalize() ignore désormais la casse et les accents (Normalizer de l'extension intl, présente dans l'image de production), comme la base. Ce changement vaut pour toutes les comparaisons de l'import : unités, regroupement des ingrédients, détection des doublons.
  • Le modèle téléchargé utilise les vraies graphies (« pièce », « Steak haché »).
  • La CI installe php-intl, comme l'image de production ; sans lui, Normalizer n'existe pas sur le PHP de Debian.

Preuves

  • 5 tests écrits avant la correction, tous rouges avant et verts après : 3 unitaires (même unité avec et sans accent, même ingrédient avec et sans accent, doublon qui ne diffère que par un accent) et 2 contre une vraie base (modèle réimporté tel quel sans erreur, unité existante « pièce » reconnue quand on écrit « Piece »).
  • PHPStan et PHPUnit complets : OK, 2357 tests.
  • Tests de l'import rejoués dans un conteneur Debian avec php-intl, comme la CI : OK, 66 tests.
  • Test navigateur officiel sur une pile jetable : 3 scénarios sur 3 passent.
  • gitleaks v8.30.1 sur l'historique de la branche : aucune fuite.
Trouvé par le comparatif attendu / réel du 2026-09-27 : le test navigateur officiel `tests/e2e/admin-product-recipe-import.spec.js` était rouge sur la version déployée (11271f7). ## Le défaut Télécharger le modèle CSV puis le réimporter sans y toucher bloquait l'import : « Unité "piece" différente de l'unité existante ("pièce") pour l'ingrédient "Pain burger" » (et « Steak hache »). Cause : depuis la migration 0016 (#166), les données de démonstration portent leurs accents (« pièce », « Steak haché »). La base retrouve bien l'ingrédient, car sa collation `utf8mb4_unicode_ci` ignore les accents ; mais la comparaison d'unité, faite en PHP par `normalize()`, en tenait compte. ## La correction - `ProductImportService::normalize()` ignore désormais la casse **et** les accents (`Normalizer` de l'extension intl, présente dans l'image de production), comme la base. Ce changement vaut pour toutes les comparaisons de l'import : unités, regroupement des ingrédients, détection des doublons. - Le modèle téléchargé utilise les vraies graphies (« pièce », « Steak haché »). - La CI installe `php-intl`, comme l'image de production ; sans lui, `Normalizer` n'existe pas sur le PHP de Debian. ## Preuves - 5 tests écrits avant la correction, tous rouges avant et verts après : 3 unitaires (même unité avec et sans accent, même ingrédient avec et sans accent, doublon qui ne diffère que par un accent) et 2 contre une vraie base (modèle réimporté tel quel sans erreur, unité existante « pièce » reconnue quand on écrit « Piece »). - PHPStan et PHPUnit complets : OK, 2357 tests. - Tests de l'import rejoués dans un conteneur Debian avec `php-intl`, comme la CI : OK, 66 tests. - Test navigateur officiel sur une pile jetable : 3 scénarios sur 3 passent. - gitleaks v8.30.1 sur l'historique de la branche : aucune fuite.
fix: import CSV compare names and units without accents, like the database
All checks were successful
CI / secret-scan (pull_request) Successful in 22s
Details
CI / php-lint (pull_request) Successful in 24s
Details
CI / static-tests (pull_request) Successful in 2m46s
Details
CI / js-tests (pull_request) Successful in 49s
Details
CI / shell-tests (pull_request) Successful in 7s
Details
CI / secret-scan (push) Successful in 22s
Details
CI / php-lint (push) Successful in 26s
Details
CI / static-tests (push) Successful in 2m49s
Details
CI / js-tests (push) Successful in 43s
Details
CI / shell-tests (push) Successful in 8s
Details
ba1c402896 
The downloaded template ("piece", "Steak hache") re-imported unchanged was
blocked against the demo data since migration 0016 added accents ("pièce",
"Steak haché"): the database matched the ingredient accent-insensitively
(utf8mb4_unicode_ci) but the PHP unit check did not. normalize() now folds
diacritics (intl Normalizer, present in the production image), the template
uses the real spellings, and CI installs php-intl like production.

Found by the 2026-09-27 expected-vs-actual audit (official e2e spec
admin-product-recipe-import was red on 11271f7).
Corentin deleted branch fix/import-accent-insensitive 2026-09-27 18:06:12 +02:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
auto-merge
Fusion automatique sur CI verte

No labels
auto-merge
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
AcadeNice/corentin_wakdo!178
No description provided.