What’s new in the Jira Cloud Ecosystem

Reading Time: 4 minutes

We’ve been busy these last few months, we welcomed Stride to our product portfolio and we launched our new brand. In the Jira Cloud team, we’re excited about all these changes, and we introduced a couple of our own. Read on if you want to learn about the new capabilities we introduced.

Bulk user search API

Normally, apps that need information on a large number of Jira users – for example to generate user-related reports – had to fetch the details of each user separately. In order to make it easier for an app and reduce the number of network roundtrips, we created an endpoint for requesting user details in bulk. Now you just need to specify an array of usernames or user keys in the request body, in order to get full representation of multiple users’ details in a single REST query. Refer to the GET /user/bulk API documentation for implementation details. Note that the endpoint is currently in an experimental state, and changes to the API are still possible.

Default values for issue fields

One of the characteristics of Jira custom fields is the ability to define the default value, which will be pre-selected when the field is displayed to the user. However, issue fields provided by Connect apps did not have the option to define the default value. This meant that the end users always had to browse through the whole selection of options and choose the right one. Now you can save your users the unnecessary steps and populate the issue fields with default options for any given project. This functionality is available for single select and multi select issue field types. In order to define the default value for a specific issue field, use the defaultValue attribute in the issue field options, as in the example:

{
    "id": 1,
    "value": "Team 1",
    "config": {
        "scope": {
            "projects2": [
                {
                    "id": 1001,
                    "attributes": [
                        "defaultValue" // set this option as default in project 1001
                    ]
                }
            ]
        }
    }
}

User-based search

A few weeks back we released JQL for user-based search, which gives you the opportunity to look at Jira’s data not only as a collection of issues, but also from the perspective of users who work with them. Since the original beta access announcement, we have made the endpoint public (while keeping it experimental) and implemented more options to narrow down the search results. In addition to looking for assignees and reporters of issues in given projects, it is now possible to search for users with specific entity properties value. Refer to the GET /user/search/query API documentation to give it a try and let us know in the related Trello card what other capabilities would make it even more valuable.

Field IDs in issue changelogs

Up until recently, issue changelog entries referenced issue fields only by the name of the field. That was problematic for apps and REST API clients, especially when field names got renamed or translated. Now, permanent IDs are provided for issue fields in changelog responses, so you can easily identify which fields have changed.

Updating worklogs in non-editable issues

In a Jira issue lifecycle, there are situations when the issue cannot be edited anymore. For example when the project has been closed, the issue has been closed or archived. But even though the issue itself should not be modified, users might still want to log or update time tracking information. It is now possible to use the /rest/api/2/issue/{issueIdOrKey}/worklog REST API endpoint with overrideEditableFlag set to true, to add or update worklogs in issues that are in a non-editable state. Note that the flag is set to false by default, and only Connect app users with admin scope permission are allowed to use it.

What’s keeping us busy

If you attended this year’s AtlasCamp in Barcelona, you may recall Max Mancini, Head of Ecosystem, announcing the adoption of Swagger as our standard for API documentation. Jira Service Desk was the first one, followed by Confluence, to publish their REST API reference in Swagger format on the recently recreated Developer Portal. It is now high time for Jira Cloud to conform and provide the improved, consistent and highly interactive documentation experience to all Atlassian Ecosystem developers. We’re working at full speed on migrating the existing JIRA Cloud REST API reference into a Swagger file and make it available on the Developer Portal.

What’s coming next

As part of our open culture, we want to help you make informed decisions that impact your businesses. And, therefore, we share our Jira Cloud Ecosystem roadmap with you. It is a publicly visible Trello board, where you can find out what we’ve shipped recently, what we are currently working on, and which can give you an idea of what we’re prioritising for the near and long-term future. You may notice that some initiatives are linked to individual issues in the ACJIRA project, while others are more general and indicate what investments we want to make to support and grow the Atlassian Ecosystem.

Insights from Jira app developers are an incredibly important part of our prioritisation, and we refer to ACJIRA project on ecosystem.atlassian.net as one of the most essential source of your feedback. Jira Cloud Ecosystem team reviews all incoming improvement requests on a regular basis to get a clear picture of the gaps and opportunities for apps development in Jira Cloud. We’d like to encourage you to demonstrate interest in individual features by voting on selected ACJIRA issues. As a voter or watcher of the issue, you will also get first hand information that the improvement was delivered to Jira Cloud.