article Section Access in Member Articles

Section Access

marcus_sommer — Fri, 30 Sep 2022 11:25:47 GMT

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

Re: Section Access

Anonymous — Fri, 21 Aug 2015 18:07:41 GMT

Thank You Marcus!! All in one Place

Re: Section Access

Wed, 26 Aug 2015 15:15:41 GMT

Thanks for sharing this document. Very helpful!

Re: Section Access

SreeniJD — Tue, 20 Oct 2015 07:51:31 GMT

Hi @Marcus_Sommer

Thanks for sharing!

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

Sreeni

Re: Section Access

marcus_sommer — Tue, 20 Oct 2015 08:22:13 GMT

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

Re: Section Access

SreeniJD — Tue, 20 Oct 2015 08:32:04 GMT

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

Re: Section Access

marcus_sommer — Tue, 20 Oct 2015 08:44:09 GMT

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

Re: Section Access

SreeniJD — Tue, 20 Oct 2015 08:48:23 GMT

Thanks Marcus. Very much helpful!

Re: Section Access

Anonymous — Thu, 10 Dec 2015 22:15:39 GMT

Definitely bookmarked this one for future reference

Re: Section Access

datagrrl — Wed, 16 Dec 2015 15:38:54 GMT

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

Re: Section Access

marcus_sommer — Wed, 16 Dec 2015 16:06:56 GMT

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

Re: Section Access

datagrrl — Wed, 16 Dec 2015 16:30:54 GMT

Thanks for your reply Marcus-

Yeah, I actually do both of those things(using a combined key and multiple records for each user) in my actual application. For example, I have some users who can see all of the data about all departments and some who can only see all of the data for a few.

I don't understand this part:

"A column-based restriction per OMIT won't be applicable"

Why isn't it applicable? I sometimes want to restrict the users view of the hourly rate, but they can see other information about the record.

I want to restrict the column RATE for some rows.

If using a combined key can get me to that, great, but I can't think of a good way to do that.

The combined key works well when I have situations where I can create keys for all possible values in the key records, but this isn't that situation.

I don't think it is reasonable to create a record in the key for every possible rate amount. Unless of course I am misunderstanding you.

It becomes more unreasonable when I look at the range of amounts in the application I am dealing which, which is much bigger than the range of pay rates would be (pennies to tens of thousands of dollars).

I could be overthinking this and the answer is simple. Please let me know if I am misunderstanding your suggestion or my case isn't clear.

Again, thanks for the reply, I appreciate any assistance.

Re: Section Access

marcus_sommer — Wed, 16 Dec 2015 16:53:39 GMT

My statement to OMIT was related to your example that a user should only see some rows of a column. If you want denied this column for certain users then of course OMIT is the proper feature.

I agree with you that to generate such combined-key and user-matching could be very expensive. In former days I have had built a nested loop-routine to create such a table which worked very good and needs nearly no corrections. Today it's a lot easier because I have splitted my applications so that "easier" section access will work and I use NTNAME with Usergroups (in DMS-mode) and we use functional users like AreaManager1, AreaManager2 ... instead of personalized users like John, James ... which reduced the maintaining efforts a lot.

This is no recommendation to use DMS instead of NT (but NTNAME instead of USER/PASSWORD is a recommendation) but for us it worked very well.

- Marcus

Re: Section Access

datagrrl — Wed, 16 Dec 2015 18:13:15 GMT

Yeah, I really use NTNAME, I just threw that example together.

I am not sure listing ever possible hourly rate would work. I think it would do the same thing anyway. I think one of my co-workers suggested a solution. I will try that out.

This has really been my only speed bump with Section Access. I find it to be pretty robust overall.

I will look into doing it by groups. I am not sure is my users will go into groups(access to rows is pretty varied), but I will look into it.

Thanks for your help.

Re: Section Access

Anonymous — Tue, 22 Dec 2015 09:58:31 GMT

This helped me because I have been busy with this recently and to have these all in one place really helped

Re: Section Access

simotrab — Thu, 07 Jan 2016 11:09:05 GMT

Thanks a lot, very useful.

Re: Section Access

Wed, 20 Apr 2016 06:42:08 GMT

Very much helpful . Thanks

Re: Section Access

flanfranco — Mon, 30 May 2016 17:28:08 GMT

This is a great post!!
Thanks!!!

Re: Section Access

ecolomer — Thu, 11 Aug 2016 06:42:50 GMT

Very useful post.

Thank's for sahring

Saludos

Re: Section Access

fkeuroglian — Fri, 12 Aug 2016 21:10:28 GMT

Useful and well explain

Thanks Marcus!