A shopfloor PC is bought, warranted and replaced as a PC, but it is FOUND by the machine it drives - nobody walks the floor looking for an asset number. The warranty tables listed the covered asset and left the reader to work out where that is. Both tables gain a Machine # column. The payload resolves it by walking the asset relationship graph in BOTH directions: the canonical edge is PC --controls--> machine, but a dual-bay pair carries controls on both bays and hand-made links are not reliably oriented. Hovering the chip shows the floor map with the machine marked, so the row answers "where do I go" without opening anything. The blueprint follows the viewer's theme and the marker is placed from mapx/mapy as a percentage of the configured map dimensions, since the preview is a few hundred pixels wide rather than the full plan. It renders only while hovered, so a long table does not build a blueprint per row. A machine with no map position still gets its chip and says so, rather than being dropped: against real data 142 PCs resolve to a machine and 125 of those are placed, so 17 rows would otherwise have silently lost their number. The chip is deliberately not a link. /machines/:id is keyed by machineid, not assetid, and resolving one to the other here would make the warranty plugin import the machines plugin (ADR-014). Worth noting separately: the existing assetLink() in these tables already sends machine-type assets to /machines/<assetid>, which is that same mismatch and predates this change.
4.0 KiB
4.0 KiB