Project-Pro/orderPRO
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
6d3dba89ed2e1bbd738f3d85269b4f19b6cc0646
orderPRO/.paul/codebase/tech_changelog.md
Jacek Pyziak 6d3dba89ed 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>
2026-04-28 22:15:04 +02:00

3.0 KiB
Raw Blame History

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 View Git Blame Copy Permalink