Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi everyone,
I am currently implementing section access in our Qlik Cloud tenant for the first time, using the OMIT function to exclude a certain column's data from user groups.
Section Access;
LOAD * INLINE [
ACCESS, USER.EMAIL, GROUP, OMIT
ADMIN, * , ADMIN_GROUP, ,
USER, * , GROUP_1 ,SECRET_COLUMN,
];
The above works fine to make it so that certain groups have SECRET_COLUMN HIDDEN. However, I want to do the inverse of this scenario, where certain groups can have SECRET_COLUMN VISIBLE, while every other non-admin user has the column hidden. I have been trying to accomplish this through something like the script below to no avail.
Section Access;
LOAD * INLINE [
ACCESS, USER.EMAIL, GROUP, OMIT
ADMIN, * , ADMIN_GROUP, ,
USER, * , * , SECRET_COLUMN,
USER, * , SECRET_GROUP, ,
];
Does anyone have any tips as to how to make this work? The easiest way to accomplish this would be if we had a group that contained every user except the ones that have access to this column, but unfortunately that does not exist in our environment.
Any help is much appreciated.
AFAIK it's not possible. If no appropriate user-groups exists you will need to list sub-groups and/or even single users. Whereby such listing mustn't mandatory be manually else be extracted from your used directory maybe with a further linking to departments/teams or similar information.
It may not be trivial and needing some efforts. A workaround might be not to use one application else n ones with appropriate adjusted data-sets. Of course such approach will cause some redundancy and needing more resources but if no global authorization-data are available and appropriate implemented it will cost extra efforts on the other side.
AFAIK it's not possible. If no appropriate user-groups exists you will need to list sub-groups and/or even single users. Whereby such listing mustn't mandatory be manually else be extracted from your used directory maybe with a further linking to departments/teams or similar information.
It may not be trivial and needing some efforts. A workaround might be not to use one application else n ones with appropriate adjusted data-sets. Of course such approach will cause some redundancy and needing more resources but if no global authorization-data are available and appropriate implemented it will cost extra efforts on the other side.
That is what I figured would be the answer. We have found a slight workaround by designating all USERs with the OMIT restriction, but then designating the privileged group as ADMIN. The drawback of this approach is that no nested/complex permissions are possible, but accomplishes our goal for the time being.
Thank you.