In a world where everything is becoming obsolete so fast, I am wondering if there is a way that we can protect some hard work we made in creating certain complex scripts and formulas that we will to deliver for consumption, but not for view/copy/edit.
Qlikview used to have such mechanisms but for the moment, in Qlik Sense, not even some of the best Qlik consultants across the globe that I know couldn't give a clear answer on this matter.
The topic is especially relevant for independent / external consultants, that might have to deliver an entire QS app to the customer's BI admin, that afterwards can look inside out in all the scripts and formulas and learn how to reuse them.
Also this is relevant for the Value Adding new partners the want to deliver BI as a service, even tho is a little bit less important.
But even in more common cases, is there a way so that an user can call an expression but cannot see/copy/modify the formula ?
Please consider at least 3 direction to answer:
- developer want to protect script against admin
- developer want to protect expression formula against admin
- developer/admin want to protect expression formula against regular user
( the forth developer/admin want to protect script against regular user seems to have some answers)
I am aware that some formulas might be transphered to script and the script can be protected against some users, but there are situations when such an approach will limit the flexibility of interface interactions, so please don't go there too much.
PS: Also please don't give answers regarding legal copyright protection, I am talking about hard core methods... 😉
I'm going to post and wait for others to answers I am curious to see if I missed something being new.
As far as I know you cannot do that at this time in Qlik Sense. Especially since the Admin of the system sets the security rules. If you host on your side you can control a lot of that with security rules. You will have to research that.
Another option (they will need a license on your server) You could provide access to items by using visual studio to connect to qlik and creating web pages. This might be a solution for when you want to demo what you have done or products.
Keep in mind after someone buys something they expect to be able to use the product as they see fit. The very idea of Qlik is to set forth a dynamic atmosphere. I myself do not see any benefit in denying access. As far as mistakes or messing up an app goes, users have to make duplicates in order to modify, so it isn't possible for them to mess up an existing app unless they become the owner of the app in the QMC.
I would suggest that a consultant gain a relationship and customer first with clients. Charge in accordance to the work you put in and be clear on the re usability in your contract. Be aware you should be explicit if you can sell an app you developed for company A to company B. If that isn't going to be allowed, an up charge may be in order.
All that you say is true most of the time for regular deliveries of Qlik apps.
But we are trying to "rent" applications and in this case all this transparency becomes a major risk of having clients that rent your app for 1 month, copy the know how and replicate your ideas in their own apps and then ... good bye revenues ...
I've been developing in Powershell for pipelines for Qlik so I haven't been on. Sorry for the late reply.
As I said you should be able to do so with the security rules on the QMC. However you cannot administrate or block things on their qlik service. I would give them a user and push qlik to an endpoint for them to log into. Then I would set up my security settings so they can use the rented applications on my server, not theirs. I'd forward the costs of the licence and a portion of the maintenance of the server as well as rental costs.
This is the unsolved issue though. In order to fill it with their data you need access to their data to map. So what is to stop you from using their data much the same way you do not trust them to use your scripts, other than a piece of paper.
It looks like you are a Qlik Partner so you should be able to sell a package deal to them instead of holding back and renting out your apps.
Today I came up with something that you could do perhaps. It's kind of orthodox.
Create a domain user on their systems. Setup that user to report to an end point. All log ins/log outs and uses. Logon scripts ect. Even if the administrator changes something on the user should report it. If it goes dormant you should know as well. (You could attach it to a service) Then you can use this user to create apps and use security to lock it down.
You can then publish the reports to a "rental stream" and if the user is ever accessed you'd know. There would be no reason for them to access that user or shut it down or anything. Basically a break in contract. You'd have to be sure that it wasn't a connection issue ect sometimes, but if you log enough information there isn't a way they could really get around it.
You'd make it so no other users can duplicate sheets or apps without being the owner of the app, and you could also have your service reporting every so often on who is owner of the apps. Might even be able to setup that service to delete the apps in the stream if it can't read your end point.
Interesting approach. Will ask my SysAdmin and Dev to look into it.
Thank you for sharing the idea.
Will come back after testing.
(It's true it is kind of on the edge, but in case no other solution there, in some cases, it looks like it could help)
Since I been delving into Qlik API instead of a domain user you could just use a Qlik user and a special app that uses the API to read into each of your Apps in the stream and push out an API call to your server that way. This is barely a little less orthodox. You loose the domain log in log out stuff so it could be modified with an insanely efficient staff. However, the same concepts apply, a qlik user that owns all the apps with security rules locked down, only a job setup to run a qlik app that monitors the rest of the qlik apps instead of a service you would have to install. This idea keeps intriguing me so my mind keeps revisiting it as I work.