Recently, I started a topic asking if there is any way to lock a component to prevent changes by users.
In other words, what I would like is for the user to be unable to expand the component to make changes, unless they provided a password to expand it.
Still on the same subject, I thought about limiting the ability for a user to export the workflow for other users to use, which would cause me to lose traceability.
And why would I want to block the expansion of a component?
A: Because there are various codes and pieces of information in the structure that the user could alter in a specific situation, or even information that the user should not copy or know.
(And by the way: I know that the Knime Hub has several features for versioning, controls, and so on…)
Since I can’t block the ability to expand a component, I thought of a VERY SIMPLE AND WEAK, not to say “childish,” way to force the user to type a “password” just to release the final result.
This doesn’t prevent the user from expanding a component at all, but it helps to trick users who are not very attentive to the rules.
From the beginning, this conditions a user to do what was explained in the manual and not try anything different.
I would like to know if there is a slightly more intelligent way to do this.
The real situation is that I developed a workflow over a 3-month period, and this workflow can be used not only by the company I work for, but also by another company in the same industry.
The effort dedicated to this work can be copied and used by another company.
Scenario: The user utilizing the workflow can download and save it, having put in no effort themselves, and then be hired by another company with the premise that they were the creator of the workflow. My ideal need would be to prevent the propagation of the workflow through user copying.
I know that Knime is a collaboration tool, but when this collaboration breaks the company barrier, it stops being collaborative and becomes competition.
Therefore, the ideal solution would be to create a feature to password-protect a component, allowing it to be expanded or executed only after a password is entered.
"In addition, I know that having a password option on a component will create a third-party market for selling and buying components.
People will create workflows and sell them with usage passwords. However, once someone buys the workflow and has the password, they could sell it to another third party. There would be a need for private key control.
This market already exists with ‘n8n’.
For Knime, it could be an opportunity to expand the brand, but it might go against the brand’s principles.
"Imagine all the public components that already exist in Knime.
The greed of those who created them and opportunity to seel it, and breaks the Knime principles.
Not that this ialready possible. (sell it)
Someone creates a YouTube channel, explains the component they made, and sells it. However, the person who bought it could also sell it, or even make it public on the Knime Hub."
But for me, (I 'm manager) Those who want to use the password it’s a risk for competition between workers.
(I think I said too much
