Rejestr i kontrola dostępu

Każda zmiana grafiku trafia do rejestru. Koordynatorzy ZRM widzą tylko swoje zespoły. Pełna ścieżka odpowiedzialności bez ryzyka.

Rejestr i kontrola dostępu

W większych stacjach grafiku nie układa jedna osoba - odpowiedzialność jest rozłożona. raTool wspiera ten model w dwóch wymiarach: rejestr zmian (każda modyfikacja jest zapisywana z autorem i czasem) oraz scoped permissions (koordynator ZRM widzi i edytuje wyłącznie swój zespół, nie cudze).

Rejestr zmian (audit log)

Każda zmiana w grafiku - utworzenie dyżuru, zmiana ratownika, anulowanie, zatwierdzenie zamiany, korekta godzin - trafia automatycznie do rejestru. Wpis zawiera:

  • Identyfikator dyżuru, którego dotyczy.
  • Akcja - created (utworzono), updated (zaktualizowano: zmiana ratownika lub statusu), deleted (usunięto), cancelled (anulowano), swapped (zamiana).
  • Kto zmienił - identyfikator użytkownika, który wykonał akcję.
  • Stary stan - wartości przed zmianą (np. user_id poprzedniego ratownika, status planned).
  • Nowy stan - wartości po zmianie.
  • Znacznik czasu - dokładny moment.

Rejestr jest append-only - wpisy nigdy nie są edytowane ani kasowane. To zapewnia, że historia jest pełna i wiarygodna nawet po kontroli z NFZ czy w sporze pracowniczym.

Wpisy generuje trigger bazodanowy - niezależnie od tego, którą drogą wprowadzono zmianę (siatka grafiku, RPC zatwierdzenia zamiany, ręczne poprawki przez support), audyt zapisuje się automatycznie. Nie da się zmodyfikować dyżuru bez śladu.

Uwaga: Aktualnie rejestr nie ma osobnego widoku w aplikacji - dostęp przez support raTool w razie potrzeby (np. przy sporze). Dedykowany ekran przeglądu rejestru pojawi się w przyszłej wersji.

Trzy poziomy odpowiedzialności w stacji

raTool nie wymaga rozbudowanej struktury organizacyjnej. Dla większości stacji wystarczają trzy poziomy:

  • Ratownik - członek stacji z dostępem tylko do własnego grafiku, dyspozycyjności i zamian.
  • Koordynator stacji - pełny dostęp do układania grafiku wszystkich ZRM-ów, zatwierdzania zamian, konfiguracji stacji.
  • Koordynator ZRM - scoped delegation: widzi cały grafik stacji (do podglądu), ale edytować może wyłącznie ZRM-y, których jest koordynatorem - i tylko gdy stacja włączy delegację.

Każda osoba może mieć kilka ról jednocześnie - np. ratownik, który dla jednego ZRM-u jest delegowanym koordynatorem.

Delegacja koordynatorów per ZRM

Strona Koordynatorzy ZRM (menu Administracja → Koordynatorzy ZRM) jest dostępna dla użytkowników z uprawnieniem zrm_coordinators.manage (typowo: koordynator stacji).

Struktura strony

Każdy aktywny ZRM ma osobną kartę, na której widzisz:

  • Lista przypisanych koordynatorów - imiona członków stacji, którzy zostali wskazani jako koordynatorzy tego ZRM-u. Każdy z przyciskiem „Odepnij", jeśli chcesz cofnąć przypisanie.
  • Przełącznik „Delegacja grafiku" - kontroluje, czy koordynatorzy ZRM-u mogą edytować grafik tego ZRM-u:
    • Włączona - „Włączona - koordynatorzy mogą edytować grafik tego ZRM-u". Otwiera im zakładkę Budowanie grafiku w trybie edycji dla ich ZRM-u (ale tylko dla ich ZRM-u - pozostałe widzą read-only).
    • Wyłączona - „Wyłączona - tylko koordynator stacji edytuje grafik". Koordynatorzy ZRM-u mają wtedy dostęp do podglądu, statystyk własnego ZRM-u i akceptacji zamian (jeśli mają uprawnienie swap.approve), ale nie modyfikują obsady.
  • Przycisk „Przypisz koordynatora" - otwiera dialog z listą członków stacji do wybrania.

Przypisywanie koordynatora

Kliknięcie „Przypisz koordynatora" otwiera okno „Przypisz koordynatora ZRM" z polem „Członek stacji" - wybierz osobę z listy. Po zapisie pojawia się na karcie ZRM-u i (jeśli delegacja jest włączona) od razu uzyskuje dostęp do edycji grafiku tego konkretnego ZRM-u.

Komunikat „Brak dostępnych członków do przypisania" oznacza, że wszyscy członkowie stacji są już przypisani jako koordynatorzy tego ZRM-u (rzadki scenariusz).

Co widzi koordynator ZRM

Po wejściu w Budowanie grafiku (zob. Układanie grafiku) koordynator z delegacją:

  • Widzi pełną siatkę wszystkich ZRM-ów stacji (do kontekstu - np. żeby uniknąć konfliktów cross-ZRM).
  • W swoim ZRM-ie ma komórki edytowalne - może przypisywać i usuwać ratowników, walidować obsadę.
  • W cudzych ZRM-ach komórki są tylko do odczytu (- zamiast +).

To samo dotyczy dashboardu Mój ZRM (jeśli istnieje w menu) - koordynator widzi statystyki dyżurów i zamian dla zespołów, których jest koordynatorem.

Bezpieczeństwo na poziomie bazy

Kontrola dostępu nie jest tylko UI - jest egzekwowana na poziomie bazy danych przez Row-Level Security (RLS). Nawet bezpośrednie zapytanie do bazy (np. przez nieuczciwie zmodyfikowanego klienta) nie wyświetli ani nie zmodyfikuje danych, do których użytkownik nie ma uprawnień. Każdy zapis przechodzi przez polityki RLS, które weryfikują:

  • Czy użytkownik ma rolę w tej stacji (has_role_on_account).
  • Czy ma odpowiednie uprawnienie do akcji (np. schedule.manage, swap.approve, zrm_coordinators.manage).
  • W przypadku ZRM coordinators: czy edytowany ZRM jest na ich liście (can_manage_zrm_schedule).

To samo dotyczy odczytu - koordynator ZRM bez schedule.manage nie zobaczy listy zgłoszeń dyspozycyjności poza własnym ZRM-em (chyba że stacja udostępniła ją publicznie).

Co może pójść nie tak

  • Koordynator ZRM nie widzi przycisku edycji - sprawdź, czy stacja ma delegację włączoną dla jego ZRM-u. Domyślnie jest wyłączona.
  • Koordynator ZRM widzi cudze ZRM-y w trybie edycji - to oznaka problemu RLS. Skontaktuj się z supportem.
  • „Brak dostępnych członków" w dialogu przypisania koordynatora - wszyscy członkowie tego ZRM-u są już przypisani lub stacja nie ma jeszcze członków poza Tobą.
  • Audyt zmiany, której się nie spodziewasz - sprawdź changed_by. Każda zmiana ma autora; jeśli zobaczysz nieoczekiwanego użytkownika, prawdopodobnie ma uprawnienia, których nie chcesz mu nadawać. Cofnij delegację lub przepnij rolę.

Co dalej?