Visma Net
About levels of access rights
With Visma Net, you can control access to system objects at broad and granular levels, down to
the control of window elements, such as buttons, text boxes, and check boxes.
Users
are assigned to roles, and you give these roles the appropriate levels of access
rights (or access levels) to workspaces, windows, and window
elements.
You have to be very careful when you assign multiple roles to a user account because these roles may have different levels of access rights to system objects.
Access rights tier structure
When configuring user roles, there are three levels of access rights to consider:
Level | Description |
---|---|
Workspace level | Access at an overall level, such as an entire workspace. Access on this level will also impact windows and entities. |
Window-level | Access based on windows. For instance, access to a specific window, but not to the window settings. You can configure whether a role can view or edit the window information. |
Entity level | Access based on functionality. For example, the ability to access and edit sales invoices, while excluding changes to currency. |
The following table summarises the levels of access rights that roles can have to the workspaces of Visma Net.
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. Users with this role will not be able to see the workspace or its contents. However, users with this access level may still have access to the functionality of the windows within the workspace. They can only access these windows from other windows with commands to open them, and they cannot 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. |
View only |
Allows the role access to the workspace. You can, however,
limit or revoke access to particular windows within the workspace. |
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.
Effects of changing access levels from Not set
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 | Then |
---|---|
Granted |
the access level to the workspaces is changed to Granted,
|
Revoked | the 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.
Resetting a role’s access level
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.
Within each workspace, you can set the access rights that roles have to Visma Net windows, which affects what users with those roles can access.
By default, a new role has the Not set access level.
Inherited access
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. The level of access rights to the window is inherited by the entities and records that can be created by using the window.
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.
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. 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. |
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.
Inherited access
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 instance, 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. |
View only |
Gives the role restricted access to the container and its
functionality. 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. 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 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. This includes the elements and actions to which they belong.
Therefore, it is recommended to set the role's access level to the container of window elements before setting an access level to an individual element or action. Once this is done, you can then 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 functionality.
Related concepts