asset-edit

Editing assets

edit_asset applies a list of typed operations to a single asset, identified by UUID. Each operation has its own required fields; mixing operation types in one call is fine and runs them in order.

Operation types

Hard rules

1. set_attribute vs add_attribute. Use set_attribute for normal single-valued attributes (like Definition) — it creates the value if absent and updates it if present, so you never need to know the current state first. add_attribute only appends an extra value to a multi-valued attribute. To see which attributes an asset can hold — including ones that are valid but currently empty — call get_asset_details and read assignableAttributes. An attribute missing from the asset's values but present there is settable, not invalid.
2. update_property is restricted. Only three fields are allowed: name, displayName, statusId. Other fields return an error listing the allowed set.
3. statusId accepts names. Pass a human-readable status name (e.g. "Candidate", "Accepted") or the UUID — chip resolves either.
4. Responsibility ops accept user identifiers in three forms. For set_responsibility and remove_responsibility, userId may be a UUID, a username, or an email. Chip resolves the form server-side. The same applies to relationType targets in add_relation / remove_relation.
5. remove_responsibility only removes direct responsibilities. It deletes a responsibility assigned directly on the asset; one inherited from a parent domain or community can't be removed here and returns an error pointing to where it's defined.
6. RICH_TEXT attribute values are Markdown. Same rule as create_asset — write Markdown, chip converts to HTML. See shared/rich-text-markdown.md for the full rules.