Roles and Permissions (legacy)

When an account is shared with other operators, it is possible to define and assign roles to
these operators in order to control their access rights. Each Operator can only have a single and unique role assigned to them at any one time.

In addition, the account owner can define roles for Application Users, assign these roles, and set permissions on individual resources.

See Roles and Role Permissions in the API Reference section for API examples of creating and updating roles and role permissions.

You can also manage roles directly in the EVRYTHNG Dashboard from the Team Settings page. See Account Management for more information.

Predefined Roles

There are three predefined roles:

• admin - the default role for the Operator who owns the account. It gives them all the rights on the account and allows them to manage new and existing roles and permissions. It is possible to assign and remove the admin role to other Operators but there must be always at least one admin within the account at all times.
• base_app_user - similar to admin, but for userInApp type roles.
• none - the default role for all operators added to the account after the admin Operator. It has no rights at all. It is also the fallback role when a custom role is deleted. In this case the none role is assigned to all the operators currently having the soon-to-be deleted role.

Custom Roles

In addition to the predefined roles, the account owner (alone) can define new custom roles within the account that make more sense within the context of the application. For example, a product manufacturing company may decide to create the "Machine Operator" and "Shop Manager" roles. These roles can then be assigned permissions allowing them to view and interact with only specific resources that they are concerned with.

Operator Role Permissions

The account with the admin role defines and updates permissions that are associated with roles. Thus each Operator (and their associated API key) will inherit these permissions if they are assigned that role. Therefore, if the role permissions are updated, all concerned Operators are updated too.

The different available permissions for Operator roles are listed below, alongside their API names:

### Global Permissions

• Global Read (global_read)
  Give a read only access to all resources, account-wide.

• Manage Resources (gl_resource_update)
  Give a read/write access to the account resources (i.e. Thngs, collection,
  products, ...), but read-only access to projects and applications settings.

• Manage Projects (gl_project_update)
  Give a read/write access to the account projects and applications settings, but
  resources remain read-only (i.e. Thngs, collections, products, etc.).

Project Permissions

• Read Project (project_read)
  Give access to specified projects only, and resource visible within these projects.

• Manage Project (project_update)
  Give access to specified projects only, allowing the user to also to edit the specified projects' configurations.

• Manage Project Resources (project_resource_update)
  Give access to specified projects only, allowing the user to also to manage the specified projects' resources such as Thngs and products.

Application User Role Permissions

Each Application User role is set a list of access rules for the resources and operations it is allowed to access. See the Role Permissions page for more information on these permissions.