password protection option for Locked VIs (read-only VIs)

[Nate_Moehring]

Currently the Protection options are Unlocked, Locked, and Password-protected.  I'd like to add a sub option to Locked, or perhaps a new option altogether that still allows you to view the diagram but not edit the VI unless you have the password.

I want to allow people to run and view all parts of the VI, but not allow them to make any changes to the VI unless they have the password.  This is one step above Locked and one step below password-protected which does not allow the user to view the diagram.

This is useful in an internal environment where you have many LabVIEW-savy users who want to look at how things work, but you still need some level of configuration management and you don't want to allow them to modify VIs.

To make this idea work and meet our needs NI would need to add support for two passwords:  One that prevents the user from modifying the VI and seeing the diagram (the current password-protected option), and a new password that prevents the user from modifying the VI but allows them to see the diagram and VI settings.  This is because we like to be able to debug problems even on a released application so we don't remove diagrams, we just password protect them.  Our release process would utilize both password options.  We would provide the read-only password to users as needed but never give out the modification password.

[Darin.K]

Contracts are often used as lingo in the CS and EE world to refer to what goes on between input and output.  My point is that changing the input (config file) is fundamentally different than changing the code, even if the resulting output is the same.  Allowing the code to change breaks the time invariance of my system.

OK.  For the problem solvers out there, here is my problem:  I need users in the lab to have the capability to look at code and debug code, but not have the ability to make changes.

Solutions proposed:

Source code control:  How does this prevent edits?  Good for blame, not good for preventing overnight data loss.

Remove Block diagrams:  How do you put probes on this?

PNG images:  How do I debug a picture?

Read-only files:  Not effective, users must have admin privileges.  Changes can still be made and not saved.  Destroys evidence after the crash....

Lock VIs: too weak and too easy to leave unlocked.

Lock VI in run mode: done and done.

Simpler solution?  I am interested in hearing it.

[AristosQueue (NI)]

> I need users in the lab to have the capability to look at code

> and debug code, but not have the ability to make changes.

Give them a machine you don't care if they destroy and the ability to restore from read-only backups on a server somewhere (aka source code control where they don't have check-in privileges).

> Lock VI in run mode: done and done.

Fails for the same reason as read-only VIs. Users can overwrite the VIs and then write them back when done to destroy evidence.

[jeff.kittle]

One option that I don't see discussed here is to convert your library (.lvlib) to a packed project library (.lvlibp).  If you check the option to keep the block diagram then users can see and debug the code without changing it.  If a change does need to be made then that info should be given to the developer to update, test and compile a new .lvlibp.