Show the controls link from both ends, and fix the dead chip links

THE RECIPROCAL LINKS BUG

A PC's page showed "Serves machine 7803" at the top. The machine's page showed
nothing equivalent, though the same edge was right there in the relationships
card at the bottom. That asymmetry read as missing data and was reported as
such.

It was neither missing data nor an API fault. The endpoint returns both
directions and always did; AssetTriageBand already walked outgoing AND incoming
and deduped, with a comment explaining that production holds reciprocal rows.
It then discarded every peer whose asset type was not 'machine', and hardcoded
the label "Serves machine". So the component could only ever work from the PC
side, and it was mounted only on the PC page.

The counterpart type and label are now props, defaulting to the old values so
the PC page is unchanged. The machine page mounts the band with
counterparttype="computer" and the label "Controlled by".

Eliminated with evidence rather than assumed, because this bug had already been
misdiagnosed twice: the endpoint runs two queries and returns both arrays; the
generic card renders both; that route has no pagination to clamp; and a single
permission gate cannot admit one direction and not the other.

THE RELATIONSHIP TYPE WAS ALSO HARDCODED

Not every asset pair is linked by 'controls'. A machine reaches a printer
through usesprinter and defaultprinter, so the band was blank on the printer
page - the one page where the link is not obvious from the asset itself. The
types are now a prop, and the printer page passes its own.

THE CHIPS WERE DEAD LINKS

Found while adopting the band more widely. It linked to /assets/<assetid>.
There is no /assets/:id route and no catch-all, so every chip in the band was
dead - and this change would have propagated that to four more pages.

AssetRelationships.vue already resolved this correctly and privately. That
function is now frontend/src/utils/assetRoute.js and both components use it, so
a third caller cannot get it wrong again. Two things it gets right that are easy
to miss: the detail routes key on pluginid, not assetid, so passing assetid
opens the wrong record; and the lookup is now case-insensitive, because
csvimport.py seeds 'Computer' and 'Machine' capitalised while this site's
database holds them lowercase - a case-sensitive match produced dead links at
whichever site seeded the other way.

The band now carries pluginid and assettypename on each chip, which the
resolver needs.

TESTS

assetRoute had none and neither did the band. Seven cover the resolver,
including the assetid-vs-pluginid confusion and the seeding-case difference.

On the backend, nothing asserted that the TARGET of a directional edge receives
it in `incoming` - only that rows carry isdirectional. That missing assertion is
this bug's exact shape, so it is now pinned: the endpoint was right all along,
and the next such report should not cost anyone a re-diagnosis of the API.

Verified on screen: the machine page shows "Controlled by G6K76CW3ESF" in the
hero, the PC page is unchanged, and a page with no such link renders no empty
band. Full suite 2162 passed, frontend 280 passed.

frontend/src/components/AssetRelationships.vue

@@ -186,6 +186,7 @@
 </template>
 
 <script setup>
+import { assetRoute } from '@/utils/assetRoute'
 import { ref, computed, onMounted, watch } from 'vue'
 import { Cog, Monitor, Printer, Globe, Package, Ruler } from 'lucide-vue-next'
 import { assetsApi, relationshipTypesApi } from '../api'
@@ -472,28 +473,7 @@ function getAssetIcon(assettype) {
   return icons[assettype] || Package
 }
 
-function getAssetRoute(asset) {
-  if (!asset) return '#'
-
-  const routeMap = {
-    'machine': '/machines',
-    'computer': '/pcs',
-    'printer': '/printers',
-    'network_device': '/network',
-    'measuring_tool': '/measuringtools'
-  }
-
-  // serializer sends assettypename; old shape used assettype
-  const typename = asset.assettypename || asset.assettype
-  const basePath = routeMap[typename] || '/assets'
-
-  // pluginid is the extension-table id the detail routes key on
-  const id = asset.pluginid
-    || asset.typedata?.networkdeviceid
-    || asset.typedata?.machineid
-    || asset.assetid
-  return `${basePath}/${id}`
-}
+const getAssetRoute = assetRoute
 </script>
 
 <style scoped>

frontend/src/components/AssetTriageBand.vue

@@ -8,13 +8,13 @@
     </div>
 
     <div v-if="machines.length" class="triage-item">
-      <span class="triage-label">{{ machines.length === 1 ? 'Serves machine' : 'Serves machines' }}</span>
+      <span class="triage-label">{{ counterpartheading }}</span>
       <span class="triage-values">
         <router-link
           v-for="machine in machines"
           :key="machine.assetid"
           class="triage-chip link"
-          :to="`/assets/${machine.assetid}`"
+          :to="assetRoute(machine)"
         >{{ machine.assetnumber || machine.name }}</router-link>
       </span>
     </div>
@@ -63,6 +63,7 @@
  */
 import { ref, computed, onMounted, watch, useSlots } from 'vue'
 import api from '@/api'
+import { assetRoute } from '@/utils/assetRoute'
 
 const props = defineProps({
   assetid: { type: Number, required: true },
@@ -71,11 +72,30 @@ const props = defineProps({
   // Shape: { level: 'ok'|'warning'|'critical'|'unknown', label: 'Reporting, 4m ago' }
   liveness: { type: Object, default: null },
   accessmethods: { type: Array, default: () => [] },
-  locationname: { type: String, default: '' }
+  locationname: { type: String, default: '' },
+  // Which side of a 'controls' edge this page wants to see, by asset type
+  // name. A PC page wants the machines it serves; a machine page wants the
+  // PCs that drive it. Defaults to 'machine' so the PC page - the only
+  // caller when this was written - keeps its exact behaviour.
+  counterparttype: { type: String, default: 'machine' },
+  // Overrides the heading. Empty keeps the shop-floor phrasing that earned
+  // its place: a PC matters because a machine stops without it.
+  counterpartlabel: { type: String, default: '' },
+  // Which relationship types link this asset to its counterpart. Not every
+  // pairing is 'controls': a PC controls a machine, but a machine reaches a
+  // printer through usesprinter and defaultprinter. Hardcoding 'controls'
+  // left the band blank on the printer page, which is the one page where the
+  // link is not obvious from the asset itself.
+  relationshiptypes: { type: Array, default: () => ['controls'] }
 })
 
 const machines = ref([])
 
+const counterpartheading = computed(() => {
+  if (props.counterpartlabel) return props.counterpartlabel
+  return machines.value.length === 1 ? 'Serves machine' : 'Serves machines'
+})
+
 const slots = useSlots()
 
 const hasAnything = computed(() =>
@@ -87,7 +107,7 @@ const hasAnything = computed(() =>
 )
 
 onMounted(loadMachines)
-watch(() => props.assetid, loadMachines)
+watch(() => [props.assetid, props.counterparttype, props.relationshiptypes], loadMachines)
 
 async function loadMachines() {
   machines.value = []
@@ -96,9 +116,11 @@ async function loadMachines() {
     const response = await api.get(`/assets/${props.assetid}/relationships`)
     const data = response.data.data || {}
     const found = []
-    // BOTH directions. The canonical edge is PC controls machine, but
-    // production also holds reciprocal rows, so reading one direction shows
-    // the link on half the pages and not the other half.
+    // BOTH directions, then deduped. Production holds reciprocal rows for
+    // the same link, so reading one direction shows it on half the pages and
+    // not the other half - and reading both without deduping shows it twice.
+    // Direction is therefore not trustworthy here and is deliberately not
+    // used to label anything.
     for (const edge of data.outgoing || []) collect(edge, edge.targetasset, found)
     for (const edge of data.incoming || []) collect(edge, edge.sourceasset, found)
     machines.value = found
@@ -111,10 +133,19 @@ async function loadMachines() {
 
 function collect(edge, other, found) {
   if (!other) return
-  if ((edge.relationshiptypename || '').toLowerCase() !== 'controls') return
-  if ((other.assettypename || '').toLowerCase() !== 'machine') return
+  const wanted = props.relationshiptypes.map(t => t.toLowerCase())
+  if (!wanted.includes((edge.relationshiptypename || '').toLowerCase())) return
+  if ((other.assettypename || '').toLowerCase() !== props.counterparttype.toLowerCase()) return
   if (found.some(m => m.assetid === other.assetid)) return
-  found.push({ assetid: other.assetid, assetnumber: other.assetnumber, name: other.name })
+  // pluginid and assettypename are what assetRoute() needs; without them the
+  // chip falls back to /assets/<assetid>, which is not a route.
+  found.push({
+    assetid: other.assetid,
+    assetnumber: other.assetnumber,
+    name: other.name,
+    pluginid: other.pluginid,
+    assettypename: other.assettypename
+  })
 }
 </script>
 

frontend/src/utils/assetRoute.js

@@ -0,0 +1,43 @@
+/**
+ * Where an asset's detail page lives.
+ *
+ * Extracted from AssetRelationships.vue because a second caller appeared (the
+ * triage band) and got it wrong: it linked to `/assets/<assetid>`, which is not
+ * a route. There is no `/assets/:id` page and no catch-all, so every chip was a
+ * dead link. One copy, so a third caller cannot repeat it.
+ *
+ * Two ids are in play and they are not interchangeable. `assetid` is the core
+ * row; the detail routes key on `pluginid`, the id of the extension-table row
+ * (machineid, computerid, printerid). Sending assetid to /machines/:id opens
+ * the wrong machine, or none.
+ */
+
+// Asset type NAME to route base. The names are seed data, and seeding is not
+// consistent about case: shopdb/core/services/csvimport.py seeds 'Computer'
+// and 'Machine' capitalised, while this site's database holds them lowercase.
+// The lookup is therefore lowercased on both sides - a case-sensitive match
+// silently produced dead links at whichever site seeded the other way.
+const ROUTE_BY_TYPE = {
+  machine: '/machines',
+  computer: '/pcs',
+  printer: '/printers',
+  network_device: '/network',
+  'network device': '/network',
+  measuring_tool: '/measuringtools',
+  'measuring tool': '/measuringtools'
+}
+
+export function assetRoute(asset) {
+  if (!asset) return '#'
+
+  const typename = String(asset.assettypename || asset.assettype || '').toLowerCase()
+  const basePath = ROUTE_BY_TYPE[typename] || '/assets'
+
+  const id = asset.pluginid
+    || asset.typedata?.networkdeviceid
+    || asset.typedata?.machineid
+    || asset.assetid
+  return `${basePath}/${id}`
+}
+
+export default assetRoute

frontend/src/utils/assetRoute.spec.js

@@ -0,0 +1,54 @@
+import { describe, it, expect } from 'vitest'
+import { assetRoute } from './assetRoute'
+
+describe('assetRoute', () => {
+  // The bug this file exists to prevent: the triage band linked to
+  // /assets/<assetid>, and there is no /assets/:id route and no catch-all,
+  // so every chip was a dead link on five detail pages.
+  it('routes by asset type, never to /assets', () => {
+    expect(assetRoute({ assettypename: 'machine', pluginid: 223, assetid: 313 }))
+      .toBe('/machines/223')
+    expect(assetRoute({ assettypename: 'computer', pluginid: 279, assetid: 304 }))
+      .toBe('/pcs/279')
+    expect(assetRoute({ assettypename: 'printer', pluginid: 1, assetid: 594 }))
+      .toBe('/printers/1')
+  })
+
+  it('uses pluginid, not assetid - they are different rows', () => {
+    // /machines/:id keys on machineid. Passing assetid opens the wrong
+    // machine, or none, and looks like a data problem rather than a link bug.
+    const route = assetRoute({ assettypename: 'machine', pluginid: 223, assetid: 313 })
+    expect(route).toBe('/machines/223')
+    expect(route).not.toContain('313')
+  })
+
+  it('matches the type name whatever case the site seeded it in', () => {
+    // csvimport.py seeds 'Computer' and 'Machine' capitalised; this site's
+    // database holds them lowercase. A case-sensitive lookup produced dead
+    // links at whichever site seeded the other way.
+    expect(assetRoute({ assettypename: 'Computer', pluginid: 7 })).toBe('/pcs/7')
+    expect(assetRoute({ assettypename: 'MACHINE', pluginid: 8 })).toBe('/machines/8')
+  })
+
+  it('accepts the older assettype key as well as assettypename', () => {
+    expect(assetRoute({ assettype: 'printer', pluginid: 4 })).toBe('/printers/4')
+  })
+
+  it('falls back through typedata when pluginid is absent', () => {
+    expect(assetRoute({ assettypename: 'network_device', typedata: { networkdeviceid: 12 } }))
+      .toBe('/network/12')
+    expect(assetRoute({ assettypename: 'machine', typedata: { machineid: 30 } }))
+      .toBe('/machines/30')
+  })
+
+  it('returns a harmless anchor for nothing', () => {
+    expect(assetRoute(null)).toBe('#')
+    expect(assetRoute(undefined)).toBe('#')
+  })
+
+  it('handles both spellings of the multiword type names', () => {
+    expect(assetRoute({ assettypename: 'network device', pluginid: 2 })).toBe('/network/2')
+    expect(assetRoute({ assettypename: 'measuring_tool', pluginid: 3 })).toBe('/measuringtools/3')
+    expect(assetRoute({ assettypename: 'measuring tool', pluginid: 3 })).toBe('/measuringtools/3')
+  })
+})