Skip to main content
Announcements
Join us at Qlik Connect for 3 magical days of learning, networking,and inspiration! REGISTER TODAY and save!
cancel
Showing results for 
Search instead for 
Did you mean: 
pauldmunoz
Partner - Contributor
Partner - Contributor

Section Access reducing Locally, but not for Users on Access Point

I'm using NTNAME for Section Access, but I'm having issues with USER permissions for the Access Point.

Locally everything is working as expected. I can set various levels of permissions and the file opens up with the reduced information.

The file reloads on the QMC without issue with the server name included in the SA admin list.

When set to ADMIN permissions or I uncheck strict Exclusion, the Access Point will open the file with no reduction as expected.

When I use any USER level permissions for the Access Point the user no longer has the permissions to open the application, but can still open the QVW on their desktop with the appropriate data reduction. I've added a text object with OSUser() to make sure that the NTNAME was matching on the Access Point, which it is in lower case.

It seems to be able to determine I'm an ADMIN based off my NTNAME on the Access Point. If I change my permissions to a USER it will locally reduce the data. Given that it seems to both be able to verify my NTNAME successfully on the Access Point and can locally reduce the data by the appropriate Section Access, I'm confused why it can't reduce the data on the Access Point for a USER.

Can't attach the code for PII, but this was the SA section at the very beginning of the file,

SECTION ACCESS;

LOAD upper(ACCESS) as ACCESS,

          upper(NTNAME) as NTNAME,

          upper(AUTHID) as %AUTHID

FROM [QVD PATH] (qvd) Where 1 = 1;

SECTION APPLICATION;

...rest of script

Added Where 1=1 to avoid QVD Optimization that I read could interfere with Section Access.

%AUTHID was just a composite key of two fields that I bridged with another table. Verified locally that this is functioning fine with the successful Section Access reductions.

Thanks!

1 Solution

Accepted Solutions
Bill_Britt
Former Employee
Former Employee

Do you have the service account in SA as admin and the AUTHID blanked? Also, once you added upper it avoided the optimization.

Bill

Bill - Principal Technical Support Engineer at Qlik
To help users find verified answers, please don't forget to use the "Accept as Solution" button on any posts that helped you resolve your problem or question.

View solution in original post

4 Replies
Bill_Britt
Former Employee
Former Employee

Do you have the service account in SA as admin and the AUTHID blanked? Also, once you added upper it avoided the optimization.

Bill

Bill - Principal Technical Support Engineer at Qlik
To help users find verified answers, please don't forget to use the "Accept as Solution" button on any posts that helped you resolve your problem or question.
pauldmunoz
Partner - Contributor
Partner - Contributor
Author

The service account did have a populated AUTHID field, which after removing looks like the USERs are now reducing properly on the Access Point.

After the change, no other ADMIN seems to be able to access the file. Would another field need to be changed?

Do you usually have ADMINs going through the access point or typically just meant for developers and the service account?

Thanks

Peter_Cammaert
Partner - Champion III
Partner - Champion III

ADMIN does not exist in the AccessPoint. Everyone is a USER, no matter what the Access field says.

The Role = ADMIN is intended for Desktop-like usage. In QV Desktop, users with this role will have access to everything. Like you said, those are developers that can always get into their own QVW. In a reload job (under publisher QVB.exe control), users like that will make sure that the batch reload program can open the document in the first place, and will make sure that the account is able to load and store all data without reduction.

Best,

Peter

pauldmunoz
Partner - Contributor
Partner - Contributor
Author

Thanks for the clarification on ADMIN, Peter.