I have a dashboard that contains highly sensitive information inside the data at a granular level (personally identifiable).
Right now that level of detail is being hidden from view by forcing the users to view the charts in aggregate only -- using calculation conditions, so that when their selections allow them too few records, the objects do not calculate.
The one issue with this is that the Users can create their own objects and circumvent this calculation condition.
To combat this, we were able to create a security rule that disables this feature by looking at membership of AD Groups.
The issue with this is that individuals that are in additional AD groups in the server, for other applications, are then not able to create objects inside those other applications either, not just the one we want to limit.
I'm looking for a security rule that will allow me to disable app object creation by membership inside an AD Group, as well as limit this functionality to a specific app.
So, a subset of users (certain AD Groups) that are granted access to the app should not be able to create their own sheets, but others inside that app can.
You could use two versions of the dashboard in two documents and assign different security rules for the documents.That would mean some effort when making changes to the document as you always have to duplicate the document after changes. I would inlcude AD in section access, so that you have the scurity rights in the document. You could as well use sction access to limit the view on the data and objects by AD Groups.
Thanks for the reply Tim.
Unfortunately, Section Access does not remove the ability for Users to create their own objects.
maybe I was a little unclear. There are several things happening here.
Section Access is already being used to dictate which AD Groups see which rows inside the data.
The first complication comes in when we need to turn off the charts once a User has drilled too deep into the data set based on their selections.
This is handled via a calculation condition on each object.
The rule for this is something like IF(GetPossibleCount([EmployeeID])<=150,0,1).
They've drilled too deep into the analysis and can begin to figure out who an individual may be, based on other available characteristics of the record. So we restrict the ability to view the charts via the calculation condition.
The second complication is that Users can circumvent this calculation condition by creating their own charts inside the app, where they can get to the underlying data and remove the calculation conditions we have imposed on the charts.
This is handled by creating a security rule that removes these specific AD Groups the ability to create their own objects inside the environment. The rule is attached to the AD Group(s), and their residency in the Group says that they can't create their own objects.
The third complication now introduced is that if any one User has residency in one of the object creation restricted AD Groups, and ALSO has access to a completely different dashboard inside the environment, their User cannot create objects in that other dashboard either.
Here's the scenario:
I'm a User in Finance, and I've been given access to two apps in Qlik Sense -- a Finance app and an HR app.
Inside the HR app I am unable to create my own objects, by design. However inside the Finance app I SHOULD be allowed to create my own objects, but the very fact that I am resident in the HR AD Group that is not allowed to create their own objects has also removed that ability for me to create my own objects in the Finance app as well.
Ideally, we would be able to handle this by assigning the object creation restriction to Users in a specific AD group, for only a specific App. However it does not seem that you can specify App GUIDs inside a security rule.
Joel, as I know you could not manage the security settings linked to AD Groups in the documents (maybe by macro, but I would not use a macro for this). My Idea of two documents was to have 1. document with access rights for the limited users only, and in this document you set the document properties->security->add Sheets to be disalowed, Than you have to set the security on each sheet to disalow adding or changing objects properties. For the users that are allowed to add objects (in your example e.g. a HR User in the HR app), you need to set the properties to allow adding and changing objects.
If you need to integrate all in one app, you need to adjust your datamodel in a way, that the detailed level could be hidden, e.g. you need to calculated aggregated data in your load script.
Unfortunately aggregating the data for the second app would not work.
We're dealing with individual employee records with things like race, gender, date of birth, etc. We need the granularity to calculate things properly.