- Wiersz przypisuje konkretnemu użytkownikowi zgodę lub jej brak do jednej transakcji — niezależnie od uprawnień roli.
- Kolumna
TYPgrupuje uprawnienia rodzajami, na przykład osobno prawo odczytu i prawo zatwierdzania. - Indeks unikalny na czterech kolumnach wyklucza dwa sprzeczne wpisy dla tego samego uprawnienia.
- Sześć indeksów wynika z tego, że tabela jest odczytywana przy budowaniu każdego ekranu.
Do czego służy tabela [dbo].[_users_cfg]
Uprawnienia nadawane rolom sprawdzają się dopóty, dopóki wszyscy na danym stanowisku mają robić dokładnie to samo. W praktyce zdarzają się odstępstwa: jeden magazynier ma dodatkowo zatwierdzać korekty, jedna osoba z biura potrzebuje dostępu do zestawienia zastrzeżonego dla kierowników. Tabela [dbo].[_users_cfg] obsługuje właśnie te przypadki.
Wpis wiąże nazwę użytkownika z konkretną transakcją wskazaną w kolumnie PLIK i przypisuje jej wartość logiczną — zgodę albo jej brak. Kolumna TYP grupuje uprawnienia rodzajami, dzięki czemu jedna transakcja może mieć osobne zgody na odczyt, edycję i zatwierdzenie. Kolumna PRX wskazuje rolę, w kontekście której dane uprawnienie obowiązuje.
Mechanizm jest potężny i właśnie dlatego wymaga dyscypliny. Uprawnienie nadane pojedynczo omija cały porządek oparty na rolach: nie widać go przy przeglądaniu definicji roli, nie przenosi się przy zmianie stanowiska i nie znika, gdy osoba przestaje go potrzebować. Kilkanaście takich wpisów jest do opanowania; kilkaset sprawia, że nikt w firmie nie potrafi odpowiedzieć na pytanie, kto ma dostęp do czego.
RolaPodstawowy zakres uprawnień wynikający z przypisania do roli
Wpis szczegółowySprawdzenie, czy dla tego użytkownika i transakcji istnieje wyjątek
RozstrzygnięcieWartość logiczna wpisu decyduje o dostępie
SkutekTransakcja zostaje udostępniona albo zablokowana
Wpis szczegółowy działa poza porządkiem ról — nie widać go przy przeglądaniu definicji roli, do której należy użytkownik.
Budowa tabeli — wykaz kolumn
Dziewięć kolumn opisuje uprawnienie: kogo dotyczy, czego dotyczy i jaka jest jego wartość.
| Kolumna | Typ | Wymagana | Znaczenie |
|---|---|---|---|
ID_USERS_CFG | int liczba całkowita | tak | Unikalny identyfikator wiersza w tabeli |
OPIS | varchar(150) tekst do 150 znaków | nie | Opis znaczenia danego parametru |
PLIK | varchar(50) tekst do 50 znaków | tak | Nazwa transakcji - pliku |
PRX | varchar(5) tekst do 5 znaków | tak | Symbol PRX parametru - oznaczający rolę w której dany parametr znajduje zastosowanie |
ROLA | varchar(20) tekst do 20 znaków | nie | Rola systemowa |
TYP | varchar(50) tekst do 50 znaków | tak | Typ uprawnienia do grupowania parametrów |
USERGUID | uniqueidentifier identyfikator GUID | nie | kod ID rekordu - użytkownika, powiazany z tabelą użytkowników _users |
USERNAME | varchar(50) tekst do 50 znaków | tak | Nazwa użytkownika dla którego określane są uprawnienia |
WARTOSC | bit wartość logiczna 0/1 | tak | Oznaczenie uprawnienia użytkownika do uruchamiania danego parametru |
Kolumna USERGUID wiąże wpis z kontem w tabeli użytkowników trwałym identyfikatorem, podczas gdy USERNAME przechowuje sam login. Obecność obu pozwala zachować powiązanie mimo zmiany loginu, na przykład po zmianie nazwiska.
Indeksy i wydajność zapytań
Sześć indeksów to dużo jak na dziewięciokolumnową tabelę, ale wynika z częstotliwości jej odczytu.
| Indeks | Kolumny | Rodzaj |
|---|---|---|
PK__users_cfg | ID_USERS_CFG | klucz główny |
TYP | PLIK, TYP | zwykły |
USERNAME | USERNAME | zwykły |
USERNAME_PRX_PLIK | USERNAME, PRX, PLIK | zwykły |
USERNAME_PRX_TYP_PLIK | USERNAME, PRX, TYP, PLIK | unikalny |
USERNAME_ROLA_TYP_PLIK | USERNAME, ROLA, TYP, PLIK | zwykły |
Tabela jest sprawdzana przy budowaniu każdego ekranu, dla każdego użytkownika. Indeks USERNAME_PRX_TYP_PLIK jest przy tym unikalny i pełni podwójną rolę: obsługuje odczyt oraz wyklucza dwa sprzeczne wpisy dla tego samego uprawnienia. Bez niego dostęp zależałby od kolejności odczytu wierszy, czyli bywałby różny w kolejnych sesjach.
Uprawnienie szczegółowe czy nowa rola — jak wybrać
Każde odstępstwo od uprawnień roli da się obsłużyć na dwa sposoby. Wybór między nimi decyduje o tym, czy za rok da się jeszcze zrozumieć, kto ma dostęp do czego.
| Kryterium | Wpis szczegółowy | Nowa rola |
|---|---|---|
| Nakład pracy | Jeden wiersz, kilka sekund | Definicja roli i przypisanie uprawnień |
| Widoczność przy audycie | Ukryta — trzeba wiedzieć, gdzie szukać | Widoczna w przeglądzie ról |
| Zachowanie przy zmianie stanowiska | Zostaje, choć przestaje mieć uzasadnienie | Zmienia się razem z przypisaniem roli |
| Powielenie dla kolejnej osoby | Kolejny wiersz, i tak przy każdej | Wystarczy przypisać istniejącą rolę |
| Sensowne przy | Pojedynczym, tymczasowym wyjątku | Odstępstwie dotyczącym więcej niż jednej osoby |
Reguła praktyczna: drugi raz to samo uprawnienie nadawane pojedynczo jest sygnałem, że powinna powstać rola.
Największym problemem wpisów szczegółowych nie jest ich nadawanie, lecz odbieranie. Uprawnienie przyznane „na czas zastępstwa” nie ma daty wygaśnięcia i nikt o nim nie pamięta, gdy zastępstwo się kończy. Po dwóch latach lista takich wpisów opisuje uprawnienia, których uzasadnienia nikt już nie potrafi odtworzyć — a odebranie ich bez wiedzy, po co powstały, grozi zablokowaniem komuś pracy.
Jak korzystać z tabeli w praktyce
Przy nadawaniu uprawnień szczegółowych warto trzymać się poniższych zasad:
- Wypełniaj kolumnę
OPISzawsze — po roku to jedyna wskazówka, dlaczego dane uprawnienie zostało nadane. - Twórz nową rolę, gdy to samo odstępstwo dotyczy drugiej osoby; wpisy szczegółowe nie skalują się.
- Przeglądaj listę wpisów co najmniej raz w roku i odbieraj te, których nikt nie potrafi uzasadnić.
- Sprawdzaj wpisy przy zmianie stanowiska pracownika — nie zmieniają się razem z rolą i zwykle tracą uzasadnienie.
- Nie używaj tego mechanizmu do odbierania uprawnień wynikających z roli; lepiej poprawić samą rolę.
- Zestawiaj tę tabelę z listą aktywnych kont — wpisy dla osób, które odeszły, są martwe, ale zaciemniają obraz.
Wpisy szczegółowe wraz z informacją, czy dotyczą aktywnego konta i czy mają wypełniony opis:
SELECT c.USERNAME,
u.NAZWISKO,
c.PRX AS ROLA_KONTEKST,
c.TYP,
c.PLIK AS TRANSAKCJA,
c.WARTOSC,
ISNULL(NULLIF(c.OPIS, ''), '(brak uzasadnienia)') AS OPIS,
CASE WHEN u.USERNAME IS NULL THEN 'konto nie istnieje'
WHEN u.AKTYWNE = 0 THEN 'konto wyłączone'
ELSE '' END AS UWAGA
FROM dbo._users_cfg AS c
LEFT JOIN dbo._users AS u ON u.USERNAME = c.USERNAME
ORDER BY UWAGA DESC, c.USERNAME, c.TYP;Wiersze z adnotacją o nieistniejącym albo wyłączonym koncie warto usunąć w pierwszej kolejności — są martwe, a wydłużają każdy przegląd uprawnień.
Uprawnienia szczegółowe są narzędziem, które ratuje sytuację raz i komplikuje ją później dziesięć razy. Warto traktować każdy taki wpis jak dług: da się go zaciągnąć w kilka sekund, ale spłaca się go przy każdym kolejnym audycie uprawnień.
Powiązane tabele i dokumentacja
Uprawnienia szczegółowe uzupełniają porządek oparty na rolach opisany w poniższych tabelach: