Rate this page:
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.
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.
We’ve introduced new features to jira:workflow-validator Forge modules that use Jira expressions.
You can now:
define a custom UI for creating, editing, or viewing validator configuration
save workflow configuration to the config context variable
pass a Jira expression in the manifest to dynamically build error messages
override Jira expressions defined in the manifest with ones stored in validator configuration
use more context variables that are available in Jira expressions
See the Jira workflow validator (preview) documentation and the new jira-workflow-validator custom UI template for more details.
We’re also looking into metrics and feedback regarding validators based on lambda functions. These will help us decide on the direction in which we’ll be taking this feature.
EDIT, 17 Aug, 2022: This change was originally announced on August 15th, 2022. However the change was only made effective in production as of August 17th, 2022 (AEDT). Our apologies for any confusion caused.
To help you debug your Forge apps more easily, app logs are now available by default when a user installs your app on their site.
Previously log access was disabled by default. If you needed log access for your app on a user’s site, you had to ask the user to manually give you log access through Admin Hub.
Now log access is enabled by default. When a user installs your Forge app on their site, you will now have automatic access to logs for your app on their site.
Note, apps that are already installed will remain in their current state of log sharing, with log access disabled by default, but we are investigating how to change this.
Disabling access
Users can still manually disable or re-enable log access through Admin Hub. This will remove your access to the logs for your app on their site, including any historic logs that were generated when you previously had access.
To help you when handling logs for your Forge app, we have added new Logging guidelines for app developers. These guidelines outline some best practices to consider when handling logs and determining what data you should, and should not, be logging.
EDIT, 12 Aug, 2022: Change from a Remove notice to a Deprecation Notice.
We've changed how Lexorank interacts with issue create, to improve the reliability and performance of Lexorank-related operations: The payload for the issue_created webhook, fired as part of an issue create post-function, no longer contains the values for Lexorank.
For example, prior to this change, Lexorank fields were returned in the payload of the webhook with the value generated on issue create:
1
"customfield_XXXXX": "0|i0002n:"After this change, the value is omitted from the issue_created webhook payload:
1
"customfield_XXXXX": nullStarting 1 Sep 2022, we’re introducing a limit of 5 redirects for webhooks. This means that when sending a webhook to its callback URL we won’t follow more than 5 redirects.
Note that webhooks that aren’t delivered after the maximum number of redirects can't be found with the get failed webhooks operation.
Instead of returning all comments for GET rest/api/{v:2|3|latest}/issue/{issueIdOrKey}/comment, we’ll limit the number of comments returned to 5000 per API call. We will truncate the list of comments returned to 5000 whenever clients request more in a single call. Consumers can still get all the comments by utilising pagination.
Instead of returning all comments for GET rest/api/{v:2|3|latest}/issue/{issueIdOrKey}/comment, we’ll limit the number of comments returned to 5000 per API call. We will truncate the list of comments returned to 5000 whenever clients request more in a single call. Consumers can still get all the comments by utilising pagination.
The default value for the maximum number of comments returned (maxResults) will remain 50.
The order and shape in which the comments are returns will be unaltered.
The following request does not specify the maxResults request parameter:
1
2
3
4
5
// Request without specifying maxResults
curl --request GET \
--url 'https://<jiraBaseUrl>/rest/api/2/issue/{issueIdOrKey}/comment' \
--user 'username@atlassian.com:<token>' \
--header 'Accept: application/json'
Currently, this means maxResults will be set to the default value 1048576. Thus, the response will be:
1
2
3
4
5
6
7
// Before the change
{
"startAt":?,
"maxResults":1048576, // default value if not specified
"total":?, // the total number of comments on the issue
"comments":[?]
}
After this change, maxResults will be set to 5000 by default when unspecified:
1
2
3
4
5
6
7
// After the change
{
"startAt":?,
"maxResults":5000, // default value if not specified
"total":?, // the total number of comments on the issue
"comments":[?]
}
The following request specifies the maxResults request parameter to a number less than 5000:
1
2
3
4
5
// Request specifying maxResults to a number less than 5000
curl --request GET \
--url 'https://<jiraBaseUrl>/rest/api/2/issue/{issueIdOrKey}/comment?maxResults=100' \
--user 'username@atlassian.com:<token>' \
--header 'Accept: application/json'
The response (before and after this change) will be:
1
2
3
4
5
6
{
"startAt":?,
"maxResults":100,
"total":?, // the total number of comments on the issue
"comments":[?]
}
IMPORTANT: If the value of maxResults exceeds 5000, we will truncate the returned list to a maximum of 5000 comments. Consumers can make additional calls to this REST API to get more comments.
The following request specifies the maxResults request parameter to a number greater than 5000:
1
2
3
4
5
// Request specifying maxResults to a number greater than 5000
curl --request GET \
--url 'https://<jiraBaseUrl>/rest/api/2/issue/{issueIdOrKey}/comment?maxResults=7500' \
--user 'username@atlassian.com:<token>' \
--header 'Accept: application/json'
The response after this change will truncate the list of comments will be:
1
2
3
4
5
6
{
"startAt":?,
"maxResults":5000, // maxResults truncated from the requested 7500 down to 5000
"total":?, // the total number of comments on the issue
"comments":[?] // the list of comments returned will be truncated to 5000 items.
}
The vast majority of our issues contain reasonable (< 5000) numbers of comments. However, there are some issues with large numbers of comments. When consumers query those issues through rest/api/{v:2|3|latest}/issue/{issueIdOrKey}/comment all at once, the backing system can become overloaded.
If you aren’t working with comments returned via GET rest/api/{v:2|3|latest}/issue/{issueIdOrKey}/comment, no changes to your client-side code are required.
If your client-side only needs to know about the total count of the comments on an issue, you can still use total from the response and no changes to your client-side are necessary.
If you are confident that your client-side code does not set maxResults to a value greater than 5000, and if you are confident that you do not have issues with more than 5000 comments, then no changes are necessary.
If your client-side code sets maxResults to a value greater than 5000, and if you have issues containing more than 5000 comments, then after this change we will be truncating the list of comments returned to a maximum of 5000. You can make additional API calls to get more comments.
Given that this is a paginated API, clients are expected to adhere to best practices by making no assumption about the number of items returned per page, and making further call to further pages to get the required list of items. If existing clients of this API endpoint have adhered to pagination best practices, then this should not be a breaking change. Otherwise, we’ll provide a deprecation period allowing clients to adjust their client-side code to avoid breakage.
We have chosen a deprecation period of 3 months, which is less than the usual period of 6 months for the following reasons:
This API endpoint is already paginated, and clients who’ve adhered to best practices should not break.
The vast majority of API calls should not be adversely affected since most issues have far fewer comments than the limit being introduced.
The changes result in significant customer benefits due to improvements to reliability and performance.
A simple migration guide exists for the very few cases where an app may need to obtain more than 5000 comments for an issue.
We recently launched a new developer support page, which serves as a centralized hub for reporting issues, managing your app and getting support. This page will streamline your experience of getting in contact with us for different areas of support:
Bugs: Report development or Marketplace bugs
Incidents: Report critical issues or breaking changes
App listing: Edit your app or access Marketplace APIs
Accounts and payment: Manage your Marketplace payments and licenses
App migration: Get help with creating a cloud version of your app
Security programs: Apply or adjust your program details
Partner resources: Request access to exclusive partner content
Ukraine support: Request emergency concessions or ask questions
If you have any questions, please get in touch with us via the developer community announcement.
We’re releasing the beta version of a major release of atlassian-connect-spring-boot. The release is marked 3.0.0-beta-1. In this release, we’re mainly migrating from Spring Security OAuth 2.x, which reached end-of-life in May 2022, to Spring Security 5.2.x. We’ve also removed certain deprecated methods. For more details, see the list of changes below.
What’s changing in atlassian-connect-spring-bootRemoved deprecated methods
Breaking Changes
|
Instead of returning all worklogs for GET rest/api/{v:2|3|latest}/issue/{issueIdOrKey}/worklog, we’ll limit the number of worklogs returned to 5000 per API call. We will truncate the list of worklogs returned to 5000 whenever clients request more in a single call. Consumers can still get all the worklogs by utilising pagination.
Instead of returning all worklogs for GET rest/api/{v:2|3|latest}/issue/{issueIdOrKey}/worklog, we’ll limit the number of worklogs returned to 5000 per API call. We will truncate the list of worklogs returned to 5000 whenever clients request more in a single call. Consumers can still get all the worklogs by utilising pagination.
The default value for the maximum number of worklogs returned (maxResults) will also be reduced from 1048576 to 5000.
The order and shape in which the worklogs are returns will be unaltered. The current ordering is ascending by worklog start date, or on or after startedAfter date if specified.
The following request does not specify the maxResults request parameter:
1
2
3
4
5
// Request without specifying maxResults
curl --request GET \
--url 'https://<jiraBaseUrl>/rest/api/2/issue/{issueIdOrKey}/worklog' \
--user 'username@atlassian.com:<token>' \
--header 'Accept: application/json'Currently, this means maxResults will be set to the default value 1048576. Thus, the response will be:
1
2
3
4
5
6
7
// Before the change
{
"startAt":?,
"maxResults":1048576, // default value if not specified
"total":?, // the total number of worklogs on the issue
"worklogs":[?]
}After this change, maxResults will be set to 5000 by default when unspecified:
1
2
3
4
5
6
7
// After the change
{
"startAt":?,
"maxResults":5000, // default value if not specified
"total":?, // the total number of worklogs on the issue
"worklogs":[?]
}The following request specifies the maxResults request parameter to a number less than 5000:
1
2
3
4
5
// Request specifying maxResults to a number less than 5000
curl --request GET \
--url 'https://<jiraBaseUrl>/rest/api/2/issue/{issueIdOrKey}/worklog?maxResults=100' \
--user 'username@atlassian.com:<token>' \
--header 'Accept: application/json'The response (before and after this change) will be:
1
2
3
4
5
6
{
"startAt":?,
"maxResults":100,
"total":?, // the total number of worklogs on the issue
"worklogs":[?]
}
IMPORTANT: If the value of maxResults exceeds 5000, we will truncate the returned list to a maximum of 5000 worklogs. Consumers can make additional calls to this REST API to get more worklogs.
The following request specifies the maxResults request parameter to a number greater than 5000:
1
2
3
4
5
// Request specifying maxResults to a number greater than 5000
curl --request GET \
--url 'https://<jiraBaseUrl>/rest/api/2/issue/{issueIdOrKey}/worklog?maxResults=7500' \
--user 'username@atlassian.com:<token>' \
--header 'Accept: application/json'The response after this change will truncate the list of worklogs will be:
1
2
3
4
5
6
{
"startAt":?,
"maxResults":5000, // maxResults truncated from the requested 7500 down to 5000
"total":?, // the total number of worklogs on the issue
"worklogs":[?] // the list of worklogs returned will be truncated to 5000 items.
}
The vast majority of our issues contain reasonable (< 5000) numbers of worklogs. However, there are some issues with large numbers of worklogs. When consumers query those issues through rest/api/{v:2|3|latest}/issue/{issueIdOrKey}/worklog all at once, the backing system can become overloaded.
If you aren’t working with worklogs returned via GET rest/api/{v:2|3|latest}/issue/{issueIdOrKey}/worklog, no changes to your client-side code are required.
If your client-side only needs to know about the total count of the worklogs on an issue, you can still use total from the response and no changes to your client-side are necessary.
If you are confident that your client-side code does not set maxResults to a value greater than 5000, and if you are confident that you do not have issues with more than 5000 worklogs, then no changes are necessary.
If your client-side code sets maxResults to a value greater than 5000, and if you have issues containing more than 5000 worklogs, then after this change we will be truncating the list of worklogs returned to a maximum of 5000. You can make additional API calls to get more worklogs.
Given that this is a paginated API, clients are expected to adhere to best practices by making no assumption about the number of items returned per page, and making further call to further pages to get the required list of items. If existing clients of this API endpoint have adhered to pagination best practices, then this should not be a breaking change. Otherwise, we’ll provide a deprecation period allowing clients to adjust their client-side code to avoid breakage.
We have chosen a deprecation period of 3 months, which is less than the usual period of 6 months for the following reasons:
This API endpoint is already paginated, and clients who’ve adhered to best practices should not break.
The vast majority of API calls should not be adversely affected since most issues have far fewer worklogs than the limit being introduced.
The changes result in significant customer benefits due to improvements to reliability and performance.
A simple migration guide exists for the very few cases where an app may need to obtain more than 5000 worklogs for an issue.
We’ve introduced the jira:globalPermission and jira:projectPermission Forge modules. These modules allow you to define custom permissions for Jira. They’re available as part of the Early Access Program (EAP). A dedicated space of the Atlassian Developer Community is available for your feedback and bug reports.
See the Jira global permission and Jira project permission reference documentation for more details.
The custom field “Epic Name“ will become optional starting from 15 Jan 2023. It will remain available after that date, and no data will be lost.
If you're a Jira REST API user or Marketplace Partner, ensure that:
Your app correctly handles the scenario when “Epic Name” is either null or not present.
In your app, you replace “Epic name” with “Issue Summary”:
1
2
3
4
...
"customfield_10011": "This is Epic name. Stop using it",
"summary": "This is Issue summary. Use this instead"
...
You'll need to make this change by 15 Jan 2023.
What is happening to Jira UI that currently uses Epic name?
It will switch to using Issue summary.
Can users configure the Epic name field to make it mandatory?
Yes, this functionality will become available later.
What is the reason for this change?
For more information, see:
We fixed a bug that triggered a refresh_token is invalid message with status 400 during the OAuth 2.0 refresh grant flow. This occurred when an additional code parameter was provided that matched the format of a JSON Web Token(JWT).
Applications making refresh_token requests that matched the above condition would have seen failures (refresh_token is invalid) to exchange tokens from February 2022 onwards.
To make it easier to track the performance of your shared apps, we’ve added quick-view cards on the developer console landing page, under a new ‘My shared apps’ section. These cards show your shared apps':
Invocation success rate for the last 7 days
Error count for the last 7 days
Last deployment event
To see this change, log into the developer console, and if you’re sharing your app, you will see a card under ‘My shared apps’.
Here’s an example:
If you aren’t sharing any of your apps yet, see Distribute your apps.
We deprecated AP.host.getSelectedText in Jira and Confluence on Jan 11, 2022, due to security and privacy concerns.
Removal of this API has begun and is rolling out across all cloud instances.
To cause minimum disruption, all calls to this API will now return an empty string ("").
For full details, see the CDAC post.
The contextId field in the extension context of the Custom field type module is deprecated and replaced with configurationId. The new field contains the same value as contextId previously did.
We’re changing this up to avoid confusion around the nomenclature contextId, which may be mistakenly interpreted as the ID of a field context. Instead, we’re referring to the ID of a field configuration here.
The contextId field will be removed on Nov 1, 2022.