After getting qlik server set up, apps created, we now have a few users ready to start using our application. I've read about section access and how to manage what users can see what data.
How do I go about setting up this method? I've read you need to create a table in our database to manage their roles.
Right now, our user base is very small as this is a new effort, but would like to be prepared. Is it better to manage users based on groups then create a table to manage these users and then tie it with qlik?
I've read you need these parameters if you do decide to do in the script editor -- Section Access; LOAD * inline [ ACCESS, USERID USER, User_ID ]; Section Application; LOAD... ... from.
Are these concrete parameters that I need to have included in my table or in the script editor? Looking for the best way to manage what users should see in our application.
I use section access all of the time and it works well for us. We have sensitive medical information; each user gets to see only his/her patients' information.
You can manage in groups, or by user. It depends on if your groups of users all get the same privileges. If they do, then your management will be easier. But either way, you need to know what they are going to get to see.
In the "Section Access" section, you will load the list of users (from an external source or a list you type Inline), along with the part of the data that they are allowed to see. I use a field called ORGID. Joe has ORGID=1, Susan has ORGID=2, etc.
After that section, you have "Section Application" where all of your 'normal' data gets loaded.
I can give you more detailed instruction if you provide a couple of sample users, where you manage your user list, and whether their privileges are based on group membership or something else.
2. Analyst - sees all data MINUS these fields: employeeSalary, employeeVINnum, managementSalary, ManagementVINnum
3. simpleUsers - should not see everything mentioned above, plus specific States: NYC, LA, ATL, DEN.
The thing I'm trying to wrap around my head is - what if I have just one application that has all the data. Am I creating this section access within a table and explicitly stating which fields they should or should not see?
Now if I were to prohibit simpeUsers from seeing specific columns in the data I'm assuming the visualizations might error out for them? I haven't tested this with any users as I am trying to plan for long term as I know this will be our next task.
As for setting the users up, what would you recommend? Did you just create a simple table in your database and then just bring that into your qlik application? I'm going through a white paper right now and hoping to gain more insight. I guess the whole process is a bit foreign but gradually understanding bit by bit.
The OMIT column tells Qlik which fields to hide from these users. I haven't tried it, so you'll need to see how it looks to the end-user. The ACCESS column contains either USER or ADMIN. Admin is only for superusers.
If your users are part of a domain, make sure your load script adds the domain name and \ in front of the usernames. My typical load script looks like this:
star is *;
Domain & '\' & UPPER("USERID") as USERID,
NULL() AS OMIT
(ooxml, embedded labels, table is Sheet1);
[Statements to LOAD the data that the app uses]
To hide those States' data from simpleUsers, you need to structure your data model correctly, which means when you load the table that contains the States field, it joins to a table that lists the States and which GROUP members can see those states. That table could look like:
This table is the (hidden) link between your user table (in section access) and all of the data you load. For every value in the States field, the GROUP value will have access. In my sample table, simpleUsers does not have access to LA or ATL but does have access to BOS. (I assume Management gets to see all data, so we enter * in States, just once. And we type "star is *;" above the Section Access in the load script.)
We just need to make sure that the other tables link correctly to this one, in a way that security is properly managed.