Section Access anomalies?

[#1]

Hi all,

I am attempting to put section access on a qvw. I have set the checks on 'Initial Data Reduction Based on Section Access' and 'Strict Exclusion' in Document Properties. When I just load the tables into my model without 'section access;' and 'section application;', the associations work perfectly. When I turn on 'section access;' and 'section application;' all USER's are unable to access the qvw and all ADMIN's see the qvw without any data having been reduced. If I turn of 'Strict Exclusion' users get in and see same as ADMIN's. This seems to point at some inconsistency in USER's data reduction fields, so that QV denies all USER's. But I don't see it.

My questions:

1. Why can USER's not get in, even though when loading the section access table into ERD for testing (by removing 'section access;' and 'section application;'  ) it shows that the associations work.

2. How come for ADMIN's there is no reduction applied? Even though the ADMIN's with * should show reduction of fields not present in the Section Access table.

Script example of logic I am using below (works fine on on my desktop version), so I think the problem has to be in my actual data model? But when I remove all tables except the dimension I do reduction on, the same happens. Any advice/ideas would be appreciated!

DataProfiler:

Load * Inline [

USERPROFILER, COUNTRY

A, Netherlands

B, Germany

C, Netherlands

C, Belgium

D,

D, England

];

section access;

Users:

Load * Inline [

ACCESS, USERID, USERPROFILER

ADMIN, steve, *

USER, peter, B

USER, tim, A

USER, tim, D

];

section application;

Many many thanks in advance,

Neal

[hic]

Try using UPPERCASE user names.

HIC

[#3]

Hi Hencric,

They actually are in my main qvw. All field values in the section access are uppercase.

Thanks,

Neal

[Peter_Cammaert]

One important question: are you testing SA functioning in QV Desktop or in the AccessPoint? There is a big difference:

• In QV Desktop, all ACCESS=ADMIN users can always open a QVW and see data, even when Strict Exclusion has been enabled. This behavior is provided because you do not want to lock out developers who are simply testing data reduction. In QV Desktop, ADMIN users have always access to everything.
• In the AccessPoint, there are no ADMINs. Even users with ACCESS=ADMIN will have their privileges set to USER.

In addition to that, when you do NOT enable Strict Exclusion, QlikView will implement a fallback strategy. When a user has all data reduced to nothing, he/she will automatically have access to all data. Both in QV Desktop and in the AccessPoint.

Peter

[#5]

Hello Peter,

I am developing and testing in QV Desktop, after which it will be deployed on AccessPoint. You say that in the Desktop, ADMIn users always have access to everything, but this does not necessarily mean all data, since it is possible to reduce data for an ADMIN in Desktop from my experience.

From your last comment it seems like my USER's somehow have their data reduced to nothing, hence access is denied with 'Strict Exclusion' on, and they can see all data with 'Strict exclusion' off. But like I said, I tried just loading the tables into my ERD and there the associations worked as they should.

Neal

[Peter_Cammaert]

Your example code works perfectly for me. Since you included me in Section Access, I did a few tests without Data Reduction, with Data Reduction and with Data Reduction+Strict Exclusion. Each time, user PETER could get in and could only see what he was allowed to see.

Are you sure the example mimics the problems you encounter in your "big" document?

Peter

[#7]

Haha yes I took the liberty to already include you.

Yes, same here. The script above uses the logic that I use in my 'big' qvw, and like you say the above script also works for me on my desktop version.

Any ideas on how I could test my 'big' applciation for the fault?

Neal

[Peter_Cammaert · Accepted solution]

ADMINs getting data reduction too: Indeed but in QV Desktop they won't get kicked out when Strict Exclusion is enabled and no matching field values could be found in Section Application;

The difference between ordinary associative behavior and section access is that SA implicitly converts all link field values and field names to upper case. AFAIK, that is about the only reason why your section access tables may work in a standard associative data model, but not in section access.

Peter

[Peter_Cammaert]

Temporarily disable Section Access and check all link field values and names for lower case characters.

Best,

Peter

[#10]

Are you saying both the field names and field values have to be uppercase? Because my userprofiler and userid field values are not uppercase, as are the userprofiler field values in my ERD.