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>
12 KiB
12 KiB
phase, plan, type, wave, depends_on, files_modified, autonomous
| phase | plan | type | wave | depends_on | files_modified | autonomous | ||||
|---|---|---|---|---|---|---|---|---|---|---|
| 07-pre-expansion-fixes | 03 | execute | 1 |
|
false |
Purpose
Użytkownik konfiguruje synchronizację "orderPRO → Allegro" i aplikacja loguje "sukces" mimo że nic nie robi. To aktywnie wprowadza w błąd. Pozostałe 4 to widoczne błędy UX (todo.md items 14-17) które obniżają czytelność głównego widoku listy zamówień — ekranu który użytkownik widzi najczęściej.
Output
- AllegroStatusSyncService:
ok: falsedla nieopracowanego kierunku + UI option disabled - Lista zamówień: source przed ID, integracja zamiast "shopPRO", "ID:" prefix
- Lista zamówień: statusy kolorowane zgodnie z ustawieniami (jeśli mapping istnieje)
- SCSS: ciemniejsze obramowanie inputów/select/textarea
Source Files
@src/Modules/Settings/AllegroStatusSyncService.php @resources/views/settings/allegro.php @resources/views/orders/list.php @resources/scss/modules/_orders.scss
<acceptance_criteria>
AC-1: orderpro_to_allegro nie daje false-positive sukcesu
Given użytkownik ustawił kierunek sync "orderPRO → Allegro" w ustawieniach
When cron uruchamia synchronizację statusów
Then serwis zwraca ['ok' => false, 'message' => 'Kierunek orderPRO -> Allegro nie jest jeszcze wdrożony.']
AND log crona odróżnia to od sukcesów (ok: false)
AC-2: Opcja sync direction "orderPRO → Allegro" oznaczona jako niedostępna
Given w formularzu ustawień Allegro jest select z opcjami kierunku synchronizacji
When użytkownik otwiera formularz ustawień
Then opcja "orderPRO → Allegro" jest widoczna ale wyraźnie oznaczona jako "(wkrótce)" lub disabled
AND formularz nie pozwala zapisać tej opcji bez ostrzeżenia
AC-3: W liście zamówień source wyświetla się przed ID, z etykietą "ID:"
Given wiersz zamówienia w div.orders-ref__meta pokazuje kolejność: [ID][source]
When renderowana jest lista zamówień
Then kolejność to: [source][ID], a ID ma prefix "ID:"
AND dla zamówień z integracji shopPRO wyświetlana jest konkretna nazwa integracji (nie "shopPRO")
AC-4: Statusy zamówień kolorowane na liście
Given administrator skonfigurował kolory statusów w ustawieniach (tabela allegro_order_status_mappings lub odpowiednik)
When renderowana jest lista zamówień z zamówieniami mającymi zmapowane statusy
Then komórka/badge statusu ma inline styl lub klasę CSS odpowiadającą skonfigurowanemu kolorowi
AND dla niemapowanych statusów wyświetlany jest tekst bez koloru (neutralny fallback)
AC-5: Ciemniejsze obramowanie pól formularza
Given input, select, textarea mają jasne obramowanie (zbyt słabo widoczne)
When użytkownik wyświetla dowolny formularz w aplikacji
Then obramowanie pól jest zauważalnie ciemniejsze (wyższy kontrast z tłem)
</acceptance_criteria>
Task 1: AllegroStatusSyncService — ok:false + UI disabled dla orderpro_to_allegro src/Modules/Settings/AllegroStatusSyncService.php, resources/views/settings/allegro.php **W AllegroStatusSyncService.php (linie ~39-45):** Zmień: ```php if ($direction === self::DIRECTION_ORDERPRO_TO_ALLEGRO) { return [ 'ok' => true, // ← BUG: powinno być false ... ]; } ``` Na: ```php if ($direction === self::DIRECTION_ORDERPRO_TO_ALLEGRO) { return [ 'ok' => false, 'direction' => $direction, 'processed' => 0, 'message' => 'Kierunek orderPRO -> Allegro nie jest jeszcze wdrożony.', ]; } ```**W resources/views/settings/allegro.php (linie ~260-267):**
Znajdź select `status_sync_direction`. Zmień opcję `orderpro_to_allegro`:
```php
<option value="orderpro_to_allegro"
<?= $statusSyncDirection === 'orderpro_to_allegro' ? ' selected' : '' ?>
disabled>
<?= $e($t('settings.allegro.settings.status_sync_direction_orderpro_to_allegro')) ?>
(wkrótce)
</option>
```
Dodaj `disabled` do atrybutu opcji. Jeśli aktualnie wybrana wartość to `orderpro_to_allegro`
(istniejące ustawienie w DB), disabled option z selected nadal wyświetla się poprawnie —
użytkownik widzi co było wybrane, ale nie może ponownie wybrać.
NIE zmieniaj logiki AllegroStatusSyncService poza tym early return.
php -l src/Modules/Settings/AllegroStatusSyncService.php
grep -A5 "DIRECTION_ORDERPRO_TO_ALLEGRO" src/Modules/Settings/AllegroStatusSyncService.php
# Powinno pokazać ok: false
grep -A3 "orderpro_to_allegro" resources/views/settings/allegro.php
# Powinno pokazać disabled
AC-1 i AC-2 satisfied: ok:false + opcja UI disabled
Task 2: Lista zamówień — source przed ID, etykieta integracji, prefix "ID:"
resources/views/orders/list.php
Przeczytaj plik `resources/views/orders/list.php` dokładnie.
Znajdź fragment renderujący `orders-ref__meta` (lub analogiczny div z source i order ID).
Obecna kolejność (wg todo.md item 15):
```html
<div class="orders-ref__meta">
<span>[ID zamówienia]</span>
<span>[source: "allegro"/"shopPRO"]</span>
</div>
```
**Zmiana 1 (item 15): Odwróć kolejność** — source przed ID:
```html
<div class="orders-ref__meta">
<span>[source]</span>
<span>ID: [ID zamówienia]</span>
</div>
```
**Zmiana 2 (item 17): Zamiast "shopPRO" pokaż konkretną nazwę integracji.**
Sprawdź jakie pole w danych zamówienia zawiera nazwę integracji.
Odczytaj co jest dostępne w `$order` array w widoku — szukaj pól: `integration_name`,
`source`, `source_name`, `integration_id`.
Jeśli `$order['source']` zawiera np. "shoppro" a konkretna nazwa integracji jest dostępna
jako osobne pole — użyj tej nazwy dla shopPRO, zachowaj "allegro" dla Allegro.
Jeśli nie ma pola z konkretną nazwą integracji w danych zwracanych przez OrdersRepository,
sprawdź co jest dostępne i użyj dostępnego pola. Nie dodawaj nowych DB queries w widoku.
Dodaj prefix "ID: " przed source_order_id lub external_order_id (którego używa widok).
php -l resources/views/orders/list.php
grep -n "orders-ref__meta\|source_order_id\|source.*span\|ID:" resources/views/orders/list.php
AC-3 satisfied: source przed ID, prefix "ID:", integracja zamiast "shopPRO"
1. AllegroStatusSyncService zwraca ok:false dla orderpro_to_allegro
2. UI opcja "orderPRO → Allegro" oznaczona jako disabled/(wkrótce)
3. Lista zamówień: source przed ID, prefix "ID:", etykieta integracji
1. Uruchom aplikację (XAMPP)
2. Przejdź do Ustawień → Integracje → Allegro → zakładka synchronizacji
- Sprawdź że opcja "orderPRO → Allegro" jest wyświetlona jako disabled/(wkrótce)
3. Przejdź do listy zamówień (/orders)
- Sprawdź kolejność: source powinien być przed ID
- Sprawdź prefix "ID:"
- Sprawdź że shopPRO pokazuje konkretną nazwę integracji
4. Wpisz "approved" lub opisz co nie gra
Wpisz "approved" aby kontynuować do kolorowania statusów i SCSS, lub opisz problemy
Task 3: Statusy kolorowane na liście + ciemniejsze obramowanie formularzy
resources/views/orders/list.php,
resources/scss/modules/_orders.scss
**Item 16: Kolorowanie statusów.**
Przeczytaj `resources/views/orders/list.php` — znajdź gdzie renderowany jest status zamówienia.
Sprawdź co jest w `$order['effective_status_id']` lub analogicznym polu.
W OrdersRepository::buildListSql() jest już JOIN do `allegro_order_status_mappings` —
sprawdź jakie kolumny są pobierane z tego JOINu (np. `asm.color` czy `asm.label_color`).
Jeśli kolor jest już dostępny w danych widoku jako pole `status_color` lub `color` —
dodaj do elementu statusu inline style:
```php
<?php $statusColor = $order['status_color'] ?? ''; ?>
<span class="order-status"
<?= $statusColor !== '' ? 'style="background-color:' . $e($statusColor) . '"' : '' ?>>
<?= $e($order['effective_status_id'] ?? $order['external_status_id'] ?? '') ?>
</span>
```
Jeśli kolor nie jest dostępny w danych widoku — sprawdź OrdersRepository::transformOrderRow()
i buildListSql() co jest pobierane z asm (allegro_order_status_mappings JOIN). Jeśli kolumna
`color` istnieje w tabeli — dodaj ją do SELECT i transformOrderRow(). Jeśli tabela nie ma
kolumny `color` — nie dodawaj, zaznacz w SUMMARY że wymaga migracji.
**Item 14: Ciemniejsze obramowanie inputów.**
Znajdź w `resources/scss/modules/_orders.scss` lub `resources/scss/_global.scss`
lub analogicznym pliku SCSS definicję borderów dla `input, select, textarea`.
Zmień kolor border na ciemniejszy o ok. 30-40% (np. z `#ddd` na `#aaa` lub z `#ccc` na `#999`).
Sprawdź najpierw które pliki SCSS definiują style formularzy — może to być inny plik niż _orders.scss.
Szukaj: `grep -rn "border.*input\|input.*border\|\.form-control" resources/scss/`
php -l resources/views/orders/list.php
# Znajdź plik SCSS z border input i zweryfikuj zmianę:
grep -rn "form-control\|input.*border\|border.*input" resources/scss/ | head -10
AC-4 i AC-5 satisfied: statusy kolorowane, obramowania ciemniejsze
DO NOT CHANGE
- Logika synchronizacji statusów poza early return (nie implementuj orderpro_to_allegro)
- Inne widoki poza orders/list.php i settings/allegro.php
- Publiczne API controllera AllegroStatusSyncService
- Routing i nazwy tras
SCOPE LIMITS
- Nie implementuj synchronizacji orderPRO→Allegro — tylko disable UI + ok:false
- Kolorowanie statusów tylko jeśli kolor jest dostępny bez dodatkowych DB queries w widoku
- Border color — tylko zmiana istniejącej wartości, nie nowy system designu
- Nie ruszaj resources/views/settings/shoppro.php (ma analogiczną opcję — osobny scope)
<success_criteria>
- AllegroStatusSyncService: ok:false dla orderpro_to_allegro
- UI: opcja disabled
- Lista zamówień: source | "ID: [id]" w poprawnej kolejności
- Lista zamówień: integracja zamiast "shopPRO"
- Statusy: kolorowane gdy kolor dostępny
- Formularze: ciemniejsze obramowanie </success_criteria>