Jacek Pyziak
5cf531d718
Re-import zamowienia wykrywa tranzycje payment_status 0/1->2 i emituje payment.status_changed, dzieki czemu chain reguly automatyzacji #7 zmienia status na w_realizacji. - OrderImportRepository: rozdzielenie paymentTransition (event 0/1->2) i statusOverwriteAllowed (preservacja status_code z Phase 62) - AllegroOrderImportService + ShopproOrdersSyncService: emit payment.status_changed na re-imporcie (gate !wasCreated && wasPaymentTransition) - bin/backfill_payment_transition_111.php: jednorazowy CLI dla zamowien payment_status=2 && status_code='nieoplacone' (Allegro + shopPRO) - Naprawa luki znalezionej w analizie zamowienia #864 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
75 lines
6.0 KiB
Markdown
75 lines
6.0 KiB
Markdown
# Technical Changelog
|
|
|
|
## 2026-05-05 - Phase 111 Plan 01: Payment Transition Event
|
|
|
|
**Co zrobiono:**
|
|
- `OrderImportRepository::upsertOrderAggregate` - rozszerzona detekcja `payment_transition`. Teraz porownuje poprzedni `payment_status` z nowym (warunek `0/1 -> 2`) zamiast polegac wylacznie na `status_code='nieoplacone'`. Logika preservacji status_code z Phase 62 (`statusOverwriteAllowed`) zostala wydzielona jako osobna decyzja.
|
|
- `OrderImportRepository::getCurrentStatusAndPaymentStatus()` - nowa metoda pomocnicza zastepujaca `getCurrentStatus()`, zwraca i status_code, i payment_status w jednym SELECT.
|
|
- `AllegroOrderImportService::importSingleOrder` - dodaje emit `payment.status_changed` gdy `payment_transition && !$wasCreated`.
|
|
- `ShopproOrdersSyncService::importOneOrder` - analogiczny emit `payment.status_changed`.
|
|
- `bin/backfill_payment_transition_111.php` - jednorazowy CLI dla zamowien z `payment_status=2 && status_code='nieoplacone'` (allegro + shoppro), idempotentny, wzorzec z Phase 98.
|
|
|
|
**Dlaczego:**
|
|
- Zamowienie #864 (Allegro) zaimportowane 10s po zlozeniu, gdy Allegro jeszcze nie potwierdzilo platnosci. Re-import 2 minuty pozniej zaktualizowal payment_status na 2, ale `order.imported` jest gated przez `$wasCreated` (Phase 98), wiec automatyzacja "Zmien status na w realizacji (allegro)" nigdy nie odpalila.
|
|
- Allegro nie mial odpowiednika `ShopproPaymentStatusSyncService`, wiec tranzycja platnosci znikala cicho. ShopPRO mial analogiczna luke w `ShopproOrdersSyncService` (flaga `payment_transition` byla wykrywana, ale nie emitowala eventu).
|
|
- Regula automatyzacji #7 (`payment.status_changed` -> `update_order_status` na `w_realizacji`) nie ma warunku integration_id, wiec po wyemitowaniu eventu obejmie zarowno Allegro jak i shopPRO.
|
|
- Idempotencja zalatwiona przez logike repo: po pierwszej tranzycji DB ma `payment_status=2`, kolejny re-import widzi old=2/new=2 i `payment_transition=false`. Brak duplikatow eventow.
|
|
|
|
## 2026-04-28 - Phase 110 Plan 01: Statistics Summary
|
|
|
|
**Co zrobiono:**
|
|
- `/statistics/summary` - nowy widok podsumowania w menu `Statystyki -> Podsumowanie`.
|
|
- `OrdersStatisticsController::summary()` - buduje miesieczny view-model dla wykresow liczby i wartosci zamowien.
|
|
- `OrdersStatisticsRepository::aggregateByMonth()` - agreguje istniejace zamowienia po miesiacu i kanale/integracji.
|
|
- `public/assets/js/modules/statistics-summary-charts.js` - renderer dwoch interaktywnych wykresow liniowych oparty o Chart.js 4.4.8 CDN.
|
|
- `resources/views/statistics/summary.php` - filtry zgodne z raportem dziennym, dwa wykresy obok siebie na desktopie oraz dwie tabele fallback pod nimi.
|
|
- Domyslny poczatek historii ustawiony na `2026-04-01` (`04-2026`) mimo starszych danych.
|
|
|
|
**Dlaczego:**
|
|
- Operator potrzebuje szybkiego trendu miesiecznego przed przejsciem do szczegolowych dziennych statystyk.
|
|
- Wykresy uzywaja obecnych tabel `orders`, `integrations`, `order_status_groups` i `order_statuses`, wiec migracja DB nie jest potrzebna.
|
|
- Seria `Razem` jest liczona z tych samych danych co serie integracji, co ulatwia sprawdzenie sum miesiecznych.
|
|
|
|
## 2026-04-28 - Phase 109 Plan 01: Checkbox Multiselect Filters
|
|
|
|
**Co zrobiono:**
|
|
- `public/assets/js/modules/checkbox-multiselect.js` - nowy vanilla JS enhancer dla natywnych `<select multiple data-checkbox-multiselect>`.
|
|
- `resources/views/layouts/app.php` - globalne podpiecie modulu z cache busting przez `filemtime()`.
|
|
- `resources/views/statistics/orders.php` - filtry `channels[]` i `status_groups[]` oznaczone do progresywnego ulepszenia bez zmiany nazw pol formularza.
|
|
- `resources/scss/app.scss` - kompaktowe style dropdownu z checkboxami i opcja "Wszystkie".
|
|
|
|
**Dlaczego:**
|
|
- Natywne selecty multiple byly malo czytelne i zajmowaly za duzo miejsca w filtrach statystyk.
|
|
- Zachowanie oryginalnego selecta w DOM utrzymuje obecny kontrakt GET i fallback bez JavaScript.
|
|
- Brak zmian w schemacie DB i logice agregacji statystyk.
|
|
|
|
> Chronologiczny log zmian technicznych — co i dlaczego.
|
|
|
|
## 2026-04-27 — Phase 108 Plan 02: Automation Dropdowns z DB
|
|
|
|
**Co zrobiono:**
|
|
- `AutomationController` — usunięto stałą `SHIPMENT_STATUS_OPTIONS` (8 grupowych kluczy)
|
|
- Dropdown statusów w warunku `shipment_status` i akcji `update_shipment_status` ładuje statusy z DB przez `DeliveryStatus::getAllOptions()`
|
|
- Walidacja w `parseConditionValue()` i `parseActionConfig()` używa `DeliveryStatus::getAllStatuses()`
|
|
- `AutomationService` — usunięto stałą `SHIPMENT_STATUS_OPTION_MAP`; ewaluacja `evaluateShipmentStatusCondition()` porównuje klucze bezpośrednio
|
|
- `resolveStatusFromActionKey()` — bezpośredni klucz statusu z DB jako target (zamiast pierwszego z grupy)
|
|
|
|
**Dlaczego:**
|
|
- Zamknięcie integracji z Plan 01 — operator dodaje status w `/settings/delivery-statuses` i jest on od razu dostępny w dropdownach automatyzacji bez deploymentu
|
|
- Eliminacja kolizji semantycznej: stary klucz grupowy `picked_up` mapował na `delivered` (paczka odebrana przez klienta), nowy klucz DB `picked_up` to "Odebrana przez kuriera" (od nadawcy)
|
|
- BREAKING: stare reguły z grupowymi kluczami (`registered`, `courier_pickup`, `dropped_at_point`, `unclaimed`, `picked_up_return`, oraz `picked_up`/`ready_for_pickup`/`cancelled` w starym znaczeniu) nie matchują — wymagają ręcznego odtworzenia z nowymi kluczami DB
|
|
|
|
## 2026-04-27 — Phase 108 Plan 01: Delivery Status Management
|
|
|
|
**Co zrobiono:**
|
|
- Tabela `delivery_statuses` z seedem 11 statusów (migracja `20260427_000103`)
|
|
- `DeliveryStatusRepository` — CRUD + per-request cache
|
|
- `DeliveryStatus.php` — dynamiczne ładowanie statusów z DB (`setRepository()`)
|
|
- Panel `/settings/delivery-statuses` z CRUD (zakładka "Statusy") i mapowaniem (zakładka "Mapowanie dostawy")
|
|
- Sidebar: "Statusy" → "Statusy zamówień", nowe "Statusy przesyłek" z badge niezmapowanych
|
|
- Badge przesyłek: inline CSS custom property `--status-color` dla niestandardowych statusów
|
|
|
|
**Dlaczego:**
|
|
- Dodanie nowego statusu wymagało zmiany kodu + deploymentu; teraz z UI
|
|
- Operator może definiować własne statusy znormalizowane bez ingerencji w kod
|