update

2026-04-13 22:31:06 +02:00
parent 38259bc706
commit e15b4ccf45
24 changed files with 1580 additions and 3858 deletions
--- a/.paul/phases/99-order-delivery-payment-edit/99-01-PLAN.md
+++ b/.paul/phases/99-order-delivery-payment-edit/99-01-PLAN.md
@@ -0,0 +1,202 @@
+---
+phase: 99-order-delivery-payment-edit
+plan: 01
+type: execute
+wave: 1
+depends_on: []
+files_modified:
+  - src/Modules/Orders/OrdersController.php
+  - src/Modules/Orders/OrdersRepository.php
+  - resources/views/orders/show.php
+  - resources/scss/views/orders/_show.scss
+  - routes/web.php
+autonomous: false
+delegation: off
+---
+
+<objective>
+## Goal
+Umozliwic uzytkownikowi zmiane formy dostawy (delivery_method) oraz formy platnosci (payment_method + external_payment_type_id) w istniejacym zamowieniu z poziomu widoku szczegolow /orders/{id} — ze szczegolnym wsparciem scenariusza "przedplata -> pobranie".
+
+## Purpose
+Klient kontaktuje sie po zlozeniu zamowienia i prosi o zmiane sposobu dostawy albo o zmiane formy platnosci na pobranie. Dzis wymaga to edycji w zrodle (shopPRO/Allegro) i re-importu albo recznej ingerencji w DB. Funkcja pozwoli obsluzyc to w jednym miejscu, spojnie z reszta przeplywu (activity log, automatyzacje oparte o `order.payment_method` z Phase 96, warunek COD w presetach przesylek).
+
+## Output
+- Nowy formularz edycji w karcie "payment_shipping" w `show.php` (modal lub inline form) z dwoma polami: forma dostawy + forma platnosci
+- Nowa akcja POST `/orders/{id}/details/update` w `OrdersController`
+- Metoda `OrdersRepository::updateDeliveryAndPayment()` z walidacja i atomowym zapisem
+- Wpis w `order_activity_log` (`event_type = 'details_change'`) z before/after w `details_json`
+- Automatyczna synchronizacja `external_payment_type_id` do `CASH_ON_DELIVERY` przy wyborze pobrania, aby Phase 96 warunek COD i presety autofill dzialaly bez re-importu
+</objective>
+
+<context>
+## Project Context
+@.paul/PROJECT.md
+@.paul/ROADMAP.md
+@.paul/STATE.md
+
+## Prior Work
+@.paul/phases/96-automation-payment-method/96-01-SUMMARY.md
+@.paul/phases/77-cod-amount-fix/
+
+## Source Files
+@src/Modules/Orders/OrdersController.php
+@src/Modules/Orders/OrdersRepository.php
+@resources/views/orders/show.php
+@src/Core/Support/StringHelper.php
+@routes/web.php
+</context>
+
+<acceptance_criteria>
+
+## AC-1: Edycja formy dostawy
+```gherkin
+Given zamowienie w /orders/{id} z delivery_method = "Kurier DPD"
+When uzytkownik otworzy formularz edycji, wybierze "InPost Paczkomat" i zatwierdzi
+Then delivery_method w DB = "InPost Paczkomat"
+  And widok po przeladowaniu pokazuje nowa wartosc
+  And w order_activity_log jest wpis event_type='details_change' z before/after w details_json
+```
+
+## AC-2: Zmiana platnosci przedplata -> pobranie
+```gherkin
+Given zamowienie z payment_method = "Przelew" i external_payment_type_id != 'CASH_ON_DELIVERY'
+When uzytkownik wybierze forme platnosci "Pobranie" i zatwierdzi
+Then payment_method zawiera wartosc wybrana przez uzytkownika (np. "Pobranie")
+  And external_payment_type_id = 'CASH_ON_DELIVERY'
+  And StringHelper::isCodPayment($order['external_payment_type_id']) zwraca true
+  And warunek automatyzacji `order.payment_method = COD` (Phase 96) wyzwala regule na tym zamowieniu
+  And autofill kwoty pobrania w formularzu przesylki (Phase 77) dziala dla tego zamowienia
+```
+
+## AC-3: Walidacja i bezpieczenstwo
+```gherkin
+Given uzytkownik wysyla POST /orders/{id}/details/update
+When brakuje _token CSRF lub zamowienie nie istnieje
+Then kontroler zwraca blad (403 dla CSRF, 404 dla brak zamowienia) bez modyfikacji DB
+  And gdy payment_method i delivery_method sa puste po trim, zwraca walidacyjny Flash error i nie zapisuje nic
+```
+
+</acceptance_criteria>
+
+<tasks>
+
+<task type="auto">
+  <name>Task 1: Repository + route + controller action</name>
+  <files>
+    src/Modules/Orders/OrdersRepository.php,
+    src/Modules/Orders/OrdersController.php,
+    routes/web.php
+  </files>
+  <action>
+    1. `OrdersRepository::updateDeliveryAndPayment(int $orderId, ?string $deliveryMethod, ?string $paymentMethod, ?string $externalPaymentTypeId, array $actor): bool`
+       - Pobierz biezacy order przez `findDetails()` (before-snapshot)
+       - Buduj UPDATE dynamicznie (tylko pola != null po trim, reszta bez zmian)
+       - Prepared statement Medoo, bez sklejania SQL
+       - Po UPDATE: `recordActivity($orderId, 'details_change', summary, detailsJson)` — detailsJson zawiera pola zmienione z kluczami `before` / `after`
+       - Zwroc true gdy faktycznie cokolwiek zmienione, false gdy no-op
+       - Zero efektow ubocznych poza orders + order_activity_log (NIE pushuj do shopPRO/Allegro — out of scope)
+    2. `OrdersController::updateDetails(int $orderId): Response`
+       - Walidacja _token (wzorzec jak `updateStatus()` linia 267)
+       - `findDetails()` -> 404 gdy brak
+       - Odczyt `delivery_method`, `payment_method` z POST, trim, oba puste -> Flash::set('orders.error') + redirect
+       - Gdy uzytkownik zaznaczyl checkbox/flaga `is_cod` (patrz Task 2) ustaw `externalPaymentTypeId = 'CASH_ON_DELIVERY'`, w przeciwnym razie przepusz istniejaca wartosc bez zmiany (null → repo pominie pole)
+       - Wywolaj repo, Flash::set('orders.success', 'Dane zamowienia zaktualizowane'), redirect do /orders/{id}
+       - Actor z SessionUserContext jak w istniejacych akcjach
+    3. `routes/web.php`: zarejestruj POST `/orders/{id}/details/update` → `OrdersController@updateDetails`, middleware identyczny jak inne POST na /orders (csrf + auth)
+    Avoid: dodawania logiki push do zrodla (shopPRO/Allegro) — zaznaczone jako out of scope. Avoid: sklejania SQL. Avoid: zmiany `findDetails()` — tylko odczyt snapshot przez istniejaca metode.
+  </action>
+  <verify>
+    curl -X POST z validnym CSRF i body `delivery_method=Kurier&payment_method=Pobranie&is_cod=1` zwraca 302 do /orders/{id};
+    SELECT z orders pokazuje zaktualizowane 3 pola;
+    SELECT z order_activity_log pokazuje wpis event_type='details_change' z details_json zawierajacym `delivery_method.before/after` i `external_payment_type_id.before/after`
+  </verify>
+  <done>AC-1, AC-3 satisfied na poziomie backend</done>
+</task>
+
+<task type="auto">
+  <name>Task 2: UI form w karcie payment_shipping</name>
+  <files>
+    resources/views/orders/show.php,
+    resources/scss/views/orders/_show.scss
+  </files>
+  <action>
+    1. W `show.php` w karcie "payment_shipping" dodaj ikonke ✎ (pattern zgodny z feedback memory — hover + dropdown/inline) ktora otwiera inline form pod naglowkiem karty.
+    2. Form:
+       - `<form method="POST" action="/orders/{id}/details/update">`
+       - Ukryty `_token`
+       - `<input type="text" name="delivery_method" value="<?= e($order['delivery_method']) ?>">` z listą datalist bazujaca na DISTINCT delivery_method z ostatnich 50 zamowien (lekki helper w controllerze — przekaz przez $data)
+       - `<input type="text" name="payment_method" value="...">` analogicznie
+       - `<label><input type="checkbox" name="is_cod" value="1" <?= StringHelper::isCodPayment($order['external_payment_type_id']) ? 'checked' : '' ?>> Pobranie (COD)</label>` — wyjasnia ze zaznaczenie ustawi external_payment_type_id
+       - Submit button "Zapisz" + cancel (ukryj form)
+    3. Kompaktowy uklad (zgodnie z CLAUDE.md: gesty), style w `_show.scss`, zero CSS w widoku
+    4. OrderProAlerts dla ewentualnych komunikatow (nie natywne alert)
+    Avoid: natywnego alert/confirm, CSS w widoku, duplikacji — jezeli datalist juz istnieje dla formy, reuse
+  </action>
+  <verify>
+    Otworz /orders/{id} w przegladarce; kliknij ✎ przy payment_shipping; zmien pola; zatwierdz; po redirect widac zaktualizowane dane w karcie
+  </verify>
+  <done>AC-1, AC-2 satisfied na poziomie UI</done>
+</task>
+
+<task type="checkpoint:human-verify" gate="blocking">
+  <what-built>
+    Edycja formy dostawy i platnosci w /orders/{id}:
+    - Ikonka ✎ w karcie payment_shipping, inline form, datalist podpowiedzi
+    - Checkbox "Pobranie (COD)" ustawia external_payment_type_id = CASH_ON_DELIVERY
+    - Wpis w activity log details_change
+  </what-built>
+  <how-to-verify>
+    1. Otworz /orders/{id} z zamowieniem platnym przelewem (external_payment_type_id != CASH_ON_DELIVERY)
+    2. Kliknij ✎ w karcie Platnosc i wysylka
+    3. Zmien delivery_method na dowolna inna wartosc, zmien payment_method na "Pobranie", zaznacz checkbox COD, zapisz
+    4. Po redirect sprawdz:
+       - karta pokazuje nowe wartosci
+       - zakladka Historia (activity log) ma wpis "Zmiana danych zamowienia" (details_change)
+       - Przejdz do formularza przesylki — autofill kwoty pobrania (Phase 77) dziala
+       - Jesli masz regule automatyzacji z warunkiem Metoda platnosci = COD (Phase 96) + jakims triggerem manualnym — zweryfikuj ze regula pasuje do tego zamowienia
+    5. Test walidacji: sprobuj zapisac z obydwoma polami pustymi — powinien pojawic sie Flash error i brak zmian
+  </how-to-verify>
+  <resume-signal>Type "approved" to continue, or describe issues to fix</resume-signal>
+</task>
+
+</tasks>
+
+<boundaries>
+
+## DO NOT CHANGE
+- `OrderImportRepository.php` — logika importu jest stabilna (Phase 62/75 re-import safety)
+- `ShopproApiClient`, `AllegroApiClient` — push do zrodla poza zakresem
+- `findDetails()`, `paginate()` — tylko konsumenci, nie modyfikacja
+- Schemat DB — wszystkie pola juz istnieja (delivery_method, payment_method, external_payment_type_id)
+
+## SCOPE LIMITS
+- Brak push zmiany formy platnosci / dostawy do shopPRO ani Allegro (jeden kierunek: orderPRO lokalnie)
+- Brak nowej tabeli / migracji
+- Brak rozszerzania modulu Automatyzacji o nowy event `details_changed` — to osobna faza jezeli potrzebne
+- Brak walidacji ze slownika form platnosci — free text z datalist podpowiedzi (spojne z dzisiejszym importem)
+- Brak edycji delivery_price / kwoty pobrania — tylko metody
+- Brak edycji danych odbiorcy / adresu — osobny scope
+
+</boundaries>
+
+<verification>
+Przed zamknieciem planu:
+- [ ] `php -l` na zmodyfikowanych plikach PHP
+- [ ] Manualny test AC-1, AC-2, AC-3 w przegladarce
+- [ ] SELECT z order_activity_log potwierdza wpis details_change z poprawnym JSON
+- [ ] Po zmianie na COD: autofill kwoty pobrania (Phase 77) dziala, warunek Metoda platnosci = COD (Phase 96) matchuje
+- [ ] Brak natywnych alert/confirm w dodanym UI
+- [ ] Brak CSS w widoku, style w `_show.scss`
+</verification>
+
+<success_criteria>
+- Wszystkie 3 AC spelnione
+- Zero regresji w istniejacych akcjach /orders/{id} (status change, add payment)
+- Spojnosc z Phase 77 (COD autofill) i Phase 96 (automation COD condition) — obie korzystaja z nowego stanu bez zadnych dodatkowych zmian
+- Nowa akcja ma CSRF + auth, Medoo prepared statements
+</success_criteria>
+
+<output>
+After completion, create `.paul/phases/99-order-delivery-payment-edit/99-01-SUMMARY.md`
+</output>
--- a/.paul/phases/99-order-delivery-payment-edit/99-01-SUMMARY.md
+++ b/.paul/phases/99-order-delivery-payment-edit/99-01-SUMMARY.md
@@ -0,0 +1,32 @@
+---
+phase: 99-order-delivery-payment-edit
+plan: 01
+status: cancelled
+completed: 2026-04-13
+---
+
+# Phase 99 Plan 01: Order Delivery & Payment Edit — CANCELLED
+
+**Plan utworzony 2026-04-13, nigdy nie uruchomiony. Zamkniety na prosbe uzytkownika bez implementacji — zakres przelozony na pozniej.**
+
+## Status
+- Plan: `.paul/phases/99-order-delivery-payment-edit/99-01-PLAN.md` (zachowany do ewentualnego odtworzenia)
+- APPLY: nie uruchomiony
+- Kod: brak zmian w repo
+
+## Powod zamkniecia
+Uzytkownik zdecydowal sie priorytetowo wykonac Phase 100 (Preset Scope & Print UX) i zamknac Phase 99 bez implementacji. Funkcjonalnosc edycji formy dostawy/platnosci w istniejacym zamowieniu moze zostac zreplanowana w przyszlej fazie, jesli bedzie potrzebna.
+
+## Acceptance Criteria Results
+| Criterion | Status |
+|-----------|--------|
+| Wszystkie AC z PLAN.md | Not executed |
+
+## Files Modified
+None.
+
+## Next
+Jesli w przyszlosci pojawi sie potrzeba, zaplanuj nowa faze z wykorzystaniem istniejacego PLAN jako punktu wyjscia.
+
+---
+*Phase 99 cancelled 2026-04-13*