validate_lifecycle
Validate a lifecycle definition before saving: reports warnings for unknown statuses, malformed transitions, and invalid actions. Dry-run the full payload against RT checks before applying it.
Instructions
Check a lifecycle definition without saving it. Takes the same payload as update_lifecycle and reports whether RT would accept it, with a warning for each problem found (unknown statuses, malformed transitions or actions, and so on). Use this to dry-run a custom lifecycle before writing it, since update_lifecycle rejects the whole payload if anything is wrong. RT checks only the payload sent: it never reads the lifecycle the name refers to, which is why the name need not exist yet and why it does nothing but label the warnings. So send a complete definition rather than the part being changed — transitions on their own report every status in them as nonexistent, including statuses the named lifecycle already has. Read the current definition with get_lifecycle, change it, and validate the whole thing.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Lifecycle name the warnings are labelled with; need not exist, and its stored definition is not consulted | |
| active | No | Active statuses | |
| colors | No | Status colors as {"status_name": "#hex_color"} | |
| rights | No | Rights required for transitions as {"from -> to": "RightName"} | |
| actions | No | UI action buttons — see update_lifecycle for the accepted formats | |
| initial | No | Initial statuses | |
| defaults | No | Default statuses (e.g. {on_create: "new"}) | |
| inactive | No | Inactive statuses | |
| transitions | No | Allowed transitions as {from_status: [to_statuses]} | |
| status_metadata | No | Per-status description/notes — see update_lifecycle | |
| transition_metadata | No | Per-transition description/notes — see update_lifecycle |