There have been a number of questions asking about how to get user information from PAC Display back to the strategy, and that looks like it would be pretty hard. Fortunately, I don’t want to do that.
All I’d like to do is change the appearance of elements in PAC Display based on the identity of the logged in user, just like security attributes can be set. The strategy need never know. But I’d really like to hide a button if a user doesn’t have permission to press it, or at a MINIMUM, grey it out.
Once suggestion is to create a completely redundant set of screens for each permission level, with only the different functions changed, but that strikes me as absurdly overcomplicated. If I have three levels of security, I don’t want to have to repeat every change I make to a common element three times - I just want ONE screen where I can indicate visually which buttons aren’t available at the user’s current security level. Is this possible? If not, can I STRONGLY request it in a future release?
Could you have “launch” buttons on your first loaded window that utilize the security attributes and when pressed set a value in the strategy for the operators level? Then you can bind the visibility attribute to that strategy tag. Unfortunately this won’t work if multiple users are connected at the same time since it relies on strategy tags (though you could possibly run softpac locally just to use it to store this tag and have a localhost control engine in PAC Display).
I feel like there would be a way to do this using AutoHotKey. If you set up an AutoHotKey script to watch the login window, you could theoretically post the username back to the controller when a user logs in. Once you have the username in the controller, you could do any number of things with it.
The key thing here is that I don’t need, or necessarily WANT, to communicate the user back to the strategy. What if there were two users, of different permission levels, logged in from different HMIs?
“Who is logged in on this HMI?” is information that ought to be available, and usable, locally, without reference back to the controller. In addition to setting the appearance of a button based on the state of a controller variable, it ought to be possible to set the appearance of the button based on the logged in user or group, and there’s no reason for that functionality to require storing a variable in the strategy.
@alt: I definitely understand, and I realize my suggestion isn’t perfect. In my application, which obviously may be totally different than yours, I’d consider sending the username to a different strategy variable per HMI workstation. It’s certainly an imperfect solution and one with complications, but for some it may be better than nothing.
