de3c5aa562
Reported: moving machine 3016 on the map and saving answered "this relationship already exists" and refused the save. The map had nothing to do with it. Every save of the machine form re-POSTed the controlling-PC link, and the server was right to refuse it - the row was already active, and assetrelationships is unique on (source, target, type). Any edit to a machine that has a controlling PC hit this; a position change is just the one somebody happened to be making. The form asked the wrong question. It used "do I know the existing link's id" as a stand-in for "is there an existing link", and read that id from rel.assetrelationshipid - a key the API has never emitted. to_dict serialises column names and the column is relationshipid, so the read was undefined on every load while controllingPcId was populated from the same relationship. The two answers disagreed, and the disagreement was invisible: undefined is not an error, it is just a falsy id. That single conflation caused both failures. Saving anything re-created the link, and CLEARING the controlling PC did nothing at all, because "no selection and no known id" reads as "nothing to do" - so removing a machine's controlling PC silently kept it. Only the first of those was reported, and the second is the one somebody would have trusted. Fixed by making the LOADED PC the authority on whether a link exists, with the relationship id used only to delete a row. If that id ever goes missing again the worst case is a link that cannot be removed, never a duplicate create. The decision moved to controllingPc.js as a pure function so it could be pinned by tests, following labelPages.js. Unchanged is now explicitly no-op rather than delete-then-create: re-linking a machine to the same PC opens a window where it has no controlling PC at all, and resolve_asset_position walks that edge, so a failure between the two calls would drop the machine's inherited position along with its link. The specs also cover a select handing back '42' against an API that gave 42, which would make an untouched link look like a swap and reach the same duplicate POST by another route. Not the printer assignment, which was the first guess: PrinterAssignmentPicker makes no relationship calls, and its save is wrapped in a catch that only logs, so it cannot surface an error from this form at all.
69 lines
3.1 KiB
JavaScript
69 lines
3.1 KiB
JavaScript
// What saving the machine form should do about its controlling-PC link.
|
|
//
|
|
// Pulled out of MachineForm.vue because the component decided this inline and
|
|
// got it wrong in a way nothing could catch: it treated "I know the id of the
|
|
// existing link" as "there IS an existing link". The id was read from
|
|
// `rel.assetrelationshipid`, a key the API has never emitted - the column is
|
|
// `relationshipid` and to_dict serialises column names - so it was undefined on
|
|
// every load, and the two questions gave opposite answers on a machine that
|
|
// plainly had a controlling PC.
|
|
//
|
|
// Both failures followed from that single conflation:
|
|
// - Saving ANY change, a map position included, re-POSTed the link that was
|
|
// already there. The server answered 409 "this relationship already
|
|
// exists", correctly, and the form surfaced it as a failed save.
|
|
// - Clearing the controlling PC did nothing at all, because "no selection and
|
|
// no known id" reads as "nothing to do".
|
|
//
|
|
// So THE LOADED PC IS THE AUTHORITY on whether a link exists, and the
|
|
// relationship id is only ever used to delete a row. If the id goes missing
|
|
// again the worst case is a link that cannot be removed, never a duplicate
|
|
// create.
|
|
|
|
/**
|
|
* Decide what to do with the controlling-PC link on save.
|
|
*
|
|
* @param {object} state
|
|
* @param {number|string|null} state.selected - PC id chosen in the form now.
|
|
* @param {number|string|null} state.loaded - PC id the link named on load.
|
|
* @param {number|null} state.existingRelationshipId - row id to delete, if known.
|
|
* @returns {{action: 'none'|'unlink'|'link'|'relink', deleteId: number|null}}
|
|
*/
|
|
export function planControllingPcChange({ selected, loaded, existingRelationshipId } = {}) {
|
|
const now = normalize(selected)
|
|
const before = normalize(loaded)
|
|
const deleteId = existingRelationshipId ?? null
|
|
|
|
// Unchanged is not a change. Somebody moving a marker on the map is not
|
|
// asking to be re-linked to the same PC, and delete-then-create on an
|
|
// untouched link opens a window where the machine has no controlling PC -
|
|
// which resolve_asset_position walks across, so a failure between the two
|
|
// calls would lose the machine's inherited position along with the link.
|
|
if (now === before) {
|
|
return { action: 'none', deleteId: null }
|
|
}
|
|
|
|
if (now === null) {
|
|
// Cleared. Nothing to delete means nothing to do, rather than an error:
|
|
// the link is already absent, which is the state being asked for.
|
|
return deleteId === null
|
|
? { action: 'none', deleteId: null }
|
|
: { action: 'unlink', deleteId }
|
|
}
|
|
|
|
if (before === null) {
|
|
return { action: 'link', deleteId: null }
|
|
}
|
|
|
|
// Swapped to a different PC. The old row goes first: 'controls' is singular
|
|
// per source, not per target, so leaving it would leave the machine with two.
|
|
return { action: 'relink', deleteId }
|
|
}
|
|
|
|
// Ids arrive as numbers from the API and strings from a <select>, and '' means
|
|
// "nothing chosen". Comparing those raw is how an unchanged PC looks changed.
|
|
function normalize(value) {
|
|
if (value === null || value === undefined || value === '') return null
|
|
return String(value)
|
|
}
|