Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
In this article, I would be showing you how to create a Jira issue using the "go-atlassian" library.
Create a new directory for your project.
Open a terminal and navigate to the project directory.
Initialize a new Go module using the following command:
In the terminal, run the following command to install the "go-atlassian" library:
Create a new Go file (e.g., main.go
) in your project directory.
Open the file and import the required packages:
You can use the V2 and V3 Jira endpoint versions.
In the main
function, create a new Jira client and authenticate using your Jira URL, username, and API token:
OPTIONAL, you can define custom-fields values you want to set on the issue creation. This library supports the following custom-fields types:
Create a new issue using the Create
method and set the custom fields:
Save the main.go
file.
In the terminal, navigate to your project directory.
Execute the following command to run the program:
This will create a new issue in Jira with the specified custom field values. Please note that you may need to modify the code according to your specific Jira configuration and custom field types.
go-atlassian is a Go library that provides a simple and convenient way to interact with various Atlassian products' REST APIs. Atlassian is a leading provider of software and tools for software development, project management, and collaboration. Some of the products that go-atlassian supports include Jira, Confluence, Jira Service Management, and more.
The go-atlassian library is designed to simplify the process of building Go applications that interact with Atlassian products. It provides a set of functions and data structures that can be used to easily send HTTP requests to the Atlassian APIs, parse the responses, and work with the data returned.
Easy-to-use functions and data structures that abstract away much of the complexity of working with the APIs.
Comprehensive support for various Atlassian products' APIs.
Support for common operations like creating, updating, and deleting entities in Atlassian products.
Active development and maintenance by the community, with regular updates and bug fixes.
Comprehensive documentation and examples to help developers get started with using the library.
If you do not have Go installed yet, you can find installation instructions here. Please note that the package requires Go version 1.20 or later for module support.
To pull the most recent version of go-atlassian, use go get
.
Then import the package into your project as you normally would. You can import the following packages:
Jira v2
github.com/ctreminiom/go-atlassian/v2/jira/v2
Jira v3
github.com/ctreminiom/go-atlassian/v2/jira/v3
Jira Software Agile
github.com/ctreminiom/go-atlassian/v2/jira/agile
Jira Service Management
github.com/ctreminiom/go-atlassian/v2/jira/sm
Jira Assets
github.com/ctreminiom/go-atlassian/v2/assets
Confluence
github.com/ctreminiom/go-atlassian/v2/confluence
Confluence v2
github.com/ctreminiom/go-atlassian/v2/confluence/v2
Admin Cloud
github.com/ctreminiom/go-atlassian/v2/admin
Bitbucket Cloud (In Progress)
github.com/ctreminiom/go-atlassian/v2/bitbucket
Before using the go-atlassian package, you need to have an Atlassian API key. If you do not have a key yet, you can sign up here.
Create a client with your instance host and access token to start communicating with the Atlassian API's. In this example, we're going to instance a new Confluence Cloud client.
If you need to use a preconfigured HTTP client, simply pass its address to the New
function.
For detailed examples and usage of the go-atlassian library, please refer to our Cookbook. This section provides step-by-step guides and code samples for common tasks and scenarios.
The library uses the services interfaces to provide a modular and flexible way to interact with Atlassian products' REST APIs. It defines a set of services interfaces that define the functionality of each API, and then provides implementations of those interfaces that can be used to interact with the APIs.
Each service interface includes a set of methods that correspond to the available endpoints in the corresponding API. For example, the IssueService
interface includes methods like Create
, Update
, and Get
that correspond to the POST
, PUT
, and GET
endpoints in the Jira Issues API.
Behind the scenes, the Create
method on the IssueService
interface is implemented by the issueService.Create
function in the go-atlassian library. This function sends an HTTP request to the relevant endpoint in the Jira Issues API, using the credentials and configuration provided by the client, and then parses the response into a usable format.
Here's a little example about how to get the issue transitions using the Issue service.
The rest of the service functions work much the same way; they are concise and behave as you would expect. The documentation contains several examples on how to use each service function.
If you need to interact with an Atlassian API endpoint that hasn't been implemented in the go-atlassian
library yet, you can make a custom API request using the built-in Client.Call
method to execute raw HTTP requests.
Please raise an issue in order to implement the endpoint
If you would like to contribute to this project, please adhere to the following guidelines.
Submit an issue describing the problem.
Fork the repo and add your contribution.
Follow the basic Go conventions found here.
Create a pull request with a description of your changes.
Again, contributions are greatly appreciated!
The project was created with the purpose to provide a unique point to provide an interface for interacting with Atlassian products.
This module is highly inspired by the Go library https://github.com/andygrunwald/go-jira but focused on Cloud solutions.
The library shares many similarities with go-jira, including its use of service interfaces to define the functionality of each API, its modular and flexible approach to working with Atlassian products' API's. However, go-atlassian also adds several new features and improvements that are not present in go-jira.
Despite these differences, go-atlassian remains heavily inspired by go-jira, and many of the core design principles and patterns used in go-jira can be found in go-atlassian as well.
Copyright © 2023 Carlos Treminio. This project is MIT licensed.
We would like to extend our sincere thanks to the following sponsors for their generous support:
Atlassian for providing us Atlassian Admin/Jira/Confluence Standard licenses.
GitBook for providing us non-profit / open-source plan so hence I would like to express my thanks here.
In this article, I would be showing you how to create a Service Management customer request with custom-fields.
Create a new directory for your project.
Open a terminal and navigate to the project directory.
Initialize a new Go module using the following command:
In the terminal, run the following command to install the "go-atlassian" library:
Create a new Go file (e.g., main.go
) in your project directory.
Open the file and import the required packages:
In the main
function, create a new Jira client and authenticate using your Jira URL, username, and API token:
Define the fields you want to set:
Create a new issue using the Create
method and set the custom fields:
Save the main.go
file.
In the terminal, navigate to your project directory.
Execute the following command to run the program:
This will create a new ITSM customer request in Jira with the specified custom field values.
In this article, I would be showing you how to extract user last-activity information from the Atlassian Admin API's using go-atlassian
Create a new directory for your project and navigate to it in your terminal or command prompt. Initialize a new Go module using the following command:
To use the "go-atlassian" library, you need to install it as a dependency in your project. Run the following command:
Create a new Go file, e.g., main.go
, and import the necessary packages:
Initialize the Atlassian Admin client with your API token:
It's required to extract the ID of the organization you're using, the organization ID can be extract on the admin URL, as the image below:
In this step, we're going to extract the organization users and store them into an array variable, please use the following code block to extract them.
With the organization users extracted, we need to iterate each user and extract the last-login information, you can use the following code to do that:
The go-atlassian jira
module provides a set of functions and types for interacting with the Jira REST API. It is designed to make it easy for developers to build powerful integrations and automations that leverage the capabilities of the Jira platform.
The module is available in two versions: v2
and v3
. These versions correspond to different versions of the Jira REST API, with v2
supporting Jira versions 6.4 to 7.2, and v3
supporting Jira versions 7.3 and later.
The Atlassian Document Format (ADF) is a JSON-based format used by Atlassian products, including Jira, to represent rich content such as text, tables, and lists. The jira
module in go-atlassian provides support for working with ADF content in both the v3
package.
In v3
, the IssueService
and related services like CommentService
provide functions that allow you to interact with ADF content. For example, the CreateIssue
function in v3
includes a parameter for Fields
, which is a struct that includes fields for specifying various attributes of the new issue, including the issue summary, description, and any custom fields. The Fields
struct includes a field for Description
, which can be set to a struct representing ADF content.
To search issues using a JQL query, use the Issue.Search service function.
body
in comments, including where comments are used in issue, issue link, and transition resources.
comment
in worklogs
description
and environment
fields in issues.
In this article, I would be showing you how to extract the boards associated with a Jira project using go-atlassian
Create a new directory for your project and navigate to it in your terminal or command prompt. Initialize a new Go module using the following command:
To use the "go-atlassian" library, you need to install it as a dependency in your project. Run the following command:
Create a new Go file, e.g., main.go
, and import the necessary packages:
Initialize the Jira Agile API client with your Jira base URL and API token:
In this step, you're going to use the Jira Agile API, more specifically, the Board service, Gets() method. This methods supports multiple query parameters, but in this example, we're going to use the ProjectKeyOrID
param to filter the board linked to a Jira project.
The following example iterates the Board.Gets() method and appends the boards into a slice.
The Jira audit logs are a set of records that document all the activities and changes made in Jira. These logs provide a detailed record of who did what, when, and where within Jira. Here are a few examples of the type of activities that are logged in the Jira audit logs:
The audit logs are useful for several reasons. For example, they can be used to track changes made to sensitive data, to identify who made specific changes to issues or projects, or to diagnose issues with Jira.
GET /rest/api/{2-3}/auditing/record
This method allows you to retrieve the audit records for specific activities that have occurred within Jira.
Jira application roles are a way of managing user permissions and access in Jira. Jira comes with a set of predefined roles that define common types of users, such as administrators, developers, and project managers.
Each Jira application role has a set of permissions associated with it, which determine what actions a user in that role is allowed to perform. For example, the "Admin" role has permission to manage Jira system settings and users, while the "Developer" role has permission to create and edit issues and view source code.
GET /rest/api/{2-3}/applicationrole
This endpoint is used to retrieve a list of all application roles that are defined in a Jira instance. This endpoint can be used to get information about the roles that are available in Jira, and to help manage user access and permissions.
GET /rest/api/{2-3}/applicationrole/{key}
This method allows you to retrieve information about a specific application role in Jira using the key name as reference.
User login and logout events
Issue creation, modification, and deletion events
Workflow transition events
Project creation, modification, and deletion events
User management events such as user creation, modification, and deletion
User management events such as user creation, modification, and deletion
In this article, I would be showing you how to create Jira workflow and append transitions using go-atlassian
Create a new directory for your project and navigate to it in your terminal or command prompt. Initialize a new Go module using the following command:
To use the "go-atlassian" library, you need to install it as a dependency in your project. Run the following command:
Create a new Go file, e.g., main.go
, and import the necessary packages:
Initialize the Jira API client with your Jira base URL and API token:
To create a new workflow, we need to the create the models.WorkflowPayloadScheme
payload struct with the following information.
Worfklow Name.
Workflow Description.
Workflow Statuses.
Workflow Transitions.
Let's try to create a workflow with directed transitions and all-to-all transitions, something like this:
The first step to create a Jira workflow is recognize what's gonna be the statuses you want to use.
In this particular example, we're needed to use the following statuses:
Open
In Progress
QA
Waiting for approval
Escalated
Closed
Resolved
The previously code extracts the status ID's from the Jira instance and if one status is not available on the instance, it'll automatically create the statuses and append the information on the statusesAsMap
variable.
With the status ID's, we can proceed with the creation of the workflow statuses payload
With the statuses id's extracted, we can create a workflow transitions. The transitions define the paths that an issue can take from one status to another.
For example: an issue in the "Open" status can transition to the "In Progress" status when work begins on it.
There're the conditional validations needed to create a valid workflow transition:
include one initial transition.
not use the same name for a global and directed transition.
have a unique name for each global transition.
have a unique 'to' status for each global transition.
have unique names for each transition from a status.
not have a 'from' status on initial and global transitions.
have a 'from' status on directed transitions.
In conclusion, we can combine the statuses and transitions structs and create the workflow using the structs created on the previous steps.
System Administrators can configure an announcement banner to display pertinent information on all Jira pages. The banner can be used to relate important information (e.g. scheduled server maintenance, approaching project deadlines, etc.) to all users. Further, the banner visibility level can be configured to display to all users or just logged-in users.
GET /rest/api/{2/3}/announcementBanner
Get returns the current announcement banner configuration.
PUT /rest/api/{2-3}/announcementBanner
Update updates the announcement banner configuration.
In Jira Cloud, custom fields are managed in a way that allows for flexibility and dynamic creation. Each new custom field that you create within a Jira Cloud instance is assigned a unique ID. This ID is used to identify and manage the custom field's configuration and data within the Jira system.
In this particular case, the library contains multiples helpers method will help you to extract the customfield information by type using the response buffer.
The following methods can be used to extract the customfield information from one issue.
This method parses a multi-select custom field from the given buffer data associated with the specified custom field ID and returns a slice of pointers to CustomFieldContextOptionSchema
structs.
ParseSelectCustomField parses a select custom field from the given buffer data associated with the specified custom field ID and returns a CustomFieldContextOptionScheme struct
This method parses a cascading custom field from the given buffer data associated with the specified custom field ID and returns a CascadingSelectScheme struct pointer.
ParseDatePickerCustomField parses the datepicker customfield from the given buffer data associated with the specified custom field ID and returns a struct time.Time value
ParseDateTimeCustomField parses the datetime customfield from the given buffer data associated with the specified custom field ID and returns a struct time.Time value.
This method parses a group-picker custom field from the given buffer data associated with the specified custom field ID and returns a slice of pointers to UserDetailScheme structs.
This method parses a group-picker custom field from the given buffer data associated with the specified custom field ID and returns a slice of pointers to GroupDetailScheme structs.
ParseFloatCustomField parses a float custom field from the given buffer data associated with the specified custom field ID and returns string.
ParseSprintCustomField parses a sprints custom field from the given buffer data associated with the specified custom field ID and returns a slice of the SprintDetailScheme struct.
ParseLabelCustomField parses a textfield slice custom field from the given buffer data associated with the specified custom field ID and returns string slice.
ParseMultiVersionCustomField parses a version-picker custom field from the given buffer data associated with the specified custom field ID and returns a slice of pointers to VersionDetailScheme structs.
ParseUserPickerCustomField parses a user custom field from the given buffer data associated with the specified custom field ID and returns a struct of UserDetailScheme.
ParseAssetCustomField parses the Jira assets elements from the given buffer data associated with the specified custom field ID and returns a struct CustomFieldAssetScheme slice.
ParseStringCustomField parses a textfield custom field from the given buffer data associated with the specified custom field ID and returns string.
If you want to extract the customfield values from a buffer of issues, you can use the following methods, it returns a map where the key is the issue key and the value is the customfield values parsed
ParseMultiSelectCustomFields extracts and parses multi-select custom field data from a given bytes.Buffer from multiple issues.
This function takes the name of the custom field to parse and a bytes.Buffer containing JSON data representing the custom field values associated with different issues. It returns a map where the key is the issue key and the value is a slice of CustomFieldContextOptionScheme structs, representing the parsed multi-select custom field values.
The JSON data within the buffer is expected to have a specific structure where the custom field values are organized by issue keys and options are represented within a context.
The function parses this structure to extract and organize the custom field values.
If the custom field data cannot be parsed successfully, an error is returned.
ParseSelectCustomFields extracts and parses select custom field data from a given bytes.Buffer from multiple issues.
This function takes the name of the custom field to parse and a bytes.Buffer containing JSON data representing the custom field values associated with different issues. It returns a map where the key is the issue key and the value is a CustomFieldContextOptionScheme struct, representing the parsed select custom field value.
ParseCascadingCustomFields extracts and parses a cascading custom field data from a given bytes.Buffer from multiple issues.
This function takes the name of the custom field to parse and a bytes.Buffer containing JSON data representing the custom field values associated with different issues. It returns a map where the key is the issue key and the value is a CascadingSelectScheme struct pointer, representing the parsed cascading custom field value.
ParseMultiUserPickerCustomFields extracts and parses a user picker custom field data from a given bytes.Buffer from multiple issues.
This function takes the name of the custom field to parse and a bytes.Buffer containing JSON data representing the custom field values associated with different issues. It returns a map where the key is the issue key and the value is a slice of UserDetailScheme structs, representing the parsed multi-select custom field values.
The JSON data within the buffer is expected to have a specific structure where the custom field values are organized by issue keys and options are represented within a context.
The function parses this structure to extract and organize the custom field values.
If the custom field data cannot be parsed successfully, an error is returned.
ParseDatePickerCustomFields extracts and parses the datepicker customfield data from a given bytes.Buffer from multiple issues.
This function takes the name of the custom field to parse and a bytes.Buffer containing JSON data representing the custom field values associated with different issues. It returns a map where the key is the issue key and the value is a time.Time value, representing the parsed datepicker values with the Jira issues.
The JSON data within the buffer is expected to have a specific structure where the custom field values are organized by issue keys and options are represented within a context.
The function parses this structure to extract and organize the custom field values.
If the custom field data cannot be parsed successfully, an error is returned.
ParseDateTimeCustomFields extracts and parses the datetime customfield data from a given bytes.Buffer from multiple issues.
This function takes the name of the custom field to parse and a bytes.Buffer containing JSON data representing the custom field values associated with different issues. It returns a map where the key is the issue key and the value is a time.Time value, representing the parsed datetime values with the Jira issues.
The JSON data within the buffer is expected to have a specific structure where the custom field values are organized by issue keys and options are represented within a context.
The function parses this structure to extract and organize the custom field values.
If the custom field data cannot be parsed successfully, an error is returned.
ParseMultiGroupPickerCustomFields extracts and parses a group picker custom field data from a given bytes.Buffer from multiple issues.
This function takes the name of the custom field to parse and a bytes.Buffer containing JSON data representing the custom field values associated with different issues. It returns a map where the key is the issue key and the value is a slice of GroupDetailScheme structs, representing the parsed multi-group custom field values.
The JSON data within the buffer is expected to have a specific structure where the custom field values are organized by issue keys and options are represented within a context.
The function parses this structure to extract and organize the custom field values.
If the custom field data cannot be parsed successfully, an error is returned.
ParseFloatCustomFields extracts and parses the float customfield information from multiple issues using a bytes.Buffer.
This function takes the name of the custom field to parse and a bytes.Buffer containing JSON data representing the custom field values associated with different issues. It returns a map where the key is the issue key and the value is a string representing the parsed float64 customfield value.
The JSON data within the buffer is expected to have a specific structure where the custom field values are organized by issue keys and options are represented within a context.
The function parses this structure to extract and organize the custom field values.
If the custom field data cannot be parsed successfully, an error is returned.
ParseStringCustomFields extracts and parses the textfield customfield information from multiple issues using a bytes.Buffer.
This function takes the name of the custom field to parse and a bytes.Buffer containing JSON data representing the custom field values associated with different issues. It returns a map where the key is the issue key and the value is a string representing the parsed textfield customfield value.
The JSON data within the buffer is expected to have a specific structure where the custom field values are organized by issue keys and options are represented within a context.
The function parses this structure to extract and organize the custom field values.
If the custom field data cannot be parsed successfully, an error is returned.
ParseUserPickerCustomFields extracts and parses a user custom field data from a given bytes.Buffer from multiple issues.
This function takes the name of the custom field to parse and a bytes.Buffer containing JSON data representing the custom field values associated with different issues. It returns a map where the key is the issue key and the value is a UserDetailScheme struct pointer ,representing the parsed user custom field value.
The JSON data within the buffer is expected to have a specific structure where the custom field values are organized by issue keys and options are represented within a context.
The function parses this structure to extract and organize the custom field values.
If the custom field data cannot be parsed successfully, an error is returned.
ParseSprintCustomFields extracts and parses sprint custom field data from a given bytes.Buffer from multiple issues.
This function takes the name of the custom field to parse and a bytes.Buffer containing JSON data representing the custom field values associated with different issues. It returns a map where the key is the issue key and the value is a slice of SprintDetailScheme structs, representing the parsed sprint custom field values.
The JSON data within the buffer is expected to have a specific structure where the custom field values are organized by issue keys and options are represented within a context.
The function parses this structure to extract and organize the custom field values.
If the custom field data cannot be parsed successfully, an error is returned.
ParseLabelCustomFields extracts and parses the label customfield information from multiple issues using a bytes.Buffer.
This function takes the name of the custom field to parse and a bytes.Buffer containing JSON data representing the custom field values associated with different issues. It returns a map where the key is the issue key and the value is a string slice representing the parsed label customfield value.
The JSON data within the buffer is expected to have a specific structure where the custom field values are organized by issue keys and options are represented within a context.
The function parses this structure to extract and organize the custom field values.
If the custom field data cannot be parsed successfully, an error is returned.
ParseMultiVersionCustomFields extracts and parses a version picker custom field data from a given bytes.Buffer from multiple issues.
This function takes the name of the custom field to parse and a bytes.Buffer containing JSON data representing the custom field values associated with different issues. It returns a map where the key is the issue key and the value is a slice of VersionDetailScheme structs, representing the parsed multi-version custom field values.
The JSON data within the buffer is expected to have a specific structure where the custom field values are organized by issue keys and options are represented within a context.
The function parses this structure to extract and organize the custom field values.
If the custom field data cannot be parsed successfully, an error is returned.
ParseAssetCustomFields extracts and parses jira assets customfield data from a given bytes.Buffer from multiple issues.
This function takes the name of the custom field to parse and a bytes.Buffer containing JSON data representing the custom field values associated with different issues. It returns a map where the key is the issue key and the value is a slice of CustomFieldAssetScheme structs, representing the parsed assets associated with a Jira issues.
In Jira, a group is a collection of users who have similar roles, responsibilities, or permissions. Groups can be used to simplify user management by allowing you to grant permissions and roles to entire groups of users rather than individual users.
Here are some ways you can use groups in Jira:
Assigning permissions: You can assign permissions to a group of users instead of individual users. For example, you might create a group called "Developers" and grant them permissions to create and modify issues.
Sharing filters and dashboards: You can share filters and dashboards with groups of users. For example, you might create a filter that shows all issues assigned to the "Developers" group and share it with all members of that group.
Managing notifications: You can use groups to manage notifications in Jira. For example, you might create a group called "Product Owners" and add all product owners to that group. You can then set up notifications so that all members of the "Product Owners" group are notified when certain events occur in Jira.
Restricting access: You can use groups to restrict access to certain parts of Jira. For example, you might create a group called "Administrators" and grant them access to sensitive parts of Jira such as user management and system settings.
POST /rest/api/{2-3}/group
Creates a group
DELETE /rest/api/{2-3}/group
Deletes a group
GET /rest/api/{2-3}/group/bulk
This is an experimental endpoint
GET /rest/api/{2-3}/group/member
POST /rest/api/{2-3}/group/user
Adds a user to a group
DELETE /rest/api/{2-3}/group/user
Removes a user from a group
Returns a list of groups, the method returns the following information:
Returns a list of all users in a group
GET /rest/api/{2-3}/field
Returns system and custom issue fields according to the following rules:
Fields that cannot be added to the issue navigator are always returned.
Fields that cannot be placed on an issue screen are always returned.
Fields that depend on global Jira settings are only returned if the setting is enabled. That is, timetracking fields, subtasks, votes, and watches.
POST /rest/api/{2-3}/field
Creates a custom field, the method returns the following information:
GET /rest/api/{2-3}/field/search
Returns a paginated list of fields for Classic Jira projects. The list can include:
all fields.
specific fields, by defining id
.
fields that contain a string in the field name or description, by defining query
.
specific fields that contain a string in the field name or description, by defining id
and query
.
Only custom fields can be queried, type
must be set to custom
. the method returns the following information:
DELETE /rest/api/{2-3}/field/{id}
Deletes a custom field. The custom field is deleted whether it is in the trash or not.
GET /rest/api/{2-3}/attachment/meta
Returns the attachment settings, that is, whether attachments are enabled and the maximum attachment size allowed, the method returns the following information:
GET /rest/api/{2-3}/attachment/{id}
Returns the metadata for an attachment. Note that the attachment itself is not returned, the method returns the following information:
GET /rest/api/{2-3}/attachment/{id}/expand/human
This is an experimental endpoint
Returns the metadata for the contents of an attachment, if it is an archive, and metadata for the attachment itself.
For example, if the attachment is a ZIP archive, then information about the files in the archive is returned and metadata for the ZIP archive. Currently, only the ZIP archive format is supported, the method returns the following information:
DELETE /rest/api/{2-3}/attachment/{id}
Deletes an attachment from an issue, the method returns the following information:
POST /rest/api/{2-3}/issue/{issueIdOrKey}/attachments
Adds one or more attachments to an issue. Attachments are posted as multipart/form-data (RFC 1867).
The request must have a X-Atlassian-Token: no-check
header, if not it is blocked. See Special headers for more information.
The name of the multipart/form-data parameter that contains the attachments must be file
.
It only accepts one attachment at once
GET /rest/api/{2-3}/attachment/content/{id}
This endpoint returns the contents of an attachment. A Range
header can be set to define a range of bytes within the attachment to download.
If successful, Jira will return a response with the attachment file. You can save the file to your local filesystem or process it in your application as needed.
GET /rest/api/{2-3}/fieldconfiguration/{id}/fields
Returns a paginated list of all fields for a configuration.
PUT /rest/api/{2-3}/fieldconfiguration/{id}/fields
Updates fields in a field configuration. The properties of the field configuration fields provided override the existing values.
The operation can set the renderer for text fields to the default text renderer (text-renderer
) or wiki style renderer (wiki-renderer
). However, the renderer cannot be updated for fields using the autocomplete renderer (autocomplete-renderer
).
This resource represents options for sharing filters. Use it to get share scopes as well as add and remove share scopes from filters.
GET /rest/api/3/filter/defaultShareScope
Returns the default sharing settings for new filters and dashboards for a user, the method returns the following information:
PUT /rest/api/3/filter/defaultShareScope
Returns the share permissions for a filter. A filter can be shared with groups, projects, all logged-in users, or the public. Sharing with all logged-in users or the public is known as global share permission, the method returns the following information:
POST /rest/api/3/filter/{id}/permission
Add a share permissions to a filter. If you add global share permission (one for all logged-in users or the public) it will overwrite all share permissions for the filter, the method returns the following information:
GET /rest/api/3/filter/{id}/permission
Returns share permission for a filter. A filter can be shared with groups, projects, all logged-in users, or the public.
Sharing with all logged-in users or the public is known as global share permission, the method returns the following information:
DELETE /rest/api/3/filter/{id}/permission/{permissionId}
Deletes share permission from a filter.
PUT /rest/api/3/filter/defaultShareScope
Sets the default sharing for new filters and dashboards for a user.
In this article, I would be showing you how to add custom-fields on a Jira project screens using go-atlassian.
Before we get started, let's first understand the Jira entities involved in this process: screens, screen tabs, and screen tab fields.
Screens:
Screens in Jira define the layout and configuration of different views, such as issue creation, editing, and viewing.
Each screen consists of one or more screen tabs.
Screen Tabs:
Screen tabs are sections within a screen that group related fields together.
A screen can have multiple screen tabs, and each tab can contain multiple fields.
Screen Tab Fields:
Screen tab fields are the individual fields (e.g., standard or custom fields) displayed within a screen tab.
Create a new directory for your project and navigate to it in your terminal or command prompt. Initialize a new Go module using the following command:
To use the "go-atlassian" library, you need to install it as a dependency in your project. Run the following command:
Create a new Go file, e.g., main.go
, and import the necessary packages:
Initialize the Jira API client with your Jira base URL and API token:
Before to add the customfields on the project screens, we need to search the issue type screen scheme associated with a Jira project, then iterates the mapping to extract the screen schemes linked. In this particular example, we're going to add the following customfields on the KP project:
Start Date customfield_10068
Sprint customfield_10020
DueDate duedate
timeTracking timetracking
Environment customfield_10069
Category customfield_10070
Testing By customfield_10071
Use the following code to extract the issue type screen scheme linked to the KP project.
With the Issue Type Screen Scheme ID extracted from the previous step, we can proceed with the screen scheme extraction, use the following code to extract the screen schemes
The next step is extract the screen ID's from the screen schemes, you can use this code to extract the screen IDs.
The final step is add the custom-fields on the screen default tabs, it's required to validate if the customfield is already added on the screen tab, if not, add the custom-field on the screen and log the result.
We can use the following code below:
This resource represents issue field configurations. Use it to get, set, and delete field configurations and field configuration schemes.
The Jira Issue Field Configurations define the behavior of fields within Jira issues. A field configuration is a set of rules that determines which fields are available for a particular issue type or project, and whether those fields are required, read-only, or hidden. Field configurations can be customized to meet the specific needs of your organization.
GET /rest/api/{2-3}/fieldconfiguration
Returns a paginated list of field configurations. The list can be for all field configurations or a subset determined by any combination of these criteria:
a list of field configuration item IDs.
whether the field configuration is a default.
whether the field configuration name or description contains a query string.
This method uses the following parameters:
POST /rest/api/{2-3}/fieldconfiguration
Creates a field configuration. The field configuration is created with the same field properties as the default configuration, with all the fields being optional.
This method uses the following parameters:
PUT /rest/api/{2-3}/fieldconfiguration/{id}
Updates a field configuration. The name and the description provided in the request override the existing values.
DELETE /rest/api/{2-3}/fieldconfiguration/{id}
Deletes a field configuration.
In this article, I would be showing you how to extract the Jira history information using a JQL query and saves it into a .csv file.
Create a new directory for your project.
Open a terminal and navigate to the project directory.
Initialize a new Go module using the following command:
In the terminal, run the following command to install the "go-atlassian" library:
Create a new Go file (e.g., main.go
) in your project directory.
Open the file and import the required packages:
In the main
function, create a new Jira client and authenticate using your Jira URL, username, and API token:
Add the following code inside the main
function to execute the JQL query and retrieve the issues:
Iterate over the retrieved issues and extract the changelog information.
Create a new CSV file and write the issue history data to it:
Save the main.go
file.
In the terminal, navigate to your project directory
In this article, I would be showing you how to edit a Jira issue with the VERB operation using the "go-atlassian" library.
Create a new directory for your project.
Open a terminal and navigate to the project directory.
Initialize a new Go module using the following command:
In the terminal, run the following command to install the "go-atlassian" library:
Create a new Go file (e.g., main.go
) in your project directory.
Open the file and import the required packages:
You can use the V2 and V3 Jira endpoint versions.
In the main
function, create a new Jira client and authenticate using your Jira URL, username, and API token:
The fields of an issue may also be updated in more flexible ways using the SET, ADD and REMOVE operations. Not all fields support all operations, but as a general rule single value fields support SET, whereas multi-value fields support SET, ADD and REMOVE, where SET replaces the field contents while ADD and REMOVE add or remove one or more values from the the current list of values.
Finally, call the Issue.Update() method and update the issue
Save the main.go
file.
In the terminal, navigate to your project directory.
Execute the following command to run the program:
In this article, I would be showing you how to edit a Jira issue using the "go-atlassian" library.
Create a new directory for your project.
Open a terminal and navigate to the project directory.
Initialize a new Go module using the following command:
In the terminal, run the following command to install the "go-atlassian" library:
Create a new Go file (e.g., main.go
) in your project directory.
Open the file and import the required packages:
You can use the V2 and V3 Jira endpoint versions.
In the main
function, create a new Jira client and authenticate using your Jira URL, username, and API token:
You do not need to send all the fields inside "fields". You can just send the fields you want to update. Absent fields are left unchanged and some fields cannot be updated this way (for example, comments). Instead you must use explicit-verb updates.
For system-fields, you can use the &models.IssueSchemeV2 struct, something like this:
For custom-fields, you can use the &models.CustomFields struct to inyect the customfield's by type, something like this:
Finally, call the Issue.Update() method and update the issue
Save the main.go
file.
In the terminal, navigate to your project directory.
Execute the following command to run the program:
Jira dashboards are customizable, visual displays that provide an overview of project status and performance metrics in real-time. Dashboards are used to track progress and identify trends, enabling teams to make informed decisions and prioritize tasks.
Here are some key elements of Jira dashboards:
Gadgets: Gadgets are the building blocks of Jira dashboards. They are small, customizable widgets that display information in various formats, such as charts, lists, or calendars. Examples of gadgets include the Agile Sprint Burndown gadget, which shows the remaining work in a sprint, or the Pie Chart gadget, which displays the distribution of issues across a project.
Filters: Filters are used to specify which data should be displayed in a gadget. For example, you can create a filter that displays all open bugs assigned to a specific developer. Filters can be saved and reused across multiple gadgets.
Layout: Dashboards can be customized with different layouts to display multiple gadgets on a single page. Users can create multiple dashboards for different purposes, such as a team dashboard or a project-specific dashboard.
Permissions: Jira dashboards can be shared with team members or made public, depending on the level of access required. Permissions can be set at the individual gadget level or for the entire dashboard.
GET /rest/api/{2-3}/dashboard
Returns a list of dashboards owned by or shared with the user. The list may be filtered to include only favorite or owned dashboards.
POST /rest/api/{2-3}/dashboard
This is an experimental endpoint
This method allows you to create a new dashboard in your Jira instance. The request body should contain a JSON object with the following properties:
name: The name of the dashboard.
sharePermissions: An array of objects representing the users and groups who have permission to view the dashboard.
gadget: An array of objects representing the gadgets that should be displayed on the dashboard.
GET /rest/api/{2-3}/dashboard/search
Returns a paginated list of dashboards. This operation is similar to Get dashboards except that the results can be refined to include dashboards that have specific attributes.
For example, dashboards with a particular name. When multiple attributes are specified only filters matching all attributes are returned.
GET /rest/api/{2-3}/dashboard/{id}
Returns a dashboard using the dashboard-id
PUT /rest/api/{2-3}/dashboard/{id}
This is an experimental endpoint
Updates a dashboard, replacing all the dashboard details with those provided. The dashboard to be updated must be owned by the user.
DELETE /rest/api/{2-3}/dashboard/{id}
This is an experimental endpoint
Deletes a dashboard, the dashboard to be deleted must be owned by the user.
POST /rest/api/{2-3}/dashboard/{id}/copy
This is an experimental endpoint
Copies a dashboard. Any values provided in the dashboard
parameter replace those in the copied dashboard.
When you run the code, the custom-fields selected will be available on the project .
However, to get a dashboard, the dashboard must be shared with the user or the user must own it. Note, users with Administer Jira are considered owners of the System dashboard. The System dashboard is considered to be shared with all other users.
startAt
The index of the first item to return in a page of results (page offset).
maxResults
The maximum number of items to return per page.
id's
The list of field configuration IDs.
isDefault
If true returns default field configurations only.
query
The query string used to match against field configuration names and descriptions.
description
The description of the field configuration.
name
The name of the field configuration. Must be unique.
GET /rest/api/{2-3}/field/search/trashed
Search returns a paginated list of fields in the trash. The list may be restricted to fields whose field name or description partially match a string.
Only custom fields can be queried, type
must be set to custom
.
POST /rest/api/{2-3}/field/{id}/trash
Move moves a custom field to trash
POST /rest/api/{2-3}/field/{id}/restore
POST /rest/api/3/field/{id}/restoreRestore restores a custom field from trash
This resource represents remote issue links, a way of linking Jira to information in other systems. Use it to get, create, update, and delete remote issue links either by ID or global ID. The global ID provides a way of accessing remote issue links using information about the item's remote system host and remote system identifier.
GET /rest/api/{2-3}/issue/{issueIdOrKey}/remotelink
Gets returns the remote issue links for an issue. When a remote issue link global ID is provided the record with that global ID is returned, otherwise all remote issue links are returned.
POST /rest/api/{2-3}/issue/{issueIdOrKey}/remotelink
Create creates or updates a remote issue link for an issue.
If a globalId
is provided and a remote issue link with that global ID is found it is updated. Any fields without values in the request are set to null. Otherwise, the remote issue link is created.
DELETE /rest/api/{2-3}/issue/{issueIdOrKey}/remotelink/{linkId}
Delete deletes a remote issue link from an issue.
GET /rest/api/{2-3}/issue/{issueIdOrKey}/remotelink/{linkId}
Get returns a remote issue link for an issue.
PUT /rest/api/{2-3}/issue/{issueIdOrKey}/remotelink/{linkId}
Update updates a remote issue link for an issue.
DELETE /rest/api/{2-3}/issue/{issueIdOrKey}/remotelink
DeleteByGlobalId deletes the remote issue link from the issue using the link's global ID where the global ID includes reserved URL characters these must be escaped in the request.
This resource represents available labels. Use it to get available labels for the global label field.
This resource represents issue link types. Use it to get, create, update, and delete link issue types as well as get lists of all link issue types.
GET /rest/api/{2-3}/issueLinkType
Returns a list of all issue link types, the method returns the following information:
POST /rest/api/{2-3}/issueLinkType
Creates an issue link type. Use this operation to create descriptions of the reasons why issues are linked.
The issue link type consists of a name and descriptions for a link's inward and outward relationships, the method returns the following information:
GET /rest/api/{2-3}/issueLinkType/{issueLinkTypeId}
Returns an issue link type, the method returns the following information:
PUT /rest/api/{2-3}/issueLinkType/{issueLinkTypeId}
Updates an issue link type, the method returns the following information:
DELETE /rest/api/{2-3}/issueLinkType/{issueLinkTypeId}
Deletes an issue link type, the method returns the following information:
This resource represents custom issue field select list options created in Jira or using the REST API. This resource supports the following field types:
Checkboxes.
Radio Buttons.
Select List (single choice).
Select List (multiple choices).
Select List (cascading).
GET /rest/api/{2-3}/field/{fieldId}/context/{contextId}/option
Returns a paginated list of all custom field option for a context. Options are returned first then cascading options, in the order they display in Jira, the method returns the following information:
POST /rest/api/{2-3}/field/{fieldId}/context/{contextId}/option
Creates options and, where the custom select field is of the type Select List (cascading), cascading options for a custom select field. The options are added to a context of the field.
The maximum number of options that can be created per request is 1000 and each field can have a maximum of 10000 options, the method returns the following information:
PUT /rest/api/{2-3}/field/{fieldId}/context/{contextId}/option
Updates the options of a custom field. If any of the options are not found, no options are updated. Options where the values in the request match the current values aren't updated and aren't reported in the response.
Note that this operation only works for issue field select list options created in Jira or using operations from the Issue custom field options resource, it cannot be used with issue field select list options created by Connect apps.
DELETE /rest/api/{2-3}/field/{fieldId}/context/{contextId}/option/{optionId}
Deletes a custom field option. Options with cascading options cannot be deleted without deleting the cascading options first.
This operation works for custom field options created in Jira or the operations from this resource. To work with issue field select list options created for Connect apps use the Issue custom field options (apps) operations.
PUT /rest/api/{2-3}/field/{fieldId}/context/{contextId}/option/move
Changes the order of custom field options or cascading options in a context.
GET /rest/api/{2-3}/issue/createmeta/{projectIdOrKey}/issuetypes
FetchIssueMappings 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.
GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes/{issueTypeId}
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.
GET /rest/api/{2-3}/issue/{issueIdOrKey}/editmeta
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.
GET /rest/api/{2-3}/issue/createmeta
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.
In this article, I would be showing you how to upload an attachment in a Confluence content using the "go-atlassian" library.
Create a new directory for your project.
Open a terminal and navigate to the project directory.
Initialize a new Go module using the following command:
In the terminal, run the following command to install the "go-atlassian" library:
Create a new Go file (e.g., main.go
) in your project directory.
Open the file and import the required packages:
In the main
function, create a new Confluence client and authenticate using your Atlassian URL, username, and API token:
Define the necessary variables for the page ID, file path, and file name:
Open the file using the provided file path:
Upload the attachment using the Content.Attachment.Create()
method and provide the page ID, file name, and file content:
Save the main.go
file.
In the terminal, navigate to your project directory.
Execute the following command to run the program:
This will upload the specified file as an attachment to the Confluence page with the provided page ID.
This resource represents Jira issues
Need help working with issues? In Jira Software, issues help you manage code, estimate workload, and keep track of your team. On this page, you'll find a quick overview of everything that you can do with an issue.
This resource represents Jira issues. Use it to:
create or edit issues, individually or in bulk.
retrieve metadata about the options for creating or editing issues.
delete an issue.
assign a user to an issue.
get issue changelogs.
send notifications about an issue.
get details of the transitions available for an issue.
transition an issue.
In the Jira REST API, custom fields are uniquely identified by the field ID, as the display names are not unique within a Jira instance. For example, you could have two fields named "Escalation date", one with an ID of "12221" and one with an ID of "12222". A custom field is actually referenced by customfield\_
+ the field ID, rather than just the field ID.
We support the following custom field types.
Group(s) Picker
User(s) Picker
URL's
Text
Number
Date
DateTime
Select
MultiSelect
RadioButton
CheckBox
Cascading Multiselect
The examples below show how to set the values for different types of custom fields in the input data.
POST /rest/api/{2-3}/issue
Creates an issue or, where the option to create subtasks is enabled in Jira, a subtask
POST /rest/api/{2-3}/issue/bulk
Creates issues and, where the option to create subtasks is enabled in Jira, subtasks.
GET /rest/api/{2-3}/issue/{issueIdOrKey}
Returns the details for an issue.
PUT /rest/api/{2-3}/issue/{issueIdOrKey}
Edits an issue. The edits to the issue's fields are defined using update
and fields
. There're two ways to edit an issue on Jira, implicit and explicit.
The simple way to update an issue is to do a GET, update the values inside "fields", and then PUT back.
If you PUT back exactly what you GOT, then you are also sending "names", "self", "key", etc. These are ignored.
You do not need to send all the fields inside "fields". You can just send the fields you want to update. Absent fields are left unchanged. For example, to update the summary:
Some fields cannot be updated this way (for example, comments). Instead you must use explicit-verb updates (see below). You can tell if a field cannot be implicitly set by the fact it doesn't have a SET verb.
If you do send along such un-SET-able fields in this manner, they are ignored. This means that you can PUT what you GET, but not all of the document is taken into consideration.
Each field supports a set of operations (verbs) for mutating the field. You can retrieve the editable fields and the operations they support using the "editmeta" resource.
The editmeta endpoint is not mapped, yet refer to this ticket
The basic operations are defined below (but custom fields can define their own).
The general shape of an update is field, array of verb-value pairs, for example:
SET: Sets the value of the field. The incoming value must be the same shape as the value of the field from a GET. For example, a string for "summary", and array of strings for "labels".
ADD: Adds an element to a field that is an array. The incoming value must be the same shape as the items of the array in a GET. For example, to add a label:
REMOVE: Removes an element from a field that is an array. The incoming value must be the same shape as the items of the array in a GET (although you can remove parts of the object that are not needed to uniquely identify the object).
EDIT: Edits an element in a field that is an array. The element is indexed/identified by the value itself (usually by id/name/key).
DELETE /rest/api/{2-3}/issue/{issueIdOrKey}
Deletes an issue.
PUT /rest/api/{2-3}/issue/{issueIdOrKey}/assignee
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.
POST /rest/api/{2-3}/issue/{issueIdOrKey}/notify
Creates an email notification for an issue and adds it to the mail queue.
GET /rest/api/{2-3}/issue/{issueIdOrKey}/transitions
Returns either all transitions or a transition that can be performed by the user on an issue, based on the issue's status.
POST /rest/api/{2-3}/issue/{issueIdOrKey}/transitions
Performs an issue transition.
Performs an issue transition and, if a transition screen is associated, updates the relevant fields from that screen.
To update fields on the transition screen, include the desired field values in the fields or update parameters within the request body. You can retrieve details about these fields by using the Get transitions endpoint with the transitions.fields expand option.
This operation supports anonymous access.
The Jira Field Context Configurations define the scope of custom fields within Jira. They determine where and how a custom field can be used within Jira, such as in which projects, issue types, and screens the field should be available. Field Context Configurations are used to ensure that the right data is captured and displayed in Jira, and that users are not presented with irrelevant fields.
GET /rest/api/{2-3}/field/{fieldId}/context
Returns a paginated list of contexts
for a custom field. Contexts can be returned as follows:
With no other parameters set, all contexts.
By defining id
only, all contexts from the list of IDs.
By defining isAnyIssueType
, limit the list of contexts returned to either those that apply to all issue types (true) or those that apply to only a subset of issue types (false)
By defining isGlobalContext
, limit the list of contexts return to either those that apply to all projects (global contexts) (true) or those that apply to only a subset of projects (false)
POST /rest/api/{2-3}/field/{fieldId}/context
Creates a custom field context. If projectIds
is empty, a global context is created. A global context is one that applies to all project. If issueTypeIds
is empty, the context applies to all issue types, the method returns the following information:
GET /rest/api/{2-3}/field/{fieldId}/context/defaultValue
Returns a paginated list of defaults for a custom field. The results can be filtered by contextId
, otherwise all values are returned. If no defaults are set for a context, nothing is returned.
PUT /rest/api/{2-3}/field/{fieldId}/context/defaultValue
Sets default for contexts of a custom field. Default is defined using these objects:
CustomFieldContextDefaultValueSingleOption
option.single
For single choice select lists and radio buttons.
CustomFieldContextDefaultValueMultipleOption
option.multiple
For multiple-choice select lists and checkboxes.
CustomFieldContextDefaultValueCascadingOption
option.cascading
For cascading select lists.
PUT /rest/api/{2-3}/field/{fieldId}/context/{contextId}
Updates a custom field context.
DELETE /rest/api/{2-3}/field/{fieldId}/context/{contextId}
Deletes a custom field context.
PUT /rest/api/{2-3}/field/{fieldId}/context/{contextId}/issuetype
Adds issue types to a custom field context, appending the issue types to the issue types list.
POST /rest/api/{2-3}/field/{fieldId}/context/{contextId}/issuetype/remove
Removes issue types from a custom field context.
PUT /rest/api/{2-3}/field/{fieldId}/context/{contextId}/project
Assigns a custom field context to projects.
POST /rest/api/{2-3}/field/{fieldId}/context/{contextId}/project/remove
Removes a custom field context from projects.
GET /rest/api/{2-3}/field/{fieldId}/context/projectmapping
Returns a paginated list of context to project mappings for a custom field. The result can be filtered by contextId
. Otherwise, all mappings are returned. Invalid IDs are ignored.
An issue's priority defines its importance in relation to other issues, so it helps your users determine which issues should be tackled first. Jira comes with a set of default priorities, which you can modify or add to. You can also choose different priorities for your projects.
GET /rest/api/{2-3}/priority
Returns the list of all issue priorities, the method returns the following information:
GET /rest/api/{2-3}/priority/{id}
Returns an issue priority, the method returns the following information:
POST /rest/api/3/priority
Creates an issue priority.
No implemented, yet. Feel free to open a new PR or issue
PUT /rest/api/3/priority/default
Sets default issue priority.
No implemented, yet. Feel free to open a new PR or issue
PUT /rest/api/3/priority/move
Changes the order of issue priorities.
No implemented, yet. Feel free to open a new PR or issue
GET /rest/api/3/priority/search
Returns a paginated list of priorities. The list can contain all priorities or a subset determined by any combination of these criteria:
a list of priority IDs. Any invalid priority IDs are ignored.
whether the field configuration is a default. This returns priorities from company-managed (classic) projects only, as there is no concept of default priorities in team-managed projects.
No implemented, yet. Feel free to open a new PR or issue
PUT /rest/api/3/priority/{id}
Updates an issue priority.
No implemented, yet. Feel free to open a new PR or issue
DELETE /rest/api/3/priority/{id}
Deletes an issue priority.
No implemented, yet. Feel free to open a new PR or issue
You can link issues to keep track of duplicate or related work. You can, for example:
create a new linked issue from an existing issue in a service project or business project
create an association between an issue and a Confluence page
link an issue to any other web page
Make sure you have the link issues project permission before getting started. Note that your Jira administrator can customize the types of links that you can create.
POST /rest/api/{2-3}/issueLink
Creates a link between two issues. Use this operation to indicate a relationship between two issues and optionally add a comment to the from (outward) issue, the method returns the following information:
If the link request duplicates a link, the response indicates that the issue link was created. If the request included a comment, the comment is added.
GET /rest/api/{2-3}/issue?fields=issuelinks
Return the issue links associated with a Jira Issue, the method returns the following information:
GET /rest/api/{2-3}/issueLink/{linkId}
Returns an issue link, the method returns the following information:
DELETE /rest/api/{2-3}/issueLink/{linkId}
Deletes an issue link, the method returns the following information:
The Issue field configuration schemes let you apply a field configuration to all issues of a certain type. When you want to change the fields that appear on all Bug issue types in a certain project, you can do so by simply configuring the associated field configuration scheme. You can also save time by reusing the same field configuration for issue types across multiple projects.
GET /rest/api/{2-3}/fieldconfigurationscheme
POST /rest/api/{2-3}/fieldconfigurationscheme
Creates a field configuration scheme.
GET /rest/api/{2-3}/fieldconfigurationscheme/mapping
GET /rest/api/{2-3}/fieldconfigurationscheme/project
The list is sorted by field configuration scheme ID. The first item contains the list of project IDs assigned to the default field configuration scheme.
PUT /rest/api/{2-3}/fieldconfigurationscheme/project
Assigns a field configuration scheme to a project. If the field configuration scheme ID is null
, the operation assigns the default field configuration scheme.
PUT /rest/api/{2-3}/fieldconfigurationscheme/{id}
Updates a field configuration scheme.
DELETE /rest/api/{2-3}/fieldconfigurationscheme/{id}
Deletes a field configuration scheme.
PUT /rest/api/{2-3}/fieldconfigurationscheme/{id}/mapping
Assigns issue types to field configurations on field configuration scheme.
POST /rest/api/{2-3}/fieldconfigurationscheme/{id}/mapping/delete
Removes issue types from the field configuration scheme.
This resource represents votes cast by users on an issue. Use it to get details of votes on an issue as well as cast and withdrawal votes.
GET /rest/api/{2-3}/issue/{issueIdOrKey}/votes
Returns details about the votes on an issue.
POST /rest/api/{2-3}/issue/{issueIdOrKey}/votes
Adds the user's vote to an issue. This is the equivalent of the user clicking Vote on an issue in Jira.
DELETE /rest/api/{2-3}/issue/{issueIdOrKey}/votes
Deletes a user's vote from an issue. This is the equivalent of the user clicking Unvote on an issue in Jira.
This resource represents various ways to search for issues. Use it to search for issues with a JQL query and find issues to populate an issue picker.
This resource represents issue type screen schemes.
GET /rest/api/{2-3}/issuetypescreenscheme
POST /rest/api/{2-3}/issuetypescreenscheme
Creates an issue-type screen scheme.
GET /rest/api/{2-3}/issuetypescreenscheme/mapping
PUT /rest/api/{2-3}/issuetypescreenscheme/project
Assigns an issue-type screen scheme to a project.
GET /rest/api/{2-3}/issuetypescreenscheme/project
CREATE THE CODE SAMPLE
PUT /rest/api/{2-3}/issuetypescreenscheme/{issueTypeScreenSchemeId}
Updates an issue type screen scheme.
DELETE /rest/api/{2-3}/issuetypescreenscheme/{issueTypeScreenSchemeId}
Deletes an issue type screen scheme.
PUT /rest/api/{2-3}/issuetypescreenscheme/{issueTypeScreenSchemeId}/mapping
Appends issue type to screen scheme mappings to an issue type screen scheme.
PUT /rest/api/{2-3}/issuetypescreenscheme/{issueTypeScreenSc}/mapping/default
Updates the default screen scheme of an issue-type screen scheme. The default screen scheme is used for all unmapped issue types.
POST /rest/api/{2-3}/issuetypescreenscheme/{issueTypeScreenSc}/mapping/remove
Removes issue type to screen scheme mappings from an issue type screen scheme.
GET /rest/api/{2-3}/issuetypescreenscheme/{issueTypeScreenSchemeId}/project
CREATE THE CODE SAMPLE
This resource represents issue type schemes in classic projects
GET /rest/api/{2-3}/issuetypescheme
POST /rest/api/{2-3}/issuetypescheme
Creates an issue type scheme.
GET /rest/api/{2-3}/issuetypescheme/mapping
GET /rest/api/{2-3}/issuetypescheme/project
PUT /rest/api/{2-3}/issuetypescheme/project
Assigns an issue type scheme to a project. If any issues in the project are assigned issue types not present in the new scheme, the operation will fail.
To complete the assignment those issues must be updated to use issue types in the new scheme.
PUT /rest/api/{2-3}/issuetypescheme/{issueTypeSchemeId}
Updates an issue type scheme.
DELETE /rest/api/{2-3}/issuetypescheme/{issueTypeSchemeId}
Deletes an issue type scheme. Only issue type schemes used in classic projects can be deleted. Any projects assigned to the scheme are reassigned to the default issue type scheme.
PUT /rest/api/{2-3}/issuetypescheme/{issueTypeSchemeId}/issuetype
Adds issue types to an issue type scheme. The added issue types are appended to the issue types list. If any of the issue types exist in the issue type scheme, the operation fails and no issue types are added.
DELETE /rest/api/{2-3}/issuetypescheme/{issueTypeSche}/issuetype/{issueType}
Removes an issue type from an issue type scheme.
Not implemented, yet. Feel free to open a PR or issue
This resource represents users watching an issue. Use it to get details of users watching an issue as well as start and stop a user watching an issue.
GET /rest/api/{2-3}/issue/{issueIdOrKey}/watchers
Returns the watchers for an issue.
POST /rest/api/{2-3}/issue/{issueIdOrKey}/watchers
Adds a user as a watcher of an issue by passing the account ID of the user. For example, "5b10ac8d82e05b22cc7d4ef5"
. If no user is specified the calling user is added.
DELETE /rest/api/{2-3}/issue/{issueIdOrKey}/watchers
Deletes a user as a watcher of an issue.
POST /rest/api/{2-3}/issue/watching
Not implemented, yet. Feel free to open a PR or issue
In Jira, a filter is a saved search query that you can use to retrieve a specific set of issues from your Jira instance. A filter can be based on various criteria such as issue type, priority, status, assignee, labels, and more.
Filters can be saved and shared with other users, allowing you to easily collaborate and work together on a specific set of issues. You can also use filters to create custom dashboards and reports to monitor the progress of your team's work.
POST /rest/api/{2-3}/filter
GET /rest/api/3/filter/favourite
This method returns the visible favorite filters of the user, the method returns the following information:
GET /rest/api/{2-3}/filter/my
Returns the filters owned by the user. If includeFavourites
is true
, the user's visible favorite filters are also returned, the method returns the following information:
GET /rest/api/{2-3}/filter/search
specific filters, by defining id
only.
filters that match all of the specified attributes. For example, all filters for a user with a particular word in their name. When multiple attributes are specified only filters matching all attributes are returned.
🔒 Permissions required: None, however, only the following filters that match the query parameters are returned:
filters owned by the user.
filters shared with a group that the user is a member of.
for.
filters shared with a public project.
filters shared with the public.
GET /rest/api/{2-3}/filter/{id}
This method returns a filter using the ID as a parameter, the method returns the following information:
PUT /rest/api/{2-3}/filter/{id}
This method updates a filter. Use this operation to update a filter's name, description, JQL, or sharing, the method returns the following information:
DELETE /rest/api/{2-3}/filter/{id}
PUT /rest/api/{2-3}/filter/{id}/owner
This is an experimental endpoint
Changes the owner of the filter.
A comment is a piece of text that can be added to an issue to provide additional information or to update the issue's status. Comments can be added by users who have permission to view and edit the issue, and can be used for a variety of purposes, such as:
Providing context or additional details about an issue.
Sharing progress or updates on the issue's status.
Asking questions or requesting feedback from other team members.
Acknowledging or responding to other comments or feedback.
Notifying other users of relevant information or changes.
Mention your teammates: If you need someone to know about a comment, you can mention them in it. Type @ followed by their name, then choose the right person from the list. The person you mention will be notified about your comment and can quickly jump to the issue to see what's happening.
Apply comment permissions: If your comment is only meant for a specific Jira group or project role, comment permissions let you restrict your comments to the appropriate audience. When writing your comment, click the lock icon under it and choose a Jira group or project role to restrict it to.
GET /rest/api/{2-3}/issue/{issueIdOrKey}/comment
Returns all comments for an issue.
GET /rest/api/{2-3}/issue/{issueIdOrKey}/comment/{id}
Returns a comment.
DELETE /rest/api/{2-3}/issue/{issueIdOrKey}/comment/{id}
Deletes a comment.
POST /rest/api/{2-3}/issue/{issueIdOrKey}/comment
Adds a comment to an issue.
The Atlassian Document Format (ADF) represents rich text stored in Atlassian products. For example, in Jira Cloud platform, the text in issue comments and in textarea
custom fields is stored as ADF, here's a bundle of examples you can use in order to create custom body messages.
Returns a list of field configuration schemes.
Returns a list of field configuration issue type items.
Returns a list of field configuration schemes and, for each scheme, a list of the projects that use it.
Searches for issues using . If the JQL query expression is too large to be encoded as a query parameter, use the version of this resource.
Searches for issues using . There is a version of this resource that can be used for smaller JQL query expressions.
Returns a list of issue type screen schemes. Only issue type screen schemes used in classic projects are returned.
Returns a list of issue-type screen scheme items. Only issue type screen schemes used in classic projects are returned.
Returns a list of issue type screen schemes and, for each issue type screen scheme, a list of the projects that use it. Only issue type screen schemes used in classic projects are returned.
Returns a list of projects associated with an issue-type screen scheme. Only company-managed projects associated with an issue-type screen scheme are returned.
Returns a list of issue type schemes.
Returns a list of issue-type scheme items. Only issue type scheme items used in classic projects are returned.
Returns a list of issue type schemes and, for each issue type scheme, a list of the projects that use it. Only issue type schemes used in classic projects are returned.
This method creates a new filter. The filter is shared according to the . The filter is not selected as a favorite, the method returns the following information:
Returns a list of filters. Use this operation to get:
filters shared with a private project that the user has Browse projects
GET /rest/api/{2-3}/issue/{issueIdOrKey}/properties
Gets returns the URLs and keys of an issue's properties.
GET /rest/api/{2-3}/issue/{issueIdOrKey}/properties/{propertyKey}
Get returns the key and value of an issue's property.
PUT /rest/api/{2-3}/issue/{issueIdOrKey}/properties/{propertyKey}
Set sets the value of an issue's property. Use this resource to store custom data against an issue.
DELETE /rest/api/{2-3}/issue/{issueIdOrKey}/properties/{propertyKey}
Deletes deletes an issue's property.
PUT /rest/api/{2-3}/issue/archive
Preserve archives the given issues based on their issue IDs or keys.
POST /rest/api/{2-3}/issue/archive
PreserveByJQL archives issues than match the provided JQL query.
PUT /rest/api/{2-3}/issue/unarchive
Restore brings back the given archived issues using their issue IDs or keys.
PUT /rest/api/{2-3}/issues/archive/export
Export generates an export of archived issues based on the provided payload.
This resource represents permissions. Use it to obtain details of all permissions and determine whether the user has certain permissions.
GET /rest/api/{2-3}/mypermissions
Returns a list of permissions indicating which permissions the user has. Details of the user's permissions can be obtained in a global, project, or issue context.
POST /rest/api/{2-3}/permissions/check
for a list of global permissions, the global permissions are granted to a user.
for a list of project permissions and lists of projects and issues, for each project permission a list of the projects and issues a user can access or manipulate.
If no account ID is provided, the operation returns details for the logged-in user.
POST /rest/api/{2-3}/permissions/project
Returns all the projects where the user is granted a list of project permissions.
This operation can be accessed anonymously.
CREATE THE CODE SAMPLE
GET /rest/api/{2-3}/issue/{issueIdOrKey}/worklog
Returns worklogs for an issue, starting from the oldest worklog or from the worklog started on or after a date and time.
POST /rest/api/{2-3}/issue/{issueIdOrKey}/worklog
Adds a worklog to an issue.
GET /rest/api/{2-3}/issue/{issueIdOrKey}/worklog/{id}
Returns a worklog.
PUT /rest/api/{2-3}/issue/{issueIdOrKey}/worklog/{id}
Updates a worklog.
DELETE /rest/api/{2-3}/issue/{issueIdOrKey}/worklog/{id}
Deletes a worklog from an issue.
GET /rest/api/{2-3}/worklog/deleted
Returns a list of IDs and delete timestamps for worklogs deleted after a date and time.
POST /rest/api/{2-3}/worklog/list
Returns worklog details for a list of worklog IDs.
GET /rest/api/{2-3}/worklog/updated
Returns a list of IDs and update timestamps for worklogs updated after a date and time.
This resource is paginated, with a limit of 1000 worklogs per page. Each page lists worklogs from oldest to youngest. If the number of items in the date range exceeds 1000, until
indicates the timestamp of the youngest item on the page. Also, nextPage
provides the URL for the next page of worklogs. The lastPage
parameter is set to true on the last page of worklogs.c
This resource represents issue resolution values. Use it to obtain a list of all issue resolution values and the details of individual resolution values.
GET /rest/api/{2-3}/resolution
Returns a list of all issue resolution values, the method returns the following information:
GET /rest/api/{2-3}/resolution/{id}
Returns an issue resolution value
No implemented, yet, feel free to open a PR or issue
No implemented, yet, feel free to open a PR or issue
No implemented, yet, feel free to open a PR or issue
No implemented, yet, feel free to open a PR or issue
No implemented, yet, feel free to open a PR or issue
No implemented, yet, feel free to open a PR or issue
A permission scheme is a collection of permission grants. A permission grant consists of a holder
and a permission
.
The holder
object contains information about the user or group being granted the permission. For example, the Administer projects permission is granted to a group named Teams in space administrators. In this case, the type is "type": "group"
, and the parameter is the group name, "parameter": "Teams in space administrators"
. The holder
object is defined by the following properties:
type
Identifies the user or group (see the list of types below).
parameter
The value of this property depends on the type
. For example, if the type
is a group, then you need to specify the group name.
The following types
are available. The expected values for the parameter
are given in parenthesis (some types
may not have a parameter
):
GET /rest/api/{2-3}/permissionscheme
Returns all permission schemes.
GET /rest/api/{2-3}/permissionscheme/{schemeId}
Returns a permission scheme.
POST /rest/api/{2-3}/permissionscheme
Creates a new permission scheme. You can create a permission scheme with or without defining a set of permission grants.
DELETE /rest/api/{2-3}/permissionscheme/{schemeId}
Deletes a permission scheme.
PUT /rest/api/{2-3}/permissionscheme/{schemeId}
Updates a permission scheme
This resource represents issues types
Just as a project can have many different types of work, Jira uses different issue types to help identify, categorize, and report on your team’s work. We’ll cover Jira’s standard-issue types below.
GET /rest/api/{2-3}/issuetype
Returns all issue types.
POST /rest/api/{2-3}/issuetype
Creates an issue type and adds it to the default issue type scheme.
GET /rest/api/{2-3}/issuetype/{id}
Returns an issue type.
PUT /rest/api/{2-3}/issuetype/{id}
Updates the issue type.
DELETE /rest/api/{2-3}/issuetype/{id}
Deletes the issue type. If the issue type is in use, all uses are updated with the alternative issue type (alternativeIssueTypeId
).
GET /rest/api/{2-3}/issuetype/{id}/alternatives
Returns a list of issue types that can be used to replace the issue type.
The alternative issue types are those assigned to the same workflow scheme, field configuration scheme, and screen scheme.
This resource represents project components. Uses to get, create, update, and delete project components. Also get components for project and get a count of issues by component.
POST /rest/api/{2-3}/component
Creates a component. Use components to provide containers for issues within a project.
GET /rest/api/{2-3}/component/{id}
Returns a component.
PUT /rest/api/{2-3}/component/{id}
Updates a component. Any fields included in the request are overwritten. If leadAccountId
is an empty string ("") the component lead is removed.
DELETE /rest/api/{2-3}/component/{id}
Deletes a component.
GET /rest/api/{2-3}/component/{id}/relatedIssueCounts
Returns the counts of issues assigned to the component.
GET /rest/api/{2-3}/project/{projectIdOrKey}/components
Returns all components in a project.
This resource represents permission schemes for a project.
GET /rest/api/{2-3}/project/{projectKeyOrId}/permissionscheme
PUT /rest/api/{2-3}/project/{projectKeyOrId}/permissionscheme
Assigns a permission scheme with a project
GET /rest/api/{2-3}/project/{projectKeyOrId}/securitylevel
GET /rest/api/{2-3}/projectCategory
Returns all project categories.
POST /rest/api/{2-3}/projectCategory
Creates a project category.
GET /rest/api/{2-3}/projectCategory/{id}
Returns a project category.
PUT /rest/api/{2-3}/projectCategory/{id}
Updates a project category.
DELETE /rest/api/{2-3}/projectCategory/{id}
Deletes a project category.
GET /rest/api/{2-3}/notificationscheme
POST /rest/api/{2-3}/notificationscheme
Create creates a notification scheme with notifications. You can create up to 1000 notifications per request.
GET /rest/api/{2-3}/notificationscheme/project
Projects returns a paginated mapping of project that have notification scheme assigned. You can provide either one or multiple notification scheme IDs or project IDs to filter by.
If you don't provide any, this will return a list of all mappings. Note that only company-managed (classic) projects are supported. This is because team-managed
projects don't have a concept of a default notification scheme. The mappings are ordered by projectId.
GET /rest/api/{2-3}/notificationscheme/{id}
Get returns a notification scheme, including the list of events and the recipients who will receive notifications for those events.
PUT /rest/api/{2-3}/notificationscheme/{id}
Update updates a notification scheme.
DELETE /rest/api/{2-3}/notificationscheme/{notificationSchemeId}
Delete deletes a notification scheme.
PUT /rest/api/{2-3}/notificationscheme/{id}/notification
Append adds notifications to a notification scheme. You can add up to 1000 notifications per request.
DELETE /rest/api/{2-3}/notificationscheme/{notificationSchemeId}/notification/{notificationId}
Remove removes a notification from a notification scheme.
POST /rest/api/{2-3}/project
Creates a project based on a project type template
GET /rest/api/{2-3}/project/search
GET /rest/api/{2-3}/project/{projectIdOrKey}
PUT /rest/api/{2-3}/project/{projectIdOrKey}
DELETE /rest/api/{2-3}/project/{projectIdOrKey}
Deletes a project.
POST /rest/api/{2-3}/project/{projectIdOrKey}/archive
Archives a project. Archived projects cannot be deleted. To delete an archived project, restore the project and then delete it. To restore a project, use the Jira UI.
POST /rest/api/{2-3}/project/{projectIdOrKey}/delete
Deletes a project asynchronously.
POST /rest/api/{2-3}/project/{projectIdOrKey}/restore
Restores a project from the Jira recycle bin.
GET /rest/api/{2-3}/project/{projectIdOrKey}/statuses
Returns the valid statuses for a project. The statuses are grouped by issue type, as each project has a set of valid issue types and each issue type has a set of valid statuses.
GET /rest/api/{2-3}/project/{projectKeyOrId}/notificationscheme
GET /rest/api/{2-3}/permissionscheme/{schemeId}/permission
Returns all permission grants for a permission scheme.
POST /rest/api/{2-3}/permissionscheme/{schemeId}/permission
Creates a permission grant in a permission scheme.
GET /rest/api/{2-3}/permissionscheme/{schemeId}/permission/{permissionId}
Returns a permission grant.
DELETE /rest/api/{2-3}/permissionscheme/{schemeId}/permission/{permissionId}
Deletes a permission grant from a permission scheme
Gets the associated with the project.
Returns all levels for the project that the user has access to.
Search returns a list of ordered by the display name.
Returns a list of projects visible to the user.
Returns the
Updates the of a project.
Gets a associated with the project.
name
description
anyone
Grant for anonymous users.
applicationRole
Grant for users with access to the specified application (application name). See Update product access settings for more information.
assignee
Grant for the user currently assigned to an issue.
group
Grant for the specified group (group name).
groupCustomField
Grant for a user in the group selected in the specified custom field (custom field ID).
projectLead
Grant for a project lead.
projectRole
Grant for the specified project role (project role ID).
reporter
Grant for the user who reported the issue.
sd.customer.portal.only
Jira Service Desk only. Grants customers permission to access the customer portal but not Jira
user
Grant for the specified user (user ID - historically this was the userkey but that is deprecated and the account ID should be used).
userCustomField
Grant for a user selected in the specified custom field (custom field ID).
This resource represents the users assigned to project roles. Use this resource to get, add, and remove default users from project roles. Also use this resource to add and remove users from a project
GET /rest/api/{2-3}/project/{projectIdOrKey}/properties
Returns all keys for the project.
GET /rest/api/{2-3}/project/{projectIdOrKey}/properties/{propertyKey}
Returns the value of a project property.
PUT /rest/api/{2-3}/project/{projectIdOrKey}/properties/{propertyKey}
Sets the value of the project property. You can use project properties to store custom data against the project.
DELETE /rest/api/{2-3}/project/{projectIdOrKey}/properties/{propertyKey}
Deletes the property from a project.
GET /rest/api/{2-3}/project/{projectIdOrKey}/versions
Returns all versions in a project. The response is not paginated.
POST /rest/api/{2-3}/version
Creates a project version.
GET /rest/api/{2-3}/version/{id}
Returns a project version.
PUT /rest/api/{2-3}/version/{id}
Updates a project version.
PUT /rest/api/{2-3}/version/{id}/mergeto/{moveIssuesTo}
Merges two project versions. The merge is completed by deleting the version specified in id
and replacing any occurrences of its ID in fixVersion
with the version ID specified in moveIssuesTo
.
GET /rest/api/{2-3}/version/{id}/relatedIssueCounts
Returns the following counts for a version:
Number of issues where the fixVersion
is set to the version.
Number of issues where the affectedVersion
is set to the version.
Number of issues where a version custom field is set to the version.
GET /rest/api/{2-3}/version/{id}/unresolvedIssueCount
Returns counts of the issues and unresolved issues for the project version.
GET /rest/api/{2-3}/project/type
Returns all project types
GET /rest/api/{2-3}/project/type/accessible
Returns all project types
GET /rest/api/{2-3}/project/type/{projectTypeKey}
Returns a project type
GET /rest/api/{2-3}/project/type/{projectTypeKey}/accessible
Returns a project type
GET /rest/api/{2-3}/projectvalidate/key
Validates a project key by confirming the key is a valid string and not in use.
GET /rest/api/{2-3}/projectvalidate/validProjectKey
Validates a project key and, if the key is invalid or in use, generates a valid random string for the project key.
GET /rest/api/{2-3}/projectvalidate/validProjectName
Checks that a project name isn't in use. If the name isn't in use, the passed string is returned. If the name is in use, this operation attempts to generate a valid project name based on the one supplied, usually by adding a sequence number. If a valid project name cannot be generated, a 404 response is returned.
GET /rest/api/{2-3}/screens/{screenId}/tabs/{tabId}/fields
Returns all fields for a screen tab.
POST /rest/api/{2-3}/screens/{screenId}/tabs/{tabId}/fields
Adds a field to a screen tab.
DELETE /rest/api/{2-3}/screens/{screenId}/tabs/{tabId}/fields/{id}
Removes a field from a screen tab.
GET /rest/api/{2-3}/screens/{screenId}/tabs
Returns the list of tabs for a screen.
POST /rest/api/{2-3}/screens/{screenId}/tabs
Creates a tab for a screen.
PUT /rest/api/{2-3}/screens/{screenId}/tabs/{tabId}
Updates the name of a screen tab.
DELETE /rest/api/{2-3}/screens/{screenId}/tabs/{tabId}
Deletes a screen tab.
POST /rest/api/{2-3}/screens/{screenId}/tabs/{tabId}/move/{pos}
Moves a screen tab.
GET /rest/api/{2-3}/project/{projectIdOrKey}/role
Returns a list of project roles for the project returning the name and self URL for each role.
GET /rest/api/{2-3}/project/{projectIdOrKey}/role/{id}
Returns a project role's details and actors associated with the project. The list of actors is sorted by display name.
GET /rest/api/{2-3}/project/{projectIdOrKey}/roledetails
Returns all project roles and the details for each role. Note that the list of project roles is common to all projects.
GET /rest/api/{2-3}/role
Gets a list of all project roles, complete with project role details and default actors.
POST /rest/api/{2-3}/role
Creates a new project role with no default actors.
Use it to obtain JQL search auto-complete data and suggestions for use in programmatic construction of queries or custom query builders. It also provides operations to:
convert one or more JQL queries with user identifiers (username or user key) to equivalent JQL queries with account IDs.
convert readable details in one or more JQL queries to IDs where a user doesn't have permission to view the entity whose details are readable.
POST /rest/api/{2-3}/jql/parse
Parses and validates JQL queries. The validation is performed in context of the current user.
GET /rest/api/{2-3}/user/assignable/multiProjectSearch
Returns a list of users who can be assigned issues in one or more projects. The list may be restricted to users whose attributes match a string.
GET /rest/api/{2-3}/user/search
Returns a list of users that match the search string and property.
GET /rest/api/{2-3}/user/viewissue/search
Returns a list of users who fulfill these criteria:
their user attributes match a search string.
they have a set of permissions for a project or issue.
GET /rest/api/{2-3}/user
Returns a user.
POST /rest/api/{2-3}/user
Creates a user. This resource is retained for legacy compatibility. As soon as a more suitable alternative is available this resource will be deprecated.
DELETE /rest/api/{2-3}/user
Deletes a user.
GET /rest/api/{2-3}/user/bulk
GET /rest/api/{2-3}/user/groups
Returns the groups to which a user belongs.
GET /rest/api/{2-3}/users/search
Returns a list of all (active and inactive) users.
Workflows can be customized to fit the needs of a particular team or project. Customization options include adding new stages or statuses, defining new transitions between statuses, and setting rules and conditions that determine when an issue can move from one stage to another. With a well-designed Jira workflow, teams can track the progress of their work more effectively and ensure that all team members are on the same page about the status of each task or issue.
POST /rest/api/{2-3}/workflow
Deprecated
Create creates a workflow. You can define transition rules using the shapes detailed in the following sections. If no transitional rules are specified the default system transition rules are used.
Conditions enable workflow rules that govern whether a transition can execute.
A condition that always fails.
A condition that blocks issue transition if there is a pending approval.
A condition that allows transition if a comparison between a number custom field and a value is true.
A condition that hides a transition from users. The transition can only be triggered from a workflow function or REST API operation.
A condition that allows only the assignee to execute a transition.
A condition that allows only the reporter to execute a transition.
A condition that allows only users with a permission to execute a transition.
A condition that allows a transition based on whether an issue has or has not transitioned through a status.
A condition that prevents a user to perform the transition, if the user has already performed a transition on the issue.
A condition that blocks transition on a parent issue if any of its subtasks are in any of one or more statuses.
A condition that allows users belonging to any group from a list of groups to execute a transition.
A condition that allows only users with at least one project roles from a list of project roles to execute a transition.
A condition that allows only users listed in a given custom field to execute the transition.
A condition that allows users belonging to a group to execute a transition.
A condition that allows users belonging to a group specified in a custom field to execute a transition.
A condition that allows users with a project role to execute a transition.
A conditions that allows a transition to execute if the value of a field is equal to a constant value or simply set.
Validators check that any input made to the transition is valid before the transition is performed.
A validator that compares two dates.
A validator that checks that a date falls on or after a reference date and before or on the reference date plus a number of days.
A validator that checks fields are not empty. By default, if a field is not included in the current context it's ignored and not validated.
A validator that checks that a field value is changed. However, this validation can be ignored for users from a list of groups.
A validator that checks that a multi-select field has only one value. Optionally, the validation can ignore values copied from subtasks.
A validator that checks the status of the parent issue of a subtask. Ìf the issue is not a subtask, no validation is performed.
A validator that checks the user has a permission.
A validator that checks if the issue has held a status.
A validator that checks the content of a field against a regular expression.
A validator that checks if a user has a permission. Obsolete. You may encounter this validator when getting transition rules and can pass it when updating or creating rules, for example, when you want to duplicate the rules from a workflow on a new workflow.
Post functions carry out any additional processing required after a Jira workflow transition is executed.
A post function that fires an event that is processed by the listeners.
A post function that sets issue status to the linked status of the destination workflow status.
A post function that adds a comment entered during the transition to an issue.
A post function that stores updates to an issue.
A post function that assigns the issue to the current user if the current user has the ASSIGNABLE_USER
permission.
A post function that assigns the issue to the project or component lead developer.
A post function that assigns the issue to the reporter.
A post function that clears the value from a field.
A post function that copies the value of one field to another, either within an issue or from parent to subtask.
A post function that updates the content of an issue custom field.
A post function that updates a simple issue field.
GET /rest/api/{2-3}/workflow/search
This operation does not return next-gen workflows, Deprecated
DELETE /rest/api/{2-3}/workflow/{entityId}
Deletes a workflow, the workflow cannot be deleted if it is:
an active workflow.
a system workflow.
associated with any workflow scheme.
associated with any draft workflow scheme.
POST /rest/api/{2-3}/workflows
Returns a list of workflows and related statuses by providing workflow names, workflow IDs, or project and issue types.
Administer Jira global permission to access all, including project-scoped, workflows
At least one of the Administer projects and View (read-only) workflow project permissions to access project-scoped workflows
GET /rest/api/{2-3}/workflows/capabilities
Get the list of workflow capabilities for a specific workflow using either the workflow ID, or the project and issue type ID pair.
The response includes the scope of the workflow, defined as global/project-based, and a list of project types that the workflow is scoped to. It also includes all rules organised into their broad categories (conditions, validators, actions, triggers, screens)
as well as the source location (Atlassian-provided, Connect, Forge).
A validator rule that checks if a user has the required permissions to execute the transition in the workflow.
A validator rule that checks if a user has the required permissions to execute the transition in the workflow.
Parameters:
A validator to block the child issue\u2019s transition depending on the parent issue\u2019s status.
A validator that checks if an issue has transitioned through specified previous status(es) before allowing the current transition to occur.
Parameters:
previousStatusIds
a comma-separated list of status IDs, currently only support one ID.
mostRecentStatusOnly
when true
only considers the most recent status for the condition evaluation. Allowed values: true
, false
.
A validation that ensures a specific field's value meets the defined criteria before allowing an issue to transition in the workflow.
Depending on the rule type, the result will vary:
Field required
Parameters:
fieldsRequired
the ID of the field that is required. For a custom field, it would look like customfield_123
.
ignoreContext
controls the impact of context settings on field validation. When set to true
, the validator doesn't check a required field if its context isn't configured for the current issue. When set to false
, the validator requires a field even if its context is invalid. Allowed values: true
, false
.
errorMessage
is the error message to display if the user does not provide a value during the transition. A default error message will be shown if you don't provide one (Optional).
POST /rest/api/{2-3}/workflows/create
Create workflows and related statuses. This method allows you to create a workflow by defining transition rules using the shapes detailed in the Atlassian REST API documentation. If no transition rules are specified, the default system transition rules will be used.
Administer Jira project permission to create all, including global-scoped, workflows
Administer projects project permissions to create project-scoped workflows
The AddStatus()
method is used to add a status to the WorkflowCreatesPayload
. This method ensures that any status used in the workflow is explicitly included in the payload under the statuses
tag.
In this example, the status "To Do" with ID "10012" is added to the workflow payload. The StatusReference
is a unique identifier used later when associating statuses with workflow steps.
The AddTransition()
method is used to add a transition between statuses in a workflow. Transitions define the movement between statuses in a workflow, such as moving from "To Do" to "In Progress".
This example adds an "INITIAL" transition called "Create" that moves the issue to the "To Do" status. The StatusReference
is used to link the transition to the appropriate status.
The AddWorkflow()
method is used to add a workflow to the WorkflowCreatesPayload
. This method is crucial for building the final payload that will be sent to the JIRA API.
In this example, the epicWorkflow
(previously populated with statuses and transitions) is added to the payload. This payload can include multiple workflows, making it possible to create several workflows in a single API request.
Any status used within a workflow (through transitions or initial states) must be included in the statuses
tag under the WorkflowCreatesPayload
struct.
This ensures that JIRA recognizes and correctly maps the statuses during workflow creation. Failure to include a status may result in errors or incomplete workflow creation.
POST /rest/api/{2-3}/workflows/create/validation
Validates workflows before creating them. This method allows you to validate the configuration of one or more workflows before they are created in Jira.
It helps ensure that the workflows adhere to the defined rules and constraints. The validation checks will include all aspects of the workflows, such as transitions, statuses, and any related conditions or validators.
Administer Jira project permission to create all, including global-scoped, workflows
Administer projects project permissions to create project-scoped workflows
POST /rest/api/{2-3}/workflows/update
Updates workflows. This method allows you to update workflows by providing a payload containing the details of the updates. You can expand specific fields using the 'expand' parameter.
POST /rest/api/{2-3}/workflows/update/validation
Validates the update of one or more workflows. This method allows you to validate changes to workflows before they are applied.
The validation checks for potential issues that could prevent the workflows from being updated successfully. The validation process will check for conditions such as:
Whether the transitions are valid.
Whether the status and transition names are unique within the workflow.
If the validation fails, a list of validation errors is returned, which should be resolved before applying the changes.
GET /rest/api/{2-3}/screenscheme
POST /rest/api/{2-3}/screenscheme
Creates a screen scheme.
PUT /rest/api/{2-3}/screenscheme/{screenSchemeId}
Updates a screen scheme. Only screen schemes used in classic projects can be updated.
DELETE /rest/api/{2-3}/screenscheme/{screenSchemeId}
Deletes a screen scheme. A screen scheme cannot be deleted if it is used in an issue type screen scheme. Only screens schemes used in classic projects can be deleted.
This resource represents the screens used to record issue details
GET /rest/api/{2-3}/field/{fieldId}/screens
GET /rest/api/{2-3}/screens
POST /rest/api/{2-3}/screens
Creates a screen with a default field tab.
POST /rest/api/{2-3}/screens/addToDefault/{fieldId}
Adds a field to the default tab of the default screen.
PUT /rest/api/{2-3}/screens/{screenId}
Updates a screen. Only screens used in classic projects can be updated.
DELETE /rest/api/{2-3}/screens/{screenId}
Deletes a screen. A screen cannot be deleted if it is used in a screen scheme, workflow, or workflow draft. Only screens used in classic projects can be deleted.
GET /rest/api/{2-3}/screens/{screenId}/availableFields
Returns the fields that can be added to a tab on a screen.
Returns the status of a .
Returns a list of the users specified by one or more account IDs.
A Jira workflow is a set of statuses and transitions that an issue moves through during its lifecycle, and typically represents a process within your organization. Workflows can be associated with particular projects and, optionally, specific issue types by using a .
Returns a list of published classic workflows. When workflow names are specified, details of those workflows are returned. Otherwise, all published classic workflows are returned.
required:
permissionKey
The permission required to perform the transition. Allowed values: .
required:
required:
Returns a list of screen schemes. Only screen schemes used in classic projects are returned.
Returns a list of the screens a field is used in.
Returns a list of all screens or those specified by one or more screen IDs.
GET /rest/api/{2-3}/workflowscheme
Returns a paginated list of all workflow schemes, not including draft workflow schemes.
POST /rest/api/{2-3}/workflowscheme
Creates a workflow scheme.
GET /rest/api/{2-3}/workflowscheme/{id}
Returns a workflow scheme.
PUT /rest/api/{2-3}/workflowscheme/{id}
Updates a workflow scheme, including the name, default workflow, issue type to project mappings, and more. If the workflow scheme is active (that is, being used by at least one project), then a draft workflow scheme is created or updated instead, provided that updateDraftIfNeeded
is set to true
.
DELETE /rest/api/{2-3}/workflowscheme/{id}
Delete deletes a workflow scheme. Please note that a workflow scheme cannot be deleted if it is active (that is, being used by at least one project).
GET /rest/api/{2-3}/workflowscheme/project
Associations returns a list of the workflow schemes associated with a list of projects.
Each returned workflow scheme includes a list of the requested projects associated with it.
Any team-managed or non-existent projects in the request are ignored and no errors are returned.
PUT /rest/api/{2-3}/workflowscheme/project
Assign assigns a workflow scheme to a project. This operation is performed only when there are no issues in the project. The workflow schemes can only be assigned to classic projects.
POST /rest/agile/1.0/sprint
Creates a future sprint. Sprint name and origin board id are required. Start date, end date, and goal are optional.
GET /rest/agile/1.0/sprint/{sprintId}
Returns the sprint for a given sprint ID. The sprint will only be returned if the user can view the board that the sprint was created on, or view at least one of the issues in the sprint.
PUT /rest/agile/1.0/sprint/{sprintId}
Performs a full update of a sprint. A full update means that the result will be exactly the same as the request body. Any fields not present in the request JSON will be set to null.
POST /rest/agile/1.0/sprint/{sprintId}
Performs a partial update of a sprint. A partial update means that fields not present in the request JSON will not be updated.
GET /rest/agile/1.0/sprint/{sprintId}/issue
Returns all issues in a sprint, for a given sprint ID. This only includes issues that the user has permission to view. By default, the returned issues are ordered by rank.
GET /rest/agile/1.0/sprint/{sprintId}/issue
GET /rest/agile/1.0/sprint/{sprintId}/issue
DELETE /rest/agile/1.0/sprint/{sprintId}
Delete deletes a sprint. Once a sprint is deleted, all open issues in the sprint will be moved to the backlog.
POST /rest/agile/1.0/sprint/{sprintId}/issue
Move moves issues to a sprint, for a given sprint ID. Issues can only be moved to open or active sprints. The maximum number of issues that can be moved in one operation is 50.
The go-atlassian agile
module provides a set of functions and types for interacting with the Jira Agile REST API. It is designed to allows developers to interact with and automate various aspects of agile project management within Jira, such as boards, sprints, and issues.
Here's a brief introduction to some key concepts in Jira Agile Rest API:
Boards: A board in Jira represents a visual representation of a project, typically in the form of a Kanban board or a Scrum board. It helps teams track and manage their work. The API provides endpoints to create, retrieve, update, and delete boards, as well as to manage the configuration and settings associated with them.
Sprints: Sprints are time-boxed iterations in agile development, typically used in Scrum methodology. They represent a fixed duration during which a team works on a set of prioritized issues. The API allows you to create, retrieve, update, and delete sprints, as well as manage the issues associated with them.
Issues: Issues in Jira represent tasks, bugs, user stories, or any other unit of work that needs to be tracked. The API provides endpoints to create, retrieve, update, and delete issues. You can also perform operations such as assigning issues to users, transitioning between workflow statuses, adding comments, and more.
Agile Boards API: This API allows you to manage the boards in Jira, including retrieving information about boards, creating new boards, updating board settings, and managing board filters.
Agile Sprints API: With the Agile Sprints API, you can interact with sprints, including creating new sprints, retrieving sprint details, updating sprint properties, and managing the issues associated with sprints.
Agile Issues API: This API allows you to perform operations on issues within the context of agile boards and sprints. You can retrieve issues assigned to a board or sprint, create new issues, update issue details, transition issues between workflow statuses, and more.
GET /rest/api/{2-3}/workflowscheme/{id}/issuetype/{issueType}
Get returns the issue type-workflow mapping for an issue type in a workflow scheme.
PUT /rest/api/{2-3}/workflowscheme/{id}/issuetype/{issueType}
Set sets the workflow for an issue type in a workflow scheme.
Note that active workflow schemes cannot be edited. If the workflow scheme is active, set updateDraftIfNeeded
to true
in the request body and a draft workflow scheme is created or updated with the new issue type-workflow mapping. The draft workflow scheme can be published in Jira.
DELETE /rest/api/{2-3}/workflowscheme/{id}/issuetype/{issueType}
Delete deletes the issue type-workflow mapping for an issue type in a workflow scheme.
Note that active workflow schemes cannot be edited. If the workflow scheme is active, set updateDraftIfNeeded
to true
and a draft workflow scheme is created or updated with the issue type-workflow mapping deleted. The draft workflow scheme can be published in Jira.
GET /rest/api/{2-3}/workflowscheme/{id}/workflow
Mapping returns the workflow-issue type mappings for a workflow scheme.
GET /rest/api/{2-3}/statuses/search
Search returns a paginated list of statuses that match a search on name or project.
GET /rest/api/{2-3}/statuses
Get returns a list of the statuses specified by one or more status IDs.
POST /rest/api/{2-3}/statuses
Create creates statuses for a global or project scope.
PUT /rest/api/{2-3}/statuses
Update updates statuses by ID.
DELETE /rest/api/{2-3}/statuses
Delete deletes statuses by ID.
GET /rest/api/{2-3}/status
Bulk returns a list of all statuses associated with active workflows.
GET /rest/api/{2-3}/status/{idOrName}
Get returns a status.
The status must be associated with an active workflow to be returned.
If a name is used on more than one status, only the status found first is returned. Therefore, identifying the status by its ID may be preferable.
This is an experimental API,
Teams in Advanced Roadmaps are different from the teams found in the rest of Jira Software Cloud. In Advanced Roadmaps, they act as a label applied to issues that designates which team will eventually pick up the work on your timeline. By adding the Team field to your Jira issues, you can save this value back to your Jira issues, which makes sprint planning easier.
Since Advanced Roadmaps is a planning tool, the Team field is a way to use features like capacity management without assigning issues to individuals, which happens in sprint grooming or planning sessions.
You can also use Advanced Roadmaps' view settings to focus on work assigned to a specific team. For example, you can choose to color issues based on the team to which they’re assigned, group issues by team on your timeline, or hide teams from your view.
POST /rest/teams/1.0/teams/find
Gets returns the Teams information from the Jira Advanced Roadmaps application.
Teams in Advanced Roadmaps are different from the teams found in the rest of Jira Software Cloud. In Advanced Roadmaps, they act as a label applied to issues that designates which team will eventually pick up the work on your timeline.
By adding the Team field to your Jira issues, you can save this value back to your Jira issues, which makes sprint planning easier
POST /rest/teams/1.0/teams/create
Create create creates a team on the Advanced Roadmaps.
In Jira, a backlog is a prioritized list of work items that need to be completed. It serves as a repository for all the tasks, user stories, bugs, and other work items that are yet to be worked on or are in the planning stage. Backlogs are typically associated with agile project management methodologies such as Scrum and Kanban.
Backlogs are visualized as lists of items that can be sorted, filtered, and prioritized. Teams can easily move items between different backlogs, update their status, estimate effort, and collaborate on the work items. Backlogs provide a centralized view of all the work in progress and assist in effective planning, tracking, and delivery of projects.
POST /rest/agile/1.0/backlog/issue
Move moves issues to the backlog.
This operation is equivalent to remove future and active sprints from a given set of issues.
At most 50 issues may be moved at once.
POST /rest/agile/1.0/backlog/{boardId}/issue
This operation is equivalent to remove future and active sprints from a given set of issues if the board has sprints.
If the board does not have sprints this will put the issues back into the backlog from the board.
At most 50 issues may be moved at once.
The go-atlassian sm
module provides a set of functions and types for interacting with the Jira Service Management REST API. It provides a programmatic interface to interact with Jira Service Management, enabling developers to automate various aspects of service management.
Here are some key components and concepts related to the Jira Service Management REST API:
Request Types: Request types represent different types of service requests or issue types within Jira Service Management. Examples include "Incident," "Change Request," "Service Request," etc. Request types define the fields and workflows associated with each type of request.
Queues: Queues in Jira Service Management are used to organize and prioritize service requests. Requests are assigned to specific queues based on their attributes or criteria, such as request type, status, or assignee. Queues help teams manage and process incoming requests efficiently.
Approvers: Approvers are individuals or groups responsible for reviewing and approving certain actions or changes within Jira Service Management. For example, an approver might need to approve a change request before it can be implemented. The REST API allows you to retrieve and manage approvers associated with requests or specific workflows.
Customers: Customers in Jira Service Management represent the end-users or customers who raise service requests. These can be individuals or groups within an organization. The REST API enables you to create, update, and manage customer accounts, as well as retrieve information about customers and their associated requests.
Workflows: Workflows define the stages and transitions that a request goes through during its lifecycle in Jira Service Management. Workflows determine how requests move from one status to another, who can perform certain actions, and what actions are available at each stage. The REST API allows you to interact with workflows, including creating, updating, and transitioning requests between workflow states.
Service Level Agreements (SLAs): SLAs define the expected response and resolution times for different request types. They help teams prioritize and meet service-level targets. The REST API allows you to manage SLAs associated with requests, retrieve SLA information, and track SLA performance.
GET /rest/servicedeskapi/knowledgebase/article
Returns articles that match the given query string across all service desks.
GET /rest/servicedeskapi/servicedesk/{serviceDeskId}/knowledgebase/article
Returns articles that match the given query and belong to the knowledge base linked to the service desk.
GET /rest/agile/1.0/epic/{epicIdOrKey}
Returns the epic for a given epic ID. This epic will only be returned if the user has permission to view it.
Note: This operation does not work for epics in next-gen projects.
GET /rest/agile/1.0/epic/{epicIdOrKey}/issue
Returns all issues that belong to the epic, for the given epic ID. This only includes issues that the user has permission to view. Issues returned from this resource include Agile fields, like sprint, closedSprints, flagged, and epic. By default, the returned issues are ordered by rank.
Note: If you are querying a next-gen project, do not use this operation. Instead, search for issues that belong to an epic by using the Search for issues using JQL operation in the Jira platform REST API.
Build your JQL query using the parent clause. For more information on the parent JQL field, see Advanced searching.
POST /rest/agile/1.0/epic/{epicIdOrKey}/issue
Move moves issues to an epic, for a given epic id. Issues can be only in a single epic at the same time. That means that already assigned issues to an epic, will not be assigned to the previous epic anymore. The user needs to have the edit issue permission for all issue they want to move and to the epic. The maximum number of issues that can be moved in one operation is 50.
POST /rest/servicedeskapi/customer
This method adds a customer to the Jira Service Management instance by passing a JSON file including an email address and display name. The display name does not need to be unique. The record's identifiers, name
and key
, are automatically generated from the request details.
POST /rest/servicedeskapi/servicedesk/{serviceDeskId}/customer
Adds one or more customers to a service desk. If any of the passed customers are associated with the service desk, no changes will be made for those customers and the resource returns a 204 success code.
GET /rest/servicedeskapi/servicedesk/{serviceDeskId}/customer
This method returns a list of the customers on a service desk.
DELETE /rest/servicedeskapi/servicedesk/{serviceDeskId}/customer
This method removes one or more customers from a service desk. The service desk must have closed access. If any of the passed customers are not associated with the service desk, no changes will be made for those customers and the resource returns a 204 success code.
Not implemented, feel free to open a PR
Not implemented, feel free to open a PR
A board displays issues from one or more projects, giving you a flexible way of viewing, managing, and reporting on work in progress.
GET /rest/agile/1.0/board/{boardId}/backlog
Returns all issues from the board's backlog, for the given board ID.
This only includes issues that the user has permission to view.
The backlog contains incomplete issues that are not assigned to any future or active sprint.
Issues returned from this resource include Agile fields, like sprint, closedSprints, flagged, and epic. By default, the returned issues are ordered by rank.
GET /rest/agile/1.0/board/{boardId}/configuration
Get the board configuration.
POST /rest/agile/1.0/board
Creates a new board. Board name, type ,and filter ID is required
GET /rest/agile/1.0/board/{boardId}/epic
Returns all epics from the board, for the given board ID. This only includes epics that the user has permission to view. Note, if the user does not have permission to view the board, no epics will be returned at all.
GET /rest/agile/1.0/board/filter/{filterId}
Returns any boards which use the provided filter id. This method can be executed by users without a valid software license in order to find which boards are using a particular filter.
GET /rest/agile/1.0/board/{boardId}
Returns the board for the given board ID.
This board will only be returned if the user has permission to view it.
Admins without the view permission will see the board as a private one, so will see only a subset of the board's data (board location for instance).
GET /rest/agile/1.0/board/{boardId}/issue
Returns all issues from a board, for a given board ID.
This only includes issues that the user has permission to view.
An issue belongs to the board if its status is mapped to the board's column.
Epic issues do not belongs to the scrum boards.
Issues returned from this resource include Agile fields, like sprint, closedSprints, flagged, and epic. By default, the returned issues are ordered by rank.
GET /rest/agile/1.0/board/{boardId}/epic/{epicId}/issue
Returns all issues that belong to an epic on the board, for the given epic ID and the board ID.
This only includes issues that the user has permission to view.
Issues returned from this resource include Agile fields, like sprint, closedSprints, flagged, and epic. By default, the returned issues are ordered by rank.
GET /rest/agile/1.0/board/{boardId}/sprint/{sprintId}/issue
Get all issues you have access to that belong to the sprint from the board.
Issue returned from this resource contains additional fields like: sprint, closedSprints, flagged and epic. Issues are returned ordered by rank. JQL order has higher priority than default rank.
GET /rest/agile/1.0/board/{boardId}/epic/none/issue
Returns all issues that do not belong to any epic on a board, for a given board ID. This only includes issues that the user has permission to view. Issues returned from this resource include Agile fields, like sprint, closedSprints, flagged, and epic. By default, the returned issues are ordered by rank.
POST /rest/agile/1.0/board/{boardId}/issue
Move issues to the backlog of a particular board (if they are already on that board).
This operation is equivalent to remove future and active sprints from a given set of issues if the board has sprints If the board does not have sprints this will put the issues back into the backlog from the board. At most 50 issues may be moved at once.
GET /rest/agile/1.0/board/{boardId}/project
Returns all projects that are associated with the board, for the given board ID. If the user does not have permission to view the board, no projects will be returned at all. Returned projects are ordered by the name.
GET /rest/agile/1.0/board/{boardId}/sprint
Returns all sprints from a board, for a given board ID. This only includes sprints that the user has permission to view.
GET /rest/agile/1.0/board/{boardId}/version
Returns all versions from a board, for a given board ID. This only includes versions that the user has permission to view. Note, if the user does not have permission to view the board, no versions will be returned at all. Returned versions are ordered by the name of the project from which they belong and then by sequence defined by user.
DELETE /rest/agile/1.0/board/{boardId}
Delete deletes the board. Admin without the view permission can still remove the board.
GET /rest/agile/1.0/board
Gets returns all boards. This only includes boards that the user has permission to view.