orderPRO/.paul/phases/80-status-change-reload/80-01-PLAN.md

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

phase	plan	type	wave	depends_on	files_modified	autonomous
80-status-change-reload	01	execute	1		public/assets/js/modules/inline-status-change.js	true

## 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.

## Project Context @.paul/PROJECT.md @.paul/ROADMAP.md @.paul/STATE.md

Source Files

@public/assets/js/modules/inline-status-change.js

<acceptance_criteria>

AC-1: Przeladowanie listy po zmianie statusu

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

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>

Task 1: Dodanie location.reload() po udanej zmianie statusu public/assets/js/modules/inline-status-change.js 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. 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) AC-1 i AC-2 spelnione: reload po sukcesie, brak reloadu przy bledzie

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

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)

<success_criteria>

• Task 1 ukonczony
• Wszystkie verification checks przechodzą
• Brak regresji w inline status change </success_criteria>

After completion, create `.paul/phases/80-status-change-reload/80-01-SUMMARY.md`