Use this resources to view and manage Things5 roles and permissions.

Roles

A role has a name, a set of permissions and optionally a "users_create_child_roles" field.

This field specifies the roles the user is allowed to assign to the new user when creating one. For example let's say the organization has 3 roles: X, Y, Z. The role X has field users_create_child_roles set to Y and Z. The user A has role X. This means that user A when creating a new user B can assign to the new user only roles Y and Z

Permission Hierarchy in Things5

How Permissions Work

In Things5, permissions follow an additive principle within the group hierarchy. This means:

1. Permission Inheritance: Permissions assigned to a parent group automatically extend to all of its child groups.

2. Additive Principle: Permissions are always cumulative. It's not possible to remove or limit permissions inherited from a parent group through more restrictive settings on a child group.

3. Prevalence of the Broadest Permission: In case of multiple roles with different permission levels, the broadest permission always prevails.

Practical Example

Consider a structure where group A is the parent of group B:

• If a user has a role on group A that provides visibility to machines, and another role on group B that doesn't include this visibility, the user will still maintain visibility to machines for both groups.

• When performing a query with a specific filter on group B, the system will still return all machines visible based on the permissions of group A.