User permissions

The site owner controls what every other user in the site can see and do. A user can only interact with a feature if their permissions allow it, and permissions can only be changed by someone holding Set permissions. A site owner can always edit permissions.

Setting permissions

1. Open the site's Users tab and select Permissions beside it.
2. If the user does not already appear as a column, use Select users… to find them in the list.
3. Set each permission for each user. Selecting a white circle turns it blue and grants the permission; selecting a blue circle turns it white and removes it.

Permissions apply to the current site, to all devices within it — both current and future — and to specific devices.

Permissions can be copied between users by selecting the user's initials at the top of the permissions column. Copying takes only the permissions granted on the table you are looking at — a user's inherited access is not copied onto someone else as a direct grant.

Where a permission comes from

A user can hold the same permission from more than one place at once, and the dot shows which. That matters because the three are removed in three different places, and only one of them is the dot in front of you.

A key above the table names each marker:

A dot can carry both rings at once — the two are drawn differently as well as coloured differently, so they can be told apart when they overlap.

What the ring is telling you

A ring means the user already has the permission without anything on this table granting it, so clearing the dot will not take it away. Hover the dot and Cloud names the source exactly and where to go: "Granted at portal level, so it applies to every site", "Granted for all devices in this site" or "Comes with site ownership", with the tab or row that revokes it.

Ownership shares the purple ring with roles because it works the same way: it is not a permission granted on this table, but something the user holds that carries a set of permissions with it. An owner gets a fixed group of view permissions on the site and its devices, so those dots are ringed rather than empty even though nobody granted them one by one. They go when ownership goes.

Two common cases:

• A permission granted portal-wide reaches every site, so it shows a ring in all of them. Removing it from one site means removing it at portal level, which removes it from all of them — see Administration.
• A permission granted for all devices in a site rings every individual device in it.

The dot always does the same thing

Whatever rings a dot carries, selecting it grants or removes the permission on the table you are looking at, and nothing else. Granting one on top of an inherited permission is allowed and sometimes deliberate — it survives the higher grant being taken away.

Where the portal has user roles:

Roles

A role is a named set of permissions assigned to a user at portal, multi-site or site level. Roles and the grants you set here are separate systems that do not know about each other: a user can hold the same permission through both, and taking one away leaves the other standing.

Nothing is stored against the user on this table when a role gives them a permission, which is why the dot stays empty and shows a ring instead. Hover it to see which role, and where it was assigned; remove it by unassigning the role on the matching roles tab, not here - Roles on a site or multi-site, User Roles at portal level.

On a touchscreen

Hovering needs a pointer, so on a phone or tablet the table offers a Tap a marker to explain it switch instead. Turn it on and tapping a dot explains it rather than granting or removing the permission — which also means no permission can be changed by a mis-tap while you are reading. Turn it off again to go back to editing.

A narrow screen also fits fewer user columns than you may have selected, so the table pages through them with arrows and a count. Only the view is paged: everyone you selected stays selected, and the rest come back when there is room for them.

Site permissions

For portal owners:

Sites on portals with API keys switched on carry one more site permission: API Key management, which allows viewing, creating, editing and deleting API keys in the site. See API keys.

One more site permission is set portal-wide rather than site by site, so it appears on the all-sites permissions table and not on an individual site's: Financial — Billing purchase, which allows buying a subscription online. Granting it there gives it for every site.

Device permissions

Set permissions for a user for all devices in a site.

Each device then has its own permissions table, which follows the same structure as the permissions listed above. Use All Device permissions wherever you can — they save setting the same thing on every device, and they cover devices added to the site later.