Section Access

[marcus_sommer]

How could I make sure that certain data are only for certain users available?

The answer is SECTION ACCESS. Section access is a connection between an authorization table (commonly placed in a hidden script and/or outsourced in an include-variable) and the application data (most to a dimension table).

Further you need to enable section access within the document properties in tab open and especially to enable the strict exclusion is important then without this is section access more a comfortable usability function to avoid confusing by the users which needs only a small data-area from the application but not more suitable for real confidential data.

Introduction to Section Access

A Primer on Section Access

Data Reduction – Yes, but How?

Section Access: Strict Exclusion

QlikView Section Access Examples

Data Reduction Using Multiple Fields

Section Access (Data Reduction) using Active Directory

In addition to these there are more complex restrictions possible but before you build one think on alternatives like Document chaining whereby those applications then have a specialized and simpler section access.

Basics for complex authorization

Authorization using a Hierarchy

Restrictions based on section access could be applied on sheets and objects.

Sheets Security with Section Access

Sheets Security with Section Access File

Chart Level Access by user

Sheet level access

Sometimes there is a need to mask or de-identify data for certain users, for this see: Mask or de-identify data for certain users using Section Access.

At least the most important remark: before thinking on section access makes one or more BACKUP's from your applications then there aren't any go backs by mistakes! One exception (which don't nullified the suggestion of having Backup's) could you find here: Bypassing QlikView Section Access – Infinity Insight Blog.

There is some content-overlapping within the above used links but I think the complement to each other is useful and of course you will find many more interesting postings here within the qlik community to these topic - the notes here are a good starting point to go further.

Have fun!

Marcus Sommer

[Anonymous]

Thank You Marcus!! All in one Place

[#3]

Thanks for sharing this document. Very helpful!

[SreeniJD]

Hi @Marcus_Sommer

Thanks for sharing!

Can you please share any limitations of Section Access in detail!

Sreeni

[marcus_sommer]

What do you mean with limitations? The approach of section access (horizontaly and vertically data-restrictions on user-, licence-, domain- or machine-level on a document-basis) is only one part of a strategy for security and usability by giving user certain accesses to the data and/or distribute them in any way.

- Marcus

[SreeniJD]

Thanks Marcus,

I have heard that if documents are with section access, they do have some issues while hosting on Server and sometimes, we do have to remove the section access to get the documents uploaded in server...

Is it a myth or true?

Sreeni

[marcus_sommer]

Section access worked very well on the server but you need to put the user from server-account into the section access part, too with ADMIN as ACCESS type and if you used user + passwords as authentication you will need a wildcard - mostly * - for the password and a Star is *; statement.

- Marcus

[SreeniJD]

Thanks Marcus. Very much helpful!

[Anonymous]

Definitely bookmarked this one for future reference

[datagrrl]

The only thing I struggle with is Section Access is wanting when I want to limit some column access based on row access.

For example. I have a manager who can see hourly rates for employees in her department, but not the other departments she can view.

I think I can write some conditional logic in the expression, but I would prefer to be able to list omit values at the row level, which you can do, but it doesn't work the way I would expect.

This is a false scenario, it was just the first simple example I thought of.

Example:

ACCESS	USER	KEY	OMIT
ADMIN	ADMIN
USER	SALESMANAGER	HR	RATE
USER	SALESMANAGER	SERVICE	RATE
USER	SALESMANAGER	SALES
USER	HRDIRECTOR	HR
USER	HRDIRECTOR	SERVICE
USER	HRDIRECTOR	SALES

[marcus_sommer]

Your example with the hourly rates is a row-based access. A column-based restriction per OMIT won't be applicable. In your case you will probaly need some kind of combined key maybe something like:

Channel & '|' & Region & '|' & Area as StrcutureKey // I use this kind of Key

and you might need to reapeat some Users several times. For example has an area-manager one entry for his/her area but a region-manager has so many entries how he/she has areas.

- Marcus