Scripting with User Roles

Ignition
, ,
1

In my project, there are 5 roles: Admin: 4, Supervisor: 3, Engineer: 2, Operator: 1, and Monitor: 0. (shown in the picture below)

image
image221×529 3.02 KB

When scripting with components in Vision, I want to disable components that do not have the required user access level.
From Wonderware, when setting security level, each role corresponds with an integer. So, I just need to write If Clause, for example, User access required is Engineer or above, so the condition is “if securitylevel > 1”.
But in Ignition, User roles is defined in string value. So, it consumes time and effort when scripting aforementioned cases.
Has anyone confronted this problem so far? And how did you solve this? Thank you for your support.

2

Configure security levels:

and use the expression function isAuthorized:

1 Like
3

Because, technically speaking, a user can have more than one role, I would make a binary value of them so that there is no ambiguity.

A vision client tag (my example is called Security Levelwith the expression:

binEnc(hasRole('Operator'),
       hasRole('Engineer'),
       hasRole('Supervisor'),
       hasRole('Admin')

would give values of:
0: Monitor
1: Operator
2: Engineer
4: Supervisor
8: Admin

Then, for components you want to disable or hide, bind the appropriate property to the expression:
{[client]Security Level} > 1

image
image795×392 21.8 KB

image
image1015×377 26.7 KB

3 Likes
4

This would work if we're assuming that an admin should be able to do everything an operator can do, and then some but that may not always be the case.

Have we foregone the built in Security Settings?

As far as your actual question; scripting to check for roles you should define a handful of functions in your scripting library that you could reuse everywhere, then your if securitylevel > 1: would become something like if security.isLevel1():, or do something like if security.getAuthLevel() > security.adminLevel: where you have different level ints defined in the library as well. - then you could update these scripts/constants in the library at any time if you needed to change how security is handled,

2 Likes
5

Don't use any scripting or expressions if all you want to do is disable components.

3 Likes
6

Thank you for your reply. But in my project, disabling components is not the only thing when working with security.

7

In my project, it supposes that the higher levels can do things that lower ones have permission. And one user has only one role.

8

Typically, to match the functionality of Wonderware, in Ignition I assign each user to all the roles they have capabilities for. So Operators only have the operator role, supervisors have the Supervisor and Operator roles, etc. Then my Vision components only call out a single role as the minimum role required for that function. The great thing about doing it this way is if you want to change it up later to where you or management decides to only grant roles on a functional level, the only thing that needs to be changed are the roles each user is assigned. This way maybe only operators can operate the plant, but technicians can do calibration/scaling of transmitters, supervisors can change alarm setpoints, and engineers can change other higher level configurations. This way allows more granular control compared to what you were limited with on Wonderware (well, you could do it with WW, but it was a pain).

3 Likes