Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
May 31, 2023 3:11:36 AM
May 15, 2021 11:05:00 AM
Security Rules can be configured to allow end-users to reload tasks directly from the Qlik Sense Hub. This way the users who don't have access to Qlik Sense Management Console can run the tasks that are created for the app directly from the hub.
Environment
- Qlik Sense February 2021 & later (For "Manage reload tasks": start/stop existing tasks from the hub)
- Qlik Sense May 2021 & later (An addition to "Reload": create tasks from the hub)
Security Rule examples are provided as-is. Further customization cannot be supplied by Qlik Support and we recommend engaging with our active community in the Qlik Sense Management forums for further assistance.
Requirements and Considerations
- By default, a user will have Read and Update permissions on Apps they own, whether they are Published or not.
- If you intend to give users permission to reload a published App they do not own, a separate security rule will be necessary to enable Read and Update permissions on the App.
- A Professional License. Analyzer licenses will only be able to view tasks, even with the security rules in place.
- By default, all users have access to the required HubSection_Task. This is the starting point to allow users to reload from the hub. If custom rules have been implemented that block access to HubSection_Task, this needs to be lifted or customised.
Note: Too many tasks run in parallel by users can cause a performance impact.
Set up the Security Rules:
- Open the Qlik Sense Management Console
- Go to Security Rules in the left side menu
- Click Create New
- Set up either a for only managing existing tasks only or b for creating new tasks and managing existing tasks:
- Start and Stop existing Reload Tasks only
Name: Reload Access from Hub (example)
Description: Allows users to reload apps from the hub (example)
Resource filter: ReloadTask_* (Can be chosen from the dropdown menu next to the box)
Actions: Read, Update
Conditions: Specify your user or group or role. - Create a new Reload Task and launch it as well as manage existing tasks
Name: Reload Access from Hub (example)
Description: Allows users to create reloads from the hub (example)
Resource filter: ReloadTask_* (Can be chosen from the dropdown menu next to the box)
Actions: Read, Update, Create
Conditions: Specify your user or group or role.
- Start and Stop existing Reload Tasks only
- Apply both rules
The specified users can now right-click on the hub to access the Management Reload Task (rule a) or/and Reload option (rule b). See Fig 1.
Clicking Reload to initiate the reload and open the App in a new tab.
Clicking Manage reload tasks to access all available reload tasks for this App. Tasks can then be started (Fig 2) or stopped (Fig 3)from this menu.
Additional Notes:
- Giving access to the Apps will always expose the Manage Properties option.
This can be mitigated by modifying the existing ReadCustomProperties rule to fit your needs. However, this will not hide the Manage Properties option. - Giving Update permissions to users allows them to edit the App's name, description, and thumbnail. This is working as expected.
It looks like this isn't working well with custom properties.
THE SETUP
CUSTOM PROPERTY
I've created a custom property called ReloadFromHubAllowedApps to be used on Users. Inside the ReloadFromHubAllowedApps custom property I added TestApp value, name of the app that I will want a user that is not an owner of that app to be able to reload from the Hub:
THE USER
Next, I've assigned the TestApp value in ReloadFromHubAllowedApps custom property for the test user, indicating that this user should be able to reload app called TestApp from the Hub:
THE APP
Lastly, I then created and published an app called TestApp to a stream, granted test user permission to the TestApp app, confirmed that the test user can see and access the app:
THE TASK
Last stop, the task for the TestApp app:
At this point, TestApp app is created and published, reload task is created, test user is permitted access to that app and configured to be able to reload the app called TestApp from the hub. So the user can see and access the app, but can't reload it yet. That's where security rules come in.
SECURITY RULES
Next I setup two security rules.
RULE 1: UPDATE APPS PERMISSION
First rule allows users Update published apps that they don't own so that they would be able to execute the reload:
This rule allowed the user to manage app's properties, edit app's name, description, and thumbnail, and see the data model:
So this rule worked fine.
RULE 2: RELOAD TASKS PERMISSION
The other rule, would grant access to reload tasks that belong to apps that user was permissioned to be able to reload using the ReloadFromHubAllowedApps custom property:
Fairly straightforward. Just for the heck of it, I hit the Preview button to confirm that the rule does impact the right user and the right task, which it does:
However, this rule doesn't work. When rule is created and saved and test user refreshes the Hub, that user still doesn't have access to the Manage reload tasks menu:
TROUBLESHOOTING
I went ahead and confirmed that the HubSectionTask rule is enabled:
After confirming that HubSectionTask is enabled and setup correctly, I've modified the Rule # 2 to see if it would work if the rule was more general:
Making the rule more general did make the Manage reload tasks option available for the test user:
The option to execute reload of the task for the app was also available:
That points to the issue being some bug somewhere with ReloadTask.app.name is not matching successfully to user.@ReloadFromHubAllowedApps custom property even though the security rule preview indicates that such rule should properly allow test user to manage task in the hub for the TestApp app.
I like this feature but if I can't dynamically and precisely control which users can see reload tasks to which app without having to create rules for each user and app and, in addition to that, as @Or and @lblancher mentioned, having to give users Update permissions to the app, it makes this user not very usable.
Please look into why custom properties are not working well and please keep us posted if you'll ever resolve the issue with having to give users Update rights to the app in order to have users be able to execute reloads from the Hub.
Thanks,
Mikhail B.
It's not quite a new idea. Using custom properties to dynamically manage permissions already exists. It just looks to be broken when applied specifically to task reloads.
And again, custom properties is not the problem here. Based on my tests that I've described above, the issue seems to be with resource.app portion of advanced conditions.
This part:
#ReloadTask.app part doesn't work. You can create a rule that says "give reload permissions for tasks that belong to app named TestApp" and users will still not be able to access reload tasks for specified app.
That's the problem. Someone needs to look into why ReloadTask.app being set to name and value being set to name of an app doesn't actually give users permissions to access reload tasks of specified app.
Give that a try. Create and publish an app called TestApp, create a reload task for that app, give user permission to the app, and create a security rule that gives user permission to reload task of an app named TestApp, and a security rule that gives user permission to update TestApp. You will see that even though you gave user permission to update the app and reload tasks for TestApp, user will still not be able to see reload tasks of TestAppin the hub. That's the bug that needs to be fixed. It's not a new idea or a feature.
Did that help to make it clearer?
tldr
This is pretty complex stuff... Previous writers have captured the gist of things, but I might be able to add some clarity too.
- You can get this to work, but there's not a lot of flexibility and the end user experience is so-so.
- Not possible (from what I've seen so far - might revise that after diving deeper into the app object security rules) to conditionally hide the "Manage properties" menu item in the right-click menu.
- The "Manage properties" popup window can be made read-only. But that's a lousy user experience.
Long version
As hinted (but not clearly stated) in point 4.b in the original post you must give CR permissions to ReloadTask_* (or ReloadTask_<taskid>) to make the "Reload" and "Manage reload tasks" appear when right clicking on an app in the hub.
Clicking Reload will do one of two things:
1. If a manual reload task already exists it will be started.
2. If such a reload DOES NOT exist it will first be created, then started.
Either way the app is reloaded.
If clicking "Manage reload tasks" you get a popup window show the tasks associated with the app. If a specific task filter was used in the reload task security rule (i.e. filter ReloadTask_<taskid>) you will only see that task.
The above assumes that the current user also has U permission to the app that was right-clicked in the hub. From what I can see Update permissions are enough to trigger a reload from the hub, even though the original article mentioned R permissions too. Might be worth looking into.
What needs fixing
- Better/more fine-grained control of what is shown when right-clicking an app in the hub. I.e. control which of "Reload", "Manage reload tasks" and "Manage properties" is displayed.
- A proper, solid tutorial in how to set things up. @mbespartochnyy has most parts covered but updates needed when point above has been fixed.
