Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Dear QlikSense Community,
I am looking for a possibility to limit the available data in my app with a whitelisting approach, i.e. all users should by default only have access to a limited amount of data, except selected users that are explicitly mentioned in the section access area. E.g. a row-wise reduction where all app users by default only have access to US data, except for example a few management-level employees which should have access to all data.
As my app has a lot of users, I do not want to list all users explicitly in the section access area.
I've tried some approaches. E.g. the following:
Section Access;
LOAD * inline [
ACCESS, USERID, COUNTRY
ADMIN, INTERNAL\SA_SCHEDULER,
ADMIN, user_1,
ADMIN, *, USA
];
with user_1 being the whitelisted user. However, this leads to user_1 also only having access to US data. If I change the second to last line to "USER, *, USA", everybody except user_1 cannot access the app at all. I've tried some more variations which also didn't work.
Is there a possibility to implement section access in this way, giving access to all data to only selected (whitelisted) users, and without explicitly listing all possible users in the section access area?
Thanks for your help!
(Please note that as far as I can tell, the section access documentation does not cover this case.)
Hi, * gives access to the loaded values in section access, not to all values.
One option is to load a dummny or admin user with all values associated, so each other with * will also have access to all values.
Section Access;
AccessTable:
LOAD * inline [
ACCESS, USERID,
ADMIN, YOURUSER
];
Outer Join (AccessTable)
LOAD COUNTRY Resident CountryTable;
Concatenate(AccessTable)
LOAD * inline [
ACCESS, USERID, COUNTRY
ADMIN, INTERNAL\SA_SCHEDULER,
ADMIN, user_1, *
ADMIN, *, USA
];
Another option is to create a linked table that relates ALL to all countries, something like:
// this is in section application
// Add the ALL key that has access to all countries
SA_Country:
LOAD * Inline [
SA_COUNTRY
ALL
];
Outer Join (SA_Country)
LOAD COUNTRY Resident CountryTable;
// Add the other countries with only access to the same country
Concatenate (SA_Country)
LOAD COUNTRY as SA_COUNTRY, COUNTRY Resident CountryTable;
So in section access you can use the SA_COUNTRY field (instead of COUNTRY) and the ALL value to give access to all countries
Hi, * gives access to the loaded values in section access, not to all values.
One option is to load a dummny or admin user with all values associated, so each other with * will also have access to all values.
Section Access;
AccessTable:
LOAD * inline [
ACCESS, USERID,
ADMIN, YOURUSER
];
Outer Join (AccessTable)
LOAD COUNTRY Resident CountryTable;
Concatenate(AccessTable)
LOAD * inline [
ACCESS, USERID, COUNTRY
ADMIN, INTERNAL\SA_SCHEDULER,
ADMIN, user_1, *
ADMIN, *, USA
];
Another option is to create a linked table that relates ALL to all countries, something like:
// this is in section application
// Add the ALL key that has access to all countries
SA_Country:
LOAD * Inline [
SA_COUNTRY
ALL
];
Outer Join (SA_Country)
LOAD COUNTRY Resident CountryTable;
// Add the other countries with only access to the same country
Concatenate (SA_Country)
LOAD COUNTRY as SA_COUNTRY, COUNTRY Resident CountryTable;
So in section access you can use the SA_COUNTRY field (instead of COUNTRY) and the ALL value to give access to all countries
Did you consider to specify the access to (hierarchically nested) user-groups instead of individual users? It may simplify the task.
- Marcus
Hi @rubenmarin , I tried out your first suggestion and it worked perfectly. Thank you very much! 🙂
@marcus_sommer Thanks for your suggestion too, I will look into that if the first solution becomes too complicated with more users. Currently I'm not sure whether I can create user groups as to my understanding these need to be created via the user directory connector, to which I currently have no access. Maybe my understanding is wrong though. In any case I appreciate the suggestion!
Quite often such user-groups exists already within the used directory, like User1 and User2 belong to TeamX which belonged to DepartmentZ - automatically added by joining respectively changed by moving within the company. At least in our company it's done by an entry from the HR department to inherit all needed default accesses/rights.
So you may not need to create such user-groups but it will depend on your environment if such logic could be used or not.
- Marcus