Qlik Community

QlikView Documents

QlikView documentation and resources.

Announcements
Customer & Partners, DEC. 9, 11 AM ET: Qlik Product & Strategy Roadmap Session: Data Analytics REGISTER NOW

Section Access

marcus_sommer
MVP & Luminary
MVP & Luminary

Section Access

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

Video - Section Access best practice

Section Access (Data Reduction) using Active Directory

Between desktop and server are differences which you should consider: Section Access: Desktop vs Server.

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

Section Access - Hide Sheet Level

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

Comments
santiago_respane
Specialist
Specialist

Excellent!

Thanks for sharing!

Regards,

0 Likes
robynrshields
Contributor III
Contributor III

Qlikview Section Access Examples do not have the updated files.  When I click on link it keeps bringing me back to the original QVW sample files from 2014, which I cannot open.

Is there a way that you could add the updated sample QVW files again?  I am most interested in Sample #7.  Thank you in advance.

0 Likes
marcus_sommer
MVP & Luminary
MVP & Luminary

Which sample do you mean?

0 Likes
robynrshields
Contributor III
Contributor III

Hi Marcus,

I'm trying to set up SA so that users can see ALL data on sheets EXCEPT for 1 sheet the data should be limited to 2 fields (row level security).  How would I do that in 1 application? 

0 Likes
robynrshields
Contributor III
Contributor III

Hi Marcus,

Thank for adding those SA examples.  However, my request is a bit complex because I want everyone who accesses the dashboard to be able to see ALL sheets except for 1.

The 1 sheet that will be different is based on 1 or 2 fields (row level access).

Section Access is only working on the row level access for the ENTIRE dashboard, but I only want it to work on 1 sheet of the dashboard.

Example:

USER     SHEETID      LOCATION

SAM          5                   All

TOM          5                   MA

JIM            5                   CT

In the above scenario, Sam should see all Locations for all sheets including SHEETID 5.

Tom and Jim should see all Locations for all sheets EXCEPT SheetID5.  On SheetID5 they should only see 1 location; Tom should see MA, and Jim should see CT.

Do you have a solution for 1 application where I can apply the Location to only 1 sheet?  Thanks in advance.

0 Likes
marcus_sommer
MVP & Luminary
MVP & Luminary

I think you will need to extend your approach to an additionally field and/or to conditions within the objects on this sheet, maybe per: if(osuser() = 'x', Field1, Field2). Strictly spoken: you are now operating with usability and not with security which allowed or denied the data-access and not depends on ... (the sheet).

- Marcus

0 Likes
bertinabel
Creator
Creator

Excelente y muy completa aportación.

Gracias.

0 Likes
vinod_gadiputi
Contributor III
Contributor III

Nice.

Thanks for sharing.

0 Likes
bvmike2001
Contributor III
Contributor III

Hello guys,

I have the following challenge with Section Access:

- a data model with 2 tables: Employee details and Travel details.

  

ORG_IDCOUNTRYEMP_IDNAME
1UK1Emp_A
2NL2Emp_B
3SE3Emp_C

   

ORG_IDEMP_IDDEST_COUNTRY
11NL
11BE
11IS
22UK
22BE
22FI
22SE
33DN
33UK

The data security requirement is like this:

- user from an Organization (e.g. Org_ID = 1) will see Travel & HR data related to his specific Org_ID and also all HR & travel data related to travels from other Organization traveling to the user Organization Country (e.g. Org_Id = 1, Country = UK)

until now I have two solution and I seek for your help and expertise to chose the appropriate one or may find a better one:

1. use a reduction field with all possible values combining Org_ID + Destination_Country and use this filed in the Travel table. this will create a rows set for each user in the Security table and requires an update every time a new Destination_Country will be available in the data set.

2. keep the Security table as simple as possible with just a row per user and build a bridge table inside the data model with the composite key linking to Travel table and Security_Org_id (duplicate from Org_ID) linking to the Security table as the reduction field.

this solution have a lower impact in defining new users and maintenance in the Security table but brings more data processing and a new table in the final dashboard data model.

I have implemented both of them an they work.

Thanks in advance for your suggestions!

Regards,

Mihai

0 Likes
Version history
Last update:
‎2015-08-16 10:35 AM
Updated by: