ver. 0.290: ShopCoupon + ShopOrder frontend migration to Domain + Controllers

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs/CHANGELOG.md

@@ -4,6 +4,27 @@ Logi zmian z migracji na Domain-Driven Architecture. Najnowsze na gorze.
 
 ---
 
+## ver. 0.290 (2026-02-17) - ShopCoupon + ShopOrder frontend migration
+
+- **ShopCoupon (frontend)** — migracja controls + factory na Domain + Controllers
+  - NOWE METODY w `CouponRepository`: 4 metody frontendowe (findByName, isAvailable, markAsUsed, incrementUsedCount)
+  - NOWY: `front\Controllers\ShopCouponController` — instancyjny kontroler z DI (useCoupon, deleteCoupon)
+  - KONWERSJA: `shop\Coupon` na fasade z dzialajacymi metodami (is_one_time, set_as_used)
+  - FIX: kupony jednorazowe nigdy nie byly oznaczane jako uzyte (is_one_time zwracalo null)
+  - USUNIETA: `front\controls\class.ShopCoupon.php`, `front\factory\class.ShopCoupon.php`
+- **ShopOrder (frontend)** — migracja controls + factory + view na Domain + Controllers
+  - NOWE METODY w `OrderRepository`: 5 metod frontendowych (findIdByHash, findHashById, orderDetailsFrontend, generateOrderNumber, createFromBasket ~180 linii)
+  - NOWY: `front\Controllers\ShopOrderController` — instancyjny kontroler z DI (paymentConfirmation, paymentStatusTpay, paymentStatusPrzelewy24pl, paymentStatusHotpay, orderDetails)
+  - POPRAWA: webhooks przelewy24/hotpay — zamiana recznych $mdb->update/insert na \shop\Order::set_as_paid() + update_status() (spójnosc z tpay, poprawna obsluga Apilo sync)
+  - UPDATE: `ShopBasketController` — DI OrderRepository (createFromBasket, findHashById)
+  - UPDATE: `ClientRepository::clientOrders()` — OrderRepository::orderDetailsFrontend()
+  - UPDATE: `shop\Order::order_resend_confirmation_email()` — OrderRepository::orderDetailsFrontend()
+  - UPDATE: `cron-turstmate.php` — OrderRepository::orderDetailsFrontend()
+  - USUNIETA: `front\controls\class.ShopOrder.php`, `front\factory\class.ShopOrder.php`, `front\view\class.ShopOrder.php`
+- Testy: 565 OK, 1716 asercji (+28: 12 CouponRepository frontend, 3 ShopCouponController, 10 OrderRepository frontend, 3 ShopOrderController)
+
+---
+
 ## ver. 0.289 (2026-02-17) - ShopCategory + ShopClient frontend migration
 
 - **ShopCategory (frontend)** — migracja factory + view na Domain + Views

docs/DATABASE_STRUCTURE.md

@@ -117,6 +117,8 @@ Zamówienia sklepu (źródło danych dla list i szczegółów klientów w panelu
 
 **Aktualizacja 2026-02-15 (ver. 0.276):** moduł `/admin/shop_order/*` korzysta z `Domain\Order\OrderRepository` przez `admin\Controllers\ShopOrderController`; usunięto legacy `admin\controls\ShopOrder` i `admin\factory\ShopOrder`.
 
+**Aktualizacja 2026-02-17 (ver. 0.290):** frontend `/shop_order/*` korzysta z `Domain\Order\OrderRepository` przez `front\Controllers\ShopOrderController`; usunięto legacy `front\controls\ShopOrder`, `front\factory\ShopOrder`, `front\view\ShopOrder`. Callery (ShopBasketController, ClientRepository, shop\Order, cron-turstmate) przepięte na OrderRepository.
+
 ## pp_banners
 Banery.
 
@@ -465,7 +467,7 @@ Kody rabatowe sklepu (modul `/admin/shop_coupon`).
 | include_discounted_product | Czy obejmuje rowniez produkty przecenione (0/1) |
 | categories | JSON z ID kategorii objetych kuponem (NULL = bez ograniczenia) |
 
-**Uzywane w:** `Domain\Coupon\CouponRepository`, `admin\Controllers\ShopCouponController`, `shop\Coupon`, `front\factory\ShopCoupon`, `front\factory\ShopOrder`
+**Uzywane w:** `Domain\Coupon\CouponRepository`, `admin\Controllers\ShopCouponController`, `front\Controllers\ShopCouponController`, `shop\Coupon`, `Domain\Order\OrderRepository`
 
 **Aktualizacja 2026-02-13 (ver. 0.266):** modul `/admin/shop_coupon` korzysta z `Domain\Coupon\CouponRepository` przez `admin\Controllers\ShopCouponController`. Usunieto legacy klasy `admin\controls\ShopCoupon` i `admin\factory\ShopCoupon`.
 

docs/FRONTEND_REFACTORING_PLAN.md

@@ -16,17 +16,17 @@ Panel administratora (33 moduły) został w pełni zmigrowany na architekturę D
 | Site | Router główny | route(), check_url_params(), title() |
 | ShopBasket | ZMIGROWANY do `front\Controllers\ShopBasketController` | Operacje koszyka, add/remove/quantity, checkout |
 | ShopClient | ZMIGROWANY do `front\Controllers\ShopClientController` | Logowanie, rejestracja, odzyskiwanie hasla, adresy, zamowienia |
-| ShopOrder | KRYTYCZNY | Webhooki płatności (tPay, Przelewy24, Hotpay) — bezpośrednie operacje DB |
+| ShopOrder | ZMIGROWANY do `front\Controllers\ShopOrderController` | Webhooki płatności + order details |
 | ShopProduct | Fasada | lazy_loading, warehouse_message, draw_product_attributes |
 | ShopProducer | Fasada | list(), products() |
-| ShopCoupon | Fasada | use_coupon(), delete_coupon() |
-| Newsletter | Fasada | signin(), confirm(), unsubscribe() |
+| ShopCoupon | ZMIGROWANY do `front\Controllers\ShopCouponController` | use_coupon(), delete_coupon() |
+| Newsletter | ZMIGROWANY do `front\Controllers\NewsletterController` | signin(), confirm(), unsubscribe() |
 
 ### front/factory/ (20 klas — pobieranie danych + logika)
 | Klasa | Status | Priorytet migracji |
 |-------|--------|--------------------|
 | ShopProduct | ORYGINALNA LOGIKA (~370 linii) | KRYTYCZNY — product_details(), promoted/top/new products |
-| ShopOrder | ORYGINALNA LOGIKA (~180 linii) | KRYTYCZNY — basket_save() tworzy zamówienie |
+| ShopOrder | ZMIGROWANA do `OrderRepository` — usunięta | — |
 | ShopClient | ZMIGROWANA do `ClientRepository` + `ShopClientController` — usunięta | — |
 | ShopCategory | ZMIGROWANA do `CategoryRepository` — usunięta | — |
 | Articles | ORYGINALNA LOGIKA | WYSOKI — złożone SQL z language fallback |
@@ -44,7 +44,7 @@ Panel administratora (33 moduły) został w pełni zmigrowany na architekturę D
 | Menu | USUNIETA — przepieta na Domain | — |
 | Pages | USUNIETA — przepieta na Domain | — |
 | ShopAttribute | ZMIGROWANA (Domain) — usunięta | — |
-| ShopCoupon | Model danych | NISKI |
+| ShopCoupon | ZMIGROWANA do `CouponRepository` — usunięta | — |
 
 ### front/view/ (12 klas — renderowanie)
 | Klasa | Status |
@@ -57,7 +57,8 @@ Panel administratora (33 moduły) został w pełni zmigrowany na architekturę D
 | Banners | PRZENIESIONA do `front\Views\Banners` |
 | Languages, Newsletter | PRZENIESIONE do `front\Views\` (nowy namespace) |
 | ShopClient | PRZENIESIONA do `front\Views\ShopClient` |
-| ShopOrder, ShopPaymentMethod | Czyste VIEW |
+| ShopOrder | ZMIGROWANA do `ShopOrderController` — usunięta |
+| ShopPaymentMethod | Czyste VIEW |
 | ShopTransport | PUSTA klasa (placeholder) |
 
 ### shop/ (14 klas — encje biznesowe)
@@ -464,38 +465,41 @@ front\factory\ShopPromotion::promotion_type_XX() → shop\Product::is_product_on
 
 ---
 
-### Etap: Order Creation Frontend Service
+### Etap: Order Creation Frontend Service — ZREALIZOWANY (ver. 0.290)
 
 **Cel:** Migracja `front\factory\ShopOrder::basket_save()` (~180 linii).
 
-**NOWE:**
-- `Domain/Order/OrderFrontendService.php`:
-  - `createOrder()` — tworzenie zamówienia z koszyka (walidacja, kalkulacja cen, insert, redukcja stanów, obsługa kuponu, wysyłka emaili, auto-status dla pobrania)
+**ZREALIZOWANE:** (wg wytycznej "NIE tworzymy osobnych FrontendService/AdminService" — metody dodane do istniejącego `OrderRepository`)
+- `Domain/Order/OrderRepository.php` — dodane metody frontendowe:
+  - `createFromBasket()` — tworzenie zamówienia z koszyka (21 parametrów, pełna logika basket_save)
   - `generateOrderNumber()` — format YYYY/MM/NNN
-  - `orderDetails()`, `orderIdByHash()`, `orderHashById()`
-- Testy: `OrderFrontendServiceTest`
+  - `orderDetailsFrontend()`, `findIdByHash()`, `findHashById()`
+- `front/Controllers/ShopOrderController.php` — kontroler z DI (OrderRepository)
+- Testy: `OrderRepositoryTest` (9 nowych), `ShopOrderControllerTest` (3 nowe)
 
-**ZMIANA:**
-- `front/factory/ShopOrder` → fasada
+**USUNIĘTE:**
+- `front/factory/class.ShopOrder.php`
+- `front/controls/class.ShopOrder.php`
+- `front/view/class.ShopOrder.php`
+
+**CALLERY ZAKTUALIZOWANE:**
+- `ShopBasketController` — DI OrderRepository, zmiana basket_save/order_hash
+- `ClientRepository::clientOrders()` — OrderRepository::orderDetailsFrontend()
+- `shop\Order::order_resend_confirmation_email()` — OrderRepository::orderDetailsFrontend()
+- `cron-turstmate.php` — OrderRepository::orderDetailsFrontend()
 
 ---
 
-### Etap: Payment Webhook Service
+### Etap: Payment Webhook Service — ZREALIZOWANY (ver. 0.290)
 
 **Cel:** Wyodrębnienie webhooków płatności z `front\controls\ShopOrder`.
 
-**NOWE:**
-- `Domain/Payment/PaymentWebhookService.php`:
-  - `processTpay(array $params)` — weryfikacja tPay
-  - `processPrzelewy24(array $params)` — weryfikacja przez API + walidacja kwoty
-  - `processHotpay(array $params)` — walidacja SHA256 hash
-  - `private markOrderPaid()` — wspólna logika (update status + email + Apilo sync)
-- Testy: `PaymentWebhookServiceTest`
+**ZREALIZOWANE:** (webhooki przeniesione do `front\Controllers\ShopOrderController` — nadal używają `\shop\Order` do operacji statusów/płatności)
+- `ShopOrderController::paymentStatusTpay()` — przeniesione 1:1
+- `ShopOrderController::paymentStatusPrzelewy24pl()` — ujednolicone z tpay (set_as_paid + update_status zamiast ręcznego $mdb->update)
+- `ShopOrderController::paymentStatusHotpay()` — analogiczna zamiana na \shop\Order metody
 
-**ZMIANA:**
-- `front/controls/ShopOrder` — webhooki stają się thin wrappers
-
-**POPRAWA:** Zamiana `file_put_contents('tpay.txt')` na `\Log::save_log()`
+**UWAGA:** `\shop\Order` nie jest jeszcze zmigrowany — osobny etap (Order Instance + Apilo Service)
 
 ---
 

docs/PROJECT_STRUCTURE.md

@@ -457,4 +457,21 @@ Pelna dokumentacja testow: `TESTING.md`
   - OPTYMALIZACJA: `addressSave()` przyjmuje `array $data` zamiast 6 parametrow
 
 ---
-*Dokument aktualizowany: 2026-02-17 (ver. 0.289)*
+
+## Aktualizacja 2026-02-17 (ver. 0.290) - ShopCoupon + ShopOrder frontend migration
+- **ShopCoupon (frontend)** — migracja controls + factory na Domain + Controllers
+  - NOWE METODY w `CouponRepository`: `findByName()`, `isAvailable()`, `markAsUsed()`, `incrementUsedCount()`
+  - NOWY: `front\Controllers\ShopCouponController` — instancyjny kontroler z DI (`useCoupon()`, `deleteCoupon()`)
+  - KONWERSJA: `shop\Coupon` na fasade z dzialajacymi metodami (`is_one_time()`, `set_as_used()`)
+  - FIX: kupony jednorazowe nigdy nie byly oznaczane jako uzyte
+  - USUNIETA: `front\controls\class.ShopCoupon.php`, `front\factory\class.ShopCoupon.php`
+- **ShopOrder (frontend)** — migracja controls + factory + view na Domain + Controllers
+  - NOWE METODY w `OrderRepository`: `findIdByHash()`, `findHashById()`, `orderDetailsFrontend()`, `generateOrderNumber()`, `createFromBasket()` (~180 linii logiki basket_save)
+  - NOWY: `front\Controllers\ShopOrderController` — instancyjny kontroler z DI (`paymentConfirmation()`, `paymentStatusTpay()`, `paymentStatusPrzelewy24pl()`, `paymentStatusHotpay()`, `orderDetails()`)
+  - POPRAWA: webhooks przelewy24/hotpay — ujednolicone z tpay (set_as_paid + update_status zamiast recznego $mdb->update)
+  - UPDATE: `ShopBasketController` — DI OrderRepository, zmiana wywolan basket_save/order_hash
+  - UPDATE: `ClientRepository::clientOrders()`, `shop\Order::order_resend_confirmation_email()`, `cron-turstmate.php` — przepiete na `OrderRepository`
+  - USUNIETA: `front\controls\class.ShopOrder.php`, `front\factory\class.ShopOrder.php`, `front\view\class.ShopOrder.php`
+
+---
+*Dokument aktualizowany: 2026-02-17 (ver. 0.290)*

docs/TESTING.md

@@ -36,7 +36,16 @@ Alternatywnie (Git Bash):
 Ostatnio zweryfikowano: 2026-02-17
 
 ```text
-OK (537 tests, 1648 assertions)
+OK (565 tests, 1716 assertions)
+```
+
+Aktualizacja po migracji ShopCoupon + ShopOrder frontend (2026-02-17, ver. 0.290):
+```text
+Pelny suite: OK (565 tests, 1716 assertions)
+Nowe testy: CouponRepositoryTest (+12: findByName 3 scenariusze, isAvailable 5 scenariuszy, markAsUsed 2 scenariusze, incrementUsedCount 2 scenariusze)
+Nowe testy: ShopCouponControllerTest (+3: constructorAcceptsRepository, hasMainActionMethods, constructorRequiresCouponRepository)
+Nowe testy: OrderRepositoryTest (+10: findIdByHash 3 scenariusze, findHashById 2 scenariusze, orderDetailsFrontend 3 scenariusze, generateOrderNumber 2 scenariusze)
+Nowe testy: ShopOrderControllerTest (+3: constructorAcceptsRepository, hasMainActionMethods, constructorRequiresOrderRepository)
 ```
 
 Aktualizacja po migracji ShopCategory + ShopClient frontend (2026-02-17, ver. 0.289):

docs/UPDATE_INSTRUCTIONS.md

@@ -18,16 +18,16 @@ Aktualizacje znajdują się w folderze `updates/0.XX/` gdzie XX oznacza dziesią
 
 ## Procedura tworzenia nowej aktualizacji
 
-## Status biezacej aktualizacji (ver. 0.289)
+## Status biezacej aktualizacji (ver. 0.290)
 
-- Wersja udostepniona: `0.289` (data: 2026-02-17).
+- Wersja udostepniona: `0.290` (data: 2026-02-17).
 - Pliki publikacyjne:
-    - `updates/0.20/ver_0.289.zip`, `ver_0.289_files.txt`
+    - `updates/0.20/ver_0.290.zip`, `ver_0.290_files.txt`
 - Pliki metadanych aktualizacji:
-    - `updates/changelog.php` (dodany wpis `ver. 0.289`)
-    - `updates/versions.php` (`$current_ver = 289`)
+    - `updates/changelog.php` (dodany wpis `ver. 0.290`)
+    - `updates/versions.php` (`$current_ver = 290`)
 - Weryfikacja testow przed publikacja:
-    - `OK (537 tests, 1648 assertions)`
+    - `OK (565 tests, 1716 assertions)`
 
 ### 1. Określ numer wersji
 Sprawdź ostatnią wersję w `updates/` i zwiększ o 1.