Sites and campuses

/admin/sites, listed in the interface as Admin, Campuses. Needs site.manage.

A site is a campus: a building, a junior school, a second college on the other side of town. One tenant, several places, and a technician who runs one of them.

Sites are optional. A school that never creates one behaves exactly as it always has, and so does every user in it.

What a site is

Name	What people call it: Senior School
Slug	A short handle, normalised on save
Notes	Free text, for whatever your school needs to say about it

That is the whole record. A site is a label to hang scope off, not a configuration surface. Statuses, priorities, roles, SLA targets, branding and templates stay tenant-wide, because a school sets those once and every campus uses them.

Scoping a person

A user is given a set of sites, or none. None means the whole tenant, which is what every user has today and keeps having.

Assign them under the user’s own record, and note that the button asks for site.manage rather than the user.manage that governs the rest of that page.

All of a person’s roles apply within their site set. The model is one scope per user, not one per role, so it cannot express “Admin at the junior campus, Read-only at the senior one”. That is a deliberate trade: the alternative that fits in a session token is a union of both roles over both campuses, which silently grants Admin at the senior campus. An honest “cannot” beats a quiet “more than you asked for”.

A wildcard role is still bounded by the scope. A superuser confined to the junior campus is a superuser at the junior campus and nothing at the senior one.

Scoping is ambient, not a filter you pass

Worth understanding because it explains the behaviour you will see.

Scope is a property of the signed-in user, carried alongside the request and applied underneath every database read and write. It is not a parameter services hand each other, and it is not a filter the interface applies to a full result set.

Two consequences:

It bounds writes as well as reads. A scoped technician cannot create a record at another campus, and cannot move one there. Hiding rows in the interface while the API still answers for them is not scoping; this is enforced at the data layer.

Out of scope reads as “not found”, not “forbidden”. Opening a device at another campus gives you a 404. “Forbidden” would confirm the record exists, and on a person record the fact that a name exists is most of what is worth protecting.

What a scoped technician sees

Scoped directly, by their own campus:

Devices · People · Tickets · Submissions · Loans · Purchases · Inductions · Documentation spaces and documents · Portal kiosks · Vendor networks on the network pane

Scoped through their parent record, because a ticket comment has no campus and the ticket it hangs off does: ticket comments, attachments, watchers, time entries and labels; MDM records and disposals on a device; kiosk requests; document versions and links; stocktake scans; damage charges.

Never scoped, deliberately: roles, users, site assignments, the audit log, and everything in the configuration section. These are either configuration every campus shares, or the substrate scoping is built out of. A scope cannot decide who edits the scope, and an audit trail with rows filtered out of it is not an audit trail. The campus list itself is unscoped too, since scoping the campus list by campus is circular.

Unassigned records belong to unscoped people

A record with no campus is visible to unscoped users only.

This is the conservative direction and it is chosen deliberately. On the day you first scope somebody, every existing record in your tenant is unassigned, so the other choice would hand a brand new campus administrator the entire history of the school, which is the exact thing you scoped them to prevent.

The cost is real: a newly scoped technician sees empty screens until records carry a campus. Plan for that. Records created by a scoped user are stamped with their campus automatically where that is unambiguous, and the Campuses page shows how many operational records are still unassigned so somebody can work through them.

Do not scope your first administrator and then judge the feature by what they see on Monday morning.

Why site.manage is its own permission

Because whoever can edit a scope can widen their own.

A scope is the control that bounds every other permission somebody holds. Editing one is a strictly larger decision than “may add a technician”, and a school should be able to hand out the second without the first. That is why site.manage is separate from user.manage and is required on the site-assignment button even inside the user editor.

Plugboard also refuses to site-scope the last unscoped holder of the administrative permissions. A tenant with nobody who can see all of it is a tenant that has locked itself out of its own configuration.

Where campuses show up elsewhere

• Network. A Meraki network or a UniFi site is pointed at a campus by hand. That mapping is what scopes network gear.
• Documentation. A space can belong to one campus, and its documents inherit that.
• The kiosk. A kiosk stands in one building, and can be set to refuse people from another campus.
• Remote access. A target can be offered at one campus only.
• Live updates. An event carrying a campus reaches only people scoped to it, or to nowhere.