2GT-RichandClaude Opus 5
7b994ad935
Closes #130. Multi-site, not multi-tenancy: a site is a named collection of devices whose clients, events, topology and dashboards are viewed separately. Sites separate what you see, not who you are — the admin/manage/read-only roles are unchanged and every user sees every site. Per-site permissions would have multiplied the work for a need nobody stated. Two measurements decided the design. Every device-derived table hangs off devices(id) — 25 of 50 tables, 35 foreign keys — so a single site_id column on devices scopes clients, events, topology, backups and the rest transitively. No other table needed one. The frontend has 162 useQuery call sites across 57 files. Threading a site through each would be a large change that leaves a permanent trap: every future query another chance to forget. The site is injected in the existing axios interceptor instead, beside the auth token, so a new query is scoped by default. Only 23 collection routes needed filtering; the 131 per-device routes are already scoped by their device. Existing installs are untouched. Migration creates one "Default Site", adopts every device into it, and a single-site install never meets the concept. An absent X-Site-Id header means unscoped, so existing API tokens and scripts behave exactly as before. Polling stays fleet-wide. Sites are a view over data already gathered, not a change to how it is gathered — a device does not stop being monitored because you are looking elsewhere. Rogue-AP detection scopes the scans but keeps the "these are ours" BSSID set fleet-wide, or your own AP in another site reads as an evil twin. Bulk actions do obey the selector: an operation that silently spanned two customers is the blast radius the wave guards exist to contain. Four rounds of defects came out of testing the UI rather than the API, and the first is the one worth recording. Switching sites called queryClient.clear(), which empties the cache and reviews as correct. It isn't: clear() destroys each query but a *mounted* observer keeps its own reference and last result, so every rendered page went on showing the previous site's data. The QueryClient is now keyed on the site, which remounts the tree against an empty cache. Three tests pin the old behaviour down so the shortcut cannot return. The others: an unscoped fallback path behind the Connected Clients chart; Config Health, TX retries and the activity feed reading fleet-wide; and site_id added to the device list query but none of the other four that build a device payload, so the Site field could not read its own value and appeared to reject every change while the writes were landing. That last one is now structural — DEVICE_BASE_COLUMNS is shared by all five, with a test that fails when a device payload is hand-rolled, and which found two further instances while being written. Frontend tests were never run by CI despite vitest being configured and six suites existing; they now run in both the workflow and ci-preflight. Verified against a live four-device fleet: the migration left every figure identical, an empty site returns zero from every read endpoint, moving a device carries its history with it, and deleting a site with devices is refused. Minor bump rather than patch: sites change the shape of the product rather than adding to it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
MikroTik Manager documentation
Reference material for people already running the platform. If you are still deciding whether to try it, the project README is the better starting point.
| Document | Covers |
|---|---|
| Configuration | Environment variables, secret management and key rotation |
| Sites | Grouping devices into sites, switching between them, and what each site scopes |
| Change Guard and Config Health | How the safety system works, its settings, and what to expect when it fires |
| Alerting | Alert rules, delivery channels, webhooks, scheduled reports, maintenance windows |
| Single sign-on (OIDC) | Identity provider setup, group-to-role mapping, break-glass behaviour |
| CAPsMAN | How centrally provisioned access points are modelled, and current limits |
| Cellular (LTE) | Signal, carriers, tower movement, and the data-cap reset SMS |
| SSH keys | Per-device keypairs, rotation, and what installing one costs |
| Bulk commands | Running one command across a fleet, in waves |
| Polling and scaling | Poller health, headroom, tuning, and clearing a backlog |
| API and automation | Scoped tokens, authentication, and driving the platform from scripts |
| Architecture | How the system is put together, for contributors |
Conventions used here
- Settings in the UI are stored in the database and apply without a restart.
- Environment variables live in
.envand require a container restart to change. - Anything described as read-only makes no writes to your devices.
Which version is this?
These pages describe a specific release, shown in the header. The platform ships frequently, so if something here does not match what you see, check that the version you are running matches the version you are reading.