opschain asset demote

Included from Basic tierassets

Demotes an asset to a new entity over the v2 EntityService.DemoteAsset. In one transaction the server creates the entity with its own id and path, copies the asset's properties (with an opschain_lineage entry appended) and its settings document, moves the asset's child entities under the new entity, and leaves the asset archived with its change history (an ordinary archived node: it can be edited, unarchived, deleted and restored). The new entity carries no template pin, actions catalogue, MintModel or background work.

opschain asset demote /projects/shop/environments/prod/assets/orders_db --parent /projects/shop --code orders_record

The demotion is refused by name while the asset has active or queued changes, pending approvals, scheduled activities, or a live child an entity may not have (an infrastructure node) — resolve the named blocker first. A workflow step or trigger aimed at the asset does not block the demotion, as with a delete; any change it later tries to start on the old asset answers as on any archived asset. Re-running the demotion against the archived asset is refused: unarchive it first. You need update and delete on the asset and update on <parent>/entities at the destination; anything else reads as not found.

The table output names the old and new nodes and how many nodes moved; -o, --output json|yaml emits the DemoteAssetResponse (oldNode, newNode, movedNodes).

Flags

Flag	Meaning
--parent <path>	The new entity's parent: any node an entity may live under (default: the asset's parent).
--code <code>	The new entity's code (default: the asset's code). A code already taken by an entity under the parent is refused.
--server <url>	Server base URL (default: the active context / OPSCHAIN_SERVER).
--auth-token <token>	Admin bearer token override (default: your opschain login session, then $OPSCHAIN_ADMIN_TOKEN, then the token stored by opschain admin login).