107 lines
3.6 KiB
Markdown
107 lines
3.6 KiB
Markdown
---
|
|
phase: 80-status-change-reload
|
|
plan: 01
|
|
type: execute
|
|
wave: 1
|
|
depends_on: []
|
|
files_modified: [public/assets/js/modules/inline-status-change.js]
|
|
autonomous: true
|
|
---
|
|
|
|
<objective>
|
|
## Goal
|
|
Po zmianie statusu zamowienia inline na liscie zamowien (/orders/list), strona przeladowuje sie automatycznie, dzieki czemu zamowienie znika z aktualnego widoku filtrowanego po statusie.
|
|
|
|
## Purpose
|
|
Gdy uzytkownik filtruje zamowienia po statusie i zmienia status jednego z nich, zamowienie powinno zniknac z listy (bo juz nie pasuje do filtra). Obecnie badge aktualizuje sie w miejscu, ale zamowienie pozostaje na liscie co jest mylace.
|
|
|
|
## Output
|
|
Zmodyfikowany `public/assets/js/modules/inline-status-change.js` z przeladowaniem strony po udanej zmianie statusu.
|
|
</objective>
|
|
|
|
<context>
|
|
## Project Context
|
|
@.paul/PROJECT.md
|
|
@.paul/ROADMAP.md
|
|
@.paul/STATE.md
|
|
|
|
## Source Files
|
|
@public/assets/js/modules/inline-status-change.js
|
|
</context>
|
|
|
|
<acceptance_criteria>
|
|
|
|
## AC-1: Przeladowanie listy po zmianie statusu
|
|
```gherkin
|
|
Given uzytkownik jest na liscie zamowien z aktywnym filtrem statusu
|
|
When zmienia status zamowienia przez inline dropdown
|
|
Then strona przeladowuje sie po udanej odpowiedzi serwera
|
|
And zamowienie z nowym statusem nie pojawia sie na liscie (bo filtr go wyklucza)
|
|
```
|
|
|
|
## AC-2: Brak przeladowania przy bledzie
|
|
```gherkin
|
|
Given uzytkownik zmienia status zamowienia inline
|
|
When serwer zwraca blad (np. 500 lub validation error)
|
|
Then strona NIE przeladowuje sie
|
|
And badge wraca do poprzedniego statusu
|
|
And wyswietla sie komunikat bledu
|
|
```
|
|
|
|
</acceptance_criteria>
|
|
|
|
<tasks>
|
|
|
|
<task type="auto">
|
|
<name>Task 1: Dodanie location.reload() po udanej zmianie statusu</name>
|
|
<files>public/assets/js/modules/inline-status-change.js</files>
|
|
<action>
|
|
W funkcji `changeStatus()`, w bloku `.then(function (result) {...})`:
|
|
- Po linii 153-154 (po udanej aktualizacji badge'a), dodac `location.reload()`.
|
|
- Reload powinien nastapic TYLKO gdy `result.ok && result.data.success`.
|
|
- Blok error (linie 142-149) i `.catch()` (linie 156-162) pozostaja bez zmian — brak reloadu przy bledzie.
|
|
- Mozna usunac aktualizacje badge'a (linie 152-154) bo reload i tak odswieza strone, ale lepiej zostawic dla plynnosci UX — uzytkownik widzi natychmiastowa zmiane badge'a, potem reload.
|
|
</action>
|
|
<verify>
|
|
1. Otworz /orders/list z filtrem statusu (np. "Nowe")
|
|
2. Zmien status zamowienia na inny (np. "W realizacji")
|
|
3. Strona przeladowuje sie i zamowienie znika z listy
|
|
4. Zmien status bez filtra — strona tez sie przeladowuje (zamowienie pojawia sie z nowym statusem)
|
|
</verify>
|
|
<done>AC-1 i AC-2 spelnione: reload po sukcesie, brak reloadu przy bledzie</done>
|
|
</task>
|
|
|
|
</tasks>
|
|
|
|
<boundaries>
|
|
|
|
## DO NOT CHANGE
|
|
- src/Modules/Orders/OrdersController.php (backend endpoint dziala poprawnie)
|
|
- resources/views/orders/list.php (konfiguracja JS jest OK)
|
|
- routes/web.php
|
|
|
|
## SCOPE LIMITS
|
|
- Nie dodawac AJAX-owego odswiezania listy (pelny reload jest prostszy i wystarczajacy)
|
|
- Nie zmieniac logiki dropdowna ani budowania badge'y
|
|
- Nie zmieniac obslugi bledow
|
|
|
|
</boundaries>
|
|
|
|
<verification>
|
|
Before declaring plan complete:
|
|
- [ ] Po zmianie statusu z filtrem — zamowienie znika z listy
|
|
- [ ] Po zmianie statusu bez filtra — zamowienie ma nowy status po reload
|
|
- [ ] Przy bledzie serwera — brak reloadu, badge wraca, komunikat bledu
|
|
- [ ] Dropdown dziala jak wczesniej (otwieranie, zamykanie, Escape)
|
|
</verification>
|
|
|
|
<success_criteria>
|
|
- Task 1 ukonczony
|
|
- Wszystkie verification checks przechodzą
|
|
- Brak regresji w inline status change
|
|
</success_criteria>
|
|
|
|
<output>
|
|
After completion, create `.paul/phases/80-status-change-reload/80-01-SUMMARY.md`
|
|
</output>
|