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).
Każda zmiana w grafiku - utworzenie dyżuru, zmiana ratownika, anulowanie, zatwierdzenie zamiany, korekta godzin - trafia automatycznie do rejestru. Wpis zawiera:
created (utworzono), updated (zaktualizowano: zmiana ratownika lub statusu), deleted (usunięto), cancelled (anulowano), swapped (zamiana).user_id poprzedniego ratownika, status planned).Rejestr jest append-only - użytkownicy aplikacji nie mogą dopisywać, edytować ani usuwać jego wpisów. Historia stacji jest usuwana dopiero razem z całą stacją, zgodnie z zasadami retencji danych.
Podstawowe 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. Zaufane RPC mogą dopisać dodatkowy kontekst operacyjny, np. rodzaj zatwierdzonej zamiany; również te wpisy przechodzą przez trigger normalizujący kontekst stacji i okresu. Nie da się zmodyfikować dyżuru bez śladu.
Rejestr operacyjny pokazuje wyłącznie zweryfikowane wpisy utworzone po uruchomieniu tej funkcji. Starsze techniczne rekordy nie miały wiarygodnego znacznika pochodzenia, dlatego nie są przedstawiane jako materiał dowodowy.
Użytkownik z uprawnieniem schedule.manage otwiera rejestr przez Administracja → Rejestr operacyjny. Na ekranie może:
Rejestr pokazuje najnowsze zdarzenia jako pierwsze. Przycisk „Pokaż starsze zdarzenia" ładuje kolejną część historii bez ryzyka pominięcia wpisów dodanych równolegle.
Eksport obejmuje dokładnie te zdarzenia, które przechodzą przez aktualnie ustawione filtry, i jest ograniczony do 10 000 najnowszych zdarzeń. Jeśli filtrom odpowiada więcej wpisów, plik zawiera 10 000 ostatnich, a na jego końcu dochodzi dodatkowy wiersz z adnotacją o ograniczeniu eksportu (trafia ona do kolumny „Zmiany przed/po"). Brak takiego wiersza oznacza, że w pliku jest komplet zdarzeń pasujących do filtrów.
Gdy zobaczysz tę adnotację, zawęź filtry - najwygodniej okresem grafikowym albo zakresem dat dyżurów - i pobierz historię w kilku plikach.
raTool nie wymaga rozbudowanej struktury organizacyjnej. Dla większości stacji wystarczają trzy poziomy:
Każda osoba może mieć kilka ról jednocześnie - np. ratownik, który dla jednego ZRM-u jest delegowanym koordynatorem.
Strona Koordynatorzy ZRM (menu Administracja → Koordynatorzy ZRM) jest dostępna dla użytkowników z uprawnieniem zrm_coordinators.manage (typowo: koordynator stacji).
Każdy aktywny ZRM ma osobną kartę, na której widzisz:
swap.approve), ale nie modyfikują obsady.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).
Po wejściu w Budowanie grafiku (zob. Układanie grafiku) koordynator z delegacją:
- 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.
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ą:
has_role_on_account).schedule.manage, swap.approve, zrm_coordinators.manage).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).