Zarządzanie bezpieczeństwem przy użyciu instrukcji Section Access

Section Access służy do kontrolowania bezpieczeństwa aplikacji. Zasadniczo jest to część skryptu ładowania danych, w której dodaje się tabelę zabezpieczeń, aby określić, co kto może zobaczyć. Qlik Sense wykorzystuje te informacje do zredukowania danych do odpowiedniego zakresu, gdy użytkownik otwiera aplikację. Oznacza to, że niektóre dane w aplikacji są ukrywane przed użytkownikiem na podstawie jego tożsamości. Instrukcja Section Access jest ściśle zintegrowana z danymi w aplikacji i polega na nich w kwestii kontroli dostępu. Ta forma dynamicznej redukcji danych może być stosowana do wierszy tabeli, kolumn lub ich kombinacji. Aby uzyskać więcej informacji, odwiedź stronę Zaufanie i bezpieczeństwo w Qlik.

Sekcje w skrypcie ładowania.

Zarządzanie kontrolą dostępu do danych odbywa się z wykorzystaniem jednej lub większej liczby tabel zabezpieczeń, które są ładowane w taki sam sposób jak zwykłe dane. Dzięki temu można przechowywać te tabele w standardowej bazie danych lub w arkuszu kalkulacyjnym. Instrukcje skryptu używane do zarządzania tabelami zabezpieczeń są podane w sekcji autoryzacji, inicjowanej w skrypcie instrukcją Section Access.

Jeśli skrypt zawiera definicję sekcji autoryzacji, część skryptu ładująca dane aplikacji musi znajdować się w odrębnej sekcji, zainicjowanej instrukcją Section Application.

Przykład:

Section Access; Load * INLINE [ ACCESS, USERID, REDUCTION USER, AD_DOMAIN\ADMIN, * USER, AD_DOMAIN\A, 1 USER, AD_DOMAIN\B, 2 USER, AD_DOMAIN\C, 3 ADMIN, INTERNAL\SA_SCHEDULER, ]; Section Application; T1: Load *, NUM AS REDUCTION; LOAD Chr(RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

Należy pamiętać, że po wprowadzeniu zmian w skrypcie ładowania trzeba zawsze załadować dane, aby zmiany zostały zastosowane.

Pola systemowe w instrukcji Section Access

Poziomy dostępu są przypisywane użytkownikom w jednej lub kilku tabelach zabezpieczeń ładowanych w części Section Access skryptu. Tabele te muszą zawierać co najmniej dwa pola systemowe: ACCESS, czyli pole określające poziom dostępu i USERID lub USER.EMAIL . Inne opcjonalne pola systemowe można dodać w zależności od przypadku. Poniżej opisano pełny zestaw pól systemowych instrukcji Section Access.

ACCESS

Określa poziom dostępu danego użytkownika.

Uprawienia dostępu do aplikacji w Qlik Sense można przyznawać określonym użytkownikom. W tabeli zabezpieczeń każdy użytkownik może mieć jeden z dwóch poziomów dostępu: ADMIN lub USER. Użytkownik z uprawnieniami ADMIN ma dostęp do wszystkich danych w aplikacji, chyba że ogranicza to tabela zabezpieczeń. Użytkownik z uprawnieniami USER ma dostęp do danych jedynie w zakresie zdefiniowanym w tabeli zabezpieczeń. Jeśli użytkownikowi nie zostanie przypisany żaden poprawny poziom dostępu, nie będzie on mógł otworzyć danej aplikacji.

Jeżeli instrukcja Section Access zostanie użyta w scenariuszu ładowania, użytkownik usługi harmonogramu INTERNAL\SA_SCHEDULER będzie potrzebować dostępu z uprawnieniami ADMIN do wykonywania operacji ładowania. Na przykład:

Section Access; LOAD * inline [ ACCESS, USERID ADMIN, INTERNAL\SA_SCHEDULER ];

Jeżeli nie chcesz używać konta INTERNAL\SA_SCHEDULER, zobacz temat Używanie personifikacji do ładowania danych, w którym przedstawiono metodę alternatywną.

Jeśli instrukcja Dostęp do sekcji jest używana w scenariuszu generowania aplikacji On-demand (ODAG) w aplikacji szablonu, użytkownik INTERNAL\SA_API musi zostać uwzględniony jako ADMIN w tabeli Dostęp do sekcji. Na przykład:

Section Access; LOAD * inline [ ACCESS, USERID ADMIN, INTERNAL\SA_API ];

USERID

Zawiera ciąg znaków odpowiadający nazwie domeny Qlik Sense i nazwie użytkownika. Program Qlik Sense pobierze dane logowania z usługi proxy i porówna je z wartością w tym polu.

Znak wieloznaczny (*) jest interpretowany jako wszyscy użytkownicy, z zastrzeżeniem dalszych warunków określonych w tabeli zabezpieczeń. Na przykład w poniższej tabeli zabezpieczeń użytkownicy należący do grupy Qlik Sense Tenant Admins mogą zobaczyć wszystkie wymienione wartości REDUCTION.

Section Access; LOAD * INLINE [ ACCESS, USERID, GROUP, REDUCTION ADMIN, *, Qlik Sense Tenant Admins, * USER, QLIK-POC\SOMEOTHERUSER1, *, 1 USER, QLIK-POC\SOMEOTHERUSER2, *, 2 ... ];

USERID oraz NTNAME używają tych samych danych uwierzytelniających, zatem sprawdzenie obu elementów w tym samym wierszu tabeli zabezpieczeń nie jest konieczne. Różnica między tymi dwoma polami polega na tym, że NTNAME sprawdza także grupy.

NTNAME

NTNAME jest starszą wersją pola QlikView i zaleca się używanie USERID, jeśli QlikView nie używa tej samej tabeli zabezpieczeń.

Pole, które powinno zawierać ciąg znaków odpowiadający nazwie użytkownika lub grupy domeny systemu Windows NT. Jeśli wykorzystywany jest inny system uwierzytelniania, powinien zawierać nazwę zweryfikowanego użytkownika. Qlik Sense pobierze dane logowania z systemu operacyjnego i porówna je z wartościami w tym polu.

GROUP

Zawiera ciąg znaków odpowiadający grupie w programie Qlik Sense. Program Qlik Sense rozpozna dane użytkownika dostarczone przez usługę proxy względem tej grupy.

SERIAL

SERIAL to starsze pole QlikView i nie jest ono używane, jeśli korzystasz tylko z Qlik Sense.

Zawiera ciąg znaków odpowiadający platformie. Jeśli pole zawiera ciąg znaków ‘QLIKSENSE’ lub symbol wieloznaczny ‘*’, dostęp może zostać przyznany w zależności od innych pól w tabeli zabezpieczeń.

Jeśli pole SERIAL zawiera numer licencji, wiersz Dostęp do sekcji odmówi dostępu do dokumentu. To ustawienie jest prawidłowe tylko w QlikView.

OMIT

Zawiera nazwę pola, które ma zostać pominięte w odniesieniu do danego użytkownika. Pole może zawierać symbole wieloznaczne lub być puste.

Zalecane jest, aby nie stosować OMIT w przypadku pól kluczowych. Pola klucza, które są pomijane, są widoczne w przeglądarce modelu danych, ale ich zawartość jest niedostępna, co może być mylące dla użytkownika. Ponadto zastosowanie pola OMIT względem pól używanych w wizualizacji może spowodować, że wizualizacja będzie niekompletna dla użytkowników, którzy nie mają dostępu do pól pominiętych.

Zarządzanie dostępem użytkownika do aplikacji

Do ograniczenia dostępu do aplikacji określonym użytkownikom można użyć instrukcji Section Access w jej najprostszej formie. Użytkownicy nie mają dostępu do aplikacji przez wykluczenie. Innymi słowy, jeśli określony identyfikator użytkownika nie zostanie wymieniony w tabeli zabezpieczeń, dany użytkownik nie będzie mógł uzyskać dostępu do aplikacji. Jedynym wyjątkiem od tej reguły jest sytuacja, w której symbol wieloznaczny (*) zostanie przypisany do pola USERID w jednym z wierszy tabeli zabezpieczeń. W tym przypadku symbol wieloznaczny oznacza, że wszyscy uwierzytelnieni użytkownicy mają dostęp do aplikacji. Oto przykład tabeli zabezpieczeń z listą identyfikatorów użytkowników:

Section Access; LOAD * inline [ ACCESS, USERID ADMIN, AD_DOMAIN\ADMIN USER, AD_DOMAIN\A USER, AD_DOMAIN\B ]; Section Application;

Zarządzanie dostępem użytkownika do określonych danych w aplikacji

Dynamiczna redukcja danych ogranicza dostęp do wierszy i kolumn w tabelach danych w aplikacjach Qlik Sense po autoryzacji użytkownika w celu uzyskania dostępu do samej aplikacji.

Zarządzanie dostępem do danych na poziomie wiersza

Dostęp do danych na poziomie wiersza można ograniczyć, dodając kolumnę redukcji danych do tabeli zabezpieczeń w sekcji dostępu skryptu ładowania. Określone rekordy (wiersze) można ukrywać przed użytkownikami przez powiązanie danych instrukcji Section Access z rzeczywistymi danymi. Kontrolowanie zakresu danych wyświetlanych lub wykluczanych polega na używaniu pól redukcji o takich samych nazwach w częściach Section Access i Section Application skryptu. Po zalogowaniu użytkownika program Qlik Sense dopasuje wybory w polach redukcji w sekcji dostępu do pól o identycznych nazwach w sekcji aplikacji (nazwy pól muszą być zapisane wielkimi literami). Po dokonaniu wyborów program Qlik Sense trwale ukryje przed użytkownikiem wszystkie dane wykluczone na podstawie tych wyborów. Jeśli jako wartość pola w kolumnie redukcji danych jest używany symbol wieloznaczny (*), jest on interpretowany jako umożliwiający użytkownikowi dostęp do rekordów powiązanych ze wszystkimi wybranymi polami redukcji w tabeli zabezpieczeń.

Kiedy Qlik Sense porównuje pole redukcji w Dostępie do sekcji z polami w modelu danych, oczekiwane jest następujące działanie:

Jeśli wartość pola w modelu danych pasuje do pola redukcji w Dostępie do sekcji, aplikacja otwiera się, pokazując dane powiązane z dopasowaniem dla określonego użytkownika. Inne dane zostaną ukryte.
Jeśli wartość pola redukującego nie pasuje do żadnej z wartości w modelu danych, aplikacja nie otworzy się dla zwykłego UŻYTKOWNIKA. Otworzy się jednak bez redukcji dla użytkownika oznaczonego jako ADMINISTRATOR.

Nie zaleca się używania kilku pól redukujących w Dostępie do sekcji, ponieważ umożliwi to powstanie innych kombinacji dostępu niż zamierzone.

Znak wieloznaczny * w kolumnie redukcji danych odnosi się tylko do wszystkich wartości w tabeli zabezpieczeń. Jeśli w części Section Application znajdują się wartości, które są niedostępne w kolumnie redukcji tabeli zabezpieczeń, zostaną one zredukowane.

Wszystkie nazwy pól używane w opisanej powyżej procedurze przenoszenia oraz wszystkie wartości tych pól muszą być zapisane wielkimi literami, ponieważ w sekcji dostępu wszystkie nazwy i wartości pól są domyślnie zamieniane na wielkie litery.

Jeśli wymagane jest włączenie ładowania skryptu w zadaniu konsoli Konsola zarządzania Qlik, wówczas domyślnie wymagany jest użytkownik konta INTERNAL\SA_SCHEDULER z dostępem ADMIN. Jeżeli nie chcesz używać konta INTERNAL\SA_SCHEDULER, zobacz temat Używanie personifikacji do ładowania danych, w którym przedstawiono metodę alternatywną.

Przykład: Redukcja danych na podstawie tożsamości użytkownika

Section Access; Authorization: LOAD * inline [ ACCESS, USERID, REDUCTION ADMIN, AD_DOMAIN\ADMIN, * USER, AD_DOMAIN\A, 1 USER, AD_DOMAIN\B, 2 USER, AD_DOMAIN\C, * ADMIN, INTERNAL\SA_SCHEDULER, * ]; Section Application; T1: LOAD *, NUM AS REDUCTION; LOAD RecNo() AS NUM AUTOGENERATE 3;

W tym przykładzie pole REDUCTION (nazwa zapisana wielkimi literami) istnieje teraz w części zarówno Section Access, jak i Section Application (wszystkie wartości pola również są zapisane wielkimi literami). W zwykłej sytuacji te dwa pola byłyby różne i niepowiązane, ale przez zastosowanie dostępu do sekcji zostaną one powiązane i wykorzystane do zredukowania liczby rekordów wyświetlanych użytkownikowi.

Wynik będzie następujący:

Użytkownik ADMIN widzi wszystkie pola oraz tylko te rekordy, które mogą wyświetlać inni użytkownicy, kiedy REDUCTION = 1 lub REDUCTION =2.
Użytkownik A widzi wszystkie pola i jedynie rekordy powiązane z wartością REDUCTION=1.
Użytkownik B widzi wszystkie pola i jedynie rekordy powiązane z wartością REDUCTION=2.
Użytkownik C widzi wszystkie pola oraz tylko te rekordy, które mogą wyświetlać inni użytkownicy, kiedy REDUCTION = 1 lub REDUCTION =2.

Zarządzanie dostępem do danych na poziomie kolumn

Dostęp do danych na poziomie kolumny można ograniczyć, dodając pole systemowe OMIT do tabeli zabezpieczeń w skrypcie Section Access. Poniższy przykład opiera się na poprzednim przykładzie, w którym stosowana jest już redukcja danych wiersza.

Przykład: Redukcja danych kolumny na podstawie identyfikatora użytkownika

Section Access; LOAD * inline [ ACCESS, USERID, REDUCTION, OMIT ADMIN, AD_DOMAIN\ADMIN, *, USER, AD_DOMAIN\A, 1, USER, AD_DOMAIN\B, 2, NUM USER, AD_DOMAIN\C, 3, ALPHA ADMIN, INTERNAL\SA_SCHEDULER, *, ]; Section Application; T1: LOAD *, NUM AS REDUCTION; LOAD Chr( RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

Pole OMIT w dostępie do sekcji definiuje pola, które mają być ukryte przed użytkownikiem.

Wynik będzie następujący:

Użytkownik ADMIN widzi wszystkie pola oraz tylko te rekordy w tym przykładzie, które mogą wyświetlać inni użytkownicy, gdy REDUCTION to 1, 2 lub 3.
Użytkownik A widzi wszystkie pola i jedynie rekordy powiązane z wartością REDUCTION=1.
Użytkownik B widzi wszystkie pola oprócz NUM i jedynie rekordy powiązane z wartością REDUCTION=2.
Użytkownik C widzi wszystkie pola oprócz ALPHA i jedynie rekordy powiązane z wartością REDUCTION=3.

Niektóre wizualizacje mają minimalne wymagania dotyczące danych, które należy spełnić, aby były renderowane. W rezultacie może zostać wyświetlony komunikat „Niekompletna wizualizacja”, gdy pole na poziomie kolumny zostanie pominięte w widoku danych użytkownika.

Zarządzanie dostępem do grup użytkowników

Instrukcja Section Access umożliwia ograniczenie zakresu danych widocznych dla użytkowników na podstawie członkostwa w grupie. Aby ograniczyć dane przy użyciu grup użytkowników, dodaj nazwę pola GROUP do tabeli zabezpieczeń w sekcji dostępu i zdefiniuj wartości dla pola GROUP.

Przykład: Redukcja danych na podstawie grup użytkownika

Section Access; LOAD * inline [ ACCESS, USERID, GROUP, REDUCTION, OMIT USER, *, ADMIN, *, USER, *, A, 1, USER, *, B, 2, NUM USER, *, C, 3, ALPHA USER, *, GROUP1, 3, ADMIN, INTERNAL\SA_SCHEDULER, *, *, ]; section application; T1: LOAD *, NUM AS REDUCTION; LOAD Chr( RecNo()+ord('A')-1) AS ALPHA, RecNo() AS NUM AUTOGENERATE 3;

Wynik będzie następujący:

Użytkownicy należący do grupy ADMIN widzą wszystkie pola oraz tylko te rekordy w tym przykładzie, które mogą wyświetlać inni użytkownicy, gdy REDUCTION to 1, 2 lub 3.
Użytkownicy należący do grupy A widzą dane powiązane z wartością REDUCTION=1 we wszystkich polach.
Użytkownicy należący do grupy B widzą dane powiązane z wartością REDUCTION=2, ale nie dane z pola NUM
Użytkownicy należący do grupy C widzą dane powiązane z wartością REDUCTION=3, ale nie dane z pola ALPHA
Użytkownicy należący do grupy GROUP1 widzą dane powiązane z wartością REDUCTION=3 we wszystkich polach

Qlik Sense porówna użytkownika z identyfikatorem użytkownika (UserID) i rozpozna go względem grup w tabeli. Jeśli użytkownik pasuje lub należy do grupy z uprawnieniami dostępu, może uzyskać dostęp do aplikacji.

Używanie personifikacji do ładowania danych

Wewnętrzne konto systemowe SA_SCHEDULER jest domyślnie używane do uruchamiania zadań ładowania. To konto ma podwyższone uprawnienia i pod względem technicznym może korzystać z dowolnego źródła danych. W QMC jest jednak ustawienie umożliwiające używanie personifikacji do uruchamiania zadań ładowania z uprawnieniami właściciela aplikacji zamiast wewnętrznego konta systemowego. Po skonfigurowaniu tego ustawienia do ładowania jest używany właściciel aplikacji, a nie SA_SCHEDULER, co oznacza, że nie dodaje się SA_SCHEDULER w tabeli Section Access, tylko właściciela aplikacji. W łańcuchu zadań aplikacje mogą mieć różnych właścicieli z uprawnieniami do źródeł zależnymi od praw dostępu każdego właściciela. Więcej informacji zawiera temat Service cluster (tylko w języku angielskim).

Zarządzanie dostępem użytkowników w środowisku wielochmurowym

Środowisko wielochmurowe Qlik Sense obejmuje różne mechanizmy uwierzytelniania użytkowników. W przypadku Qlik Sense Enterprise on Windows identyfikator USERID jest zwykle weryfikowany w tabeli zabezpieczeń przez usługę proxy. W Qlik Cloud tę rolę uwierzytelniania przyjmuje dostawca tożsamości. W związku z tym instrukcja Section Access skonfigurowana dla środowiska lokalnego, takiego jak Qlik Sense Enterprise on Windows, nie będzie działać w środowisku chmurowym.

W przypadku korzystania z dostawcy tożsamości OIDC (Qlik IdP lub niestandardowego dostawcy tożsamości) z Qlik Cloud subject claim jest używane do identyfikacji użytkowników podczas logowania. Jeżeli stosowana jest instrukcja Section Access, wartość pola USERID w tabeli zabezpieczeń jest porównywana z wartością subject claim. Podczas konfiguracji dzierżawy dopilnuj, by nazwa konta SAM została zamapowana do subject claim Twojego dostawcy tożsamości. Na przykład, jeśli nazwa Twojego konta SAM to AD_DOMAIN\Dev, ustaw subject claim na AD_DOMAIN\Dev. Aby zobaczyć wartość subject claim dostawcy tożsamości, dołącz /api/v1/diagnose-claims do adresu URL dzierżawy w przeglądarce, na przykład your-tenant.us.qlikcloud.com/api/v1/diagnose-claims. W odpowiedzi JSON subject claim nazywa się sub.

Jeśli nie możesz użyć nazwy konta SAM, istnieje inny sposób uwierzytelnienia użytkownika. Ponieważ adresy e-mail zwykle pozostają takie same w różnych środowiskach, możesz użyć w tabeli zabezpieczeń pola USER.EMAIL zamiast USERID. Oto przykład tego, jak mogłaby wyglądać tabela zabezpieczeń:

ACCESS	USERID	USER.EMAIL	Comment	COUNTRY
USER	ABC\Joe	*	Access-on-prem	United States
USER	*	joe.smith@example.com	Access-in-cloud	United States
USER	ABC\Ursula	*	Access-on-prem	Germany
USER	*	ursula.schultz@example.com	Access-in-cloud	Germany
USER	ABC\Stefan	*	Access-on-prem	Sweden
USER	*	stefan.svensson@example.com	Access-in-cloud	Sweden

Skrypt autoryzacji:

Section Access; LOAD * INLINE [ ACCESS, USERID, USER.EMAIL, COUNTRY USER, ABC\Joe, *, United States USER, *, joe.smith@example.com, United States USER, ABC\Ursula, *, Germany USER, *, ursula.schultz@example.com, Germany USER, ABC\Stefan, *, Sweden USER, *, stefan.svensson@example.com, Sweden ];

Pamiętaj, że każdy użytkownik ma dwa rekordy: Jeden do dostępu lokalnego, a drugi do dostępu w chmurze. Symbole wieloznaczne zapewniają używanie tylko odpowiednich pól uwierzytelniających. W tym przykładzie pole COUNTRY jest używane jako pole redukcji danych.

Używanie Section Access i Insight Advisor Chat

Aby aplikacje korzystające z instrukcji Section Access były dostępne w Insight Advisor Chat, następujący użytkownicy usługi muszą mieć dostęp administracyjny w skrypcie Section Access:

INTERNAL/sa_repository: Dzięki temu skrypt Section Access jest dostępny z usługą repozytorium do kontrolowania dostępu użytkowników.
INTERNAL/sa_scheduler: Umożliwia to załadowanie aplikacji przy użyciu zadań QMC.

Jeśli masz poufne informacje w nazwach aplikacji, pól lub elementów głównych, mogą one zostać ujawnione przez udostępnienie aplikacji używających instrukcji Section Access dla funkcji Insight Advisor Chat. Sugestie aplikacji dotyczące zapytań obejmują aplikacje ze strumieni, do których użytkownicy mają dostęp. Mogą to być aplikacje, do których użytkownicy nie mają dostępu w instrukcji Section Access aplikacji. Jednak wybranie tych aplikacji nie da żadnych efektów. Po kliknięciu Wymiary lub Miary w celu wyświetlenia dostępnych elementów z aplikacji używającej instrukcji Section Access użytkownicy mogą zobaczyć elementy, do których nie mają dostępu. Kliknięcie tych elementów nie spowoduje jednak udostępnienia użytkownikom żadnych danych.

Na przykład:

Section Access; LOAD * inline [ USERID ,ACCESS INTERNAL\sa_repository ,ADMIN INTERNAL\sa_scheduler ,ADMIN DOMAINNAME\user1 ,ADMIN DOMAINNAME\user2 ,USER DOMAINNAME\user3 ,USER ];

Gdy ci użytkownicy znajdą się w skrypcie Section Access, możesz udostępnić aplikację dla funkcji Insight Advisor Chat. Po załadowaniu aplikacji będzie ona dostępna w funkcji Insight Advisor Chat.

Wytyczne i wskazówki dotyczące korzystania z instrukcji Section Access

Oto kilka ważnych faktów i przydatnych wskazówek dotyczących instrukcji Section Access.

Wszystkie nazwy i wartości pól wymienione w instrukcjach LOAD lub SELECT w sekcji dostępu muszą być zapisane wielkimi literami. Zmień zapis wszelkich nazw pól zawierających w bazie danych małe litery na zapis wielkimi literami przy użyciu funkcji Upper, zanim pole zostanie odczytane przez instrukcję LOAD lub SELECT.
Więcej informacji zawiera temat Upper — funkcja skryptu i funkcja wykresu.
Wymienione tutaj nazwy pól systemowych Section Access nie mogą być używane jako nazwy pól w modelu danych.
Aplikacje muszą zostać opublikowane przed zastosowaniem środków kontroli z części Section Access. Załadowanie aplikacji nie spowoduje zastosowania nowych ani zmienionych skryptów Section Access.
Migawka przedstawia dane zgodnie z uprawnieniami dostępu użytkownika, który ją rejestruje, i może być udostępniana w narracji. Użytkownicy wracający do wizualizacji z narracji w celu wyświetlenia danych na żywo w aplikacji są jednak ograniczeni własnymi uprawnieniami dostępu.
Do wartości wymiaru głównego nie należy przypisywać kolorów, jeśli korzysta się z dostępu do sekcji albo z danych poufnych, ponieważ wartości mogą zostać ujawnione przez konfigurację kolorów.
Aby uniknąć ujawnienia zastrzeżonych danych, przed opublikowaniem aplikacji należy usunąć wszystkie dołączone pliki, względem których obowiązują ustawienia dostępu do sekcji. Dołączone pliki są zawarte w momencie publikowania aplikacji. Jeśli publikowana aplikacja zostanie skopiowana, dołączone pliki zostaną dodane do kopii. Jeśli jednak względem dołączonych plików danych zastosowano ograniczenia dostępu do sekcji, wówczas ustawienia dostępu do sekcji nie zostaną zachowane w przypadku skopiowania plików, dzięki czemu użytkownicy skopiowanej aplikacji będą widzieć wszystkie dane w dołączonych plikach.
Symbol wieloznaczny (*) jest interpretowany jako wszystkie (wymienione) wartości tego pola w tabeli. Jego użycie w jednym z pól systemowych (USERID, GROUP) w tabeli załadowanej w sekcji dostępu skryptu jest interpretowane jako wszystkie możliwe (nie tylko wymienione) wartości tego pola.
Pola zabezpieczeń można umieścić w różnych tabelach.
W przypadku ładowania danych z pliku QVD funkcja Upper powoduje spowolnienie procesu ładowania.
Jeśli użytkownik zablokuje sobie dostęp do aplikacji, konfigurując Section Access, wówczas może otworzyć aplikację bez danych i zmodyfikować sekcję dostępu w skrypcie ładowania danych. Wymaga to uprawnień do edytowania i przeładowania skryptu ładowania danych.
Więcej informacji zawiera temat Otwieranie aplikacji bez danych.
Po wykonaniu ładowania binarnego ograniczenia dostępu zostaną odziedziczone przez nową aplikację Qlik Sense.

Czy ta strona była pomocna?

Jeżeli natkniesz się na problemy z tą stroną lub jej zawartością — literówkę, brakujący krok lub błąd techniczny — daj nam znać, co możemy poprawić!

Przekaż tu opinię