Qlik Sense for Windows: How to allow task reloads on the Hub

[John_Sathya]

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:

1. Open the Qlik Sense Management Console
2. Go to Security Rules in the left side menu
3. Click Create New 
4. Set up either a for only managing existing tasks only or b for creating new tasks and managing existing tasks:
   
   
   1. 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.
      
      
   2. 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.
      
      
5. 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.

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.

Fig 2

Fig 3

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. 

[Ken_T]

Was this fully tested?

in my testing, this allows users to also be able to view the load script for published tasks and reload published tasks from the hub, which seems like a very, very bad idea for system stability.

is there any way to implement this new feature without allowing the user to change the load script on a published task?

[Sonja_Bauernfeind]

Hello  @Ken_T 

Yes, this was fully tested.

And thank you so much for the feedback! Always appreciated 🙂 

I'll take the feedback on access to the script to our SMEs to see if we can provide a workaround (tightening of security rules) or if this is considered working as designed.  Will update the article and reply to you once I finished the testing.

All the best,

Sonja 

[Ken_T]

Thanks @Sonja_Bauernfeind ! I was not able to get it to work without exposing  theload script and reload button for a published task.   (That seems a very good way to cause issues if a user is changing something the system expects to be locked for changes ) - Hopefully a workaround can be found. We were excited about this functionality when we first found it, but, after testing it, and logging a support ticket,  we had to decide to plan to not implement it.

[Sonja_Bauernfeind]

Hello @Ken_T!

This is now with our developers. Will keep you informed in this article once we have a proper conclusion. 

-Sonja

PS: Keep the feedback coming 🙂 

[Or]

@John_Sathya   @Sonja_Bauernfeind 

Follow up question regarding this specific instruction:

"If you intend to give users permissions to reload a published App, a separate security rule will be necessary to enable Read and Update permissions on the App."

What exactly will a user be able to do (other than run reload tasks) if they are given update permissions on a published app? I'd like to allow them to run reload tasks from hub, but I don't want them making any changes to the underlying app...

Thanks!

[Or]

@John_Sathya @Sonja_Bauernfeind 

Attempting to answer my own question here, but still hoping for an official response...

Giving a user UPDATE access to App_* for published apps appears to allow them to change the app name or description, which obviously isn't feasible just to allow someone to reload the app. Unless there's a more specific property that we should be setting the security rule on, this means allowing users (or administrators) to reload published tasks from the hub isn't feasible. Assuming this is indeed the case, it's quite unfortunate as allowing task runs from the hub would have been great if it actually worked outside of one's own Work stream.

Hopefully there's a property out there that will allow reloads of published apps without allowing users to change important aspects of the app, or there are plans to introduce a solution for this in a near-future version. As it stands, the only available option is to continue using QMC to reload apps (as users can't break anything related to the app if you only give them access to the Tasks section and make the rule QMC-only).

[Sonja_Bauernfeind]

Hello @Or 

We'll add your question to our query with our developers around this! Thank you for getting in touch. 

[lblancher]

@John_Sathya @Sonja_Bauernfeind 

Thank you for the information on this, however, I would like to echo the comments of @Or that giving a user the Update permission on a published application is not good.  I'm excited (and subscribed) to find out what you hear from the development team about how to work around this limitation.

Regards,

Lucas

[Sonja_Bauernfeind]

Hello all!

The article was updated. 

@Ken_T  Ken, we've tested this in-house and based on the above rules, the end-user does not have access to the script.  They can see the Data Model, but will not be able to see or edit the script. You may have other rules in place that are in addition to giving more access. I would recommend posting about this in our forums.

My testing included two rules: The Reload rule and a single Update all Apps rules for a user named User 1. User 1 was then able to reload the app, manage reloads, edit the name/thumbnail/description, and see the Data Model. But no reload script. 

@Or @lblancher The update permissions are required. I got more feedback on how to prevent an update of the properties, but the thumbnail, description, name, etc are baked into the Update functionality.

I would suggest logging an idea for this to see what our devs can do about improving this experience. 

All the best,
Sonja 

[Or]

@Sonja_Bauernfeind  Thanks for getting this looked at and providing the relevant information. This does unfortunately mean that reload-from-hub isn't an option for me at the moment, but it's good to have confirmation. Luckily, reload-from-QMC is still working without allowing users to change any app information, so we'll stick to that option.