Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi Folks
I'm using the VizLib button for manually reloading an app. After some testing, I found that I need to create a security rule, which gives the users of the app the privilege to update the data connections, used in the load script.
I would have expected, that a read access for the data connection is sufficient, but it isn't. Does anybody know the reason for this behaviour?
We are using the November 2020 release of QlikSense Enterprise on virtual Windows machines, so the Qlik button does not have the reload feature yet.
Looking forward to your feedback. Thank you very much for your support.
Best regards,
Dirk
Hi @dirk_fischer - yes this is expected as reloads of published apps require connection ownership or additional security rules. Qlik requires it to be a Professional license type as well. However....
Additionally, for Writeback scenarios, we have a serverless version, and the user writing the data needs access to the connections and the ability to reload a published app - this requires additional security rules spelled out here: https://community.vizlib.com/support/solutions/articles/35000156627-vizlib-writeback-table-guides-ql... . With the Enterprise version of Vizlib Collaboration, it works will all user types (Professional, Analyzer, and Analyzer Capacity) and writes and reloads are securely handled by a Qlik Service account. Here are some of the FAQs.
Please reach out to Vizlib Support and we'll help get you going. https://community.vizlib.com/support/solutions/articles/35000167040-vizlib-writeback-table-input-for...
Hi @dirk_fischer - yes this is expected as reloads of published apps require connection ownership or additional security rules. Qlik requires it to be a Professional license type as well. However....
Additionally, for Writeback scenarios, we have a serverless version, and the user writing the data needs access to the connections and the ability to reload a published app - this requires additional security rules spelled out here: https://community.vizlib.com/support/solutions/articles/35000156627-vizlib-writeback-table-guides-ql... . With the Enterprise version of Vizlib Collaboration, it works will all user types (Professional, Analyzer, and Analyzer Capacity) and writes and reloads are securely handled by a Qlik Service account. Here are some of the FAQs.
Please reach out to Vizlib Support and we'll help get you going. https://community.vizlib.com/support/solutions/articles/35000167040-vizlib-writeback-table-input-for...
Hello @dirk_fischer
Please refer to below article to know information about access control.
Thanks,
Padma Priya
Hello PadmaPriya
thank you very much for your response. I looked at the article, but unfortunately it does not explain, what's the difference between giving the user the privilege to read from a data connection and to update from a data connection. Probably there is a difference in the functionality and I would like to understand this difference.
Maybe it's just that for reloading an app, you have to have the privilege to update the app and also to update the data connection - so a sort of "as designed".
To know the reason behind the requirement would give me a better understanding of what#s going on that's what I'm looking for.
Anyhow, thank you very much for your support.
Best regards
Dirk
thank you very much for your reply. So if there is a design requirement to have connection ownership for reloading published apps, then the update privilege is the requirement to have, if you want to reload such an app with a VizLib action from the button.
I have the administrator role myself, so it's logical, that I don't have any problems reloading the app, even if the data connection belongs to the Qlik service account.
Thank you very much for the hint with the professional license type - in the moment we are using these licenses only, but in the future this might change and then there is something to be taken into consideration before building an app with reload functionality.
Best regards,
Dirk