Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Nov 30, 2022 5:09:36 AM
May 17, 2015 3:46:34 AM
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.
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.
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.
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.
This means that Erica has no valid reduction values in the reduction field and is denied access to the application.
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.
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.
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...
Try adding a * as reduction value for service user. This will give the user access to all values represented in the section access table.
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.
Thanks for the Post. Clear and simple example.
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.
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.
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"