Display Dashboard using mask/unmasked QVD based user group defined in QMC
Hi, I currently have 2 set of QVD (mask/unmasked with same schema), and I would like to implement a single app that will show mask/unmasked data based on user group defined in QMC. Currently I try to load 2 set of QVD into an app and inside the app I use expression and OSuser() function to determine which QVD column to be used based on the active directory of a user. Would like to ask for opinion on current approach and it is possible to bring user group defined in QMC into dashboard and use in expression?
Not sure if 'Section Access' fits to your use case. Section Access is the Qlik advised standard approach to reduce data for different users based on organization security policy.
Like @Digvijay_Singh already hinted is section access the common way in Qlik to control the access to the data-set. But it's not a masking of data else a very strict reduction to the authorized data and everything else is removed.
If any kind of masking is needed or any kind of a comparison between the restricted and unrestricted data you will need some extra measures - mostly by loading the data n times with the appropriate details or masking and then picking the wanted ones per query against the osuser() which must not mandatory be single users else it could be also user-groups and/or string-parts from them.
If you are going in this direction I suggest to consider to evaluate the logged user on a global level with variables which are then directly used within the dimensions/expressions/conditions to avoid the use of if-loops to pick the wanted ones.
Thanks for the reply! I would like to check is that any function to bring the AD user groups into expression to use? I do check the documentation it seems like didn't have any info regarding AD user group.
Sorry, my statement above wasn't quite correct. Groups could be used within the section access but querying the user per osuser() returned the current user not any of the groups in which the user is included. I was mistaken this because our (custom) users have their membership encoded within the id which I could extract with string-functions.
If this isn't the case in your environment you will need to list all relevant users or you includes a mapping-table between users and their groups within the data-model. This mustn't be done with hard-coded users else could be loaded from the active directory or any curated data-source.
If you don't use a fully section access based approach be aware that the per osuser() controlled visibility is a visibility control and not an access control because the data are further there and any mistakes (forgotten and/or wrongly placed/implemented conditions) or providing the users any possibilities to get access to the physical file or that they could add/change any objects the visibility of these data may come back again.
