computers: the machine number identifies the machine, not the PC
A bay reporting machinenumber 3015 got a 500 from the collector every five minutes since it was imaged, and would have forever: the reported number was written to the PC's own assets.assetnumber, which is uniquely indexed and already held by machine 3015, so the insert failed with "Duplicate entry '3015' for key 'ix_assets_assetnumber'" and the entire report was discarded. Operating system, boot time, applications, printers and access protocols never landed. Every retry did the same thing, so there was no path out of it. A new PC now takes its hostname as its asset number, which is what the data already shows: of 289 computers none has a numeric asset number and 214 use their hostname. An existing PC's asset number is left alone; overwriting it renamed the PC onto the machine's identifier, changing how that PC is identified everywhere else. The machine number instead does what it was collected for. It resolves the machine and links the PC to it with a 'controls' relationship carrying a collector:machine origin label, the same discipline the printer and measuring-tool links use, so a link made by hand is never archived by a collector push. Reporting a different machine archives this PC's previous link; a machine ShopDB does not know is reported as a warning rather than invented. When another PC was already linked to that machine it has been replaced. The old link is archived rather than deleted, so which PC ran a machine in a given month remains answerable, and an alert goes out by email and webhook. The retired PC's status is deliberately not changed: the collector cannot tell whether it was shelved, sent for repair or re-imaged for another bay, and guessing would overwrite what a person set.
This commit is contained in:
24
CHANGELOG.md
24
CHANGELOG.md
@@ -12,6 +12,19 @@ ADR-007 and ADR-002.
|
||||
|
||||
### Fixed
|
||||
|
||||
- A shop-floor PC that reported the machine number of a machine ShopDB already
|
||||
knew got a 500 from the collector, on every report, forever. The reported
|
||||
machine number was being written to the PC's own `assets.assetnumber`, which
|
||||
is uniquely indexed and already held by the machine, so the insert failed with
|
||||
a duplicate-key error and the whole report was lost: operating system, boot
|
||||
time, applications, printers and access protocols never landed. The machine
|
||||
number now identifies the machine only. A new PC takes its hostname as its
|
||||
asset number, which is what the existing data already does, and an existing
|
||||
PC's asset number is never overwritten.
|
||||
- A backup export containing a value with an empty right-hand side (`Name=`)
|
||||
failed to parse, and with it the whole file, so that machine could never be
|
||||
backed up. The form is not strictly legal but occurs in real exports. It is
|
||||
now read as an empty string, preserving the value name.
|
||||
- The 3D parts kiosk label prefix never appeared on the kiosk. The kiosk runs
|
||||
logged out, and an unauthenticated read of a setting is limited to an
|
||||
allowlist the key was not on, so the kiosk got a 404 and fell back to no
|
||||
@@ -35,6 +48,17 @@ ADR-007 and ADR-002.
|
||||
|
||||
### Added
|
||||
|
||||
- A PC reporting a machine number is now linked to that machine. Until now the
|
||||
number was collected and then discarded, so a replaced PC never took over its
|
||||
bay: the retired PC kept the link and everything that walks PC to machine, the
|
||||
warranty machine column and the DNC info card among them, pointed at hardware
|
||||
that had been pulled out. The link is a `controls` relationship carrying a
|
||||
`collector:machine` origin label, so a link made by hand is never touched.
|
||||
Superseding a PC archives the old link rather than deleting it, keeping the
|
||||
history of which PC ran a machine and when, and raises an alert by email and
|
||||
webhook. The retired PC's status is deliberately left alone: the collector
|
||||
cannot tell whether it was shelved, sent for repair or re-imaged for another
|
||||
bay, so a person decides.
|
||||
- Plugin contract 0.16.0: `get_settings_defaults()` lets a plugin declare the
|
||||
settings it owns (key, default, type, category, description, and whether an
|
||||
unauthenticated caller may read it). See `docs/PLUGIN-HOOKS.md`.
|
||||
|
||||
Reference in New Issue
Block a user