Access rights can be defined based on (a combination of) various criteria. In the previous example we used the ACCESS, USERID, and PASSWORD fields, but as we saw in the Access Restriction Table Wizard dialog, there are more options, as seen here:

These options, and their description, are listed in the following table:

Note that just about any combination of fields is allowable. For instance, if just NTNAME and PASSWORD is defined, the domain user will need to be logged on correctly and provide the password associated with their domain account in section access. Also, it is valid to just have USERID, so only a name needs to be given to get access, regardless of domain user, and there will be no prompt for a password.

In the next section, we'll look at how we can use section access to restrict the data that users can see.

Besides the fields listed in the previous section, we can associate additional fields with the security fields to reduce the set of data that individual users have access to. Let's follow this example and see how we can limit the flight type (and associated flights) that are available to different users:

The resulting script should look like this:

Section Access;
LOAD * INLINE [
    ACCESS, USERID, PASSWORD, %FLIGHTTYPE
    ADMIN, ADMIN, ADMIN123, *
    USER, DF, DF123, DOMESTIC_FOREIGN
    USER, DU, DU123, DOMESTIC_US
    USER, IF, IF123, INTERNATIONAL_FOREIGN
];
Section Application;

LOAD * INLINE [
    Flight Type, %FLIGHTTYPE
    "Domestic, Foreign Carriers", DOMESTIC_FOREIGN
    "Domestic, US Carriers Only", DOMESTIC_US
    "International, Foreign Carriers", INTERNATIONAL_FOREIGN
    "International, US Carriers Only", INTERNATIONAL_US
];

In this script, we've created the %FLIGHTTYPE field. This field exists in both the section access part of the script as well as in the actual data model, thereby acting as a bridge field between these two sections. Through association, we can now limit what a particular user can access within the data model.

You may notice that for the ADMIN user, we used an asterisk (*) instead of a %FLIGHTTYPE value. When we use an asterisk, it means that the user gets access to all values listed in the reduction field. In this case, that means that ADMIN gets access to the DOMESTIC_FOREIGN, DOMESTIC_US, and INTERNATIONAL_US flight types, but not to the INTERNATIONAL_FOREIGN flight type, since that is not listed in the section access table.

If we want the ADMIN user to be able to access the INTERNATIONAL_FOREIGN flight type as well, we will need to add an additional line referencing the INTERNATIONAL_FOREIGN flight type to the section access inline table. Let's do that now:

Although we have now finished the script part of setting up section access with reduction fields, we will need to make a few more changes before we can see the results. Let's head over to the frontend.

We will need to tell QlikView to perform an Initial Data Reduction when opening the document. When using initial data reduction, QlikView removes all of the data the user does not have access to, based on the authorizations in section access.

Let's follow these steps to set up initial data reduction for our document:

We have now set up the document to, upon opening, exclude all of the data that the user does not have access to. Let's have a closer look at the options that we set in the Document Properties:

When a document containing section access is loaded into another document using binary load, the new document will inherit the section access of the original application. Take a minute to try logging in as the DUDF and IF users and see how the data is reduced to show only the authorized flight types. After that, reopen the document and log in as the ADMIN user, we'll need the privileges to make our next changes.

While looking at the filds in the Access Restriction Table Wizard, you may have noticed that there is one field that is a little different from the others: the OMIT field. While all of the other fields are used to identify a user, the OMIT field is used to remove fields from the data model for the specified user.

In the next exercise, we will create a new user, NOCARRIER, and will remove the Carrier Name field for this user. Let's follow these steps:

The resulting script should look like this:

Section Access;
LOAD * INLINE [
    ACCESS, USERID, PASSWORD, %FLIGHTTYPE, OMIT
    ADMIN, ADMIN, ADMIN123, *,
    ADMIN, ADMIN, ADMIN123, INTERNATIONAL_US,
    USER, DF, DF123, DOMESTIC_FOREIGN,
    USER, DU, DU123, DOMESTIC_US,
    USER, IF, IF123, INTERNATIONAL_FOREIGN,
    USER, NOCARRIER, NOCARRIER123, *, Carrier Name
];

We've created a new user, NOCARRIER, whose password is NOCARRIER123. This user has access to all flight types, but cannot see the Carrier Name field.

We'll test if this works according to plan, but this time we will use another method. Let's follow these steps:

If everything went well, we should see that the Carrier Name listbox is empty, and that the field is marked as (unavailable).

By opening a second copy of the QlikView software and testing our file in that, we've significantly reduced the risk of getting locked out of our document. If anything is wrong, we can just revert back to the document that we did not close after saving and make the required changes to section access before repeating the process to try again. Using this approach is highly recommended.

Now that we've seen how we can limit who has access to our document, and what they can see, we will now look at how we can restrict what users can do within the document in the next section.