Do czego służy RLS w Power BI
W międzynarodowej sieci handlowej raport sprzedaży zwykle zaczyna życie jako jeden plik dla centrali. Potem prosi o niego zespół w Polsce, później w Czechach i w Niemczech, i pojawia się pokusa, żeby zrobić kopię dla każdego rynku. Po kilku miesiącach jest kilka wersji tego samego raportu, każda z trochę inną definicją sell-through, a poprawka w jednej nie trafia do pozostałych.
Zabezpieczenia na poziomie wiersza rozwiązują ten problem od strony danych. Raport i model semantyczny są jedne, a Power BI filtruje wiersze w zależności od tego, kto go otwiera. Kierownik sprzedaży w Polsce widzi tylko polskie sklepy i polski e-commerce, zespół w Czechach – tylko czeskie, a centrala – wszystko. Wszyscy korzystają z tych samych miar, tej samej logiki i tego samego harmonogramu odświeżania.
RLS działa na poziomie modelu, a nie wizualizacji. Ograniczenie obowiązuje więc w każdym miejscu, w którym ktoś sięga do danych: na stronach raportu, w eksporcie do Excela, w funkcji „Analizuj w programie Excel” i w nowych raportach zbudowanych na tym samym modelu. Filtr w wizualizacji albo ukryta strona tego nie gwarantują.
Statyczny i dynamiczny RLS dla rynków
Są dwa sposoby budowania ról. W statycznym RLS każda rola ma na sztywno wpisany filtr, na przykład rola „Polska” z warunkiem kod rynku = „PL”. W dynamicznym RLS jest jedna rola, a filtr sam dobiera dane do zalogowanej osoby na podstawie tabeli uprawnień i funkcji USERPRINCIPALNAME(), która zwraca jej adres logowania.
| Cecha | Statyczny RLS | Dynamiczny RLS |
|---|---|---|
| Liczba ról | Jedna na rynek | Jedna dla wszystkich |
| Gdzie są uprawnienia | W definicji ról w pliku | W tabeli uprawnień w danych |
| Nowy rynek | Nowa rola i ponowna publikacja | Nowy wiersz w tabeli uprawnień |
| Osoba z kilkoma rynkami | Członek kilku ról | Kilka wierszy w tabeli |
| Kiedy wybrać | Kilka stałych rynków | Wiele rynków lub częste zmiany |
Moja reguła kciuka: przy trzech–czterech rynkach i stabilnym zespole statyczne role są prostsze i łatwiejsze do sprawdzenia. Gdy rynków jest więcej, gdy ludzie często zmieniają zakres odpowiedzialności albo gdy dostęp ma zależeć także od kategorii czy kanału, wybieram dynamiczny RLS. Zmiana uprawnień sprowadza się wtedy do edycji tabeli, bez dotykania pliku raportu.
Role rynków w Power BI krok po kroku
Warunkiem jest poprawny model: tabela wymiaru rynku (albo sklepu z kolumną rynku) połączona relacją jeden do wielu z tabelami faktów sprzedaży, zapasów i planu. Filtr założony na wymiar przepływa wtedy relacjami do wszystkich faktów. Konfiguracja wygląda tak:
- Krok 1. W Power BI Desktop, na karcie Modelowanie, wybierz „Zarządzaj rolami” i utwórz rolę.
- Krok 2. Wskaż tabelę wymiaru rynku i wpisz wyrażenie DAX, które zwraca prawdę dla wierszy, jakie rola ma widzieć.
- Krok 3. Sprawdź rolę opcją „Wyświetl jako” (szczegóły w kolejnej sekcji) i opublikuj raport w usłudze Power BI.
- Krok 4. W usłudze otwórz ustawienia zabezpieczeń modelu semantycznego i przypisz do ról użytkowników albo grupy zabezpieczeń.
- Krok 5. Udostępnij raport odbiorcom z rolą przeglądającego w obszarze roboczym albo przez aplikację.
-- Rola statyczna „Polska”, filtr na tabeli Rynek
[KodRynku] = "PL"
-- Rola dynamiczna „Rynki”, filtr na tabeli Rynek
[KodRynku]
IN CALCULATETABLE (
VALUES ( Uprawnienia[KodRynku] ),
Uprawnienia[Email] = USERPRINCIPALNAME ()
)
-- Ta sama rola, filtr na tabeli Uprawnienia (każdy widzi tylko swoje wiersze)
[Email] = USERPRINCIPALNAME ()Tabela uprawnień ma dwie kolumny: adres e-mail użytkownika i kod rynku. Osoba odpowiedzialna za dwa rynki ma dwa wiersze. Tabelę najlepiej trzymać poza plikiem raportu, na przykład w pliku SharePoint albo w bazie danych, i ukryć ją w widoku raportu. Nie łączę jej relacją z resztą modelu: wyrażenie z CALCULATETABLE samo wybiera dozwolone rynki, więc nie trzeba włączać relacji dwukierunkowych, które spowalniają model i łatwo wprowadzają niejednoznaczne ścieżki filtrów.
Ten sam wzorzec rozszerza się na inne wymiary. Jeśli kierownik e-commerce na danym rynku ma widzieć tylko sprzedaż internetową, tabela uprawnień dostaje trzecią kolumnę z kanałem, a rola – drugi, analogiczny filtr na tabeli kanałów. Filtry na różnych tabelach w jednej roli działają łącznie, więc użytkownik widzi tylko wiersze spełniające oba warunki. Zanim dodam kolejny wymiar, sprawdzam jednak, czy to naprawdę kwestia uprawnień, a nie wygody, bo do tego wystarczy domyślny filtr raportu.
Centrala, która ma widzieć wszystkie rynki, dostaje osobną rolę bez filtra. Role w Power BI się sumują: jeśli ktoś należy do dwóch ról, widzi wszystkie wiersze dozwolone w którejkolwiek z nich. Dlatego nie da się rolą „odebrać” dostępu nadanego inną rolą, a przypisania warto utrzymywać przez grupy zabezpieczeń, a nie pojedyncze osoby.
Jak przetestować RLS w Power BI
Testowanie to etap, którego nie warto skracać, bo błąd w RLS oznacza, że ktoś widzi dane, których nie powinien, albo nie widzi swoich. Sprawdzam role w dwóch miejscach.
- W Power BI Desktop: na karcie Modelowanie wybierz „Wyświetl jako” i zaznacz rolę. Dla dynamicznego RLS zaznacz także opcję innego użytkownika i wpisz adres e-mail z tabeli uprawnień, bo USERPRINCIPALNAME() zwraca inaczej Twój własny adres.
- W usłudze Power BI: w ustawieniach zabezpieczeń modelu semantycznego wybierz rolę i funkcję „Testuj jako rolę”. Raport otworzy się tak, jak zobaczy go członek tej roli.
- Porównaj sumy: sprzedaż widoczna dla każdej roli powinna równać się sumie dla danego rynku w raporcie centrali, a suma wszystkich rynków – wynikowi całej firmy.
- Sprawdź przypadek brzegowy: osobę spoza tabeli uprawnień. Powinna zobaczyć pusty raport, a nie wszystkie dane.
Najczęstsze zaskoczenie przy testach po publikacji: autor raportu widzi wszystko, mimo że jest przypisany do roli. To nie błąd. RLS nie ogranicza osób, które mają w obszarze roboczym rolę administratora, członka ani współautora, bo mogą one edytować model. Filtry działają dla odbiorców z rolą przeglądającego i dla osób, którym raport udostępniono lub które korzystają z aplikacji.
Najczęstsze błędy przy wdrażaniu RLS w Power BI
- Filtr założony na tabelę faktów zamiast na wymiar. Działa, ale jest wolniejszy i nie obejmuje planu ani zapasów, jeśli leżą w osobnych tabelach.
- Tabela faktów bez relacji z wymiarem rynku, na przykład plik z planem dołączony później. Rola go nie filtruje i każdy widzi plan wszystkich rynków.
- Odbiorcy dodani do obszaru roboczego jako członkowie, a nie przeglądający, przez co RLS ich nie obejmuje.
- Adresy w tabeli uprawnień zapisane inaczej niż login, na przykład alias zamiast głównego adresu. Użytkownik widzi wtedy pusty raport.
- Miary z udziałem w wyniku całej firmy. Funkcja ALL w DAX nie omija RLS, więc udział rynku liczony od sumy wszystkich rynków zwraca 100%. Jeśli rynki mają widzieć swój udział, wynik całej firmy trzeba dostarczyć w osobnej, zagregowanej tabeli, której RLS nie filtruje.
RLS ogranicza wiersze, ale nie ukrywa tabel ani kolumn. Jeśli część zespołów nie powinna widzieć na przykład kosztu zakupu i marży, potrzebne są zabezpieczenia na poziomie obiektów (OLS) albo osobny model. To decyzja, którą warto podjąć razem z projektem raportu, a nie po jego publikacji. Więcej o tym, jak zaplanować strony raportu sprzedaży, piszę w artykule o dashboardach w Power BI.
Jeśli przygotowujesz raport dla kilku rynków i chcesz od początku ułożyć model i uprawnienia tak, żeby jeden plik obsłużył wszystkie zespoły, umów konsultację – odpowiadam w ciągu jednego dnia roboczego.