Skip to main content
Announcements
Join us at Qlik Connect for 3 magical days of learning, networking,and inspiration! REGISTER TODAY and save!

Section Access: Strict Exclusion

No ratings
cancel
Showing results for 
Search instead for 
Did you mean: 
ToniKautto
Employee
Employee

Section Access: Strict Exclusion

Last Update:

Nov 30, 2022 5:09:36 AM

Updated By:

Sonja_Bauernfeind

Created date:

May 17, 2015 3:46:34 AM

Attachments

The strict exclusion feature often causes confusion and misunderstanding. The main purpose is to protect user access, due to incorrectly set up section access reduction. A good start to understanding the feature it is good to first recap on the basic reduction logic of Section Access.

In its simplest form, a Section Access can be defined as below. The logic for reduction is that the reduction values are applied as selections, and the possible data after the selection is the reduced data provided to the user.

1.png

In this example Anna the admin gets access to all the data through the reduction values A and B. Mary the user only gets access to value A. But what is the expected outcome for Erica the user?

Erica has a reduction value that does not exist in the data. The expected reduction result is the same as if you select the value C.

  1. Open the search box in list box
    2.png
  2. Enter the non-existing value
    3.png
  3. Hit enter to apply the search
    4.png
  4. The value can not be select and all previous values remain as possible values

From this little test we can draw the conclusion that the expected result for a non-existing reduction value is that you get all the possible values in the field. In other words the reduction has no impact, and when Erica logs in she gets access to all the data.

5.png

In QlikView, the Strict Exclusion function can be enabled in Document Properties. With this enabled reduction on non-existing values is not allowed.

Note that in Qlik Sense Strict Exclusion is always ON. See Adapting the data load script in Qlik Sense.

6.png

This means that Erica has no valid reduction values in the reduction field and is denied access to the application.

7.png

If Erica has at least one valid reduction value the reduction will always match on the existing value(s) only. There is no risk for getting all values or being locked out by strict exclusion. Do a search for valid and invalid values in a list box as reference, for example search for A or C as below and A will be the found and selected value.

8.png

IMPORTANT: With strict exclusion enabled you can easily lock yourself out of the QlikView application. Always reload with a user that has valid reduction values, otherwise you will not be able to access the document after reloading.

Labels (2)
Comments
amezzaro
Partner - Contributor II
Partner - Contributor II

Correct.Thank you very much. We were aware of this, and we usually add a line in the SectionAccess with empty values for the Qlik Service identity :

Section Access:

USER_ACCESS:

SQL

SELECT [ users from database ]

Concatenate    /* administrative access and qlik service hard coded*/

LOAD * INLINE [

NTNAME                   , ACCESS,    A  , B,       C

'NTNAME_QVUSER' ,  'ADMIN' ,       ,     ,

'NTNAME_ADMINUSER1'    ,  'ADMIN' ,   , ,

'NTNAME_ADMINUSER2'    ,  'ADMIN' ,  , ,

This way it works, normally.

In this very last case, we occasionally add wrong rows with specific values for the QVUSER

from the database and at the end the USER_ACCESS table had multiple values for the

QV User:

USER_ACCESS

NTNAME                   , ACCESS,    A  , B,       C

'NTNAME_QVUSER' ,  'ADMIN' ,       ,     ,

'NTNAME_USER1'    ,  'ADMIN' ,  XX ,YY , ZZ

'NTNAME_USER2'    ,  'ADMIN' ,  XX ,YY , ZZ

'NTNAME_QVUSER' ,  'ADMIN' ,   XX , YY ,ZZ

This is not working, of course...

ToniKautto
Employee
Employee

Try adding a * as reduction value for service user. This will give the user access to all values represented in the section access table.

amezzaro
Partner - Contributor II
Partner - Contributor II

Thanks again,Toni. '*' or nothing '' it seems the same, indeed, from a QV Admin perspective in the Secton Access table,as far as I experienced.

Another issue we met with strict exclusion is that one user could be excluded if he has NO entry AT ALL in one of the Section Application  tables. So, it's better to move any meaningless bridge table outside of the Section Application if it is not granted that every user has an entry on it.

krishnacbe
Partner - Specialist III
Partner - Specialist III

Thanks for the Post. Clear and simple example.

omerfaruk
Creator
Creator

Thanks for the post.

One addition, if you use * instead of leaving empty for the restricted field in the section access table, you should append all possible values to your section access table otherwise, admin or users having full access will only have access to all "listed" values rather than all "possible" values.

ToniKautto
Employee
Employee

Wildcard reduction value behaves the same ways regardless if you have strict exclusion or not.

I would suggest that you post a question in community, and describe a section access scenario that you want to accomplish. It is often easier to discuss best options around a specific solution, rather than discussing general capabilities.

Introduction to Section Access‌ is a bit dated by still covers the basics of section access in QlikView.

thomas_wang
Creator
Creator

I'm sorry that what I said might cause misunderstanding to you and others. Meanwhile, I would like you to confirm this discussion: Re: Section Access "Star"

Version history
Last update:
‎2022-11-30 05:09 AM
Updated by: