# Scripting with User Roles **URL:** \ **Category:** Ignition\ **Tags:** ignition81, vision, scripting\ **Created:** [September 16, 2024, 8:25am UTC](https://forum.inductiveautomation.com/t/scripting-with-user-roles/96007 "2024-09-16T08:25:44Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Phat\_Truc](https://avatars.discourse-cdn.com/v4/letter/p/dc4da7/32.png) [@Phat\_Truc](https://forum.inductiveautomation.com/u/Phat_Truc)\ **Post date:** [September 16, 2024, 8:25am UTC](https://forum.inductiveautomation.com/t/scripting-with-user-roles/96007/1 "2024-09-16T08:25:44Z")
In my project, there are 5 roles: Admin: 4, Supervisor: 3, Engineer: 2, Operator: 1, and Monitor: 0. (shown in the picture below) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/8/9/8929d07d86bae222c97e8e2fae2fb773fbd88fa2.png) 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. ---
**Author:** ![pascal.fragnoud](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pascal.fragnoud/32/24728_2.png) [@pascal.fragnoud](https://forum.inductiveautomation.com/u/pascal.fragnoud)\ **Post date:** [September 16, 2024, 9:33am UTC](https://forum.inductiveautomation.com/t/scripting-with-user-roles/96007/2 "2024-09-16T09:33:42Z")
Configure security levels: > **[Security Levels | Ignition User Manual](https://www.docs.inductiveautomation.com/docs/8.1/platform/security/identity-provider-authentication-strategy/security-levels)** > > With Security Levels, you define a hierarchy for access inside a Perspective Session or Vision Client. This authorization system provides a way for you to map roles from an Identity Provider (IdP) to Ignition roles. Any IdP can be used to provide... and use the expression function `isAuthorized`: > **[isAuthorized | Ignition User Manual](https://www.docs.inductiveautomation.com/docs/8.1/appendix/expression-functions/users/isAuthorized)** > > Returns a qualified value with a boolean value which is true if the user in the current Session is authorized, false otherwise. ---
**Author:** ![JordanCClark](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/jordancclark/32/83362_2.png) [@JordanCClark](https://forum.inductiveautomation.com/u/JordanCClark)\ **Post date:** [September 16, 2024, 12:25pm UTC](https://forum.inductiveautomation.com/t/scripting-with-user-roles/96007/3 "2024-09-16T12:25:34Z")
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 Level`with the expression: ```python 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](https://us1.discourse-cdn.com/inductiveautomation/original/3X/6/0/6065cfb3741d695751a70bccb77628676b2fd8ef.png) ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/d/1/d190c1f09a1ecdba21925b2f70cdcec384c739e9.png) ---
**Author:** ![amarks](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/amarks/32/45610_2.png) [@amarks](https://forum.inductiveautomation.com/u/amarks)\ **Post date:** [September 16, 2024, 1:20pm UTC](https://forum.inductiveautomation.com/t/scripting-with-user-roles/96007/4 "2024-09-16T13:20:44Z")
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, ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [September 16, 2024, 1:59pm UTC](https://forum.inductiveautomation.com/t/scripting-with-user-roles/96007/5 "2024-09-16T13:59:34Z")
> **[Component and Window Security | Ignition User Manual](https://www.docs.inductiveautomation.com/docs/8.1/ignition-modules/vision/security-in-vision/component-and-window-security)** > > Role-based security inside of Vision works on multiple levels: component, group, container, and window levels. Each of these levels also have special categories of security that help with tuning security to various design considerations. Don't use any scripting or expressions if all you want to do is disable components. ---
**Author:** ![Phat\_Truc](https://avatars.discourse-cdn.com/v4/letter/p/dc4da7/32.png) [@Phat\_Truc](https://forum.inductiveautomation.com/u/Phat_Truc)\ **Post date:** [September 17, 2024, 1:12am UTC](https://forum.inductiveautomation.com/t/scripting-with-user-roles/96007/6 "2024-09-17T01:12:45Z")
Thank you for your reply. But in my project, disabling components is not the only thing when working with security. ---
**Author:** ![Phat\_Truc](https://avatars.discourse-cdn.com/v4/letter/p/dc4da7/32.png) [@Phat\_Truc](https://forum.inductiveautomation.com/u/Phat_Truc)\ **Post date:** [September 17, 2024, 1:14am UTC](https://forum.inductiveautomation.com/t/scripting-with-user-roles/96007/7 "2024-09-17T01:14:30Z")
In my project, it supposes that the higher levels can do things that lower ones have permission. And one user has only one role. ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [September 17, 2024, 1:56am UTC](https://forum.inductiveautomation.com/t/scripting-with-user-roles/96007/8 "2024-09-17T01:56:45Z")
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).