Skip to main content

I know you can lock a project from editing, but is there a way to password protect a project we install on a client's server so they can't view how we built it?  We've spent hundreds of hours building an ERP integration that we want to sell multiple times and don't want a client or competitor to simply rebuild it by exporting, or just looking at the project design and mimicking it.


 


 

As an alternative, can we delete a project after deploying?  So it could be run by the customer, and if we had to modify it, we would re-import it, modify, redeploy, and remove again?


Hi Mark, Only users that have permissions on the repository database can make changes to it. So by limiting who has access to the project repository you can protect your IP. The Service account running the scheduler would still need access, but you could block access from others. 


Yes, but if they have rights to the server that TX runs on, they can launch TX and then open the project and look at it.  Can they not?

The issue isn't just write protecting it, but keeping them from using the TX, we want to be the 'keeper' of TX and let them consume the DW & Cubes, but since it's their hardware, we can't not let them log onto their own machine


We have exactly the same concerns.


In the past you had the "runtime" option where the partner could set a password that would prevent editing of the project but not opening it or exporting it.


More granular security that prevents exporting would be great. For example tightening the "runtime" mode so that only the execution tab would show for those without the password. Or without the necessary AD rights would be even better.


You could then lock down the projectRepository even further by storing it encrypted for example, so that even someone who can take a backup cannot read the actual contents, which avoids people backing up your projectrepository and reading it in their Discovery Hub.


Not perfect but it would help ease concerns.


I do realize that when you lose the password you might be screwed but we work by developing on our own environment and then deploying to a customer's environment. So for us that is not an issue.


Reply