Bunzl árlistájához szükséges egy eddig hiányzó mértékegység. A "Legkisebb
eladási egység" / "Mennyiségi egység" mezőt két párhuzamos árlista-import
validálja külön-külön (a régi PriceListService.php ProductUnitEnum-mal, az új
PricelistFileProcessService.php saját PricelistSellerUnitEnum-mal), mindkettő
végül ugyanabba a products.sellerUnit / products.amountUnit DB enum oszlopba
ír. A puszta enum-bővítés önmagában nem lett volna elég: a DB oszlop
korlátozta volna a végrehajtást, csak ott, a legkésőbbi ponton bukva el.
- ProductUnitEnum: új 'm' case (régi pipeline validációja + a DB oszlopokat
generáló forrás).
- PricelistSellerUnitEnum: új 'm' case (új pipeline validációja).
- Migráció: products.sellerUnit/amountUnit és order_archives_items ugyanezen
oszlopainak DB enum bővítése 'm'-mel, ProductUnitEnum::getKeys()-ből
generálva, hogy a PHP enum és a DB oszlop ne csúszhasson el egymástól. A
down() az 'm' értékű sorokat NULL-ra állítja visszagörgetéskor, különben a
szűkített enum miatt az ALTER hibára futna. A "Mértékegység" (productUnit)
oszlopot szándékosan nem bővítettem, a jegy csak a másik két mezőt említi.
- schema:dump frissítve.
5 új teszt mindkét pipeline validációjára és a DB enum oszlopra.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
A migrate:fresh eddig 103 migrációt futtatott le minden teszt-futásnál. A dump
egyetlen SQL fájlként tölti be ugyanazt a 48 táblát: migrate:fresh 21,09 ->
12,07 mp, egy teszt --filter-rel 27,80 -> 20,88 mp.
A dumpot a Laravel csak akkor tölti be, ha a migrations tábla ÜRES
(MigrateCommand::prepareDatabase), tehát az e2e/d2d környezetek - ahol már
vannak lefutott migrációk - változatlanul inkrementálisan migrálnak. Ezért
--prune NÉLKÜL készült: a 103 migrációs fájl a helyén marad.
Karbantartás: minden új migráció után újra kell generálni (php artisan
schema:dump). Ha elmarad, az nem törik el semmit, csak a dump utáni
migrációkat egyenként futtatja le.
A betöltéshez a mysql kliens kell a PATH-on
(C:\www\envkit\services\mysql\11.8.2\bin).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A csomagolás mostantól nyomot hagy: melyik környezetre mi készült, mi lett kirakva, és
mennyi a lemaradás - ez az, ami a "melyik verzió fut az e2e-n" kérdést kiveszi a fejből.
- deployment_packages tábla + modell (BaseAuditable): target, tartomány, darabszámok,
mappa/ZIP útvonal, deployed_at. A csomagolás és a tényleges kirakás két külön esemény.
- Targetenkénti előtöltés: a kezdő commit az adott környezetre utoljára kirakottként
megjelölt csomag to_commit-je. Rebase után nem létező hash esetén inkább üres marad,
mint hogy hamis tartományt mutasson.
- "Környezetek állapota" panel: napló szerinti állapot + commit-lemaradás
(git rev-list --count), és gombra a szerver deploy-version.json-jának lekérdezése.
Ha a kettő eltér, az elmaradt vagy félbemaradt feltöltés jele. Szándékosan gombra fut,
nem minden rendereléskor: így nem indul kimenő kérés magától.
- ZIP a kész mappából (a fájllista a zip létrejötte előtt készül, így nem csomagolja
magát), letöltés a naplóból. A DB-ből jövő útvonalat kiírás előtt a kimeneti mappához
kötjük, hogy egy módosított rekord se tehessen letölthetővé tetszőleges fájlt.
- _torles.sh: alapból dry run, --confirm kell a törléshez, app-gyökér ellenőrzéssel,
abszolút útvonal és .. kiszűrésével, LF sorvéggel és BOM nélkül. Lefuttatva ellenőrizve.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- új PricelistExecution Pennant flag (enabled + roles=[developer]) a jóváhagyás,
végrehajtás és visszavonás rollout-kapujaként
- új execution_failed fájlstátusz: a validálásig tartó szakasz fail státuszától
szándékosan elkülönítve, mert itt már történhettek termék- és árírások
- PricelistFileStatusEnum::color(): a badge-színek eddig két helyen, kimerítő
match-ben voltak duplikálva, amit az új case eltört volna
- pricelist_file_lines.applied_snapshot + executed_at a chunkolt, idempotens
végrehajtáshoz és a kompenzáló visszaállításhoz
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
