This is a companion post to the article KB 000004090

1) In order to function properly in Desktop as well as server environments, two separate ADMIN entities must be defined: the first one is associated with an empty string (or any string that does not match data in the reduction field), and this entity (typically a Publisher machine) is used for reloading the application data, but this entity cannot open the application in a server environment (as designed). The second ADMIN entity is associated with an "*" in the Section Access part of the script and is never allowed to reload data, but is on the other hand allowed to view all data in a non-reduced state on the server as well as desktop.

2) The initial table must NOT contain any record regarding the first ADMIN entity mentioned in (1) above, since this entity must be able to refer to a reduction value that is NOT a part of the logical data table outside the section access area. This entity must ALWAYS be defined in the section access area and nowhere else.

3)  The initial table must be dropped in order to avoid collisions between reduced and non-reduced data in the section application, otherwise, the strict exclusion flag will prevent any access to the server document. This is as designed, a bad reduction is always supposed to fail any attempt to log in on the document.

Assigning an ADMIN level to an entity that is subject to data reduction is NEVER a good practice and should be avoided, such an entity should either be elevated to full ADMIN level and consequently not subject to any data reduction or demoted to USER level (this is usually the most plausible action).

It is strongly recommended that the initial table is dropped, since this table is not fully reduced and does not contain all records that are part of the section access area (see #2 and #3 above) and, consequently, will not function as a proper link table to the logical data structure in section application (see modified example where a link table is defined based on the table in the section access area rather than the initial table).

4) It is possible to use Groups in section access (from an AD for example). They are added in the exact same way as users under NTNAME. When mixing users and groups in section access extra care needs to be taken with the permissions. If a user is present as both an individual user and a group member you should ensure they have the same permissions in both cases.

5) Do not have an Active Directory Group named as the service account running the QlikView Services. Any user member of this group will get the same privileges as the QlilView Service account (Usually Admin privileges)

6) Ensure the Strict Exclusion setting is checked in the Settings\Document Properties\Opening tab settings of the application if data reduction is being used. 

Please see the QVW attached (SA_EXAMPLE.QWV) for a script example. Section access user ID and credentials are set as following:

UID, PWD, Description:
A, A, Reload only - no server access.
ADMIN, ADMIN, No reload - full server access.
AAA, AAA, No reload - limited server access.
B, B, No reload - limited server access.
C, C, No reload - limited server access.
BFS, BFS, No reload - limited server access.
BHX, BHX, No reload - limited server access.
BRSGH, BRSGH, No reload - limited server access.

(Issues within and Overcoming through)

In General, we use section access for Data level, User – sheet or object level security on an application. Here, I came across a scenario which i should restrict multiple fields from different tables. That’s OK.

But during this data Reduction for a particular user, he/she may or may not have data in some Section access Restricted fields. As, we all know that SA will not grant access to users without data or Null () in any of the restricted fields i.e. when strict exclusion is checked under opening tab of document properties.

To overcome this and granting access to app for all users who have at least one data point in sync. We need to concatenate the SA table to each Master table based on the field mapping with each master. There by data will exist in all Masters and section access grants access to users & also this approach will impose nulls into other fields of masters. By this User may not get to see data which is not available, but can have access to all other required areas where data exists without subsiding into access denied initially.

Sample For Creating Above Scenario:

Temp_SA: //This table is being used for concatenating with other Masters and will be dropped at the end.
LOAD DEPT,ID_EMP
 INLINE [
    ACCESS, USERID, PASSWORD, DEPT, ID_EMP
    ADMIN, ADMIN, @123, *, *
    USER, A, 123, IT, 1
    USER, B, 123, SALES, 2
    USER, C, 123, NETWORK, 3
    USER, D, 123, CC, 4
];

Section Access;
LOAD * INLINE [
    ACCESS, USERID, PASSWORD, DEPARTMENT, EMPID
    ADMIN, ADMIN, @123, *, *
    USER, A, 123, IT, 1
    USER, B, 123, SALES, 2
    USER, C, 123, NETWORK, 3
    USER, D, 123, CC, 4
];
Section Application;


Dept_Master:
 LOAD * INLINE [
    DEPARTMENT, TurnOver
    IT, 22
    SALES, 33
    NETWORK, 455
];

Concatenate

Load DEPT as  DEPARTMENT
Resident Temp_SA where not exists (DEPARTMENT,DEPT); //For Checking only unavailable data field and concatenating with master.



Emp_Master:
LOAD * INLINE [
    EMPID, IssuesLogged
    2, 43433
    3, 3222
    4, 32243
];

Concatenate

Load ID_EMP as EMPID 
Resident Temp_SA where not exists (EMPID,ID_EMP); //For Checking only unavailable data field and concatenating with master.

DROP Table Temp_SA; // Dropping once Concatenation is done. 

Elaborating the above script and data set:

In Above sample data set with Section access mapped, the user “A” is not having any data in Emp_Master to get mapped. Similarly users “B” is not having any data in Dept_Master to get mapped and show case anything in APP.

So, due to strict exclusion checked. When we login with credentials of these both users, will get access denied to app.

For avoiding this we are concatenating the SA Table by calling it in resident with exists condition to all masters with required fields alone, here Where Not Exists condition is used to avoid creating nulls in already available fields by getting concatenated again.

There By using above Concatenation approach with SA, all users will have access to Application at any given point in time. If In case any data level error occurs or if data doesn’t have match required.

PFA QVW and Doc For Ref.

Thanks & Regards,

Hirish V