Section Access with OSUSER without Specifying each user in script

[proctors]

I'd like to use section access such that Qlikview looks at the OSUSER and limits their data to a fields Billing_USERID and Service_USERID. Both USERID fields are matched with a person's data and they should only be allowed to see their data.

I don't want to have to create an in-line or external list of all of our users because it would be a lot to maintain (new hires). All USERID's match our OSUSER() data except that the OSUSER() has the domain\ attached to it. For example, my Billing_USERID is proctors and my OSUSER() is CHOP.EDU\PROCTORS.

It would be nice if Qlikview could see who is logged in, compare that to the loaded USERID fields and only show them their USERID data. Is this possible?

[Anil_Babu_Samineni]

You can define conditionally like If(OSUSER() = Billing_USERID, 1, 0) . So, Finally you can define QVUSER() to show the user name of customer logged.

[marcus_sommer]

In a classical section access by using NTNAME as section access authentification you could use normal windows user-groups which meant you need only to develop and maintain the authorization on a user-group level. If these user-groups are sensible maintained from your HR + IT department there is not much need to maintain them within Qlik.

- Marcus

[proctors]

How would I make this apply in my QV? For example, I have field with Billing User Name that is linked to their USERID. Where would I put this to make sure they can only select their own name or could only load data about themselves?

[proctors]

Hi.

I'm confused, how do I specify that a particular user can only see their own data?

[marcus_sommer]

It is meant that there is usually some kind of hierarchy in the rights within a company. For example that a user belonged to a team and various teams belong to a certain department and so on. Now you could authorize a user to certain access-rights over their membership to a team, department and so on.

This approach is quite commonly used in many companies to control the access of users to the network-shares, to the rights within their ERP systems and so on. If somebody is hired or left the company or changed the position the status and the membership to the various groups will be set/adjusted from the HR and/or IT.

Normally these rights to work on certain stuff are usually the same like the requirements within a visualization tool like QlikView to see and operate with their results. Therefore why developing and maintain a further authorization logic? Even if there is some exception from this it's easier to use this as a default-approach and to add special instructions on top of it.

- Marcus

[rubenmarin · Accepted solution]

Hi Stephon, I didn't tested, better do a backup copy before apply changes to section acces to prevent bloking to document to everyone.

Maybe there is a better option and i'm not sure of the data and how security should apply but to give and idea maybe loading the users from the same fact data?:

SECTION Access;

Users:

LOAD 'USER' as ACCESS,

  'CHOP.EDU\' & Billing_USERID,

  Billing_USERID as BILLING_USERID,

  Billing_USERID as SERVICE_USERID // Same user have access to both fields?

From billingTable;

// not sure if this is needed

concatenate

LOAD 'USER' as ACCESS,

  'CHOP.EDU\' & Service_USERID,

  Service_USERID as BILLING_USERID,

  Service_USERID as SERVICE_USERID

From serviceTable;

SECTION Application;

And loading additional fields in caps (BILLING_USERID and SERVICE_USERID) in fact tables to apply setion access.