Last updated Sep 21, 2023

Rate this page:

Changelog

This page includes release notes and updates for Jira Cloud app developers. Use this page to keep track of upcoming changes, deprecation notices, new features, and feature updates from Jira Cloud Platform.

Forge changelog

For updates about changes to the Forge platform, see the Forge changelog in the Forge documentation.

Go to our developer community to ask questions. You may also be interested in the What's New blog for Atlassian Cloud where details of major changes that affect all users of the Jira Cloud products are announced.

21 September 2023

Added New screen tabs API: get bulk screen tabs

We’ve added a new screen tabs API to Jira Cloud Platform. The get bulk screen tabs API allows you to get tabs from multiple screens, filtered by tab ID and/or screen ID. Follow the link for detailed documentation.

18 September 2023

Removed Workflow updates will no longer be on an issue’s history

To improve the performance of workflow updates, we’re no longer recording them on an issue’s history. APIs like Get changelogs won’t display workflow updates anymore.

Added  Licensing Fields Available in Connect Lifecycle Event

Two fields that were previously only available through an API call are now available through the /installed lifecycle event. From today the /installed lifecycle event will return with 2 additional fields: entitlementId and entitlementNumber where available. For documentation on this event, see this page.

13 September 2023

Fixed Add Field to Screen Tab API and Add field to Default Screen Tab API - Invalid scope should return 400 Bad Request instead of 500

When consumers trying to add custom fields with invalid scope to a global screen tab, API returns 500 internal server error instead of a 400 Bad Request.

This change is for the API return 400 bad request instead of 500 when a custom field with Project scope is passed as parameter.

  • Current

    • Error code: 500

    • Error message: "Internal server error"

  • New:

    • Error code: 400

    • Error message: "<<field_id>> is a team-managed field and you can't add it to a global screen."

Progressive rollout by region/tenant pending

8 September 2023

Removed Workflow status properties will no longer support group names

As of 8th of September 2023, we’re removing the ability to use group names shaped like jira.permission[.subtasks].{permission}.group.[.suffix]in workflow status properties. Entities that haven’t been translated from group name to group ID will no longer work as expected.

More details

To ensure we can rename groups safely, we no longer support group names in status properties.

If your workflow uses a status property with the shape jira.permission[.subtasks].{permission}.group.[.suffix], your admin will have to change the value to the group’s ID.

Site admins can find a group’s ID by going to Settings > User management > Groups. After selecting a group, the ID will be at the end of the URL.

If your app uses the above workflow status properties, you’ll need to update your code to use group IDs instead of group names by the end of the deprecation period on 8th of September 2023.

Announcement Canada region coming soon for Connect data residency

In October 2023, Atlassian plans to add support for Canada to Connect apps, alongside existing data residency regions available to customers. Once this region is available, we will be updating our data residency supported region keys to include Canada (CA) alongside our existing supported data residency regions. We will provide further updates closer to availability.

More details

As a reminder, if you indicate support for a realm, it means your app stores the relevant data that is in-scope for your app’s data residency solution (see Atlassian’s documentation on in-scope data for our products here). For more information, please refer to the Connect data residency documentation.

In addition to Canada, Atlassian is exploring making additional data residency regions available in the future. These can be identified on the Atlassian Cloud Roadmap and we will provide similar updates/notice prior to these regions being available.

Added UI modifications on Global issue create now support new project types

UI modifications, the Forge module that enables apps to modify fields, now allows you to create UIMs on the Global issue create modal for Jira Work Management projects.

For more information, see the list of supported project types for GIC.

7 September 2023

Announcement Preview for Issue View in UI modifications

We’re pleased to announce a preview release of support for a new location via the UI modifications extension point: Issue view.

It’s the second Jira location to be supported, following the initial support for the Global issue create modal.

More details

Documentation specific to the Issue view is available under this link. The supported fields and methods are listed here.

To assign a UI modification to the Issue view context, you need to pass a viewType equal to IssueView while creating or updating the UI modification. See more details in our REST API docs.

At the same time, we’re ending the UI modifications Issue View Early Access Program. Your apps developed during the EAP will continue to work.

Added New Workflow Scheme REST APIs

Jira Cloud Platform features new workflow scheme APIs for company-managed and team-managed projects, allowing you to programmatically retrieve and update the details of workflow schemes. These new APIs are all declarative, allowing you to define the desired end state as well as system transitions from your current state to the desired state.

The new APIs are:

6 September 2023

Deprecation Notice End of support for atlassian-connect-spring-boot 3.x

Support for atlassian-connect-spring-boot 3.x will end on 18 November 2023.

Apps must migrate to atlassian-connect-spring-boot 4.x during this period.

Added Release of atlassian-connect-spring-boot 4.0.1

We have released a Spring Boot 3.x compatible version for Atlassian Connect Spring Boot (ACSB 4.x). To continue to be supported, please upgrade by November 18 2023.

More details

With this release, you can start to migrate apps to ACSB 4 and Spring Boot 3.

This release includes these updates:

  • Migration to Spring Boot 3.1.0.

  • Migration to Java 17.

The previous 2.7.x version of Spring Boot is reaching End Of Life (EOL) by November 18th 2023 (Spring Boot).

4 September 2023

Deprecation Notice Introducing per issue limits for issue list fields

In 6 months, we will enforce limits per issue for the number of:

  • Comments: 5000 comments per issue

  • Worklogs: 5000 worklogs per issue

  • Attachments: 2000 attachments per issue

  • Issue links: 2000 issue links per issue (excluding child issues and subtasks)

  • Remote links: 2000 remote issue links per issue

An error response will occur if the limit is exceeded for:

  • Operations via REST APIs

  • Automation rules

  • Issue transitions

If issue data already exceeds the limits, this will be transformed into an attachment within the issue.

More details

What’s changing?

Creating and updating issue data

Limits on the number of list field Items allowed per issue

Maximum limits per issue

Impacted APIs

Operations will result in an error after the change

Old response

New response

5000 comments per issue

POST rest/api/{v:2|3|latest}/issue/{issueIdOrKey}/comment

PUT /rest/api/{v:2|3|latest}/issue/{issueIdOrKey}/comment/{id}

POST /rest/api/{v:2|3|latest}/issue/{issueIdOrKey}/transitions

  • Adding a comment to an issue with 5000 or more comments

  • Updating a comment in an issue with more than 5000 comments

200 OK

413 Content Too Large

message: COMMENTS_PER_ISSUE_LIMIT_EXCEEDED

5000 worklogs per issue

POST rest/api/{v:2|3|latest}/issue/{issueIdOrKey}/worklog

PUT /rest/api/{v:2|3|latest}/issue/{issueIdOrKey}/worklog/{id}

POST /rest/api/{v:2|3|latest}/issue/{issueIdOrKey}/transitions

  • Adding a comment to an issue with 5000 or more comments

  • Updating a comment in an issue with more than 5000 comments

200 OK

413 Content Too Large

message: WORKLOGS_PER_ISSUE_LIMIT_EXCEEDED

2000 attachments per issue

POST /rest/api/{v:2|3|latest}/issue/{issueIdOrKey}/attachments

POST /rest/api/{v:2|3|latest}/issue/{issueIdOrKey}/transitions

  • Adding an attachment to an issue with 2000 or more attachments

200 OK

413 Content Too Large

message: ATTACHMENTS_PER_ISSUE_LIMIT_EXCEEDED

2000 issue links per issue (excluding child issues and subtasks)

POST /rest/api/{v:2|3|latest}/issueLink

POST /rest/api/{v:2|3|latest}/issue/{issueIdOrKey}/transitions

  • Adding an issue link to an issue with 2000 or more issue links

200 OK

413 Content Too Large

message: ISSUE_LINKS_PER_ISSUE_LIMIT_EXCEEDED

2000 remote links per issue

POST/rest/api/{v:2|3|latest}/issue/{issueIdOrKey}/remotelink

PUT/rest/api/{v:2|3|latest}/issue/{issueIdOrKey}/remotelink/{linkId}

POST /rest/api/{v:2|3|latest}/issue/{issueIdOrKey}/transitions

  • Adding an remote link to an issue with 2000 or more remote links

200 OK

413 Content Too Large

message: REMOTE_LINKS_PER_ISSUE_LIMIT_EXCEEDED

Migrations

The above limits per issue will also apply to site import and JCMA migrations. Instead of an error, issues with field data over the limit will have a transformation rule applied, such that the field data over the limit is converted into attachments on the issue.

Existing issues over the limit

Existing issues with field data over the limit will have a transformation rule applied, such that the field data over the limit is converted into attachments on the issue.

Why is it changing?

Whilst the vast majority of our issues are associated with a reasonable amount of comments, worklogs, attachments, issue links and remote links, there are some issues with extreme data shapes on an issue. These large data sizes can lead to reliability issues and incidents in unpredictable ways.

What do I need to do?

No changes to your app, automation or workflows are necessary if

  • you aren’t working with the APIs listed above

  • you know none of your issues would have fields that are over the limit

If your app/automation/workflows are performing operations that would cause it to exceed limits, you need to handle the new error message appropriately.

If your app/automation/workflows needs to create comments/worklogs/attachments/issue links/remote links in an issue that will cause the limit to be exceeded, consider creating them in another issue.

If your app/automation/workflows needs to update comments/worklogs/attachments/issue links/remote links in an issue that is already exceeding limit for that field, consider moving items to another issue before attempting the update.

By when do I need to do it?

Th deprecation period is 6 months.

1 September 2023

Removed Deprecating support for passing Connect JWTs as a query string parameter to Atlassian APIs

As per Understanding JWT for Connect apps and our previous deprecation notice, the Jira and Confluence APIs now only allow Connect apps to provide authentication JWTs as an Authorization: JWT header in requests. the Atlassian Jira and Confluence APIs will no longer inspect the ?jwt= query string parameter and requests for all apps, and consequently may fail with a HTTP 401 response.

Please utilise the JWT auth header as a means to authenticate as outlined in: https://developer.atlassian.com/cloud/jira/platform/understanding-jwt-for-connect-apps/#creating-a-jwt-token

This change does not affect how Jira or Confluence provides the Atlassian product JWTs to Connect app modules/iframes.

Please note: This removal will progressive rollout by tenants, increasing to 100% by the 15th September, 2023

More details

Why is it changing?

Accepting sensitive JWTs as a query string parameter presents a problem as the query string is often saved in web browser history, passed through Referers to other web sites, stored in web logs such as intermediate proxy servers.

What do I need to do?

If your app provides its Connect JWT to the Atlassian APIs as a query string parameter, you must update it to pass the JWT via an Authorization: JWT header.

Added Custom domains now added to the Connect Lifecycle HTTP request payload

The Connect lifecycle HTTP request payload for both Jira and Jira Service Management (JSM) now contains two new fields for apps installed on sites participating in the custom domains beta. These reflect any custom domains configured for each product:

  • displayUrl: The custom domain for Jira;

  • displayUrlServicedeskHelpCenter: The custom domain for JSM.

The updated payload:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 { "key": "my-app", "clientKey": "redacted", "publicKey": "redacted", "sharedSecret": "redacted", "serverVersion": "100234", "pluginsVersion": "1001.0.0-SNAPSHOT", "baseUrl": "https://my-service-desk.jira-dev.com", "displayUrl": "https://stg-test-22aug-1239.jira.staypositive.au", "productType": "jira", "description": "Atlassian JIRA at https://my-service-desk.jira-dev.com", "eventType": "installed", "cloudId": "f3fa27a2-189a-4ea5-a06c-374567baf7d5", "displayUrlServicedeskHelpCenter": "https://stg-test-22aug-1352.jsm.staypositive.au" }

If no custom domains have been added to the Jira or JSM, then the value of these fields will fallback to baseUrl, which is the default site URL.

Please note that API requests from your App should always use the baseUrl. The displayUrl and displayUrlServicedeskHelpCenter properties should only be used when displaying or rendering URLs.

31 August 2023

Added UI modifications now support the issue type system field

UI modifications, the Forge module that allows apps to modify fields, now supports the issue type system field for Global issue create modal.

For more information, see the list of supported fields.