Skip to main content
Announcements
Introducing Qlik Answers: A plug-and-play, Generative AI powered RAG solution. READ ALL ABOUT IT!
cancel
Showing results for 
Search instead for 
Did you mean: 
novelasFrost
Contributor
Contributor

Section Access Not Working as Expected

Hello,

Trying to put a section access that limits users to values within two columns: 1) Territory and 2) Sub-Territory

Here's how I set it up:

 

LIB CONNECT TO 'DB';

Section Access;


[Security Table]:
Load Distinct
Access AS ACCESS,
Upper([NTName]) AS NTNAME,
Upper([UserID]) AS USERID,
Upper(Password) AS PASSWORD,
Show_Sales_Flag AS SHOW_SALES_FLAG,
SALES_AREA_ID_SECURITY,
Territory,
S_Territory AS SubTerritory
;
SELECT
[Access]
,COMP.[NTName] AS NTName
,DBC.[UserID] AS UserID
,DBC.[Password] AS Password
,DBC.[User_Name]
,DBC.[Show_Sales_Flag] AS Show_Sales_Flag
,DBC.[Type]
,COMP.[SalesArea] AS SALES_AREA_ID_SECURITY
,FFC.Territory
,FFC.S_Territory
FROM [DB].[schema].[TBL1] DBC
Inner Join [DB].[schema].[TBL2] COMP on COMP.[NTName] = DBC.[NTName]
Inner join [DB].[schema].[TBL3] FFC on FFC.[NTName] = DBC.[NTName];

[OMITTEDFIELDS]:
LOAD * INLINE [
SHOW_SALES_FLAG, OMIT
Y, NOTHING
N, Sales_Fig1
N, Sales_Fig2
N, Sales_Fig3
N, Sales_Fig4];

Section Application;

 

The corresponding fields in my datamodel are Territory and SubTerritory. It's working for users that have access to a few Territories; however, if a user has access to all Territories, that is "*"--then I see a problem as the section access still filters their access, in what seems to be an alphabetical way. So let's say there are only three territories---A, B, C--and if user A has access set up as  * under Territory, this user is seeing only territory A. What is wrong with my section access code? Also, there are some dollar fields that are omitted as well. Those work as expected. 

Labels (1)
2 Replies
marcus_sommer

I think a section access on multiple fields is possible by using multiple fields but I never tried it in this way else I combined the fields. If your fields are hierarchically structured without an overlapping you could just apply the field with the highest granularity.

Beside of this applying the star * wildcard within the section access doesn't mean that all records are available else only those which were loaded within the section access. Not listed values won't be included as well as NULL. Or with other words it's a white-list-logic and only existing and valide values are in and everything else is dismissed (deleted from the data-model).

Further the section access worked like many other authorization which means any denying respectively not listing will overwrite all permissions.

A good check which data are really loaded and if the relations between the section access table and the data-model are working like expected is to comment the section access statement to make these data a visible and accessible within the UI, for example within a table-box and then selecting on the user and the reducing fields.

NadiaB
Support
Support

Hi @novelasFrost 

By any chance could you confirm if this is Qlik Sense or QlikView ? NTNAME is a legacy QlikView field, I see you have UserID already, just wanted to make sure that the one that has been reviewed and configured for the access is UserID, it is suggested to comment out the unsupported fields. 

https://help.qlik.com/en-US/sense/November2022/Subsystems/Hub/Content/Sense_Hub/Scripting/Security/m...

"NTNAME is a legacy QlikView field and it is recommended to use USERID if QlikView is not using the same security table."

When it comes to the wildcard in the reduction field:

"The wildcard character * in the data reduction column refers only to all values in the security table. If there are values in Section Application that are not available in the reduction column of the security table, they will be reduced."

Just make sure that all territories are in the table, for example if your table you granted access to User 1 to territory A and User to Territory B , and you grant access to User 3 with *, the only territories the user will see are A and B, not C as it was not listed. you can create profiles instead to make sure you explicitly list the values you want to grant access to. 

The following article has some steps to troubleshoot Section Access:

https://community.qlik.com/t5/Official-Support-Articles/How-To-Validate-And-Troubleshoot-Section-Acc...

Hope it helps!!

 

 

Don't forget to mark as "Solution Accepted" the comment that resolves the question/issue. #ngm