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

[datagrrl]

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.

[marcus_sommer]

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

[datagrrl]

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.

[Anonymous]

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

[simotrab]

Thanks a lot, very useful.

[#7]

Very much helpful . Thanks

[flanfranco]

This is a great post!!
Thanks!!!

[ecolomer]

Very useful post.

Thank's for sahring

Saludos

[fkeuroglian]

Useful and well explain

Thanks Marcus!

[fkeuroglian]

Excellent Marcus, very usefull examples and all of the material

Thanks!