Permissions

Control who can access a project and what they can do — per application (Cloud and Edge), for users and groups.

A project’s Permissions control who can access it and what they’re allowed to do. Access is granted per project, so a person can have different access in different buildings.

Per application

THMI has two applications — the Cloud and the on-site Edge — and they do different things, so a person’s role is set per application. For each user or group you can assign up to three roles:

The role sets differ because the applications differ: the Cloud is where the project is configured (hence Manager and Admin), while the Edge is where it’s operated on site (hence Operator). At least one of the three must be set for a permission to mean anything.

The roles

• Viewer — can see, but not change.
• Operator — day-to-day operation: respond to alarms and change writable values, but not reconfigure the project.
• Manager — can configure much of the project (its tags, alarms, pages, and settings).
• Admin — full control of the project, including its permissions.

Users and groups

Permissions are granted to individual users and to user groups. Granting a group a role gives that role to everyone in it — the scalable way to manage access, since you update the group once instead of every project.

You add one or more principals at once and set their roles, and you can bulk-edit or bulk-remove existing permissions to adjust many at the same time. The permissions list shows each principal’s Cloud, Cloud + Edge, and Edge role side by side.

How access adds up

A person can be granted access more than once — directly and through one or more groups they belong to. When that happens, the grants combine, and the most permissive wins. There’s no “direct beats group” or precedence order: someone who is a Viewer directly but a Manager through a group is effectively a Manager.

The practical consequence is at removal time. Taking a role away in one place doesn’t lower someone’s access if another grant still provides it — to actually reduce what a person can do, remove every grant that gives it (check their groups, not just their direct permission).

This adds up within each application slot — Cloud, Cloud + Edge, and Edge are worked out separately, so a generous Edge role never widens what someone can do in the Cloud.

The anonymous user

A project can include a built-in anonymous user, so people without a login can use the project on the on-site Edge. It can only ever be a Viewer on Edge — any Cloud, Cloud + Edge, or other role you select for it is ignored.

Permissions on individual items

Some things carry permissions of their own on top of the project role, so access can be decided for one item at a time: who can see a page or document, who can change a tag’s value, and who can see and act on the alarms in an alarm category. See Item permissions.