update_issue
Update an issue: any of summary, description, type, assignee, priority, labels, dueDate, parentKey, fixVersions, or status (which performs the transition, and fires the project's rules — a rule may append a checklist to the description, in which case 'description' is listed in 'changed'). Only the fields you pass are changed. A project's workflow may put conditions on a move — that only certain people may make it, or that it must set certain fields — and a refusal names the condition and, where it is about who you are, lists the states you CAN reach. Fields a move requires must be sent in this same call, with 'resolution' and 'fields': a value set by an earlier call does not satisfy the condition. Answers with 'notified' (who this actually reaches) and 'unresolvedMentions' (what looked like a mention and reached nobody, each with a reason) — a wrong handle is stored as written and never refused, so that list is the only sign it did not land.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Issue key, e.g. 'UK-1'. | |
| type | No | New issue type name, e.g. 'Task', 'Bug', 'Story', 'Epic'. | |
| fields | No | The project's own columns to fill in with this update, by their NAMES: 'Segment=AI; Country=Poland', or a JSON object. Same shape as set_issue_fields — this exists here because a move a workflow conditions on a column has to set it in the same call. | |
| labels | No | Labels to set, space or comma separated. Replaces the existing set. | |
| status | No | Status name to move the issue to, e.g. 'In Progress', 'Done'. | |
| dueDate | No | The day this is due, as YYYY-MM-DD. A calendar day, not a timestamp. Pass an empty string to clear it. | |
| summary | No | New summary (title). | |
| assignee | No | Assignee username or email. Pass an empty string to unassign. 'agent:<role>' (e.g. 'agent:product') hands the issue to that agent instead: you become the assignee and the agent works on your behalf — allowed only where a switched-on duty of that role in this project takes issues like this one (list_project_rules shows the duties). | |
| priority | No | Priority name, e.g. 'High'. | |
| parentKey | No | Key of the issue this one hangs off, e.g. 'PM-276' — moves it under that story or epic. To DETACH it instead, send detachParent: true; an empty string still works but is easy to lose on the way. Nothing is renamed and the key never changes: an issue keeps the key of the project it lives in. A sub-task must stay in its parent's project; anything else may cross projects. | |
| resolution | No | Resolution name to set, e.g. 'Fixed', 'Won't Do'. Some workflows require one on the move into a finished state; sending it here is how that condition is met. | |
| description | No | New description. Markdown, with $…$ / $$…$$ LaTeX formulas and [~username] mentions. | |
| fixVersions | No | The versions of the project this goes out in, by name, comma-separated: '2.4.0, 2.4.1'. REPLACES the set — to add one, send the ones it has (get_issue's 'fixVersions') with the new one. Pass an empty string to take it out of every version. A name the project does not have refuses the update and lists the ones it has. | |
| detachParent | No | Take this issue out from under its parent and leave it top-level. The reliable way to detach: unlike an empty parentKey it cannot arrive as the two characters "" or be dropped as «nothing was sent». Refused together with a parentKey, since the two would be asking for opposite things. |