Skip to main content
cancel
Showing results for 
Search instead for 
Did you mean: 
justcotto
Contributor III
Contributor III

Users not having access after implementing section access

Hello, I am trying to reduce users access using section access.  I only want users to see their respective business unit.  I have a file which I am loading users from.

SECTION Access;
Users:
LOAD 'USER' AS ACCESS,
UPPER(NTNAME) AS NTNAME,
UPPER(OPID) AS OPID,
UPPER(ORG) AS ORG
FROM
[..\..\10_Data\User Testing\QVDs\Users.qvd]
(qvd);

Concatenate(Users)
LOAD * INLINE [
ACCESS, NTNAME, OPID, ORG
ADMIN, DOMAIN\ADGROUP1 *, *
ADMIN, DOMAIN\ADGROUP2, *, *
ADMIN, DOMAIN\ADGROUP3, *, *
];

Now my team is in ADGROUP1 and everyone can access the dashboard through accesspoint.  But users in ADGROUP2 cannot.  Also the list of users being pulled from the QVD are individual IDs not ADGroups in the form DOMAIN\OPID.

2 Replies
DesmoArka
Partner - Contributor III
Partner - Contributor III

Hi,

I don't know if it could be the problem, but consider that the wildcard, character *, in this row refers only to all values within the section access table. If there are values in the section application that are not available in the REDUCTION field in section access, they will be reduced.

I hope this helps you.

Brett_Bleess
Former Employee
Former Employee

Believe the prior partner is spot on with their observation, strict exclusion is likely the issue in that if there are no values associated with a particular row related to the reduction fields, that would in turn lock out the user...  I would recommend reviewing the following Design Blog post for starters:

https://community.qlik.com/t5/Qlik-Design-Blog/A-Primer-on-Section-Access/ba-p/1465766

Note, there are some additional links at the bottom of that one, two related to dynamic data reduction which you will also need to review.  The one thing you likely want to do here is the following piece noted in the post above:

A good way to debug your Section Access is to temporarily remove the Section Access statement and run the script. The authorization table will then be visible in the data model and you can make selections in NTNAME.

You do this by commenting the Section Access; line of the script, which will then load your security table into the normal data model such that you can then add a list box for the NTNAME field and select a user to see what appears in the other key list boxes/fields as far as available selections, as if things are greyed out, then you know you have a problem in the model somewhere if they should be able to see some values etc.  We are working on getting a short video put together to demo this to better understand, but hopefully this will make sense in the meantime.

Regards,
Brett

To help users find verified answers, please do not forget to use the "Accept as Solution" button on any post(s) that helped you resolve your problem or question.
I now work a compressed schedule, Tuesday, Wednesday and Thursday, so those will be the days I will reply to any follow-up posts.