Elevated Privileges

These are the resources that users can access as privileges are raised

Resource	Standard User	Manager	Administrator
Assets	View	Create, Update, Delete	Create, Update, Delete
Metadata	View	Create, Update	Create, Update, Delete
Zones	View	Create, Update	Create, Update, Delete
Systems	View	Create, Update	Create, Update, Delete, Add / Remove Module
Modules	None	None	Create, Update, Delete, Start, Stop (logic only) and View all types
Settings	None	View	Create, Update

This allows a sufficiently privileged individual to perform tasks such as:

Creating new systems
- Add existing Calendar and Staff API modules
- Create a new Booking, Auto Check-in drivers and start them
- Configure any custom settings (such as sensor id for the room)
Modify metadata in zones
- Adding or removing bookable desks
- Changing owner of parking spaces
- etc

Configuring Permissions

Typically this would be managed via the concierge application. This is a description of the JSON that application generates.

User groups are used to apply permissions
User groups can be applied at logon via SSO

Enabling Permission Elevation

This must be done on a per-domain basis. Specify a root zone for the domain, permissions will only apply to Systems and Zones that are associated with this zone.

Defining permissions

In the org zone defined in the domain config, create a metadata entry called permissions

{
  # if someone is in group1, group3 and group4 they won't have any permissions
  # deny always takes precedence
  "deny": ["group1"],
  "manage": ["group2", "group3"],
  "admin": ["group4"]
}

You only need to define the keys that you’re using.

Permissions can be defined at multiple levels in the zone hierarchy
- i.e. you can provide global permissions to a group then deny that group from modifying certain zones.
- Or provide allow manage permissions globally and admin in certain zones