Section access - Qlik View

Setting up user authorization under QlikView is generally referred to as section access, named after the statement that initiates the authorization section of the script. In section access, fields are loaded with details on which user is allowed which access rights. These fields are loaded in the same way as any other field in QlikView and can be sourced from an inline table, database, or external file.

Better Save than sorry (2)

It is strongly recommended to make a backup copy of your QlikView document before setting up section access. If anything goes wrong during the setup of section access, you will not be able to open your document anymore. Be very careful!

Besides using an inline table, database, or external file, there is also the option of storing and maintaining section access information under QlikView Publisher. Logically, this is no different than storing a table file with section access information in a (semi-)shared folder or, for example, on SharePoint. The data is loaded into the QlikView document as a web file.

As this book is focused on development within QlikView Desktop, storing section access information in QlikView
Publisher is out of scope, but it is a good idea to take note of.

Let's start with a simple exercise that protects our QlikView document with a username and password:

  1. Press Ctrl + E to open the Edit Script window.
  2. Go to File | Save Entire Document As in the menu.
  3. Save the file as Airline Operations SA.qvw.
  4. Now that we've created a separate copy of the file, select the Hidden Script tab.
  5. Go to Insert | Section Access | Inline from the menu.
  6. In the Access Restriction Table Wizard dialog click on the Basic User Access Table button and click on OK.
  7. In the Inline Data Wizard dialog, enter the data from the following table:

    Section access

  8. Click on OK to close the Inline Data Wizard dialog.

The following script should have now been generated:

As we can see, the script is started with the Section Access statement, which indicates to QlikView that we will be loading user authorization data. This data, access, userid, and password, is loaded in the next step using an inline table. The script is ended with the Section Application statement, indicating that QlikView should return to the regular application script.

We used a hidden script tab to create our section access. When using regular script, any user with privileges to view the script has full access to either the user credentials in plain text (when using an inline table), or to the location of the access files (when using an external table file). By using a hidden script, we can limit who will be able to see the section access script, adding an extra layer of security.

Another thing that you may have noticed is that all field names and field data are written in uppercase. While technically this is not necessary for data loaded from an inline table, any data loaded in section access from an external source must always be in uppercase. For the sake of consistency, it is a good idea to always load all data in uppercase in the section access area.

Now that we've seen how a basic section access example is set up, let's see if it works by following these steps:

  1. Save the document by selecting File | Save Entire Document in the menu.
  2. Click on OK to close the Edit Script dialog.
  3. Close QlikView Desktop by selecting File | Exit in the menu.
  4. Reopen QlikView and the Airline Operations SA.qvw file.
  5. In the User Identification input box, enter admin.
  6. In the Password input box, enter admini2 3.

If everything was set up ok, you should now be back in the document. Feel free to repeat these steps and enter wrong usernames and passwords to verify that QlikView will deny access to the document.

QlikView will only verify your user credentials once during each session. You can verify this by closing the document and reopening it, without exiting QlikView Desktop. QlikView will not ask for your username and password the second time. Only when you completely close and reopen QlikView Desktop will you be asked for your credentials again. This is important to remember when changing and testing section access.

Section access fields

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:

Section access fields

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.

Reduction fields

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:

  1. Open the Edit Script dialog and select the Hidden Script tab.
  2. Update the inline Section Access table so it contains the following information:

    Reduction fields

  3. Next, place the cursor after the Section Application statement.
  4. Go to Insert | Load Statement | Load Inline in the menu.
  5. In the Inline Data Wizard, select Tools | Document data.
  6. In the Import Document Data Wizard window, select the field Flight Type.
  7. Make sure that Values to import is set to All Values and click on OK.
  8. Add Flight Type as a column header, and add a second column header for % FLIGHTTYPE.
  9. Fill the table so it looks like the following table:


  10. Click on OK to close the Inline Data Wizard dialog.

The resulting script should look like this:

In this script, we've created the % FLIGHT TYPE 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 with in the data model.

Basing an inline table on existing data

One nice feature in the Inline Data Wizard dialog is the C) ability to load the contents of an already loaded field by using Tools | Document Data. This can be very useful when we want to group the values of an existing field.

You may notice that for the ADMIN user, we used an asterisk (*) instead of a % FLIGHT TYPE 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:

  1. Create a new line after the line admin, admin, admin123, *.
  2. On this new line, enter the following values: ADMIN, ADMIN, ADMIN123,INTERNATIONAL_US.
  3. Go to File | Save Entire Document to save the document.
  4. Click on the Reload button to reload the script.

In this exercise, we reduce the data model based on a single field. To reduce the data model on multiple fields, we can simply add another reduction column to the section access table and add a bridge field to the data model.

One important caveat to be aware of in this scenario is that the reduction will be performed over the intersection of all fields.
If, for example, we give a user access to the Domestic, US Carriers Only flight type and to the Jet engine type, the user will only be able to see domestic flights carried out by US carriers using a jet-powered aircraft. Any flights that were made using another engine type will be excluded.

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.

Initial data reduction

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.

Using initial data reduction is very important. Not using it means that everyone with access to the document has access to all of the data. This means he entire point of using section access is all but lost.

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

  1. Open the Document Properties window by pressing Ctrl + Alt + D.
  2. Go to the Opening tab, and select the Initial Data Reduction Based on Section Access checkbox.
  3. Make sure that the Strict Exclusion checkbox is checked.
  4. Check the Prohibit Binary Load checkbox (seen in the following screenshot).
  5. Click on OK to close the Document Properties dialog.
  6. Go to File | Save in the menu to save the document.


  7. Initial Data Reduction Eased on Section Access 0 Strict Exclusion
  8. I Initial Selection Based on Section Access [j Prohibit B-ary Load

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:

  • Initial Data Reduction Based on Section Access: This option enables initial data reduction for the document.
  • Strict Exclusion: When set, QlikView denies access to users whose data reductions fields cannot be matched to values in the data model. This does not apply to ADMIN users, who will instead get access to the entire data model. It is recommended to always enable this option to prevent unwanted access to data within the document.
  • Prohibit Binary Load: When set, it is not possible to load the document into another QlikView document using a binary load. It is recommended to always enable this setting unless you are using a multitiered data architecture that uses binary loads, for example, when using QlikMarts.

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.

Omitting fields

While looking at the fields 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:

  1. Open the script editor by pressing Ctrl + E and select the Hidden Script tab.
  2. Update the section access INLINE table by adding the OMIT field.
  3. Set the value of the new omit field to null for all existing users, by adding a comma (,) at the end of each admin and user line.
  4. Add a new user at the bottom of the list by entering the following script:
    USER, NOCARRIER, NOCARRIER123, *, Carrier Name.
  5. Go to File | Save Entire Document to save the document.
  6. Click on the Reload button to reload the script.

The resulting script should look like this:

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:

  1. Keep your current QlikView application (the program) and document open.
  2. Start a second copy of QlikView from the start menu or your quick launch shortcut.
  3. If you get an Auto Recover Files Found warning, click on Close to close it.
  4. Go to File | Open and select the Airline Operations SA.qvw file.
  5. When prompted for a user id and password, enter NOCARRIER and NOCARRIER123 respectively.

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

(unavaMable)[Camer Name]

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.

Association works in section access too

So far we have been using a single table to store our section access data. However, we can use multiple, associated tables as well.

For example, when we want to OMIT multiple fields for a single user, we need to add each field on a separate line. We can do this within the single table that we've been using so far. However, a better alternative is to remove the OMIT field from the first table and create a second, associated table that contains the USERID and OMIT fields.

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.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Qlik View Topics