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.

[AristosQueue (NI)]

As a member of LV R&D, I say, "Yes, we could do this if you really want."

As a user of LabVIEW, I say, "Why would we want this?" To me, that sort of thing is the job of your source code control software and all the configuration options that it supplies. Besides, if people can see the code, they're going to want to be able to try adjusting it, whether for adding comments or for their own experimentation. To me, it just doesn't make any sense to say "you can see but not change this." Let them make changes. It's your source code control system that should stop them from checking in changes if they're not authorized to make changes.

[Nate_Moehring]

It's not that I'm concerned about their changes getting into SVN.  There have been instances when we go to a lab workstation and look at the version number of our software and have an expectation of how it should behave, only to find through investigation that somebody has locally modified a VI.  Engineers on the bench (who aren't the authors) may have valid reasons for wanting to look at the code, especially for algorithm validation or just to understand why the software is behaving as it is, but are not authorized to be changing the software because they think they know best.

[jcarmody]

I use TortoiseSVN in Windows; all I have to do is look at the glyphs in Windows Explorer to know that something was changed.

[Nate_Moehring]

Many of our lab machines are not on the network, or their on a closed network that doesn't have access to the corporate SVN server.

[AristosQueue (NI)]

Nate: And marking the files read-only and not giving those engineers elevated system privileges isn't enough?

[Nate_Moehring]

When a machine is off network users typically get elevated privileges, not restricted.  And in either case, I am not the admin of the machines.

[AristosQueue (NI)]

> When a machine is off network users typically get elevated privileges, not restricted.

I would agree if "off network" was equivalent to "off system entirely". But as long as the machine is doing useful work as part of a larger system, privileges should be handed out to do your job and nothing more. And that means no saving over files marked read-only.

> And in either case, I am not the admin of the machines.

But someone is. I don't think it is LabVIEW's job to fix this. If LV adds a setting like this, someone who thinks they know better will just copy the diagram to a new VI and then save over your VI anyway. You aren't preventing anything unless you've protected the file system. Talk to the system's admin and fix the engineer's login privileges.

[Nate_Moehring]

Effectively recreating the VI with their change and overwriting the original VI isn't straightforward, they would need to manually check and set all of the VI properties.  But you're right, it's a hack I hadn't considered, one that's conceivably easy enough that I can see someone trying it and making matters worse.

Getting to the IS department involved is another issue...

My idea may not be bullet proof, but I'd still like to see it as an option.  OR, alternatively, NI needs to publish a VI Viewer application, which I know has been requested in the past and would be very useful.  But this does not meet all of my requirements.

[AristosQueue (NI)]

Maybe save your VIs without block diagrams and put PNGs of the diagrams on the machine if the engineer needs to look at them?

or use vugie's VI viewer tool from LAVA, which allows for flipping through the case/event structures.

[Darin.K]

So a developer should have to go to all of the customers computers and verify that they have proper IT configurations and SCC?  And if certain settings aren't set on the customer machine then every askance look can trigger a dirty dot.

It is not unreasonable for a user of a piece of software to want to see the code.  That makes for good users IMO.

It is not unreasonable for a developer of a piece of software to want assurances that when problems are encountered changes to the code can be summarily ruled out.  And in the real world, some code can only be run on site.  If a problem is reported I do not like spending half an hour going over what may or may not have been changed.

The solution seems quite simple.  The developer sets an access level : have at it, look but don't touch, don't even look, and changing it requires a password.  Look but don't touch (this idea) could simply mean that the password is required to change from run mode to edit mode.

This new system would be a reasonable way to distribute vi.lib VIs.

Preventing the manual override is pretty easy to do with a lvlib or two.  At any rate, the users aren't your adversaries, they simply have a ingrained instinct to poke things when they are able to.  A simple barrier to this behavior is usually all you need.