Module issues_api

Source

Enums§

AssignIssueError
struct for typed errors of method assign_issue
CreateIssueError
struct for typed errors of method create_issue
CreateIssuesError
struct for typed errors of method create_issues
DeleteIssueError
struct for typed errors of method delete_issue
DoTransitionError
struct for typed errors of method do_transition
EditIssueError
struct for typed errors of method edit_issue
GetChangeLogsError
struct for typed errors of method get_change_logs
GetCreateIssueMetaError
struct for typed errors of method get_create_issue_meta
GetEditIssueMetaError
struct for typed errors of method get_edit_issue_meta
GetIssueError
struct for typed errors of method get_issue
GetTransitionsError
struct for typed errors of method get_transitions
NotifyError
struct for typed errors of method notify

Functions§

assign_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.
create_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. 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. Permissions required: Browse projects and Create issues project permissions for the project in which the issue or subtask is created.
create_issues
Creates 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. 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.
delete_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.
do_transition
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.
edit_issue
Edits an issue. A transition may be applied and issue properties updated as part of the edit. 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. Connect app users with admin permissions (from user permissions and app scopes) 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.
get_change_logs
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.
get_create_issue_meta
Returns details of projects, issue types within projects, and, when requested, the create screen fields for each issue type for the user. Use the information to populate the requests in Create issue and Create issues. The request can be restricted to specific projects or issue types using the query parameters. The response will contain information for the valid projects, issue types, or project and issue type combinations requested. Note that invalid project, issue type, or project and issue type combinations do not generate errors. This operation can be accessed anonymously. Permissions required: Create issues project permission in the requested projects.
get_edit_issue_meta
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. Connect app users with admin permissions (from user permissions and app scopes) can return additional details using: * overrideScreenSecurity Returns hidden fields. * overrideEditableFlag Returns uneditable fields. For example, where an issue has a workflow status of closed none of its fields are editable. 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.
get_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.
get_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.
notify
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.