Denying Control Studio Access from the Pro Workstation

What would be the best way to keep the 'Operator' user account from accessing Control Studio on the Pro workstation?

  • There is a parameter that can be checked before launching control studio. Look at the vb script that runs when the icon for control studio icon is pressed. Use the parameter isConfig (check spelling as I am unsure of the exact name) and use that to decide to launch or not. You can books online for the exact syntax required

    Existing code

    Launch control studio (Not sure of the syntax as I am offline now)

    New Code

    If isConfig Then
    Launch Control Studio
    Else
    MsgBox "Your User Privileges Do Not Allow Control Studio Access"
    Endif 

    Steve Linehan
    +91-770-200-6903
  • In reply to Steve Linehan:

    Thank you for your reply. This looks like it will work. I only wanted to deny access for the Operator account only. Will this affect all accounts on the Pro workstation?
  • In reply to bjames:

    The problem is the operator can launch control studio from a variety of locations... some customizable and some not.

    Another solution is to ensure the Operator account does not have access to the application. The DeltaV Basic Operator group does not have access to the application (v12.3.1).

    Now, adding the operator(s) to the basic operator group is not trivial. They may lose all sorts of other rights you didn't bank on. A full assessment should be made and tested if this is way you choose to implement. My opinion is this is a centralized and all-encompassing way to address the issue.

  • In reply to Youssef.El-Bahtimy:

    I tried to find this similar feature in Graphics Studio and cannot seem to locate it or something equivalent. Is there a way to check that a user has can configure in DeltaV Live before opening control studio?
  • In reply to Brian Hrankowsky:

    You can use DLSYS.CanPerformFunction(key, area) and it returns whether the current user can perform the function.

    Example: DLSYS.CanPerformFunction("Can Configure","AREA_A")

    You can use the above on the interaction active for the CS button script but if you use in the script you would need to use await DLSYS.CanPerformFunctionAsync
  • In reply to Matt Stoner:

    Thanks

    interesting - i saw that function in the function menu in script assistant, but there was no help for it in the graphic studio help.

    likely we'd want to add a visibility condition to the control studio icon/button so that it is only visible when the user has configure permissions anywhere (for the toolbar) or in the area that the module belongs to (for the faceplate).

    is there a preferred way to do that?
  • In reply to Brian Hrankowsky:

    The Can Configure key is for all areas so it doesn't matter which area you check.

    Use the DLSYS.CanPerformFunction("Can Configure","AREA_A") but I think it would be better if it looks like the button is disabled or give the user a message saying they aren't allowed. Having it completely disappear sometimes causes many people to continue to ask if it is broken (speaking from experience).

    You can look at the CD_DCC_DETAIL Gem button if you want to see what I mean as it will show a disabled button that does nothing if the DCC block doesn't exist in the module (used on EDC_fp).

    If you script and put a message box that says they are not a valid user then you will need to use the await DLSYS.CanPerformFunctionAsync("Can Configure","AREA_A") for the check to either open CS or give the error message.
  • In reply to Matt Stoner:

    Thanks Matt,

    For future, if we need a similar capability based on a user defined key, is there a syntax for a user having a key in any area?

    Is there a way to determine what area a module is in? (I don't see a function that returns that information)

    Thanks!