All what you need is the security implementation with dynamic data reduction:
Security
A security mechanism in QlikView can be set up in two different ways: It can either built into the QlikView document script, or it can be set up through the use of QlikView Publisher. The following lines refer to the case when the security mechanism is built into the QlikView script.
Sections in the Script
Access control is managed via one or several security tables loaded in the same way as QlikView normally loads data. It is thus possible to store these tables in a normal database. The script statements managing the security tables are given within the access section, which in the script is initiated by the statement section access.
If an access section is defined in the script, the part of the script loading the "normal" data must be put in a different section, initiated by the statement section application.
Access Levels in Section Access
Access to QlikView documents can be authorized to specified users or groups of users. In the security table, users can be assigned the access levels ADMIN or USER. If no access level is assigned, the user cannot open the QlikView document.
A person with ADMIN access can change everything in the document. Using the Security page in the Document Properties and Sheet Properties dialogs, a person with ADMIN access can limit the users' possibilities of modifying the document. A person with USER privileges cannot access the Security pages.
Section Access system fields
The access levels are assigned to users in one or several tables loaded within the section access. These tables can contain several different user-specific system fields, typically USERID and PASSWORD, and the field defining the access level, ACCESS. All Section Access system fields will be used for authentication or authorization. The full set of section access system fields are described below.
None, all, or any combination of the security fields may be loaded in the access section. It is thus not necessary to use USERID - an authorization can be made using other fields, e.g. serial number only.
ACCESS
A field that defines what access the corresponding user should have.
USERID
A field that should contain an accepted user ID. QlikView will prompt for a User ID and compare to the value in this field. This user ID is not the same as the Windows user ID.
PASSWORD
A field that should contain an accepted password. QlikView will prompt for a Password and compare it to the value in this field. This password is not the same as the Windows password.
SERIAL
A field that should contain a number corresponding to the QlikView serial number.
Example: 4900 2394 7113 7304
QlikView will check the serial number of the user and compare it to the value in this field.
NTNAME
A field that should contain a string corresponding to a Windows NT Domain user name or group name.
QlikView will fetch the logon information from the OS and compare to the value in this field.
NTDOMAINSID
A field that should contain a string corresponding to a Windows NT Domain SID.
Example: S-1-5-21-125976590-4672381061092489882
QlikView will fetch the logon information from the OS and compare to the value in this field.
QlikView will fetch the logon information from the OS and compare to the value in this field.
OMIT
A field that should contain the field that should be omitted for this specific user. Wildcards may be used and the field may be empty. A facile way of doing this is to use a subfield.
QlikView will compare the QlikView serial number with the field SERIAL, the Windows NT User name and groups with NTNAME, the Windows NT Domain SID with NTDOMAINSID and the Windows NT SID with NTSID. It will further prompt for User ID and Password and compare these with the fields USERID and PASSWORD.
If the found combination of user ID, password and environment properties also is found in section access, then the document is opened with the corresponding access level. If not, QlikView will deny the user access to the document. If the User ID and/or the Password are not entered correctly within three attempts the entire log-on procedure must be repeated.
Dynamic Data Reduction QlikView and QlikView Server support a feature by which some of the data in a document can be hidden from the user based on the section access login.
First of all, fields (columns) can be hidden by the use of the system field OMIT.
Secondly, records (rows) can be hidden by linking the Section Access data with the real data: The selection of values to be shown/excluded is controlled by means of having one or more fields with common names in section access and section application. After user login QlikView will attempt to copy the selections in fields in section access to any fields in section application with exactly the same field names (the field names must be written in UPPER CASE). After the selections have been made, QlikView will permanently hide all data excluded by these selections from the user.
In order for this procedure to take place, the option Initial Data Reduction Based on Section Access on the Opening page of the Document Properties dialog must be selected. If this feature is used in documents that are to be distributed by other means than via QlikView Server, the option Prohibit Binary Load on the same page of the Document Properties must be selected in order to maintain data protection.
The field DEPT now exists with the same UPPERCASE name in both section access and section application. All field values are also UPPERCASE. The two fields would normally be totally different and separated, but if Initial data reduction based on selection access has been checked, the following will result:
