In Necto, permissions on any securable entity (workboard, data source, model) are inherited from their parent entity (folder, subfolder). However, inheritance can be broken for a securable entity at a lower level in the hierarchy by assigning a unique permission to that securable entity.
When there are overlapping roles and permissions in the hierarchy and a user has multiple roles, access rights are determined based on permission weights and inheritance rules.
Each permission type has a weight that determines its strength. The higher the weight the stronger the permission. For example, Deny is stronger than Write, and Write is stronger than Read. Admin is the strongest. The following table ranks the permissions by weight:
|
Permission |
Weight |
Description |
Admin |
5 |
Super-user with all administrative rights, including definition of permissions to others. |
|
Deny |
4 |
The user sees that the entity exists but is not allowed to view it. |
|
Write |
3 |
The user is allowed to edit the entity. |
|
Read |
2 |
The user is allowed only to view the entity. |
|
Hidden |
1 |
The user does not see the entity at all. |
|
None |
0 |
No permission has been assigned. Permissions will be inherited from the parent folder. |
Necto applies the following inheritance rules:
When a role has different permission types for Level 1 and Level 2 (or more levels) of an entity hierarchy, and no permission has been assigned to Level 3 (lowest level), then Level 3 will inherit the permission of the previous level unless Level 1 (Root) is Admin.
Example 1
A user is a member of Role A. In a workboard hierarchy, the following permissions are assigned:
§ Folder: Role A – Permission Admin
§ Subfolder: Role A – Permission Hidden
§ Workboard: No permission defined
This user will have Admin rights to the workboard since the permission of the root folder is Admin. The following figure illustrates this example:
Example 2
A user is a member of Role A. In a workboard hierarchy, the following permissions are assigned:
§ Folder: Role A – Permission Read
§ Subfolder: Role A – Permission Hidden
§ Workboard: No permission defined
This user will not see the workboard (Hidden permission) since the subfolder permission is Hidden and the permission of the root folder is not Admin. The following figure illustrates this example:
Example 3
A user is a member of Role A. In a workboard hierarchy, the following permissions are assigned:
§ Folder: Role A – Permission Read
§ Subfolder: Role A – Permission Deny
§ Workboard: No permission defined
This user will see the workboard but not be able to access it (Deny permission) since the subfolder permission is Deny and the permission of the root folder is not Admin. The following figure illustrates this example:
When a user has multiple roles for the levels of a hierarchy, the user’s access rights to a lower level for which there are no permissions defined for any of the user’s roles, are determined by applying the strongest of the permissions.
Example 1
A user has two roles – Role A and Role B. In a workboard hierarchy, the following permissions are assigned:
§ Folder: Role A – Permission Admin
§ Subfolder: Role B – Permission Hidden
§ Workboard: No permission defined
This user will have Admin rights to the workboard since Admin is the stronger between the two permissions. The following figure illustrates this example:
Example 2
A user has two roles – Role A and Role B. In a workboard hierarchy, the following permissions are assigned:
§ Folder: Role A – Permission Read
§ Subfolder: Role B – Permission Hidden
§ Workboard: No permission defined
This user will have Read rights to the workboard since Read is stronger than Hidden. The following figure illustrates this example:
Example 3
A user has two roles – Role A and Role B. In a workboard hierarchy, the following permissions are assigned:
§ Folder: Role A – Permission Read
§ Subfolder: Role B – Permission Deny
§ Workboard: No permission defined
This user will have Deny permission to the workboard since Deny is stronger than Read. The following figure illustrates this example:
This rule applies to a more complex hierarchy containing multiple levels with different permissions per role. If a user has different roles with different permissions, the user’s access rights to a lower level for which there are no permissions defined for any of the user’s roles, are determined by a combination of Rule 1 and Rule 2.
The following example illustrates the complex hierarchy.
There are three roles, Role A, Role B and Role C, each having different permissions at different levels of the hierarchy. A user has two roles, Role A and Role B. At the lowest level of the hierarchy, this user has both Deny (Role A) and Read (Role B) permissions. The user’s access rights to the next lower level is determined as follows:
§ The user is not part of Role C, so this role is removed from the calculation
§ Rule 1 is applied: Use last folder permission unless root permission is Admin. In the following example, Deny is taken for Role A and Admin for Role B.
§ Rule 2 is applied: Combining hierarchies and selecting the stronger permission. In the following example, Admin is applied since it is stronger than Deny.
