orderPRO/.paul/phases/07-pre-expansion-fixes/07-05-PLAN.md at 22fc3300557df91cb172f151bbb4dd8d818373c1

Files

Jacek Pyziak 03c18f6782 plan(07-pre-expansion-fixes): create 5 plans for pre-expansion fixes

07-01: Performance — N+1 subqueries, information_schema static, DB indexes
07-02: Stability — SSL verification (4 clients), cron throttle→DB, migration 000014b
07-03: UX — orderpro_to_allegro disable, orders list items 14-17
07-04: Tests — AllegroTokenManager + AllegroOrderImportService unit tests
07-05: InPost ShipmentProviderInterface (replaces allegro_wza workaround)

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

2026-03-13 17:44:42 +01:00

8.6 KiB

Raw Blame History

phase, plan, type, wave, depends_on, files_modified, autonomous

phase

plan

type

wave

depends_on

files_modified

autonomous

07-pre-expansion-fixes

execute

src/Modules/Settings/InpostShipmentService.php

src/Modules/Shipments/ShipmentController.php

src/Modules/Shipments/ShipmentProviderRegistry.php

src/Core/Application.php

false

## Goal Zastąpić workaround `inpost → allegro_wza` prawdziwym `InpostShipmentService implements ShipmentProviderInterface`, korzystającym z credentiali z `InpostIntegrationRepository`.

Purpose

Obecnie InPost shipments są tworzone przez Allegro WZA API, co oznacza że użytkownik potrzebuje aktywnej integracji Allegro żeby nadawać przez InPost. To jest cichy bloker dla użytkowników z InPost-only. Każdy nowy przewoźnik dodany bez własnego providera będzie powielał ten pattern.

Output

src/Modules/Settings/InpostShipmentService.php — implementacja ShipmentProviderInterface
ShipmentController.php — usunięty workaround remap inpost → allegro_wza
Wiring w Application.php / ShipmentProviderRegistry

## Project Context @.paul/PROJECT.md

Source Files

@src/Modules/Shipments/ShipmentProviderInterface.php @src/Modules/Shipments/ShipmentController.php @src/Modules/Settings/InpostIntegrationRepository.php @src/Modules/Settings/AllegroShipmentService.php

<acceptance_criteria>

AC-1: InpostShipmentService implementuje ShipmentProviderInterface

Given ShipmentProviderInterface definiuje kontrakt dla providerów przesyłek
When tworzysz InpostShipmentService
Then klasa implementuje ShipmentProviderInterface
  AND php -l nie zgłasza błędów
  AND klasa poprawnie typuje wszystkie wymagane metody interfejsu

AC-2: InPost shipments tworzone przez InPost API (nie Allegro WZA)

Given użytkownik ma skonfigurowane credentiale InPost (token w InpostIntegrationRepository)
  AND nie ma skonfigurowanej integracji Allegro
When tworzy przesyłkę InPost przez ShipmentController
Then ShipmentController używa InpostShipmentService (nie AllegroShipmentService)
  AND workaround "if (inpost) { providerCode = allegro_wza }" jest usunięty

AC-3: Brak regresji dla istniejących Allegro WZA shipments

Given użytkownik tworzy przesyłkę przez Allegro WZA (provider_code = allegro_wza)
When ShipmentController przetwarza żądanie
Then flow Allegro WZA działa dokładnie jak przed zmianami
  AND InPost nie jest mylony z Allegro WZA

</acceptance_criteria>

Który endpoint InPost API do tworzenia paczek? InPost ma dwa API: A) Allegro WZA (paczkomaty przez Allegro) — obecny workaround, wymaga Allegro auth B) InPost ShipX API (natywne API InPost) — bezpośrednie, wymaga tokenu InPost

InpostIntegrationRepository przechowuje credentiale — sprawdź jakie pola.
Odczytaj: src/Modules/Settings/InpostIntegrationRepository.php

Opcja A: Zaimplementuj natywny InPost ShipX API (wymaga dokumentacji i tokenu)
Opcja B: Wydziel logikę Allegro WZA do oddzielnego providera bez remapu,
         a InPost nadal przez Allegro WZA ale bez tajnego remapu (jawny config)

Natywny InPost ShipX API Pełna niezależność od Allegro; własne credentiale wystarczą; długoterminowo poprawne Wymaga znajomości ShipX API; potrzebne credentiale testowe do weryfikacji Allegro WZA ale jawnie skonfigurowany (bez tajnego remapu) Szybkie; nie wymaga nowej integracji API; eliminuje workaround kod Nadal wymaga integracji Allegro; nie rozwiązuje problemu InPost-only użytkowników Wybierz: "shipx" lub "allegro-wza-explicit", lub opisz inne podejście Task 1: Implementuj InpostShipmentService zgodnie z wybraną opcją src/Modules/Settings/InpostShipmentService.php, src/Modules/Settings/InpostIntegrationRepository.php Przeczytaj `src/Modules/Shipments/ShipmentProviderInterface.php` — zrozum wymagany kontrakt. Przeczytaj `src/Modules/Settings/AllegroShipmentService.php` — jako wzorzec implementacji. Przeczytaj `src/Modules/Settings/InpostIntegrationRepository.php` — jakie credentiale są dostępne.

**Jeśli wybrano "shipx" (natywny InPost ShipX API):**
- Stwórz `InpostShipmentService implements ShipmentProviderInterface`
- Konstruktor przyjmuje `InpostIntegrationRepository` (dla tokenu)
- Metoda create(): wywołuje ShipX API endpoint tworzenia przesyłki
- Metoda getLabel(): pobiera etykietę przez ShipX API
- Używaj cURL (jak inne ApiClienty) z SSL verification
- Endpointy ShipX: `https://api-shipx-pl.easypack24.net/v1/`

**Jeśli wybrano "allegro-wza-explicit":**
- Stwórz `InpostShipmentService` który wrapuje `AllegroShipmentService`
- Zamiast tajnego remapu — jawna delegacja
- Konstruktor przyjmuje `AllegroShipmentService $allegroService`
- Każda metoda deleguje do $allegroService

W obu przypadkach: namespace App\Modules\Settings, php -l musi przejść.

php -l src/Modules/Settings/InpostShipmentService.php grep "implements ShipmentProviderInterface" src/Modules/Settings/InpostShipmentService.php AC-1 satisfied: InpostShipmentService implementuje ShipmentProviderInterface Task 2: Usuń workaround z ShipmentController, podłącz InpostShipmentService src/Modules/Shipments/ShipmentController.php, src/Core/Application.php **W ShipmentController.php:** Znajdź linie ~164-166: ```php if ($providerCode === 'inpost') { $providerCode = 'allegro_wza'; } ``` Usuń ten blok. ShipmentProviderRegistry powinien teraz zawierać 'inpost' jako zarejestrowany provider.

Sprawdź czy jest podobny remap w innych miejscach ShipmentController (linia ~239, ~286) — usuń wszystkie.

**W Application.php (lub ShipmentProviderRegistry):**
Znajdź gdzie rejestrowane są shipment providers.
Dodaj rejestrację InpostShipmentService pod kluczem 'inpost':
```php
$inpostService = new InpostShipmentService(...); // odpowiednie zależności
$providerRegistry->register('inpost', $inpostService);
```
Sprawdź jak AllegroShipmentService jest rejestrowany — użyj tego samego wzorca.

NIE usuwaj rejestracji allegro_wza — nadal musi działać.

php -l src/Modules/Shipments/ShipmentController.php php -l src/Core/Application.php grep -n "inpost.*allegro_wza\|allegro_wza.*inpost" src/Modules/Shipments/ShipmentController.php # Powinno zwrócić 0 — remap usunięty AC-2 i AC-3 satisfied: workaround usunięty, InpostShipmentService zarejestrowany InpostShipmentService zaimplementowany i podłączony. Workaround remap inpost→allegro_wza usunięty. 1. Uruchom aplikację (XAMPP) 2. Przejdź do tworzenia przesyłki InPost 3. Sprawdź że przesyłka InPost jest tworzona (lub zwraca czytelny błąd bez PHP errors) 4. Sprawdź że tworzenie przesyłki Allegro WZA nadal działa 5. Sprawdź logi PHP — brak Fatal errors Wpisz "approved" jeśli działa, lub opisz błędy

DO NOT CHANGE

AllegroShipmentService — nie modyfikuj istniejącej logiki
ShipmentProviderInterface — nie zmieniaj kontraktu
Routing (routes/web.php) — nie zmieniaj URL endpointów

SCOPE LIMITS

Nie implementuj InPost tracking/status sync — tylko create shipment + label
Nie zmieniaj UI wyboru przewoźnika — tylko backend provider
Apaczka, InPost paczkomat przez Allegro WZA nadal działa niezależnie

Przed zamknięciem planu: - [ ] php -l InpostShipmentService.php - [ ] php -l ShipmentController.php - [ ] grep inpost.*allegro_wza ShipmentController.php — 0 wyników - [ ] Checkpoint human-verify zaliczony

<success_criteria>

InpostShipmentService.php istnieje i implementuje ShipmentProviderInterface
Remap usunięty z ShipmentController
Allegro WZA flow bez regresji
Checkpoint human-verify: approved </success_criteria>

Po zakończeniu utwórz `.paul/phases/07-pre-expansion-fixes/07-05-SUMMARY.md`

8.6 KiB Raw Blame History