feat(109): checkbox multiselect filters
Phase 109 complete: - Add checkbox dropdown enhancement for statistics multi-select filters - Preserve GET contract for channels[] and status_groups[] - Update PAUL plan context to read .paul/codebase docs Co-Authored-By: Codex <noreply@openai.com>
This commit is contained in:
44
.paul/codebase/tech_changelog.md
Normal file
44
.paul/codebase/tech_changelog.md
Normal file
@@ -0,0 +1,44 @@
|
||||
# Technical Changelog
|
||||
|
||||
## 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
|
||||
Reference in New Issue
Block a user