In this scenario, the administrator wants to create a Deployment Admin who has access to a single stream only.
Resolution:
Name: _DeploymentAdminAppAccess-SingleStream
Description: Uses resources.stream.name to limit the scope of which apps are visible in the QMC
Filter: App_*
Actions: Read + Update
Conditions: ((user.roles="DeploymentAdmin-single") and (resource.stream.name="Completed Code"))
Context: Only in QMC
It creates a new user role which is assigned to a given user and statically references a stream name. resource.stream.id is a more robust way of referencing a stream since the GUID does not change while the name can.
Name: _DeploymentAdmin
Description: Same as the default but with a different user.roles and we removed ReloadTask_* since it needs to be handled separately
Filter: ServiceCluster_*,ServerNodeConfiguration_*,Engine*,Proxy*,VirtualProxy*,Repository*,Printing*,Scheduler*,User*,CustomProperty*,Tag_*,License*,TermsAcceptance_*,UserSyncTask_*,SchemaEvent_*,CompositeEvent_*
Actions: Create + Read + Update + Delete
Conditions: ((user.roles="DeploymentAdmin-single"))
Context: Only in QMC
Name: _DeploymentAdminQmcSections
Description: Same as the default but with a different user.roles
Filter: Actions: Read
Conditions: ((user.roles="DeploymentAdmin-single"))
Context: Only in QMC
Name: _DeploymentAdminRulesAccess
Description: Same as the default but with a different user.roles
Filter: SystemRule_*
Actions: Create + Read + Update + Delete
Conditions: user.roles = "DeploymentAdmin-single" and (resource.category = "Sync" or resource.category = "License")
Context: Only in QMC
Name: _DeploymentAdmin-Reloads
Description: Totally new rule where it inherits the ability to interact with tasks based on inheritance from App read rights
Filter: ReloadTask_*
Actions: Create + Read + Update + Delete
Conditions: ((user.roles="DeploymentAdmin-single") and (resource.App.HasPrivilege("read")))
Context: Only in QMC
Notes:
This isn't very scalable since it requires a specific role to be created for each stream. There are alternative approaches if you have user meta-data (e.g. user.group) which can be leveraged.
We in Qlik Support have virtually no scope when it comes to debugging or writing custom security rules for customers. That level of implementation advice needs to be handled by the folks in Professional Services or Presales. That being said, this example is provided for demonstration purposes to explain a specific scenario. No Support or maintenance is implied or provided. Further customization is expected to be necessary and it is the responsibility of the end administrator to test and implement an appropriate rule for their specific use case.
