Class Issues

Enables admins to archive up to 1000 issues in a single request using issue ID/key, returning details of the issue(s) archived in the process and the errors encountered, if any.

Note that:

• You can't archive subtasks directly, only through their parent issues
• You can only archive issues from software, service management, and business projects

Permissions required: Jira admin or site admin: global permission

License required: Premium or Enterprise

Signed-in users only: This API can't be accessed anonymously.

Enables admins to archive up to 1000 issues in a single request using issue ID/key, returning details of the issue(s) archived in the process and the errors encountered, if any.

Note that:

• You can't archive subtasks directly, only through their parent issues
• You can only archive issues from software, service management, and business projects

Permissions required: Jira admin or site admin: global permission

License required: Premium or Enterprise

Signed-in users only: This API can't be accessed anonymously.

Enables admins to archive up to 100,000 issues in a single request using JQL, returning the URL to check the status of the submitted request.

You can use the get task and cancel task APIs to manage the request.

Note that:

• You can't archive subtasks directly, only through their parent issues
• You can only archive issues from software, service management, and business projects

Permissions required: Jira admin or site admin: global permission

License required: Premium or Enterprise

Signed-in users only: This API can't be accessed anonymously.

Rate limiting: Only a single request per jira instance can be active at any given time.

Enables admins to archive up to 100,000 issues in a single request using JQL, returning the URL to check the status of the submitted request.

You can use the get task and cancel task APIs to manage the request.

Note that:

• You can't archive subtasks directly, only through their parent issues
• You can only archive issues from software, service management, and business projects

Permissions required: Jira admin or site admin: global permission

License required: Premium or Enterprise

Signed-in users only: This API can't be accessed anonymously.

Rate limiting: Only a single request per jira instance can be active at any given time.

Assigns an issue to a user. Use this operation when the calling user does not have the Edit Issues permission but has the Assign issue permission for the project that the issue is in.

If name or accountId is set to:

• "-1", the issue is assigned to the default assignee for the project.
• null, the issue is set to unassigned.

This operation can be accessed anonymously.

Permissions required:

• Browse Projects and Assign Issues project permission for the project that the issue is in.
• If issue-level security is configured, issue-level security permission to view the issue.

Assigns an issue to a user. Use this operation when the calling user does not have the Edit Issues permission but has the Assign issue permission for the project that the issue is in.

If name or accountId is set to:

• "-1", the issue is assigned to the default assignee for the project.
• null, the issue is set to unassigned.

This operation can be accessed anonymously.

Permissions required:

• Browse Projects and Assign Issues project permission for the project that the issue is in.
• If issue-level security is configured, issue-level security permission to view the issue.

Returns the details for a set of requested issues. You can request up to 100 issues.

Each issue is identified by its ID or key, however, if the identifier doesn't match an issue, a case-insensitive search and check for moved issues is performed. If a matching issue is found its details are returned, a 302 or other redirect is not returned.

Issues will be returned in ascending id order. If there are errors, Jira will return a list of issues which couldn't be fetched along with error messages.

This operation can be accessed anonymously.

Permissions required: Issues are included in the response where the user has:

• Browse projects project permission for the project that the issue is in.
• If issue-level security is configured, issue-level security permission to view the issue.

Returns the details for a set of requested issues. You can request up to 100 issues.

Each issue is identified by its ID or key, however, if the identifier doesn't match an issue, a case-insensitive search and check for moved issues is performed. If a matching issue is found its details are returned, a 302 or other redirect is not returned.

Issues will be returned in ascending id order. If there are errors, Jira will return a list of issues which couldn't be fetched along with error messages.

This operation can be accessed anonymously.

Permissions required: Issues are included in the response where the user has:

• Browse projects project permission for the project that the issue is in.
• If issue-level security is configured, issue-level security permission to view the issue.

Creates an issue or, where the option to create subtasks is enabled in Jira, a subtask. A transition may be applied, to move the issue or subtask to a workflow step other than the default start step, and issue properties set.

The content of the issue or subtask is defined using update and fields. The fields that can be set in the issue or subtask are determined using the Get create issue metadata. These are the same fields that appear on the issue's create screen. Note that the description, environment, and any textarea type custom fields (multi-line text fields) take Atlassian Document Format content. Single line custom fields (textfield) accept a string and don't handle Atlassian Document Format content.

Creating a subtask differs from creating an issue as follows:

• issueType must be set to a subtask issue type (use Get create issue metadata to find subtask issue types).
• parent must contain the ID or key of the parent issue.

In a next-gen project any issue may be made a child providing that the parent and child are members of the same project.

Permissions required: Browse projects and Create issues project permissions for the project in which the issue or subtask is created.

Creates an issue or, where the option to create subtasks is enabled in Jira, a subtask. A transition may be applied, to move the issue or subtask to a workflow step other than the default start step, and issue properties set.

The content of the issue or subtask is defined using update and fields. The fields that can be set in the issue or subtask are determined using the Get create issue metadata. These are the same fields that appear on the issue's create screen. Note that the description, environment, and any textarea type custom fields (multi-line text fields) take Atlassian Document Format content. Single line custom fields (textfield) accept a string and don't handle Atlassian Document Format content.

Creating a subtask differs from creating an issue as follows:

• issueType must be set to a subtask issue type (use Get create issue metadata to find subtask issue types).
• parent must contain the ID or key of the parent issue.

In a next-gen project any issue may be made a child providing that the parent and child are members of the same project.

Permissions required: Browse projects and Create issues project permissions for the project in which the issue or subtask is created.

Creates upto 50 issues and, where the option to create subtasks is enabled in Jira, subtasks. Transitions may be applied, to move the issues or subtasks to a workflow step other than the default start step, and issue properties set.

The content of each issue or subtask is defined using update and fields. The fields that can be set in the issue or subtask are determined using the Get create issue metadata. These are the same fields that appear on the issues' create screens. Note that the description, environment, and any textarea type custom fields (multi-line text fields) take Atlassian Document Format content. Single line custom fields (textfield) accept a string and don't handle Atlassian Document Format content.

Creating a subtask differs from creating an issue as follows:

• issueType must be set to a subtask issue type (use Get create issue metadata to find subtask issue types).
• parent the must contain the ID or key of the parent issue.

Permissions required: Browse projects and Create issues project permissions for the project in which each issue or subtask is created.

Creates upto 50 issues and, where the option to create subtasks is enabled in Jira, subtasks. Transitions may be applied, to move the issues or subtasks to a workflow step other than the default start step, and issue properties set.

The content of each issue or subtask is defined using update and fields. The fields that can be set in the issue or subtask are determined using the Get create issue metadata. These are the same fields that appear on the issues' create screens. Note that the description, environment, and any textarea type custom fields (multi-line text fields) take Atlassian Document Format content. Single line custom fields (textfield) accept a string and don't handle Atlassian Document Format content.

Creating a subtask differs from creating an issue as follows:

• issueType must be set to a subtask issue type (use Get create issue metadata to find subtask issue types).
• parent the must contain the ID or key of the parent issue.

Permissions required: Browse projects and Create issues project permissions for the project in which each issue or subtask is created.

Deletes an issue.

An issue cannot be deleted if it has one or more subtasks. To delete an issue with subtasks, set deleteSubtasks. This causes the issue's subtasks to be deleted with the issue.

This operation can be accessed anonymously.

Permissions required:

• Browse projects and Delete issues project permission for the project containing the issue.
• If issue-level security is configured, issue-level security permission to view the issue.

Deletes an issue.

An issue cannot be deleted if it has one or more subtasks. To delete an issue with subtasks, set deleteSubtasks. This causes the issue's subtasks to be deleted with the issue.

This operation can be accessed anonymously.

Permissions required:

• Browse projects and Delete issues project permission for the project containing the issue.
• If issue-level security is configured, issue-level security permission to view the issue.

Performs an issue transition and, if the transition has a screen, updates the fields from the transition screen.

SortByCategory To update the fields on the transition screen, specify the fields in the fields or update parameters in the request body. Get details about the fields using Get transitions with the transitions.fields expand.

This operation can be accessed anonymously.

Permissions required:

• Browse projects and Transition issues project permission for the project that the issue is in.
• If issue-level security is configured, issue-level security permission to view the issue.

Performs an issue transition and, if the transition has a screen, updates the fields from the transition screen.

SortByCategory To update the fields on the transition screen, specify the fields in the fields or update parameters in the request body. Get details about the fields using Get transitions with the transitions.fields expand.

This operation can be accessed anonymously.

Permissions required:

• Browse projects and Transition issues project permission for the project that the issue is in.
• If issue-level security is configured, issue-level security permission to view the issue.

Edits an issue. Issue properties may be updated as part of the edit. Please note that issue transition is not supported and is ignored here. To transition an issue, please use Transition issue.

The edits to the issue's fields are defined using update and fields. The fields that can be edited are determined using Get edit issue metadata.

The parent field may be set by key or ID. For standard issue types, the parent may be removed by setting update.parent.set.none to true. Note that the description, environment, and any textarea type custom fields (multi-line text fields) take Atlassian Document Format content. Single line custom fields (textfield) accept a string and don't handle Atlassian Document Format content.

Connect apps having an app user with Administer Jira global permission, and Forge apps acting on behalf of users with Administer Jira global permission, can override the screen security configuration using overrideScreenSecurity and overrideEditableFlag.

This operation can be accessed anonymously.

Permissions required:

• Browse projects and Edit issues project permission for the project that the issue is in.
• If issue-level security is configured, issue-level security permission to view the issue.

Edits an issue. Issue properties may be updated as part of the edit. Please note that issue transition is not supported and is ignored here. To transition an issue, please use Transition issue.

The edits to the issue's fields are defined using update and fields. The fields that can be edited are determined using Get edit issue metadata.

The parent field may be set by key or ID. For standard issue types, the parent may be removed by setting update.parent.set.none to true. Note that the description, environment, and any textarea type custom fields (multi-line text fields) take Atlassian Document Format content. Single line custom fields (textfield) accept a string and don't handle Atlassian Document Format content.

Connect apps having an app user with Administer Jira global permission, and Forge apps acting on behalf of users with Administer Jira global permission, can override the screen security configuration using overrideScreenSecurity and overrideEditableFlag.

This operation can be accessed anonymously.

Permissions required:

• Browse projects and Edit issues project permission for the project that the issue is in.
• If issue-level security is configured, issue-level security permission to view the issue.

Enables admins to retrieve details of all archived issues. Upon a successful request, the admin who submitted it will receive an email with a link to download a CSV file with the issue details.

Note that this API only exports the values of system fields and archival-specific fields (ArchivedBy and ArchivedDate). Custom fields aren't supported.

Permissions required: Jira admin or site admin: global permission

License required: Premium or Enterprise

Signed-in users only: This API can't be accessed anonymously.

Rate limiting: Only a single request can be active at any given time.

Enables admins to retrieve details of all archived issues. Upon a successful request, the admin who submitted it will receive an email with a link to download a CSV file with the issue details.

Note that this API only exports the values of system fields and archival-specific fields (ArchivedBy and ArchivedDate). Custom fields aren't supported.

Permissions required: Jira admin or site admin: global permission

License required: Premium or Enterprise

Signed-in users only: This API can't be accessed anonymously.

Rate limiting: Only a single request can be active at any given time.

Bulk fetch changelogs for multiple issues and filter by fields

Returns a paginated list of all changelogs for given issues sorted by changelog date and issue IDs, starting from the oldest changelog and smallest issue ID.

Issues are identified by their ID or key, and optionally changelogs can be filtered by their field IDs. You can request the changelogs of up to 1000 issues and can filter them by up to 10 field IDs.

Permissions required:

• Browse projects project permission for the projects that the issues are in.
• If issue-level security is configured, issue-level security permission to view the issues.

Bulk fetch changelogs for multiple issues and filter by fields

Returns a paginated list of all changelogs for given issues sorted by changelog date and issue IDs, starting from the oldest changelog and smallest issue ID.

Issues are identified by their ID or key, and optionally changelogs can be filtered by their field IDs. You can request the changelogs of up to 1000 issues and can filter them by up to 10 field IDs.

Permissions required:

• Browse projects project permission for the projects that the issues are in.
• If issue-level security is configured, issue-level security permission to view the issues.

Returns a paginated list of all changelogs for an issue sorted by date, starting from the oldest.

This operation can be accessed anonymously.

Permissions required:

• Browse projects project permission for the project that the issue is in.
• If issue-level security is configured, issue-level security permission to view the issue.

Returns a paginated list of all changelogs for an issue sorted by date, starting from the oldest.

This operation can be accessed anonymously.

Permissions required:

• Browse projects project permission for the project that the issue is in.
• If issue-level security is configured, issue-level security permission to view the issue.

Returns changelogs for an issue specified by a list of changelog IDs.

This operation can be accessed anonymously.

Permissions required:

• Browse projects project permission for the project that the issue is in.
• If issue-level security is configured, issue-level security permission to view the issue.

Returns changelogs for an issue specified by a list of changelog IDs.

This operation can be accessed anonymously.

Permissions required:

• Browse projects project permission for the project that the issue is in.
• If issue-level security is configured, issue-level security permission to view the issue.

Returns a page of field metadata for a specified project and issuetype id. Use the information to populate the requests in Create issue and Create issues.

This operation can be accessed anonymously.

Permissions required: Create issues project permission in the requested projects.

Returns a page of field metadata for a specified project and issuetype id. Use the information to populate the requests in Create issue and Create issues.

This operation can be accessed anonymously.

Permissions required: Create issues project permission in the requested projects.

Returns a page of issue type metadata for a specified project. Use the information to populate the requests in Create issue and Create issues.

This operation can be accessed anonymously.

Permissions required: Create issues project permission in the requested projects.

Returns a page of issue type metadata for a specified project. Use the information to populate the requests in Create issue and Create issues.

This operation can be accessed anonymously.

Permissions required: Create issues project permission in the requested projects.

Returns the edit screen fields for an issue that are visible to and editable by the user. Use the information to populate the requests in Edit issue.

This endpoint will check for these conditions:

1. Field is available on a field screen - through screen, screen scheme, issue type screen scheme, and issue type scheme configuration. overrideScreenSecurity=true skips this condition.
2. Field is visible in the field configuration. overrideScreenSecurity=true skips this condition.
3. Field is shown on the issue: each field has different conditions here. For example: Attachment field only shows if attachments are enabled. Assignee only shows if user has permissions to assign the issue.
4. If a field is custom then it must have valid custom field context, applicable for its project and issue type. All system fields are assumed to have context in all projects and all issue types.
5. Issue has a project, issue type, and status defined.
6. Issue is assigned to a valid workflow, and the current status has assigned a workflow step. overrideEditableFlag=true skips this condition.
7. The current workflow step is editable. This is true by default, but can be disabled by setting the jira.issue.editable property to false. overrideEditableFlag=true skips this condition.
8. User has Edit issues permission.
9. Workflow permissions allow editing a field. This is true by default but can be modified using jira.permission.* workflow properties.

Fields hidden using Issue layout settings page remain editable.

Connect apps having an app user with Administer Jira global permission, and Forge apps acting on behalf of users with Administer Jira global permission, can return additional details using:

• overrideScreenSecurity When this flag is true, then this endpoint skips checking if fields are available through screens, and field configuration (conditions 1. and 2. from the list above).
• overrideEditableFlag When this flag is true, then this endpoint skips checking if workflow is present and if the current step is editable (conditions 6. and 7. from the list above).

This operation can be accessed anonymously.

Permissions required:

• Browse projects project permission for the project that the issue is in.
• If issue-level security is configured, issue-level security permission to view the issue.

Note: For any fields to be editable the user must have the Edit issues project permission for the issue.

Returns the edit screen fields for an issue that are visible to and editable by the user. Use the information to populate the requests in Edit issue.

This endpoint will check for these conditions:

1. Field is available on a field screen - through screen, screen scheme, issue type screen scheme, and issue type scheme configuration. overrideScreenSecurity=true skips this condition.
2. Field is visible in the field configuration. overrideScreenSecurity=true skips this condition.
3. Field is shown on the issue: each field has different conditions here. For example: Attachment field only shows if attachments are enabled. Assignee only shows if user has permissions to assign the issue.
4. If a field is custom then it must have valid custom field context, applicable for its project and issue type. All system fields are assumed to have context in all projects and all issue types.
5. Issue has a project, issue type, and status defined.
6. Issue is assigned to a valid workflow, and the current status has assigned a workflow step. overrideEditableFlag=true skips this condition.
7. The current workflow step is editable. This is true by default, but can be disabled by setting the jira.issue.editable property to false. overrideEditableFlag=true skips this condition.
8. User has Edit issues permission.
9. Workflow permissions allow editing a field. This is true by default but can be modified using jira.permission.* workflow properties.

Fields hidden using Issue layout settings page remain editable.

Connect apps having an app user with Administer Jira global permission, and Forge apps acting on behalf of users with Administer Jira global permission, can return additional details using:

• overrideScreenSecurity When this flag is true, then this endpoint skips checking if fields are available through screens, and field configuration (conditions 1. and 2. from the list above).
• overrideEditableFlag When this flag is true, then this endpoint skips checking if workflow is present and if the current step is editable (conditions 6. and 7. from the list above).

This operation can be accessed anonymously.

Permissions required:

• Browse projects project permission for the project that the issue is in.
• If issue-level security is configured, issue-level security permission to view the issue.

Note: For any fields to be editable the user must have the Edit issues project permission for the issue.

Returns all issue events.

Permissions required: Administer Jira global permission.

Returns all issue events.

Permissions required: Administer Jira global permission.

Returns the details for an issue.

The issue is identified by its ID or key, however, if the identifier doesn't match an issue, a case-insensitive search and check for moved issues is performed. If a matching issue is found its details are returned, a 302 or other redirect is not returned. The issue key returned in the response is the key of the issue found.

This operation can be accessed anonymously.

Permissions required:

• Browse projects project permission for the project that the issue is in.
• If issue-level security is configured, issue-level security permission to view the issue.

Returns the details for an issue.

The issue is identified by its ID or key, however, if the identifier doesn't match an issue, a case-insensitive search and check for moved issues is performed. If a matching issue is found its details are returned, a 302 or other redirect is not returned. The issue key returned in the response is the key of the issue found.

This operation can be accessed anonymously.

Permissions required:

• Browse projects project permission for the project that the issue is in.
• If issue-level security is configured, issue-level security permission to view the issue.

Returns all issues breaching and approaching per-issue limits.

Permissions required:

• Browse projects project permission is required for the project the issues are in. Results may be incomplete otherwise
• Administer Jira global permission.

Returns all issues breaching and approaching per-issue limits.

Permissions required:

• Browse projects project permission is required for the project the issues are in. Results may be incomplete otherwise
• Administer Jira global permission.

Returns either all transitions or a transition that can be performed by the user on an issue, based on the issue's status.

Note, if a request is made for a transition that does not exist or cannot be performed on the issue, given its status, the response will return any empty transitions list.

This operation can be accessed anonymously.

Permissions required: A list or transition is returned only when the user has:

• Browse projects project permission for the project that the issue is in.
• If issue-level security is configured, issue-level security permission to view the issue.

However, if the user does not have the Transition issues project permission the response will not list any transitions.

Returns either all transitions or a transition that can be performed by the user on an issue, based on the issue's status.

Note, if a request is made for a transition that does not exist or cannot be performed on the issue, given its status, the response will return any empty transitions list.

This operation can be accessed anonymously.

Permissions required: A list or transition is returned only when the user has:

• Browse projects project permission for the project that the issue is in.
• If issue-level security is configured, issue-level security permission to view the issue.

However, if the user does not have the Transition issues project permission the response will not list any transitions.

Creates an email notification for an issue and adds it to the mail queue.

Permissions required:

• Browse Projects project permission for the project that the issue is in.
• If issue-level security is configured, issue-level security permission to view the issue.

Creates an email notification for an issue and adds it to the mail queue.

Permissions required:

• Browse Projects project permission for the project that the issue is in.
• If issue-level security is configured, issue-level security permission to view the issue.

Enables admins to unarchive up to 1000 issues in a single request using issue ID/key, returning details of the issue(s) unarchived in the process and the errors encountered, if any.

Note that:

• You can't unarchive subtasks directly, only through their parent issues
• You can only unarchive issues from software, service management, and business projects

Permissions required: Jira admin or site admin: global permission

License required: Premium or Enterprise

Signed-in users only: This API can't be accessed anonymously.

Enables admins to unarchive up to 1000 issues in a single request using issue ID/key, returning details of the issue(s) unarchived in the process and the errors encountered, if any.

Note that:

• You can't unarchive subtasks directly, only through their parent issues
• You can only unarchive issues from software, service management, and business projects

Permissions required: Jira admin or site admin: global permission

License required: Premium or Enterprise

Signed-in users only: This API can't be accessed anonymously.