Put an issue (or an epic with its children) into a release, or take it out (release null). Releases on only (D113).
move_to_releasePut an issue (or an epic with its children) into a release, or take it out (release null). Releases on only (D113).
Same as update_issue with release, plus an optional reason: after the release's baseline is locked, the change is written to the scope history of both releases with the reason (D113). An epic's children follow it unless they name another release. The target must exist and not be released yet (400). Members, release managers and project admins; viewers 403.
Put an issue — or an epic with all its children — into a planned release (release: null takes it out). Call get_issue first and pass its version. Add a short reason when the user gave one: after the release's baseline is locked it is kept in the scope history the release managers read.
WRITE: version must be the version from your latest read of this file (get_issue for issues, list_comments for comments, list_sprints for sprints, get_doc for project docs, read_file for md files). If the file changed since, the call fails with 409 version_conflict and the error contains the current file (details.current, details.current_version): re-read it, re-apply your change on top of the current content and retry with the new version. Never overwrite someone else's change blindly — if your change and theirs disagree, ask the user which to keep.
You act with exactly the rights of the user who owns this token; a project you cannot see returns not_found.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Why it moves (kept in the scope history after the baseline). | |
| release | Yes | ||
| version | Yes | Optimistic-lock version of the file; +1 on every write. Every write must send the version it read. | |
| issue_key | Yes | Issue key `{PROJECT}-{n}`, e.g. `KJ-101`. | |
| project_key | Yes | Project key, e.g. `KJ`. 2–10 chars, uppercase letters and digits, starts with a letter. |