Zapisane filtry

SavedFilter to nazwana, zapisana kombinacja query paramów search/label/status/priority/assignee dla projektu, tworzona przez saveFilter(name, queryParams) z useSavedFilters() i wylistowywana z powrotem przez Project::savedFilters(). Ta kategoria dokumentuje dwie prawdziwe luki znalezione podczas researchu: Controller całkowicie omija warstwę Service (zobacz ../activity-log/01-log-a-new-kind-of-activity.md, który już wprowadza brakujący SavedFilterService jako własny przećwiczony przykład), oraz kolumna context jest zapisywana przy każdym zapisie, ale nigdy faktycznie nigdzie nie odczytywana — każdy zapisany filtr pojawia się niezależnie od tego, z jakiego widoku (List/Board/Calendar) został zapisany.

Przewodniki, w kolejności, w jakiej faktycznie będziesz ich potrzebować

1. Wyodrębnij warstwę Service — ten sam SavedFilterService wprowadzony w ../activity-log/01-log-a-new-kind-of-activity.md, pokryty tutaj w pełni (zarówno create(), jak i delete(), plus zmiany Controllera/trasy/testów), ponieważ ta kategoria to miejsce, do którego faktycznie należy.
2. Spraw, żeby context faktycznie sterował tym, które filtry się pokazują — przećwiczony przykład naprawiający drugą lukę: filtrowanie listy zapisanych filtrów po kontekście aktywnego widoku zamiast pokazywania każdego zapisanego filtra projektu wszędzie.

Architektura w jednym akapicie

SavedFilter (project_id, name, context, query_params — ten ostatni rzutowany na array) nie ma dedykowanej Policy; zarówno SavedFilterController::store(), jak i destroy() autoryzują tylko względem view na projekcie (rodzicu Project::savedFilters()), więc każdy członek może utworzyć albo usunąć dowolny zapisany filtr należący do projektu, w którym jest — nie ma dziś żadnej koncepcji własności per-filtr, w przeciwieństwie do rozróżnienia własne/cudze przy komentarzach. Na froncie useSavedFilters() oblicza context jako `project_${projectId}` zawsze, gdy podany jest projectId, i całkowicie odmawia zapisu (logując do konsoli, nie pokazując błędu widocznego dla użytkownika), gdy go nie ma — co oznacza, że własna wartość fallback contextu hooka, dosłowny string 'project_issues', nigdy faktycznie nie jest wysyłany do serwera przez żadne prawdziwe miejsce wywołania dzisiaj, ponieważ dotarcie do tej gałęzi wymaga braku projectId, co następna linia zamienia w wczesny return. context jest zapisywany wiernie tak czy inaczej, ale nic na froncie dziś nie odczytuje ani nie filtruje po nim przy wylistowywaniu zapisanych filtrów z powrotem — zobacz przewodnik 2.