Emerson Exchange 365

It depends on how the operator calls (open) the graphics. If you use buttons to call a graphic, you can put code behind the button to check which user is logged on. You can also use visibility on the button to prevent it displaying if the correct user isn't logged on. Unfortunately, if they use the regular open graphic popup from the toolbar, this will list all the graphics in the pic folder, which means they could bypass your button selection logic.

It might be easier to use visibility on the objects you don't want less privileged users to see, the graphics still opens regardless of user, but the sensitive data is not visible, this prevents any chance of bypassing your security mechanism.

In reply to AdrianOffield:

Dear Adrian, thanks for your answer.
i don't want to use software key by code. there isn't any way for this by User Manager or other program?

In reply to AdrianOffield:

What about removing the OPEN PICTURE Button on the ToolBar, or hiding it based on logged on User. And using a controlled Picture list or navigation scheme. Although the pictures are on every workstations, and there is no User security to manage them, one needs to have access to the picture via the interface. The Picture Directory popup can be customized to list only the pictures an operator can select. This list can have custom dynamics added to manage access to pictures based on current user. This is available as standard.

For many customers, we implement a custom navigation scheme, where we control which displays a user has access to, and the first thing done is to remove the generic Open Picture button from the tool bar.

And as Adrian suggests, additional visibility options are added in graphics where certain information is reserved.

Andre Dicaire

In reply to Andre Dicaire:

Andre,

Your response implies that you can figure out the permission level of the logged on user. I've only been able to get Operate to tell me some very narrow permission levels about a user. Is there a way to retrieve the group the user belongs to? Otherwise, what are you using for your criteria?

In reply to dave_marshall:

Dave,

There is no simple means to determine user security access via DeltaV Operate Scripts. In the cases where user name is used to determine OPERATE behavior (i.e. hide or show a button), it is typically done by having a short list of permitted users encoded in a script ( or a short list of denied users), and you set that up manually.

For more ambitious users, the USERT.SCR file, along with the WLNAMES and ANT, could be parsed by a function that can check if a User has a particular privilege or LOCK assigned. Note that these files are system generated and Emerson does not support their use by users. What that means is, the content and structure of these files may change, and this would not be announced or documented. In other words, don't call the GSC complaining a hotfix or upgrade broke your function. Also, DO NOT attempt to modify any of these files.

These are structured text files. in the USERT file, there are multiple entries for each user, based on Plant Areas, and for BPCS and SIS.
USERI
{
NAME='ADI'
DOMAIN='PLANTWEBCAL.DELTAV.SYSTEM.LOCAL'
AKEYS { AREA=1 WLOCKS='1,2,3,4,5,6,17,18,19,20,21,22,23,16,15,14,13,12,11,10,9,8,7' }
}
Write Locks are listed with the index. The WLNAMES file can identify the index's Name.

ITEM { WLOCKS=18 NAME='Can Configure'}

If I want to know if a user has "Can Configure" for BPCS, that is a site wide key and will be in none or all the areas for that user. So searching the file for the first instance of the NAME, I find the line starting with "AKEYS" for BPCS or "SISAKEYS" for SIS, and parse that line to find ",18," which is the index for "Can Configure". The example above shows the write locks for AREA = 1 (AREA_B, or whatever you named it)

If you were looking for say a special privilege, like Tuning or User Lock 04. these are assigned per area. You might need to check all the areas for that user. Not a big deal as your function would loop through the file reading each line checking for user, then area then lock, as needed.

Now, you will need a trigger to call this function, which would be whenever the current user changes. When someone logs onto the console, and starts OPERATE, you can set the appropriate flag parameter for your hidden icons and such. When the Current User changes, you update this flag and that changes the visibility of those icons. You'll have one function to check during an upgrade based on any changes that may or may not occur to these source files.

Note that you want to keep this simple, and have solid error checking so you don't cause an issue with user logon actions.

Andre Dicaire

In reply to dave_marshall:

Dave,

The runtime privileges and user information in DeltaV does not include Group information used in User Manager. The Groups in User Manager are a method to create privilege profiles and assign those write locks/keys to users. Whether the key is assigned explicitly, or via a group, the result is a collection of keys for each area for each user, and this is what is downloaded to each console.

In addition to the DeltaV write locks, each user is placed in some Windows security groups to give them access to the windows applications, allowing them to launch, or save files etc.

I'm not aware of any other functions that expose User privilege in Operate. What "narrow permission levels" did you get and how did you get that.

Andre Dicaire

In reply to Tyler Anderson:

Thanks Tyler. I tried to find some user information in BOL, and having never used this, I did not find it. Thanks for pointing us to the DeltaV Operate Pictures Help. Much better answer.

Andre Dicaire

In reply to Andre Dicaire:

Hi Andre,

Thank you for your thorough reply and the valuable information. I've just recently discovered the SCR files and the treasure trove of useful information they contain.

When I referred to the narrow permission levels, I'm talking about at least one specific VBA functions that will return a boolean response. I say at least one because the only one I have found so far is: frsuserconfigprivchk.

Dave

In reply to Andre Dicaire:

Hi,

In one of the similar application, we used 3 text files (Like PCSD language resource files), to list & index all areas, stations, & users. During the operator interface loading, these indexes are loaded into arrays in the interface.
Upon operate run mode, the station name is checked & index is stored. During username change (value found on toolbar) the user index is stored. Upon each new login, a code combines these two indexes & generates a unique user group integer for that machine on that location (0-10 = Project_Visitor access, 11-99=Project_Operator access, 100-199 = Project_maintenance access, etc.)
During opening of specific graphic (initialize script), the area name index is checked for the tag, & compared with above user index integer, to make applicable objects visible or not. Off-course this strategy was foreseen & implemented from project specific template/toolbar design phase itself.

We had to go through this routine, as:
1. We had multiple locations & multiple areas per location, so it was very difficult to check for all accesses at all instances.
2. Areas accessed from different locations needed different control privileges for same user groups.
3. User groups were custom named/leveled for project.
4. Customer did not like to see "User do not have access for this function or area is not assigned to alarms & events......." error. If access is not there, the buttons should be invisible.
5. DeltaV standard keys (can config, can Install, etc are not enough in most of the cases). Another trouble with THISUSER/USERCAN function is that is needs "area name" & not "area index". So, looping routines cannot be used here. Area indexes can have gaps, which gives errors. Also, area name vs. index structure is not always maintained/available in operator interface, so you cannot really know which area you are checking the rights to.

The above code includes custom scripting, & manual update on resource files. But it works fine for all variations & possibilities.
I will now check with the above files (USERT) specified by Andre, to see if the manual update of resource files can be eliminated... :-)

Thanks.
Amod Bobade.

In reply to Tyler Anderson:

Hello Tyler,

I was browsing the forum in connection with displaying user privileges on graphic display. Your input is good enough to display all required data. I'm just curious if you know any method of changing user privileges in similar way. Of course, we can always use User Manager and (un)assign keys there and then download necessary nodes. Is it possible to do it via VBA script in operate or other way that doesn't require downloading after applying changes?

Thomas

Hi ,you can create user with required privilege ,and this user use only by authorize person,and for normal operator can use normal user only for normal operation work .