Access rights level for user accounts with multiple roles
General rule in Visma Net
If a user has multiple roles assigned and the roles have different access levels to the system object, Visma Net applies the most permissive access level among the roles.
The following table illustrates this with an example.
| When | And | Then |
|---|---|---|
| A user is assigned both the Employee and Sales manager roles | The Employee role has the Revoked access level to the Inventory module, and the Sales manager role has the Granted access level to this module | the user has the Granted access level to the Inventory module, that is, the most permissive level. |
Roles with inherited and defined granular levels
The method of calculating access rights differs from the general rule described in the previous paragraph for a user who has been assigned multiple roles. This happens when some or all of these roles have the Inherited access level, which is applied to window element containers and window elements by default.
For this user, the following two rules are used to calculate access rights to a window element container or window element:
RULE 1
| IF | THEN |
|---|---|
| all roles have the Inherited access level to the particular window element container or window elements | the resulting access level is the most permissive access level of the system object at the next highest access level. |
In practice, this means that a window element container will have the same access level as the window that is closest in the access hierarchy. Similarly, a window element will have the access level of the nearest element container up in the hierarchy. See example 1 below.
RULE 2
| IF | THEN |
|---|---|
| you have explicitly specified an access level to the particular window element container or window element for at least one role. Let’s say you have chosen the “View only” access level to a Release button, while the other roles have the Inherited access level to it. | this gives you the access right that is the most permissive access level among those roles with explicitly defined access levels, that is the “View only” level. See example 3 below. |
In these cases the system ignores the roles with the Inherited level of access rights, which is something to consider when making changes at the detail level.
This algorithm is used to optimise the speed of loading the window.
Access level examples: Scenarios with multiple roles
The following are additional examples that illustrate the system behaviour described in this section.
Example 1
Suppose that a user is assigned the Employee and the Accountant user roles. The Employee role has the Revoked access level to the Customers (AR303000) window, and the Accountant role has the Edit access level to this window. The default access level both roles have to the window elements is Inherited.
The user with these roles, then, has the Edit access level to the Customers (AR303000) window and its elements.
Example 2
Suppose that a user is assigned the Employee and Accountant user roles. Both roles have the Insert access level to the Purchase invoices (AP301000) window. You have decided to forbid users with the Accountant role to release invoices. For the Accountant role, you specify the Revoked access level for the Release button in this window. The Employee role has the Inherited access level to the Release button. With the settings you have specified, the user has the Revoked access level to the Release button.
Example 3
Suppose that a user is assigned the Employee, Warehouse Worker, and Sales assistant user roles. All these roles have the Insert access level to the Receipts (IN301000) window. The Employee role has the Inherited access level to the Release button on this window, the Warehouse worker role has the Revoked access level to this button, and the Sales assistant role has the View only access level to this button. As a result, the user has the View only access level (the most permissive level of the two explicitly defined levels) to this button.