Commit Graph

25 Commits

Author SHA1 Message Date
E98Developer
b8fd71ed23 FIX Deployment csomagoló a 403-teszt valódi HTTP kérésre váltása
A Livewire::test() a HttpException-t válasszá alakítja és nem dobja tovább
(RequestBroker: withoutExceptionHandling([HttpException::class])), ezért a toThrow()
sosem teljesült volna. A jogosultság-ellenőrzés valódi belépési pontja az oldal URL-je,
így a teszt most GET-tel kéri le és assertForbidden()-nel ellenőriz.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-16 07:34:29 +02:00
E98Developer
bfc1484611 ADD Deployment csomagoló phase3 napló, környezetkövetés, ZIP letöltés és törlő szkript
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>
2026-08-16 07:20:34 +02:00
E98Developer
7ad9c6fea8 ADD Deployment csomagoló phase2 csomag előállítása (mappa, manifest, törlendők, verziójelölő)
A kijelölt tartományból elkészül a feltölthető mappa: deploy_<target>_<időbélyeg>, benne
a fájlok eredeti relatív útvonalon, hogy a feltöltés mappa-összeolvasztás legyen.

- GitRepository::archiveTo(): git archive --format=zip + ZipArchive kicsomagolás, ~100
  fájlonként darabolva a parancssor-limit miatt. A tartalom a git objektumtárból jön, nem a
  working tree-ből: így nem szivárog ki commitolatlan módosítás, és a .gitattributes eol=lf
  miatt LF sorvéggel kerül a Linux célgépre. Üres pathspec esetén nem hívunk gitet, mert az
  a TELJES fát csomagolná.
- DeploymentPackageBuilder: _MANIFEST.json/.txt (sha1 + méret fájlonként), _TORLENDO.txt a
  törölt és az átnevezett fájlok régi útvonalával, _TEENDOK.md a diffből származó lépésekkel
  (migrate, composer install, asset-figyelmeztetés, verzió-ellenőrzés), és public/
  deploy-version.json a kirakott commit hashével.
- A git archive által kihagyott fájlok (pl. .gitattributes export-ignore) külön "missing"
  listára kerülnek - csendben hiányzó fájl a manuális deploynál a legrosszabb hiba.
- Felületen fájlonkénti kézi kivétel, megerősítéses csomagolás gomb, eredmény-kártya.
- DeploymentGuard::ensureEnvironmentAllowed(): a builder felhasználó nélkül is ellenőrzi az
  env kapcsolót és a stage whitelistet, így konzolról indítva sem fut le egy szerveren.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-16 07:09:05 +02:00
E98Developer
6027511585 FIX Deployment csomagoló phase1 git ikon és a commit törzsére kiterjesztett keresés
- a topbar menüpont a most bemásolt git ikont használja; a fájl ico_gitpng néven
  érkezett, átnevezve ico_git.png-re, hogy illeszkedjen az ico_*.png konvencióhoz,
  amiből a nav az útvonalat építi
- a git log a törzset (%b) is elkéri, és a keresés a tárgysor mellett ebben is keres:
  a hash-re ritkán keres ember, az érdemi leírás viszont gyakran a törzsben van
- a --shortstat sora a törzs után érkezik, ezért a parse leválasztja róla, különben
  a "N files changed" szöveg a törzsbe és a keresésbe is beszivárogna

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-16 06:59:04 +02:00
E98Developer
09eed3eeb3 ADD Deployment csomagoló phase1 védelem, git olvasó és read-only commit/diff felület
Két commit közötti fájlok összegyűjtését előkészítő felület első fázisa: célkörnyezet
választás (e2e/d2d), commitlista, diff-előnézet figyelmeztetésekkel. Ez a fázis még
semmit nem ír a fájlrendszerre, a csomagolás a phase2-ben érkezik.

- DeploymentGuard: .env kapcsoló + hardkódolt stage whitelist + developer szerep +
  feature flag; a flag szándékosan nem biztonsági réteg, csak láthatóság-vezérlés
- GitRepository: csak olvasó wrapper, argumentum-tömbös Symfony Process (nincs shell),
  hash- és referencia-validáció, core.quotePath=false az ékezetes útvonalakhoz
- ChangeSetAnalyzer: kizárási lista, törlendő/másolandó szétválasztás (átnevezésnél
  mindkettő), figyelmeztetések migrációra, composer.lock-ra és a nem verziókövetett
  fordított assetekre

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-16 06:45:09 +02:00
E98Developer
8bcfeba0f9 ADD EV3-357 Árlista feldolgozás phase5/5 beszállítói blokkolás (PricelistGuard)
Egy beszállítóhoz egyszerre legfeljebb egy nyitott végrehajtás tartozhat: egy
execution_failed fájl után a termékek félig frissített állapotban vannak, egy új
import erre a kevert alapra rétegződne rá (és a validálás is ehhez számolná a
diffeket); két párhuzamos végrehajtás pedig nem determinisztikus eredményt adna.

- új PricelistGuard service: egyetlen igazságforrás a blokkoláshoz
- mind a NÉGY belépési pont véd: modern Filament create, régebbi
  PriceListProcessor oldal, legacy Admin\PriceListController import, konzol
  parancs. A legacy import a legfontosabb - az közvetlenül ír a products
  táblába, megkerülve a modult, és a beszállítókat ma még nagyrészt ott kezelik.
- az `inprogress` önmagában nem blokkol: az előfeldolgozás és a validálás
  egyetlen terméket sem ír, csak a már elindult végrehajtás számít
- a beszállító nem tűnik el a select listából, hanem konkrét magyarázatot kap a
  felhasználó arról, melyik fájl blokkol és miért
- blokkolt beszállítónál másik fájl jóváhagyása sem indítható

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-15 06:46:40 +02:00
E98Developer
e338f68ee8 ADD EV3-357 Árlista feldolgozás phase5/4 visszavonás, elakadás-észlelés, kényszerlezárás
- PricelistExecutionJob + új PricelistRevertJob: $tries=1, $timeout, failed()
  hook. A service catch ága csak PHP exceptiont fog el; worker timeout vagy
  memórialimit esetén a fájl inprogress-ben ragadna, döntési gomb nélkül.
- heartbeat backstop a kill -9 esetére, ahol a failed() sem fut: minden chunk ír
  a rekordba, így az updated_at a szívverés (isExecutionStuck). Ezzel garantált,
  hogy minden kísérlet véges időn belül terminális állapotba jut - enélkül a
  kényszerlezárás sem nyílna ki soha.
- kompenzáló visszaállítás R1-R4: árak törlése, termékek visszaállítása a
  snapshotból, létrehozott termékek kivonása (soft delete, NEM fizikai törlés,
  mert lehet rájuk hivatkozás), árlista + fájl lezárása
- konfliktuskezelés: a végrehajtás óta kézzel módosított terméket kihagyjuk és
  jelentjük, nem írjuk felül vakon
- FIX phase5/3: a snapshot csak az írás ELŐTTI updated_at-et tárolta, amihez
  képest a termék a végrehajtás után mindig eltér - a konfliktus-ellenőrzés így
  minden sort kihagyott volna. Most a saját írásunk utáni updated_at is bekerül.
- kényszerlezárás: csak legalább egy terminális hibába futott visszaállítási
  kísérlet után, flag + developer szerepkör mögött, kötelező indoklással
- döntéstámogató panel: mi történt már meg az importból, hogy a felhasználó ne
  vakon válasszon a Folytatás és a Visszavonás között

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-15 06:36:21 +02:00
E98Developer
93111ef2e0 ADD EV3-357 Árlista feldolgozás phase5/3 chunkolt végrehajtás (E1-E6)
A sleep(1) szimuláció helyén valódi import: árlista fejrekord -> új gyártók ->
új termékek -> termékfrissítés -> árak -> lezárás.

- szándékosan nincs egyetlen átfogó tranzakció: fázisonként/chunkonként
  tranzakciózunk, az atomicitást az adja, hogy az árlista E6-ig draft marad,
  tehát félbeszakadáskor sem kerül ki félkész ár a felhasználók felé
- minden fázis idempotencia-jelölője az az artefaktum, amit maga hoz létre
  (price_list_id / producer_id / product_id / applied_snapshot / pivot sor),
  így a megszakadt futás folytatható, nem kezd elölről
- E4 a termék TÉNYLEGES, írás előtti állapotát menti az applied_snapshot-ba,
  ugyanabban a tranzakcióban - ebből áll majd vissza a Visszavonás
- új EXECUTION_FIELD_MAP: a PRODUCT_FIELD_MAP csak a diff-számításhoz kellett,
  az import a legacy importPriceList()-tel azonos, bővebb mezőkört ír
- hiányzó opcionális oszlop (pl. Akció) nem írja felül a termék meglévő értékét
- updateStepStatus: az Execution lépés 'failed' státusza execution_failed
  fájlstátuszra képződik le, a többi lépésé marad fail

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 15:19:50 +02:00
E98Developer
eee27aa659 ADD EV3-357 Árlista feldolgozás phase5/2 jóváhagyás/elutasítás akció
- PricelistFile::canBeApproved() / hasExecutionStarted(): a jóváhagyás feltételei
  egy helyen, hogy a felületi gomb és a service ugyanazt ellenőrizze
- approve(): a státusz MÉG A DISPATCH ELŐTT billen át, különben a queue-latency
  alatt a gomb látszana és egy második kattintás párhuzamos importot indítana
- reject(): új 'rejected' lépésstátusz - nem 'failed', mert azt az
  updateStepStatus fail fájlstátuszra fordítaná, az elutasítás viszont closed
- a döntés (ki, mikor, milyen indokkal) a file_meta.approval-ba kerül, mert a
  BaseAuditable a nevével ellentétben nem naplóz
- Edit gomb szűkítése hasExecutionStarted()-tel három helyen, köztük az
  EditPricelistFile::afterSave()-ben, ami a teljes láncot újraindítja

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-10 15:00:33 +02:00
E98Developer
259df71c7b ADD EV3-431 Profitcenter - betűkód phase1 addd feature flag override relation manager 2026-08-08 16:46:34 +02:00
E98Developer
d6c6f0af1c EV3-431 Profitcenter - betűkód phase1 addd feature flag with laravel pennant 2026-08-08 16:09:54 +02:00
E98Developer
a30aa2dd51 EV3-357 Árlista feltöltés és feldolgzás újra gondolása phase4 fejléc adatok akciós lehetőség bővítése 2026-08-03 12:09:41 +02:00
E98Developer
e49b7515e0 EV3-357 Árlista feltöltés és feldolgzás újra gondolása phase3 fejlec adatok cseréje 2026-07-22 12:37:24 +02:00
E98Developer
0b1240f972 ADD EV3-358 statisztika modul bővítése aktuális ár megjelenítéssel phase 2 layout problem 2026-07-01 19:56:01 +02:00
E98Developer
57c654db2d EV3-439 Szállítási korlátozások 2026-06-07 21:25:03 +02:00
E98Developer
4b7db9fe00 EV3-415 Termék betöltése adminsztrációs felületen 2026-05-08 06:56:39 +02:00
E98Developer
de1eb871b9 EV3-414 Verzióváltott teszt - Külső user készlet módosítás 2026-05-07 03:02:06 +02:00
E98Developer
5ad60e27e4 EV3-413 Kilépéskor azonos login oldara írányítás
ADD AdminLoginTest
2026-05-06 21:10:45 +02:00
E98Developer
af90aa63b7 EV3-413 Kilépéskor azonos login oldara írányítás 2026-05-06 15:32:34 +02:00
E98Developer
e31f33d9bf ADD delivery calendar part2 2026-04-20 21:32:05 +02:00
E98Developer
9fa6a7b056 ADD DeliveryCalendar phase1 2026-04-15 06:42:55 +02:00
E98Developer
0581fee616 ADD work_calendar api sync and test support 2026-04-08 21:47:28 +02:00
E98Developer
a534cf074d ADD first laravel dusk test 2026-04-08 13:25:17 +02:00
E98Developer
d3817eecc4 ADD laravel dusk 2026-03-30 14:16:51 +02:00
E98Developer
68b7c35bef git init 2026-02-28 06:53:05 +01:00