From the docs, it mentions users with proper credentials…however other than reentering the password for the user that locked the screen, I don't see a means of entering a username. I'm using this globally as a clean screen function which worked fine up until recent migration to an SQL db usersource. That usersource uses a badge ID, and the password is hard-coded the same for all operators, so my current login does this. But I see no method of doing this on the system lock interface. Are there any methods or classes that aren't documented that can be exposed, or is that the limitation? Because the common password is hidden and hard coded, noone really knows what to enter.
If that's the limitation, I'm considering just using a timeout and unlock. I assume that the function of calling the system lock restarts the inactivity time? If so, is it best to just have a client timer script that checks for inactivity > X? These are touchscreens, so does the wiping around on the lockscreen restart inactivity, or does it time until the screen is unlocked? I'm not sure how inactivity behaves under system locked. I thought of just using the islocked method in a timer, but I didn't see any way to insure the timer resets upon lock.
Can't speak to the overall wisdom of this approach, but it is possible to make your own modal popup window in Vision that prevents user interaction, so you can avoid the lockScreen function and do whatever you want on your popup:
Use of getGlobals within a Vision client is pretty safe; even if you trigger a terrible memory leak you can restart the client pretty easily.
It's using it on the gateway that you want to be very careful with your PPE
But really, the 'risk' is mostly about storing user defined Python class objects. As long as you don't do that (built in data types and Java imports are fine), I wouldn't be scared away from the potential utility of the globals dictionary.