Finish tags, and expose the firmware timeouts in the UI
Two follow-ups from @Orhideous after v0.24.16.
Tags (#149)
He asked whether tags were supported at all, having created one and watched
it sit at "0 devices" with no way to put it on anything. Tracing it, the
feature was complete except for the part that makes it a feature:
tags / device_tags tables present
POST /tags/:id/devices (assign) present
tagsApi.assignDevices() in client present
Settings: create, colour, delete present
Devices page: filter by tag present
Devices page: tag chips on rows present
anything that calls assignDevices nothing, anywhere
So a tag could be created and filtered on, and the filter could only ever
return nothing. He was right to ask.
A tag picker now sits under the device name: current tags as removable
chips, a dropdown to add. The API is tag-centric because it was built for
bulk assignment; people think device-centric, and the component translates.
His second question was sharper — whether tags are justified at all next to
search, device types and sites. As built they were not, and not because
they lacked assignment: nothing consumed them. Rollouts, bulk commands,
maintenance windows and alert rules all had no notion of a tag.
So bulk commands can now select by tag. That is the case tags actually win:
sites group by where a device is and types by what it is, both
single-valued, while a tag is many-per-device and crosses both. "The three
switches I upgrade first" is not expressible any other way.
Firmware timeouts (#141)
"how can I set firmware_download_timeout_min and firmware_reboot_timeout_min
from UI?" — you could not. I added the settings, wired them into the
orchestrator, and built no control, which makes them SQL-only and therefore
just a different pair of hardcoded values.
Now under Settings -> Polling, clamped 1-120 minutes in the form and again
on the server.
The card holds only edits in state and reads everything else from the saved
settings. Mirroring props into state through an effect was the first shape
and the wrong one: it trips the cascading-render rule, and it leaves two
sources of truth that disagree while a save is in flight. Second time this
session that pattern has been the wrong answer.
Verified against the running stack: settings round-trip through the API and
resolve to the right millisecond values with clamping intact; a tag created,
assigned to a device, and read back on both /tags/device/:id and the devices
list.
Docs: commands.md gains a section on choosing devices by tag and why tags
earn their place beside sites and types; README corrected, since it had been
advertising tags that could not be assigned.
Container image: ghcr.io/2gt-media-group-llc/mikrotik-manager:0.24.17-beta
Documentation: https://2gt-media-group-llc.github.io/mikrotik-manager/