Permissions in the NAVIGATOR system
NAVIGATOR system has a complex permission system is implemented. Permissions to a specific system element (document, dictionary element, budget, etc.) may result direct from user rights, organizational structure, membership in groups or roles in the system. In addition, permissions can depend on object relationships such as document category, task structure, and budget structure.
In earlier versions, the permission systems were limited to selected object categories, e.g. documents. From version 5.2, permissions are systematically added to all system elements.
Usually, the permissions are visible in the Permissions tab. Above there is a typical view of the tab with an example of a document.
The permissions for a document category looks a bit different. After entering the category edition, the permissions are at the bottom of the settings.
Basic settings
There are three authorization levels in the system:
Read – the user can see the object but cannot delete or modify it
Modification – The user can edit the object and delete it.
Adding – The permission occurs at the document category or budget structure level. Users with permission to add an item can create new objects (documents, budgets, etc.) and edit items that they have created.
A user with modification rights can add the rights.
As we can see, we can add permissions for:
Organizational structure – rights are granted to all employees from a given structure (eg the Economic Division) and subordinate units (eg the Finance and Accounting Department). Choosing the organizational structure, we can also choose a specific position, eg Chief Accountant.
User – here we can select a specific user, e.g. Zoe Roberts.
Important note: while there seems to be a slight difference between the position and the user, the ramifications of choosing one or the other option are significant. If we choose a position, the rights will always be assigned to this position and if, for example, Zoe Roberts leaves the position of the Controlling Department Manager, she will lose the rights to the given object and the new manager will automatically gain rights. However, if we assign rights to the user, after the change of position, Zoe Roberts will still have rights to the object, but the new manager of the Controlling Department will no longer have such rights.
Group – Permissions are granted to all members of groups and subgroups.
Family of positions – Permissions for positions from a specific group of positions (option at the position definition)
Management level – Permissions for positions from a specific management level (option at the position definition)
To be able to save new rights, select the level of rights: Modify or Read
Finally, it is worth adding that the user who has the right to read the document also has the right to add comments. If a person who does not have permission to read the document, is marked in a comment then, after saving the comment, that person will be granted such permissions. The system warns against such a situation with an appropriate message:
Roles
Of course, individual settings for each element of the system would be very time-consuming, which is why a role system has been implemented. Along with the system, there is a set of predefined roles for modules installed. We can add our own roles at any time. The role list can be found in Settings-> Personalization-> Roles.
The most important information is located in the Name and Module columns. They define the type of rights and the module the rights apply to. For standard roles there are following settings:
Administrator – the user assigned to this role has the rights to read, modify and add both documents and document categories. Additionally, it can add permissions to items.
Standard user – the user assigned to this role has the rights to the module, i.e. he can see the module and can see the elements in the given module. Detailed rights to individual elements result from e.g. rights to the document category or the document itself.
This means that the module administrator will be able to see all documents even if they do not have rights to the document category or the document itself. This person may not be listed on the Permissions tab for the document.
Assigning a user to a role
The role is assigned to the user via the HR-> Structure-> Employees module. In the Permissions tab there is a tree with modules and roles assigned to them. To make an assigment, select the checkbox next to the role.
Application permissions
The application permissions work in a similar way to the standard user’s module permissions.
After selecting the application you enter the application configuration part. The first item there (General information) is the Permissions tab. In this tab you can assign permissions that apply to individual users.
Application options do not affect the permissions to documents from the application level. It only affects the ability to view the application.
Types of permissions
Permission concerning the object
This is the standard permission model which we described above. Each object (document, budget, document category, module, application, etc.) can be assigned permissions for a user, group or organizational structure.
Permission derives from workflow
Each user, who is an executor of the step in workflow, gains privileges to the document that started this workflow. User can view and modify the document. If the user did not have permission to the document before, then after executing the step in workflow, he will keep permission to read document but modification permission will be withdrawn. If the user previously had the permissions to the document, he still will have the same permissions.
As you can see in the example above, Zoe Roberts has permissions from the workflow as well as permissions to the document. Rebecah Henderson only has workflow’s permissions. Within the Permission Code column, the letter B means that the authorization cames from the workflow.
Along with the rights from the workflow, the user can by default:
- Consult the document with any user -> the new user is granted permission to read this document
- Pass the step to any user -> the new user gets the same permissions to document as the user forwarding the step.
- Mention user in comments -> new user gets read permission
- Grant the permission to any user, if he has the permission to modify the document -> the new user receives the permission to this document
Permission inheritance
Next to the permissions assigned to the object there are permissions inherited from the parent item or from the document category. When editing a document, there is a checkbox in the Permission tab that controls permission inheritance:
After turning off this option, number of people with permissions clearly decreases. In the permission table, the Permissions Type of access are Inherited.
Most of the permissions to objects in the system are inherited from document categories or from parent items. Therefore, it’s easy to manage privileges system, because you can set standard privileges for item such as sales invoices, rather than for each document in this category separately.