Zapisane filtry

SavedFilter to nazwana, zapisana kombinacja query paramów search/label/status/priority/assignee dla projektu (param priority zawiera id priorytetów, np. 1,3, a nie nazwy — usunięcie priorytetu usuwa jego id z zapisanych filtrów projektu, zobacz ../priorities/README.mdPriorytetyPriorytet issue'a to zasób per-projekt, oparty na prawdziwej tabeli bazodanowej priorities (App\Models\Priority) — a nie na sztywnym enumie low / medium /…), 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.mdLog aktywnościZaloguj nowy rodzaj aktywnościNie ma żadnego enuma, żadnego kroku rejestracji, żadnej mapy na froncie do zaktualizowania — zalogowanie nowego rodzaju aktywności to pojedyncze wywołanie…, 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ę ServiceZapisane filtryWyodrębnij warstwę ServiceSavedFilterController to jedyny Controller w aplikacji, który tworzy i usuwa model Eloquent bezpośrednio, omijając konwencję Controller → Service → Reposit… — ten sam SavedFilterService wprowadzony w ../activity-log/01-log-a-new-kind-of-activity.mdLog aktywnościZaloguj nowy rodzaj aktywnościNie ma żadnego enuma, żadnego kroku rejestracji, żadnej mapy na froncie do zaktualizowania — zalogowanie nowego rodzaju aktywności to pojedyncze wywołanie…, 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ąZapisane filtrySpraw, żeby `context` faktycznie sterował tym, które filtry się pokazująDziś context jest zapisywany (jako project${projectId} ), ale nigdy nie odczytywany z powrotem — Pages/Projects/Show.tsx przekazuje całą tablicę savedFilte… — 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 komentarzachRole i uprawnienia (RBAC)Każdy projekt ma własną kontrolę dostępu opartą na rolach: cztery wbudowane poziomy roli systemowej (Owner, Admin, Member, Viewer) oraz dowolną liczbę proj…. 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.