UX panelu: reset dla niezmienionych rekordów, ogólne potwierdzenia, przycisk Close w podglądzie, ukryte akcje listy

Start with the cited files: controllers/templates/_column_actions.php, controllers/templates/_form_buttons.php, the preview controllers, and the template and layout field definitions. Reproduce the reported browser behaviors at the listed viewport sizes, then trace each affected action to its view or controller. Done means the listed acceptance criteria pass; the issue also includes several additional UX and permissions changes beyond those criteria.

Problem

Sprawdzone w przeglądarce (Playwright, 1280 px, 768 px, 375 px):

1. Reset dla rekordów zgodnych z widokiem. Lista i formularz pokazują Reset to Default dla każdego rekordu z zarejestrowanym widokiem, także niezmienionego (Customized ✗). Reset kończy się flashem „The record was restored from its view file.”, choć nic się nie zmieniło (updated_at przed i po: 2026-10-03 19:16:27).
2. Ogólne potwierdzenia. Wszystkie akcje (reset, usunięcie, duplikacja na liście) pytają tym samym „Are you sure?” (backend::lang.form.action_confirm), bez nazwy rekordu i skutku. Rdzeń przy usuwaniu pyta „Delete this record?”. Duplicate w formularzu nie pyta wcale, na liście pyta.
3. Close w podglądzie HTML otwiera drugi formularz. Podgląd otwiera się w nowej karcie, a jego Close to link do formularza. Po kliknięciu użytkownik ma dwie karty z tym samym formularzem, co grozi nadpisaniem zmian z nieaktualnej karty. To samo dotyczy „Return to the templates list” na stronie błędu podglądu PDF.
4. Akcje listy poza ekranem. Przy 1280 px lista ma 938 px, a tabela 1036 px, więc z kolumny akcji widać tylko przycisk PDF. Przy 375 px pierwszy przycisk jest na x≈894.
5. Kod niewidoczny przy edycji. code jest tylko w kontekście create (code@create). Edytor nie widzi kodu, którego używa programista w loadTemplate().
6. Usuń przy używanym layoucie jest aktywne, a odmowa przychodzi dopiero po potwierdzeniu.
7. Rola z samymi uprawnieniami layoutów (bez Access templates) nie ma wejścia do listy, a Create & Close kończy się „Access Denied”, bo przekierowuje na listę szablonów. README to opisuje, ekran uprawnień nie.
8. Tytuł karty bez nazwy rekordu („Edit template”, „Preview HTML”), więc przy kilku otwartych kartach trudno je odróżnić.

Dowód

• controllers/templates/_column_actions.php:15-44 (reset przy followsView(), potwierdzenia action_confirm), controllers/templates/_form_buttons.php:63-95.
• controllers/templates/preview.php:19-24, controllers/layouts/preview.php:19-24.
• models/template/fields.yaml:10-14, models/layout/fields.yaml:14-18 (code@create).
• controllers/layouts/config_form.yaml:12-13, 17-18 (redirectClose na listę w kontrolerze Templates).
• Każdy punkt odtworzony w Chromium (Playwright) na danych demo.

Skutek

Mylące komunikaty sukcesu, ryzyko nadpisania zmian z drugiej karty, ukryte akcje na typowych laptopach i ślepe uliczki dla ról z wąskimi uprawnieniami.

Proponowane rozwiązanie

• Reset tylko dla isCustomised().
• Potwierdzenia z nazwą rekordu i skutkiem („Reset Invoice to its view file? Your changes will be lost.”). Duplicate w formularzu i na liście zachowuje się tak samo.
• Close w podglądzie otwartym w nowej karcie zamyka kartę (window.close()), a w innym przypadku zostaje link.
• created_at domyślnie invisible na obu listach albo węższa kolumna akcji.
• code@update jako pole tylko do odczytu.
• Usuń nieaktywne z podpowiedzią „Używany przez N szablonów”, gdy layout ma szablony.
• redirectClose layoutów zależne od uprawnień albo opis wymagań w komentarzu uprawnienia.
• Tytuł strony z nazwą rekordu.

Kryteria akceptacji

• Rekord zgodny z widokiem nie ma aktywnego resetu.
• Potwierdzenia mówią, czego dotyczą i co się stanie.
• Close w podglądzie nie otwiera drugiego formularza.
• Akcje listy są widoczne przy 1366 px.
• Kod jest widoczny przy edycji.

Powiązane issues

#208, #209, #210, #211, #248, #254 (wcześniejsze poprawki UX listy i formularza), #174, #262 (uprawnienia).