`computer-prestages create` can reassign nested records from an existing prestage

[homebysix]

jamf-cli version

1.31.1 (commit 1f9a036)

Product namespace

pro (Jamf Pro / Platform API)

Auth method

token (pre-existing bearer)

OS / platform

macOS 27.2 (arm64)

Command run

jamf-cli pro computer-prestages get "$SOURCE_ID" -o json > source.json
jq '.displayName = "Copy"' source.json > copy.json
jamf-cli pro computer-prestages create < copy.json

Expected behavior

The source prestage remains unchanged. The new prestage receives newly allocated location, purchasing, and account-settings records. Alternatively, create rejects a payload containing IDs that already belong to another prestage.

Actual behavior

Source before create:
locationInformation.id: 3
purchasingInformation.id: 3
accountSettings.id: 3

Source after create:
locationInformation: null
purchasingInformation: null
accountSettings.id: 0

Copy after create:
locationInformation.id: 3
purchasingInformation.id: 3
accountSettings.id: 3


The new prestage received all three nested records from the source prestage. No error or warning was returned.

Anything else?

We reproduced this with two disposable prestages in a Jamf Pro development tenant, then deleted them. The same resulting state occurred in production, where the source prestage would no longer load in the Jamf Pro web UI.

The create --help output currently recommends retrieving a prestage, changing its name with jq, and passing the complete response to create. Could create remove or reset server-owned id and versionLock fields before sending the request?

This is related to #134’s prestage locking work, but concerns create requests reusing existing nested IDs rather than stale version locks.

Thanks for considering!