Inheritance of user groups
When user groups have partly the same permission concerning classes and fields it can be helpful to define a user group hierarchy. When this is done, a user group might become a "sub-group" of another user group (which would then be its "parent"). A sub-group inherits all permissions from its parent. A hierarchy can be easily defined by setting a parent for a user group in the property "Inherits from" in the Properties tab of a user group.
Suppose:
- we have a user group C that inherits from A, and
- we have a class CLASS with a field FIELD.
The following rules are relevant:
- Suppose user group A has read permission on class CLASS. And user group C has only update permission on class CLASS. This means that users in user group C are allowed to update records of class CLASS.
- Suppose user group A has read permission on class CLASS and 'Permitted fields only' is set to true. However, there are no field permissions set for user group A. User group C has no read permission on class CLASS, but has a read permission on a particular field FIELD. This means that users in user group C are allowed to read FIELD.
- Suppose user group A has search permission on class CLASS and but has no read permission on the same class. This implies that none of the fields can be used to search. User group C has no search permission on class CLASS, but has a read permission on a particular field FIELD. This means that users in user group C are allowed to search on FIELD.
- Suppose user group A has a read permission value on class CLASS 'Helper' but there is no helper defined. This implies that nothing can be read. User group C has a helper defined. This means that this helper is applied to define if users in user group C can read class CLASS.
- Suppose user group A has a read permission value on class CLASS 'User related' but there is no route to the user class defined. This implies that nothing can be read. User group C has a route defined. This means that this route is applied to define if users in user group C can read class CLASS.
User groups can inherited permissions from more than one other user group.
Suppose C has two parents.
In case conflicting permissions are inherited from two or more parents, the following rule is applied:
Basic rule: The first user group in the list of parents supercedes the second, and so on.
Please be aware of the following cases:
- Suppose user group A has read permission on class CLASS. And user group B has no read permission on class CLASS but has update permission on class CLASS. In practice, this means that User group B is not allowed to update records of class CLASS because read permission is also required. So both parents are not allowed to update record of class CLASS.
User group C inherits both permissions from both parents, and therefore users in user group C are allowed to update records of class CLASS. -
Suppose user group A has read permission on class CLASS and 'Permitted fields only' is set to true. However, there are no field permissions set for User group A. User group B has no read permission on class CLASS but has a read permission on a particular field FIELD. So both parents are not allowed to read fields of class CLASS.
User group C inherits both permissions from both parents, and therefore users in user group C are allowed to read FIELD.
-
Suppose user group A has search permission on class CLASS and but no read permission. This implies that none of the fields can be used to search. User group B has no search permission on class CLASS but has a read permission on a particular field FIELD. So both parents are not allowed to search on class CLASS.
User group C inherits both permissions from both parents, and therefore users in user group C are allowed to search on FIELD.
-
Suppose user group A has a read permission value on class CLASS 'Helper' but there is no helper defined. This implies that nothing can be read. User group B has a helper defined. So both parents are not allowed to read class CLASS.
User group C inherits the permission from one parent and the helper from the other. And therefore the helper is applied to calculate whether users in user group C can read class CLASS. - Suppose user group A has a read permission value on class CLASS 'User related' but there is no route to the user class defined. This implies that nothing can be read. User group B has a route defined. So both parents are not allowed to read class CLASS.
User group C inherits the permission from one parent and the route from the other. And therefore the route is applied to calculate whether users in user group C can read class CLASS.