Diffrent AccessLevels for operators groups for the buttons in one graphic

Hi Michal!

Have you checked out the function IsAssignedRole() ?

As you describe, creating different windows user groups for the various roles are the most straight forward possible and since $AccessLevel will get the highest value of any group you need to be able to query the various roles.

It should get you going where a $AccessLevel approach is not providing enough dimensions.

Hi Richard,

thanks a lot for your answer, I'm going to check it soon. I was also thinking about AddPermission() function, have you ever used it? Do you have any experience with it?

PS. I'm not using OMI in this project.

For a stand-alone InTouch application, you have the option of InTouch or OS Security.

The option of ArchestrA will require your application to be used together with Application Server and will connect to whatever Authentication settings is used there.

Then "InTouch" is used, you will define the users, passwords and Access Level in Window Maker, when you login in Runtime, you will be assigned the access level of your user and can build your Animations and behavior based on $AccessLevel and/or the $Operator tag

$AccessLevel has a range of 0-9999, where above 9000 will also give you permission to edit users.

It is then up to you as a developer how you want to use the 0-9999, 
Animations of Disable or Visible are commonly used to ensure that the logged in user does only have access to the proper functions.

Lets say, Button 1 $AccessLevel >= 1000, Button 2 $AccessLevel >= 5000 and Button 3 $AccessLevel >= 8000.

And $Operator == "Richard" might gain access that other users don't have or $Operator == "None" will hide or disable buttons and so on. (But it is not advisable to build a long lasting application with direct references to specific users even if it is convenient during development).

In OS mode, there is no way for you to link a user group to a Access Level in Window Maker and it is here where you need to use the AddPermission().

https://docs.aveva.com/bundle/intouch-hmi/page/315680.html

The AddPermission() is preferably used in the Application Startup script and will then link domain or local usergroups to a Access Level.

The great advantage of OS Security is among other things that you can offload user administration to IT, password change, new users, disable users, can all be managed in the Active Directory witch is usually already in place in a organization, or if you simply want to use "Single Sign-on" using the LogonCurrentUser() function.

If a runtime user logs in and is a member of multiple groups, the access level will be determined by the group with the highest access level.

Even if this is used you are challenged with that your animations that you use are restricted by one dimension.

The problem is when you want a certain user to have access to both Button 1 and 3, then greater then, or less than a integer value could become an issue.

Then you need to make direct statements, and it is here where the IsAssignedRole() becomes more intuitive.

You can use it in a statement like 

IsAssignedRole("MyAD\SCADA-Users") or IsAssignedRole("MyAD\SCADA-Admins")

To link an animation to multiple groups, all depending on your need.

It is of course possible to use similar approach using $AccessLevel

$AccessLevel == 1000 or $AccessLevel == 5000

It all comes down to how you want to build your application, remember, you can belong to multiple groups, but only gain one access level.

For a stand-alone InTouch application, you have the option of InTouch or OS Security.

The option of ArchestrA will require your application to be used together with Application Server and will connect to whatever Authentication settings is used there.

Then "InTouch" is used, you will define the users, passwords and Access Level in Window Maker, when you login in Runtime, you will be assigned the access level of your user and can build your Animations and behavior based on $AccessLevel and/or the $Operator tag

$AccessLevel has a range of 0-9999, where above 9000 will also give you permission to edit users.

It is then up to you as a developer how you want to use the 0-9999, 
Animations of Disable or Visible are commonly used to ensure that the logged in user does only have access to the proper functions.

Lets say, Button 1 $AccessLevel >= 1000, Button 2 $AccessLevel >= 5000 and Button 3 $AccessLevel >= 8000.

And $Operator == "Richard" might gain access that other users don't have or $Operator == "None" will hide or disable buttons and so on. (But it is not advisable to build a long lasting application with direct references to specific users even if it is convenient during development).

In OS mode, there is no way for you to link a user group to a Access Level in Window Maker and it is here where you need to use the AddPermission().

https://docs.aveva.com/bundle/intouch-hmi/page/315680.html

The AddPermission() is preferably used in the Application Startup script and will then link domain or local usergroups to a Access Level.

The great advantage of OS Security is among other things that you can offload user administration to IT, password change, new users, disable users, can all be managed in the Active Directory witch is usually already in place in a organization, or if you simply want to use "Single Sign-on" using the LogonCurrentUser() function.

If a runtime user logs in and is a member of multiple groups, the access level will be determined by the group with the highest access level.

Even if this is used you are challenged with that your animations that you use are restricted by one dimension.

The problem is when you want a certain user to have access to both Button 1 and 3, then greater then, or less than a integer value could become an issue.

Then you need to make direct statements, and it is here where the IsAssignedRole() becomes more intuitive.

You can use it in a statement like 

IsAssignedRole("MyAD\SCADA-Users") or IsAssignedRole("MyAD\SCADA-Admins")

To link an animation to multiple groups, all depending on your need.

It is of course possible to use similar approach using $AccessLevel

$AccessLevel == 1000 or $AccessLevel == 5000

It all comes down to how you want to build your application, remember, you can belong to multiple groups, but only gain one access level.