By default a relay is available to every active relation that satisfies the configured conditions (geofence, valid booking). With the access policy you can restrict a relay to a selected group instead — for example a hangar door that only board members and staff may open.
Access policy
On the Configuration tab of the relay, set Access policy:
| Policy | Behaviour |
|---|---|
| All relations (default) | Current behaviour: every active relation, subject to the geofence and booking conditions. |
| Selected relations only | Only relations on the Access List tab can operate the relay. Everyone else is refused, regardless of the other conditions. |
Managing the access list
The Access List tab works like the exceptions tab. Click Add and choose what the entry applies to:
- Relation -- one individual relation.
- Role -- every relation holding that role (e.g. Flight Instructor).
- Label -- every relation carrying that label (e.g. Staff).
Role and label membership is evaluated live at every access attempt: give someone the label tomorrow and they can open the door tomorrow, without touching the relay configuration. The list shows a type chip per entry (relation, role, or the label in its own colour).
Note
the Access List tab is always visible so you can prepare the list in advance; an information banner reminds you when the policy is still set to All relations and the list is not yet enforced.
Relationship with access exceptions
Access exceptions always take priority over the access list:
- An individual exception wins in all cases — Always granted admits someone who is not on the list; Blocked refuses someone who is.
- Otherwise a Blocked exception (also via role or label) wins over Always granted.
- Otherwise the access policy and list apply, followed by the regular geofence and booking checks.
Unlike an Always granted exception, being on the access list does not bypass the geofence or booking conditions — list members simply take part in the normal rules.