About levels of access rights

The following table summarises the levels of access rights that roles can have to the workspaces of Visma.net ERP.

Level	Description
Not set	Allows all roles to have access to the workspace until Revoked or Granted access level is set to the workspace for at least one role. After that, a role with this level is denied access to the workspace.
Revoked	Denies the role access to the workspace and its windows; for users with the role, the workspace and its contents are not visible. However, a role with this access level to a workspace may have access to the functionality of the windows within it. A user with such a role can access windows within the workspace only from other windows that have commands that cause the system to open the window (if applicable); the user will not be able to view the windows on the navigation pane.
Granted	Allows the role access to the workspace. You can, however, limit or revoke access to particular windows within the workspace. Only a user with a role with an access level to a window higher than Revoked can access it by clicking the workspace on the main menu and then clicking the window on the navigation pane.
View only	Allows the role access to the workspace. You can, however, limit or revoke access to particular windows within the workspace. Only a user with a role with the access level to a window higher than Revoked can access it by clicking the workspace on the main menu and then clicking the window on the navigation pane.

You can set up access rights to individual windows in the Hidden node (which cannot be accessed from the main menu) on the site map, but not to the node itself.

If you change a role's access level to a workspace from Not set to Granted or Revoked, and apply this access level to all nested objects, the role's access rights to workspaces and windows with the Not set access level are changed as follows:

• If you set the access level for the workspace to Granted, access level to the workspaces is changed to Granted, and access level to windows are changed to Delete (which allows full access to the window and its functionality).
• If you set the access level for the workspace to Revoked, access levels to the windows are changed to Revoked.

Access configuration works similarly for a workspace with the Not set access level and the windows within it.

The capability to set up an access level to a workspace and to all objects within it at once is helpful if the role's access level to most objects within the workspace is Delete or Revoked.

You can reset a role's access level to a workspace to Not set any time you want.
While resetting access levels, you have the option to update the access level to Not set either for all the workspaces and windows or for only the selected workspace.
Similar options are available when you set access level for a workspace to Not set.
For a procedure that describes how to reset access rights, see: Reset access rights to a suite or a module.

Access rights at the window level

Within each workspace, you can set the access rights that roles have to Visma.net ERP windows, which affects what users with those roles can access.
The level of access rights to the window is inherited by the entities and records that can be created by using the window.
You can set any of the following levels of access rights to windows.

Level	Description
Not set	When assigned to all roles, allows all roles to have access to the window until access rights are set to any other level for at least one role. After at least one role has been assigned another level of access rights, access to the window is denied for a role with this access level.
Revoked	Denies the role access to the window and its functionality.
View only	Gives the role restricted access to the window and its functionality. This level allows users with the role to view the window and any records associated with the window (in drop-down lists on other windows). This level forbids users with the role to edit details about any record, create new records or entities of the type, and delete records.
Edit	Gives the role restricted access to the window and its functionality. This level allows users with the role to view the window, select records, and edit details about any record. This level forbids users with the role to create new records or entities of the type, and to delete records. The Clipboard button is available on the window toolbar for users with the role.
Insert	Gives the role restricted access to the window and its functionality. This level allows users with the role to view the window, select records, edit details about any record, and create new records or entities of the type. This level forbids users with the role to delete records. The Clipboard and Insert buttons are available on the window toolbar for users with the role.
Delete	Gives the role complete access to the window and its functionality. This level encompasses the capabilities of the View only, Edit, and Insert levels, while also giving users with the role the ability to delete records. For users with the role, the Clipboard, Insert, and Delete buttons are available on the window toolbar.

By default, a new role has the Not set access level.

If you change access rights for a user role to a window or a window element, your changes affect only this window or window element.
To make the window available in the navigation pane to a user with this role, set the access level for the window to the View only level or more permissive and set the access level for the workspace where the window is located to Granted.

Each window includes containers of elements, such as nested windows, tabs, and grids.

Each container includes multiple elements and actions.

You can restrict access to any of these containers in the window.
The level of access rights a role has to the container is inherited by the entities and records created by using the container, if applicable.
For example: If you permit access for a user role to a grid, a user with this role can access all records in this grid.
By default, containers inherit access level from the window to which they belong.
You can set any of the following levels of access rights to the containers.

Level	Description
Inherited	Indicates that the role's access to the container is inherited from its access level to the window.
Revoked	Denies the role access to the container and hides it from the window for users with the role. These users will not see the container in the window.
View only	Gives the role restricted access to the container and its functionality. This level allows users with the role to view the container and any records associated with the container (in drop-down lists on other windows), if applicable. The level forbids users with the role to edit details about any record, create new records or entities of the type, and delete records, if applicable.
Edit	Gives users with the role restricted access to the container and its functionality. This level allows users with the role to view the container, select records, and edit details about any record, if applicable. The level forbids users with the role to create new records or entities of the type, and delete records, if applicable.
Insert	Gives the role restricted access to the container and its functionality. This level allows users with the role to view the container, select records, edit details about any record, and create new records or entities of the type, if applicable. This level forbids users with the role to delete records, if applicable.
Delete	Gives the role complete access to the container and its functionality. This level encompasses the capabilities of the View only, Edit, and Insert levels, while also giving users with the role the ability to delete records, if applicable.

By default, a role's access rights to the window elements and actions are inherited from the role's access level to the container of window elements to which elements and actions belong.

Thus, you should set the role's access level to the container of window elements before setting an access level to an element or an action.

Then you can set access rights to the window elements and actions.

You can set up the following levels of access rights to window elements.

Level	Description
Inherited	Indicates that the role's access level to the element is inherited from its access level to the container of window elements.
Revoked	Denies the role access to the element and hides the element. A user with the role will not see the element in the window.
View only	Makes the element read-only for users with the role. A user with the role will see the element in the window but will not be able to use it.
Edit	Allows the use of the element for users with the role.

If a particular window toolbar contains window-specific buttons, you can deny access for the role to these buttons, by setting Revoked for the buttons.

You can revoke access to some of the elements to hide their contents from users with View only access level.

Configuring a role's access rights at the window control level requires in-depth knowledge of Visma.net ERP functionality.

The level of access rights a user account has to a system object is defined by the user roles assigned to the user.

If a user has multiple roles assigned and the roles have different access levels to the system object, the following general rule is used: Visma.net ERP applies the most permissive access level among the roles.

For example: Suppose that a user is assigned 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.

With these settings, the user has the Granted access level to the Inventory module.

The algorithm of calculating access rights differs from the general rule described in the previous paragraph for a user with multiple roles assigned, some or all of which have the Inherited access level (which is applied to window element containers and window elements by default).

For this user, the following rules are used to calculate access rights to a window element container or window element:

• If all roles have the Inherited access level to the particular window element container or window element, the resulting access level is the most permissive access level of the system object at the next highest level, that is, the window (for a window element container) or the window element container (for a window element).
• If you have explicitly specified an access level to the particular window element container or window element for at least one role, while the other roles have the Inherited access level to this system object, then the resulting level of access rights is the most permissive access level among only the roles with explicitly defined access levels.
  
  The system ignores the roles with the Inherited level of access rights.
  
  This algorithm is used to optimise the speed of loading the window.

The following examples illustrate the system behaviour described in this section:

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.
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.
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.