Kurs Power BI: RLS: bezpieczeństwo na poziomie wiersza

W skrócieRLS (Row-Level Security) to zabezpieczenia na poziomie wiersza: ten sam raport pokazuje każdemu odbiorcy tylko jego dane. Na raporcie Nordvelli budujemy role statyczne i rolę dynamiczną z USERPRINCIPALNAME i tabelą mapującą, testujemy je przez Wyświetl jako i przypisujemy osobom w usłudze Power BI.

Masz w Nordvelli jeden raport sprzedaży: kartę z łączną sprzedażą 467,78 mln zł, tabelę sklepów i wykres miast. Teraz zarząd chce, żeby ten sam plik otwierali kierownicy piętnastu sklepów, ale każdy ma widzieć wyłącznie swój sklep, nie całą sieć. Piętnaście kopii raportu rozjedzie się przy pierwszej zmianie miary. Rozwiązaniem jest RLS, czyli zabezpieczenia na poziomie wiersza (po angielsku Row-Level Security). RLS filtruje dane zależnie od tego, kto ogląda raport, przy jednym wspólnym pliku i jednym modelu.

W tym rozdziale przejdziemy pełną ścieżkę na modelu Nordvelli: od roli statycznej dla jednego regionu, przez test roli bez publikowania, po dynamiczny RLS z funkcją USERPRINCIPALNAME i tabelą mapującą, w której jedna reguła obsługuje wszystkich kierowników. Pokażemy też pułapkę, w którą łatwo wpaść przy pierwszej roli dynamicznej: reguła jest aktywna, a raport dalej pokazuje całą sieć. Na końcu opublikujemy model, przypiszemy do roli osobę w usłudze Power BI i przejdziemy przez najczęstsze problemy, przez które ktoś widzi za dużo albo za mało.

Po co RLS i jak on działa

Co chcemy osiągnąć. Raport Nordvelli trafi do dyrektorów regionów i kierowników sklepów, a każdy z nich powinien widzieć tylko dane swojego regionu albo sklepu. Chcemy zapisać takie ograniczenie w samym modelu, zamiast budować osobny raport dla każdej osoby.

RLS to reguła bezpieczeństwa zapisana wewnątrz modelu danych. Definiujesz rolę i piszesz dla niej wyrażenie DAX, które dla każdego wiersza wybranej tabeli zwraca prawdę albo fałsz. Gdy osoba przypisana do roli otwiera raport, Power BI dokłada ten filtr do każdego zapytania, które wysyłają wizualizacje. Ta osoba nie widzi ani reguły, ani tego, że coś zostało odcięte: jej karty i wykresy po prostu pokazują liczby policzone na dozwolonych wierszach. Obraz nad tą sekcją pokazuje to na raporcie Nordvelli z rolą Sklep Warszawa.

Kluczowa rzecz, zanim napiszesz pierwszy filtr: w modelu gwiazdy filtr nakładasz na tabelę wymiaru, nie na tabelę faktów. W Nordvelli chcemy ograniczyć sprzedaż do wybranych sklepów. Nie piszemy więc reguły dla 108 675 wierszy FaktSprzedaz, tylko dla 15 wierszy DimSklepy. Relacja jeden do wielu między DimSklepy a FaktSprzedaz przenosi to ograniczenie dalej: jeśli w DimSklepy zostaną tylko sklepy krakowskie, przez relację po SklepID w FaktSprzedaz zostaną tylko ich transakcje. Filtr na wymiarze sprawdza mniej wierszy i płynie w naturalnym kierunku relacji.

Wyobraź sobie, że kierownik z Krakowa otwiera raport Nordvelli. Bez RLS jego karta sprzedaży pokazuje 467,78 mln zł, czyli całą sieć. Z rolą, która zostawia w DimSklepy tylko Kraków, ta sama karta i ta sama miara pokażą 50,48 mln zł z dwóch krakowskich sklepów. Raport się nie zmienia i nie ma żadnej kopii pliku. Cały mechanizm siedzi w modelu.

Role statyczne w oknie Zarządzaj rolami

Co chcemy osiągnąć. Dyrektor Regionu Południe w Nordvelli ma widzieć tylko sklepy ze swojego regionu. Chcemy zbudować dla niego rolę ze stałą regułą filtrującą.

Zaczynamy od najprostszego wariantu: rola statyczna, czyli jedna stała reguła na jedną rolę. Kolumna Region w DimSklepy ma sześć wartości: Centrum, Południe, Zachód, Północ, Wschód i Online. Region Południe to trzy sklepy: dwa w Krakowie i jeden w Katowicach. To dobry kandydat na filtr statyczny.

Otwórz plik startowy z bloku Pliki do tej lekcji (ma gotowy model gwiazdy i nie ma jeszcze żadnych ról) i przejdź do widoku modelu. Przycisk Zarządzaj rolami jest w grupie Zabezpieczenia na karcie Narzędzia główne. W widoku raportu ten sam przycisk znajdziesz na karcie Modelowanie. Obok jest Wyświetl jako, którym za chwilę sprawdzimy wynik.

Okno Zarządzaj rolami zabezpieczeń ma trzy kolumny: Role po lewej, Tabele w środku i Reguły po prawej. Kliknij Nowy nad listą ról. Power BI doda rolę o nazwie Bez tytułu. Nazwę zmienisz w menu trzech kropek przy roli, poleceniem Zmień nazwę: wpisz Region Południe. Nazwa jest ważna, bo w usłudze będziesz przypisywać do roli ludzi właśnie po niej. Potem kliknij DimSklepy na liście tabel, a w kolumnie Reguły przycisk Nowy. Pojawi się wiersz kreatora z trzema polami: Kolumna, Warunek i Wartość. Wybierz Region, zostaw warunek Równa Się i wpisz Południe. Na koniec kliknij Zapisz.

Kreator zapisuje regułę w modelu jako wyrażenie DAX. Sprawdziliśmy to w pliku z tej lekcji: reguła roli Region Południe ma postać:

[Region] == "Południe"

Podwójny znak równości to porównanie ścisłe. Różni się od zwykłego = tylko tym, że pusta wartość nie zrówna się z pustym tekstem ani z zerem. Ten sam warunek możesz wpisać sam w edytorze DAX, ze zwykłym =. Na danych Nordvelli wynik będzie identyczny, bo kolumna Region nie ma pustych wartości.

Reguła może być bogatsza niż pojedyncze porównanie. Załóżmy, że rola ma objąć dwa miasta i tylko salony flagowe (kolumna Typ ma w Nordvelli wartości Flagship, Standard, Compact i E-commerce). Kreator to zbuduje. Dodaj rolę Flagowce Kraków i Katowice, wybierz DimSklepy i dodaj dwie reguły. W pierwszej wybierz kolumnę Miasto, warunek W i wartości Kraków oraz Katowice (kolejne dokładasz przyciskiem Dodaj). W drugiej wybierz Typ, Równa Się i Flagship.

Tę samą regułę zapiszesz w edytorze DAX. Kliknij Przełącz do edytora języka DAX i wpisz:

[Miasto] IN { "Kraków", "Katowice" }
    && [Typ] = "Flagship"

W pliku tej lekcji są cztery role statyczne, a do jednego modelu możesz dodać ich dowolnie wiele. Tabela poniżej pokazuje, co każda z nich zostawia w danych Nordvelli. Liczby policzyliśmy na pliku z bloku Pliki do tej lekcji.

Zwróć uwagę na rolę Sklep Warszawa. Filtr po mieście obejmuje też sklep internetowy, bo w DimSklepy Nordvella Online ma miasto Warszawa. Jeśli rola ma dotyczyć tylko salonów, dołóż drugą regułę, na przykład Typ nie równa się E-commerce. Takie niespodzianki widać dopiero w danych, dlatego każdą rolę sprawdzamy podglądem.

Zobacz też: Szkolenie Power BI - Desktop, DAX i Online + Copilot

Test roli poleceniem Wyświetl jako

Co chcemy osiągnąć. Zanim raport z rolą trafi do dyrektora regionu, chcemy zobaczyć, co pokaże mu raport Nordvelli, bez publikowania i bez logowania na jego konto.

Nie publikuj roli, zanim nie sprawdzisz jej na własne oczy. Power BI Desktop ma do tego wbudowany podgląd. Przejdź do widoku raportu i na karcie Modelowanie kliknij Wyświetl jako (po angielsku View as). Otworzy się okno Wyświetl jako role z pozycjami Brak, Inni użytkownicy i listą Twoich ról. Zaznacz Region Południe i kliknij OK.

Nad raportem pojawi się jasny pasek z ikoną ostrzeżenia i napisem Oglądasz jako: Region Południe. To znak, że raport jest w trybie podglądu roli. Wszystkie wizualizacje przeliczają się natychmiast, jakby oglądał je ktoś z tej roli. Karta sprzedaży spada z 468 mln zł do 83 mln zł, liczba transakcji ze 109 tys. do 20 tys., a w tabeli zostają trzy sklepy: Katowice, Kraków Galeria i Kraków Stare Miasto. Jeśli liczby zgadzają się z tym, co ma widzieć dyrektor Południa, rola działa. Z podglądu wychodzisz przyciskiem Zatrzymaj wyświetlanie na prawym końcu paska.

Rola działa też na fragmentatorach. Rozwiń listę Miasto: zamiast jedenastu miast zobaczysz tylko Katowice i Kraków. Osoba z tą rolą nie dowie się z fragmentatora nawet tego, jakie inne miasta są w danych.

W oknie Wyświetl jako możesz zaznaczyć kilka ról naraz. Zaznacz Region Południe i Sklep Warszawa, kliknij OK. Pasek pokaże obie role, a raport sumę ich uprawnień: 306 mln zł, 71 tys. transakcji i siedem sklepów. Tak samo działa przypisanie jednej osoby do dwóch ról w usłudze Power BI: filtry ról łączą się operatorem lub.

Okno ma jeszcze opcję Inni użytkownicy z polem na adres e-mail. Przy rolach statycznych nie jest potrzebna. Przyda się przy roli dynamicznej, bo tam filtr zależy od tego, kto jest zalogowany, a w Desktopie bez podglądu funkcja USERPRINCIPALNAME zwraca nazwę konta Windows, na którym pracujesz (u nas POWERBI-KURS\powerbi). Wpisując adres testowego kierownika, symulujesz, że to on otwiera raport. Adres zatwierdź klawiszem Tab, a dopiero potem zaznacz rolę i kliknij OK. W naszych testach adres wpisany bez zatwierdzenia przepadał: pasek pokazywał samą rolę, bez adresu.

Dynamiczny RLS z USERPRINCIPALNAME i tabelą mapującą

Co chcemy osiągnąć. Nordvella ma piętnaście sklepów, każdy z własnym kierownikiem, a piętnaście osobnych ról trzeba by poprawiać przy każdej zmianie kadrowej. Chcemy jednej roli, która sama rozpozna zalogowaną osobę i pokaże jej tylko jej sklep.

Role statyczne są proste, ale nie skalują się. Dynamiczny RLS rozwiązuje to jedną rolą, która sama rozpoznaje, kto ogląda raport. Trzon mechanizmu to funkcja USERPRINCIPALNAME. W usłudze Power BI zwraca nazwę główną użytkownika (po angielsku user principal name, w skrócie UPN), czyli login konta Microsoft, którym ktoś się zalogował. Zwykle jest to jego adres e-mail.

Potrzebujesz jeszcze tabeli mapującej, która łączy adres kierownika z jego sklepem. W danych Nordvelli jej nie ma, więc dodajemy ją sami. Najprościej zbudować małą tabelę w samym Power BI: w widoku tabeli kliknij Nowa tabela na karcie Narzędzia tabel i wpisz wyrażenie z funkcją DATATABLE. W firmie takie dane trzymasz zwykle w arkuszu albo w bazie i wczytujesz przez Power Query, ale do nauki wystarczy tabela zapisana w DAX:

MapaManagerow = DATATABLE(
    "Email", STRING,
    "SklepID", INTEGER,
    {
        { "anna.wisniewska@nordvella.pl",    1 },
        { "piotr.nowak@nordvella.pl",        4 },
        { "tomasz.lewandowski@nordvella.pl", 6 },
        { "robert.kaminski@nordvella.pl",    8 },
        { "michal.wisniewski@nordvella.pl", 10 },
        { "sylwia.pietrzak@nordvella.pl",   15 }
    }
)

Tabela MapaManagerow ma dwie kolumny: Email (adres logowania do Power BI) i SklepID (ten sam klucz, którego używa DimSklepy). W pliku jest sześciu kierowników. W prawdziwym wdrożeniu dopiszesz tu wszystkich, po jednym wierszu na osobę. Teraz połącz tabelę z modelem: w widoku modelu przeciągnij SklepID z MapaManagerow na SklepID w DimSklepy. Otworzy się okno Nowa relacja.

Zmień ustawienia na Wiele do jednego (*:1) i Pojedyncza. Wiele do jednego, bo w prawdziwej firmie sklep może mieć dwóch kierowników albo zastępcę i wtedy ten sam SklepID pojawi się w mapie kilka razy. Pojedyncza, bo przy RLS chcemy jednego, przewidywalnego kierunku: filtr płynie od DimSklepy do MapaManagerow, nie odwrotnie. W następnej części zobaczysz, że ma to konsekwencje.

Reguła roli dynamicznej: filtr musi trafić na DimSklepy

Co chcemy osiągnąć. Mamy tabelę mapującą i relację. Teraz chcemy roli Manager sklepu, która kierownikowi z Krakowa pokaże tylko jego sklep. Zrobimy to w dwóch podejściach, bo pierwsze, najbardziej intuicyjne, nie działa, a warto zobaczyć dlaczego.

Podejście pierwsze: filtr na tabeli mapującej. W oknie Zarządzaj rolami utwórz rolę Manager sklepu, wybierz tabelę MapaManagerow, przełącz się do edytora DAX i wpisz regułę, która porównuje kolumnę Email z adresem zalogowanej osoby:

[Email] = USERPRINCIPALNAME()

Sprawdź to w podglądzie. Kliknij Wyświetl jako, zaznacz Inni użytkownicy i wpisz piotr.nowak@nordvella.pl. Naciśnij Tab, zaznacz Manager sklepu i kliknij OK.

Pasek potwierdza: Oglądasz jako: Manager sklepu, piotr.nowak@nordvella.pl. A raport dalej pokazuje 468 mln zł i 109 tys. transakcji, czyli całą sieć.

Dlaczego? Filtr zostawił w MapaManagerow jeden wiersz, ze sklepem 4. Relacja między MapaManagerow a DimSklepy ma kierunek Pojedyncza, od DimSklepy do MapaManagerow. Filtr z tabeli mapującej nie płynie więc w stronę DimSklepy, a bez tego nie dotrze do FaktSprzedaz. Częsta rada brzmi: ustaw kierunek Oba i zaznacz Zastosuj filtr zabezpieczeń w obu kierunkach. Sprawdziliśmy to na modelu Nordvelli: Power BI odmawia zapisu takiej relacji.

Podejście drugie, które działa: filtr wprost na DimSklepy. Tabelę mapującą czytamy wewnątrz reguły. W roli Manager sklepu wyczyść regułę na MapaManagerow, kliknij DimSklepy i w edytorze DAX wpisz:

DimSklepy[SklepID] IN
    SELECTCOLUMNS (
        FILTER ( MapaManagerow, MapaManagerow[Email] = USERPRINCIPALNAME () ),
        "SklepID", MapaManagerow[SklepID]
    )

Prześledźmy, co się dzieje, gdy raport otwiera kierownik Krakowa. USERPRINCIPALNAME zwraca piotr.nowak@nordvella.pl. FILTER zostawia w MapaManagerow wiersz z tym adresem, a SELECTCOLUMNS wyciąga z niego jedną kolumnę, SklepID, z wartością 4. Reguła sprawdza dla każdego sklepu, czy jego numer jest na tej liście (operator IN), więc w DimSklepy zostaje tylko sklep 4, Nordvella Kraków Stare Miasto. Dalej działa zwykła relacja DimSklepy do FaktSprzedaz. Relacja z MapaManagerow może zostać jednokierunkowa, bo filtr nie musi przez nią przechodzić.

Ta sama rola obsłuży każdego kierownika z mapy. Tabela poniżej pokazuje, co zobaczy każdy adres z pliku tej lekcji:

Zwróć uwagę na ostatni wiersz. Jeśli ktoś zaloguje się adresem, którego nie ma w MapaManagerow, lista numerów sklepów będzie pusta i raport też. To poprawne zachowanie, ale bywa mylące. Gdy dyrektor sprzedaży ma widzieć całą sieć, potrzebuje osobnego warunku. Najprościej dodać małą tabelę z adresami dyrektorów:

TabelaDyrektorow =
DATATABLE (
    "Email", STRING,
    { { "dyrektor@nordvella.pl" } }
)

i dopisać ją do reguły roli Manager sklepu operatorem lub:

VAR ZalogowanyEmail = USERPRINCIPALNAME ()
VAR CzyDyrektor =
    CONTAINS ( TabelaDyrektorow, TabelaDyrektorow[Email], ZalogowanyEmail )
RETURN
    CzyDyrektor
        || DimSklepy[SklepID]
            IN SELECTCOLUMNS (
                FILTER ( MapaManagerow, MapaManagerow[Email] = ZalogowanyEmail ),
                "SklepID", MapaManagerow[SklepID]
            )

Czytaj to tak: adres zalogowanej osoby trafia do zmiennej ZalogowanyEmail. CONTAINS sprawdza, czy ten adres jest w tabeli TabelaDyrektorow. Jeśli tak, CzyDyrektor jest prawdą dla każdego wiersza DimSklepy, więc dyrektor widzi wszystkie sklepy. Jeśli nie, decyduje część po operatorze lub (||), czyli ta sama lista sklepów z mapy co wcześniej. Tabeli TabelaDyrektorow nie ma w pliku do pobrania. Sprawdziliśmy ten wariant na tymczasowej tabeli z jednym adresem: dyrektor@nordvella.pl zobaczył całą sieć (467 775 009 zł), a piotr.nowak@nordvella.pl dalej tylko swój sklep (31 545 740 zł).

Role w usłudze Power BI: osoby i grupy

Co chcemy osiągnąć. Rola z Desktopu nikogo nie ogranicza, dopóki nie przypiszemy do niej ludzi w usłudze Power BI. Chcemy przypisać do ról Nordvelli osoby albo grupy tak, żeby zmiany kadrowe nie wymagały poprawiania raportu.

Najpierw publikacja. Zapisz plik, na karcie Narzędzia główne kliknij Opublikuj i wybierz obszar roboczy. My publikujemy do obszaru Nordvella Zarzad.

W usłudze otwórz obszar roboczy. Po publikacji są w nim dwa elementy o tej samej nazwie: raport i model semantyczny. Role należą do modelu, więc przy modelu nordvella_21_rls kliknij Więcej opcji (trzy kropki) i wybierz Zabezpieczenia.

Otworzy się strona Zabezpieczenia na poziomie wiersza. Po lewej jest lista ról z Desktopu, przy każdej liczba członków w nawiasie. Kliknij rolę, a po prawej w polu Osoby lub grupy należące do tej roli wpisz adres e-mail albo nazwę grupy, kliknij Dodaj, a na koniec Zapisz. W naszym środowisku demo nie ma grup, więc do roli Region Południe dodaliśmy jedno konto testowe, Martę Wiśniewską.

Tu podejmujesz ważną decyzję: przypisywać ludzi pojedynczo czy przez grupę. Przy stałej strukturze lepiej przez grupę zabezpieczeń z katalogu firmowego (Microsoft Entra ID). Zamiast dodawać do roli Region Południe kolejne osoby, dodajesz jedną grupę, na przykład Nordvella-Region-Poludnie. Gdy ktoś dołącza do zespołu albo odchodzi, administrator zmienia skład grupy w jednym miejscu, a uprawnienia w raporcie idą za tym same.

Rolę sprawdzisz też w usłudze, na dokładnie tym modelu, który widzą odbiorcy. Na stronie Zabezpieczenia na poziomie wiersza najedź na rolę, kliknij trzy kropki, które pojawią się obok jej nazwy, i wybierz Testuj jako rola. Raport otworzy się z zielonym paskiem u góry.

Od zapisu RLS działa w usłudze dla osób przypisanych do ról, gdy dostają raport przez udostępnienie, przez aplikację albo jako odbiorcy w obszarze roboczym. Jest jeden ważny wyjątek, o którym w następnej części: role obszaru roboczego wyższe niż Osoba przeglądająca omijają RLS.

Częste problemy z RLS i jak je rozwiązać

Co chcemy osiągnąć. Przy testach RLS w Nordvelli zdarza się, że ktoś widzi za dużo danych albo pusty raport. Chcemy umieć szybko znaleźć przyczynę każdego z czterech najczęstszych problemów.

RLS rzadko sprawia kłopot przy budowaniu. Kłopoty wychodzą przy testach, kiedy ktoś nagle widzi za dużo albo za mało. Przejdźmy przez cztery pułapki i sposób ich rozbrojenia na modelu Nordvelli.

Użytkownik widzi wszystkie dane mimo roli

Najczęstsza przyczyna: ta osoba ma w obszarze roboczym rolę Administrator, Członek albo Współautor. Te role omijają RLS, bo służą do edytowania, a nie tylko do czytania. Rozwiązanie: odbiorcy raportu mają być w obszarze w roli Osoba przeglądająca albo dostawać raport przez aplikację lub udostępnienie. Druga przyczyna to reguła, której filtr nie dochodzi do faktów. Przykład znasz z tej lekcji: reguła na MapaManagerow była aktywna, a raport pokazywał 468 mln zł. Trzecia: osoba należy do dwóch ról, a jedna z nich daje szeroki dostęp. Filtry ról się sumują, więc wygrywa ta szersza. W każdym z tych przypadków zacznij od podglądu Wyświetl jako z adresem tej osoby i sprawdź, ile wierszy zostaje w DimSklepy.

Filtr nie przechodzi na tabelę faktów

Nakładasz filtr na DimSklepy, ale FaktSprzedaz pokazuje pełne liczby. Powodem jest brak relacji, relacja nieaktywna albo połączenie po złej kolumnie. RLS filtruje wymiar, a resztę przenosi relacja od wymiaru do faktów. Sprawdź w widoku modelu, czy relacja DimSklepy do FaktSprzedaz istnieje i czy jest aktywna (linia ciągła, nie przerywana). Kierunek filtrowania zostaw pojedynczy: filtrowanie w obie strony potrafi przenieść ograniczenie z jednego wymiaru na drugi i dać wyniki, których się nie spodziewasz.

Dynamiczny RLS zwraca pusty raport

Kierownik loguje się i widzi kreski we wszystkich kartach. Najczęściej to niedopasowanie adresu: wartość w kolumnie Email różni się od tego, co zwraca USERPRINCIPALNAME (literówka, spacja na końcu albo inna domena). W Desktopie ten sam objaw daje adres, który nie został przyjęty w oknie Wyświetl jako: pasek pokazuje wtedy samą rolę, bez adresu.

Najszybciej sprawdzisz to w widoku zapytań DAX (czwarta ikona na pasku po lewej). Ten widok działa także w trybie podglądu roli, więc pokazuje dokładnie to, co widzi silnik pod rolą. Uruchom zapytanie:

EVALUATE
ROW (
    "Zalogowany", USERPRINCIPALNAME (),
    "Sklepy widoczne", COUNTROWS ( DimSklepy ) + 0,
    "Wiersze mapy", COUNTROWS ( MapaManagerow ) + 0
)

Dopisek + 0 zamienia pusty wynik na zero, żeby brak wierszy był widoczny od razu.

Jeśli pod rolą Sklepy widoczne pokazuje 0, sprawdź, czy adres z pierwszej kolumny jest w tabeli mapującej. Listę wszystkich adresów z nazwami sklepów wypisze drugie zapytanie. Uruchom je bez podglądu roli, bo pod rolą zobaczysz tylko wiersz zalogowanej osoby:

EVALUATE
SELECTCOLUMNS (
    MapaManagerow,
    "Email", MapaManagerow[Email],
    "SklepID", MapaManagerow[SklepID],
    "Nazwa sklepu", RELATED ( DimSklepy[Nazwa] )
)
ORDER BY [SklepID]

Miara sumy całej sieci przestaje pokazywać całość

Czasem raport ma pokazywać kierownikowi jego sprzedaż obok średniej sieci, do porównania. Zwykła miara policzy tylko widoczne wiersze, bo RLS ogranicza każde zapytanie. Sam DAX nie obejdzie RLS: pod rolą Manager sklepu dla piotr.nowak@nordvella.pl wyrażenie CALCULATE ( [Łączna sprzedaż], ALL ( DimSklepy ) ) zwraca 31 545 740 zł, tyle samo co zwykła miara. ALL zdejmuje filtry raportu, ale nie filtr roli.

Uczciwe porównanie da się zbudować bez łamania zasad bezpieczeństwa. Wykorzystaj to, co widać na zrzucie z widoku tabeli: tabele i kolumny obliczeniowe Power BI liczy przy odświeżaniu danych, poza RLS. Dodaj tabelę obliczeniową (Nowa tabela), która przy każdym sklepie zapisze od razu średnią całej sieci:

BenchmarkSieci =
VAR Sklepy =
    ADDCOLUMNS (
        VALUES ( DimSklepy[SklepID] ),
        "SprzedazSklepu", [Łączna sprzedaż]
    )
VAR SredniaSieci = AVERAGEX ( Sklepy, [SprzedazSklepu] )
RETURN
    ADDCOLUMNS ( Sklepy, "SredniaSieci", SredniaSieci )

Połącz BenchmarkSieci z DimSklepy po SklepID (Wiele do jednego, Pojedyncza). Rola Manager sklepu zostawi w niej tylko wiersz sklepu zalogowanej osoby, a w tym wierszu jest już średnia całej sieci. Relacja jest tu konieczna: bez niej BenchmarkSieci nie podlega roli i każdy zobaczyłby sprzedaż wszystkich sklepów. Wynik sprawdzisz pod rolą w widoku zapytań DAX:

EVALUATE
ROW (
    "Moja sprzedaż", [Łączna sprzedaż],
    "Z ALL ( DimSklepy )", CALCULATE ( [Łączna sprzedaż], ALL ( DimSklepy ) ),
    "Średnia sieci", MAX ( BenchmarkSieci[SredniaSieci] ),
    "Wiersze benchmarku", COUNTROWS ( BenchmarkSieci )
)

U nas dla piotr.nowak@nordvella.pl wyszło: 31 545 740 zł, 31 545 740 zł, 31 185 001 zł i 1 wiersz. Średnia to 467 775 009 zł podzielone przez 15 sklepów. Kierownik widzi swoją sprzedaż i średnią sieci, ale nie sprzedaż pozostałych sklepów. Tabeli BenchmarkSieci nie ma w pliku do pobrania, dodaj ją sam, jeśli chcesz przećwiczyć ten wzorzec. Po dodaniu relacji Power BI może poprosić o ręczne odświeżenie (pasek z przyciskiem Odśwież teraz): kliknij go przed włączeniem podglądu roli, nie w trakcie.

✕