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>
Closes#131.
Reported as the wrong device being marked root: an RB4011 at priority 4096 says
"root bridge: yes", two APs at 8192 say they are not and name the RB4011's MAC,
and the map crowned an AP anyway — consistently, always the same one.
The detection had never worked at all. It looked for a device with no port whose
STP role was 'root', but RouterOS reports the role as 'root-port'. Nothing ever
matched, so the set of devices-with-a-root-port was permanently empty and the
lookup returned the first device in the list. It was not choosing badly; it was
not choosing.
The same mismatch broke link state. Blocking was derived from a role of
'alternate' or 'backup' against values that arrive as 'alternate-port' and
'backup-port', so blocked links were drawn as forwarding — which is the "traffic
connection path" half of the report, since a blocked link shown as live yields a
path that does not exist.
Roles are now normalised on write so both ends of the system share one
vocabulary, and the root is no longer inferred. RouterOS answers it directly:
/interface/bridge/monitor reports whether a bridge is the root and names the root
it sees, which is exactly what the reporter's own screenshots show the device
knowing. That is collected into device_bridges and resolved in
utils/stpRoot.ts with 13 tests.
Two properties of real networks shaped the resolution, both observed on the
development fleet rather than reasoned about:
* **A root belongs to a spanning tree, not to a fleet.** Two of four devices
here legitimately report root at once, being separate bridge domains, so
roots are resolved per connected component.
* **The root may not be ours.** One switch points at priority 8192 on a MAC
belonging to no device in the inventory. Naming a local device in that case
is precisely the original bug, so the crown is withheld and the foreign
bridge id reported instead.
Verified against that fleet: the managed root resolves to the device that claims
it, a self-rooted bridge keeps its own crown, and the switch with an external
root now reports "not ours" where the old logic confidently crowned it — the
reported symptom, reproduced and fixed.
Also adds collectStp to the full sync. It previously ran only on the five-minute
slow poll, so pressing Sync after rewiring did not refresh the map.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Closes#95. Addresses the second round of #94 feedback. Includes a regression
introduced in v0.22.0.
Wireless write paths were not CAPsMAN-aware (regression)
v0.22.0 widened getAP() and the bulk-SSID selector to include cap/controller
roles so a controller — normally tagged a router — would stop being invisible to
the wireless section. Those same helpers gate the write endpoints, so the change
also allowed writes to devices whose radios a controller owns. Reads needed
widening; writes needed a guard, and did not get one.
Five paths now refuse or skip provisioned radios: bulk SSID deployment, single
interface create, interface edit, interface delete, and guest network setup.
Delete was the worst of them — RouterOS will not remove a provisioned interface,
but the cached row was deleted anyway, so it vanished from the UI until the next
poll brought it back.
The check is shared: partitionRadios() splits physical radios into locally
controllable and controller-owned, assertNotCapsmanManaged() refuses an edit to a
provisioned interface and names the controller.
Neighbours identified only by MAC (#95)
Topology resolved a neighbour to a managed device by IP address. A trunk port has
no IP, so LLDP across one reports a MAC and an identity but no address — and
those links stayed unresolved, drawing an external node beside the very device it
already had on the map. Two directly connected devices appeared four times.
Resolution by MAC now runs first, before address matching, because a MAC is
hardware identity and unique fleet-wide where an address is not. This is the same
join the CAPsMAN radio matching uses.
CAPsMAN panel, from the reporter's testing
- Radios and provisioned interfaces were two tables describing the same things
from different angles; they are now one, per interface, with the access point,
SSID, band, frequency, channel, clients and status.
- Provisioning rules sit inside the configuration they apply. Rules referencing a
configuration we did not collect are listed separately rather than dropped,
since that usually means a stale reference.
- The Wireless header reported zero clients while the Clients page reported 32:
it summed the CAP-local count, which is empty under central forwarding. It now
takes the greater of that and the controller's per-radio counts, so a controller
that is also a CAP is not double-counted.
- A remote radio could be attributed to the controller by the five-octet prefix
fallback when the two shared a MAC block. Prefix matches now refuse the
controller for a non-local radio; exact matches are still honoured.
Radios tab followed device_type
device_type is user-supplied tagging, and a router with radios had no way to
display them. The tab now follows the detected wifi_role, which is a fact about
the hardware.
48 tests on the CAPsMAN module, 22 on topology, including a fixture built from the
device output in #95. Verified against the fleet: topology output unchanged, so MAC
resolution merged nothing it should not have; guards correctly permissive on a
standalone AP.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Closes#90, #91, #92.
#90 — Spurious topology links
Topology treated IP addresses and system identities as unique across the whole
fleet. They are unique only within a broadcast domain, so an installation with
physically separate segments that each reuse 10.2.0.0/24 saw devices in one
segment joined to devices in another.
The reporter pointed at shared-segment detection, and that is one of four sites
with the same flaw — but not the first. Step 2 resolves a neighbour IP to a
managed device from a global first-wins map, so a reused address silently
resolves to whichever device was loaded first; the union-find in step 6 then
merges on the resulting device id, a correct-looking key derived from bad data.
Fixing only step 6 would have left the reported link in place.
Addresses and identities are now scoped to the device that reported them
wherever they name a neighbour, so they still collapse one device's duplicate
sightings but can never join two devices. Resolution and LLDP-coverage
suppression additionally require the address to be unambiguous fleet-wide.
MAC addresses and resolved device ids are unaffected — they identify hardware,
and genuinely shared segments still merge on them.
Ambiguity detection deliberately ignores MAC divergence. A switch assigns a MAC
per port, so a device with two uplinks is reported under several MACs; an
earlier version of this fix treated that as a conflict and refused to resolve
ordinary multi-port hardware. Caught on a live fleet, where three sightings of
one CRS510 disagreed on MAC but agreed on identity. The signals used instead are
an address claimed by two managed devices, or sightings that disagree about the
neighbour's identity.
The graph builder is extracted from the route into a pure module with 16 tests,
including a fixture of the reporter's five-device, three-segment network. It had
no test coverage before, which is why a flaw this systemic went unnoticed.
Verified against a live fleet: graph output is identical before and after, and
the ambiguity list is empty when addressing is clean.
#91 — CPU load not rounded
The devices table rendered the raw value from a 5-minute Influx mean, so a
device idling between 1% and 2% displayed as 1.3333333333333333%. Rounded for
display; the sparkline keeps the unrounded series so its curve stays smooth.
#92 — Serial number in the device table
Serials were already collected, stored, returned by the API and matched by
global search, so this is presentation only: a sortable SERIAL column, and
serial added to the table's filter predicate.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Squash-merge of PR #28 from @denis-ev. All three review blockers addressed: encryption key management documented, string truncation replaced with skip+warn validation, and undefined return on duplicate merge fixed with proper 500. Local test stack verified against cloned prod DB — migrations, new features, and backend all clean.
Gustavo
2GT-RichandClaude Opus 5
Denis