update_lifecycle
Replace a stored Request Tracker lifecycle by sending the full definition; omitted keys are dropped, so fetch the current config, modify, and send the whole object back to update.
Instructions
Update a lifecycle's configuration. Pass the full lifecycle definition including initial, active, inactive status arrays, transitions, rights, actions, and defaults. This REPLACES the stored configuration — any key you omit is dropped, including keys inherited from a create_lifecycle clone. RT fills in a missing defaults.on_create from the first initial status, and falls back to ModifyTicket — DeleteTicket for deleted — where rights are missing, but it does that in memory as it loads the config: neither key reappears in get_lifecycle, so one absent there is a working default rather than damage to repair. Omitted actions, colors, status_metadata and transition_metadata are simply lost. Cloning "default" inherits a full set of metadata, so omitting those two keys here silently strips the descriptions from every status. Use get_lifecycle first to get the current config, then modify and send the whole thing back. The lifecycle is validated before saving; any warning fails the update with a 400.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Lifecycle name to update | |
| active | No | Active statuses (work in progress) | |
| colors | No | Status colors as {"status_name": "#hex_color"}. Colors appear in the RT web UI next to status names. | |
| rights | No | Rights required for transitions as {"from -> to": "RightName"} | |
| actions | No | UI action buttons for transitions, keyed by transition: {"new -> open": {"label": "Open It", "update": "Respond"}}. RT also accepts its native flat array alternating transition string and info object (["new -> open", {"label": "Open It"}]), which is what get_lifecycle returns for lifecycles cloned from default — send that form back unchanged if you are not editing it. An array of {from, to, label} objects is REJECTED with a 400. "label" is the button text; "update" is optional and opens that form when clicked ("Respond" or "Comment"). Wildcards are allowed, e.g. "* -> resolved". The keyed form is ordered by sorted transition string; the array form keeps the order given. | |
| initial | No | Initial statuses (tickets start here) | |
| defaults | No | Default statuses (e.g. {on_create: "new", approved: "open"}) | |
| inactive | No | Inactive statuses (finished/closed) | |
| transitions | No | Allowed transitions as {from_status: [to_statuses]}. Use "" key for statuses available at creation. | |
| status_metadata | No | Per-status documentation, keyed by status name: {"stalled": {"description": "Blocked, waiting on something external.", "notes": "Note what you are waiting on."}}. "description" is human-facing, "notes" is guidance for an AI agent working the ticket. Both are optional free text; no other fields are allowed. | |
| transition_metadata | No | Per-transition documentation, keyed like rights: {"open -> resolved": {"description": "The work is complete.", "notes": "Resolve when the work is verified."}}. Same two optional fields as status_metadata. Wildcards are allowed ("* -> rejected"), and unlike rights, matching entries merge field by field with the more specific key winning. |