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 deprecated OAuth 2.0 (3LO) authentication for site URIs (i.e. *.atlassian.net) in Jira Cloud platform, Jira Software Cloud, and Jira Service Management Cloud.
All OAuth 2.0 (3LO) requests should be made through api.atlassian.com by 14 November 2022. After this date, OAuth 2.0 (3LO) requests using site URIs will fail. See the OAuth 2.0 documentation for details of how to construct api.atlassian.com URIs.
We’ve added 5 new operations that enable you to create, update, and delete statuses as well as get statuses in bulk using their IDs and search statuses by name or the project they used in.
The 5 new operations are:
Bulk create statuses – Creates statuses for a global or project scope.
Bulk update statuses – Updates statuses by ID.
Bulk delete statuses – Deletes statuses by ID if they're not being used.
Bulk get statuses – Returns a list of the statuses specified by one or more status IDs.
Search statuses paginated – Returns a paginated list of statuses that match a search on name or project.
The bulk get statuses and search status paginated operations include an expand option that returns details of the project and issue types that use the statuses.
On 22 February, we announced the availability of new scopes for Forge and OAuth 2.0 (3LO) apps. Following concerns raised by our developer community, we have now paused the deprecation of classic scopes and removed the requirement to transition your app to new scopes by 23 August 2022.
There is no action for you to take regarding your app scopes at this stage. Apps using either classic or new scopes can continue to do so. For those that haven’t adopted new scopes yet, please continue using classic scopes – we’ll let you know when you can start transitioning.
FAQ
Q1: I have already updated my app with new scopes. Will it stop working now?
A1: Your app will continue to work with new scopes. There is no need for you to make any further changes.
Q2: Am I going to need to roll back to the classic scopes?
A2: You do not need to roll back to classic scopes.
Q3: Does this mean the new scopes are not be reliable?
A3: Using new scopes is in no way less reliable than classic scopes. Both new and classic scopes are equally as reliable to use for your app.
Q4: Will I have to update to another, newer set of scopes?
A4: We have now started a review process of the new scopes and intend to run extensive usability studies with our partners. Once we have more clarity on the best solution, we will update you via the changelog and developer community.
We’ve introduced the jira:entityProperty Forge module. This module enables entity properties to be indexed, so their values are available to search using JQL. The module is available as part of the Early Access Program (EAP). The dedicated Forge Jira entityProperty EAP Atlassian Developer Community space is available for your feedback and bug reports.
See the Jira entity property reference documentation for more details.
We’re working on changing REST APIs that have a group name field. The group ID field will be added along with group name. This change will likely occur by July 2022.
You may already start seeing this change in some Public APIs. The documentation will be updated when the change is made.
Both group ID and group name will be:
Present in the API response. For example, in the “Get all application roles” API, the response will contain a group ID.
Accepted as query parameter/ request body. For example, in the “Bulk get groups” API, it will accept group ID.
An improvement will be made in the coming days to allow customers (site admins) to turn off (or back on) end-user installation capabilities for OAuth 2.0 (3LO) apps. If you are a developer of OAuth 2.0 (3LO) apps, you do not need to take any action as a result of this change, as this message is only to communicate the impact to the customer.
Previously, controls were not in place for an admin to block their users from installing 3LO apps. Adding the ability for an admin to prohibit users from installing 3LO apps now aligns more closely to how a user would install any other, non-3LO apps on the Marketplace. This functionality was requested by several Atlassian enterprise customers to gain increased control over where their data is shared and which apps have access to their instance. By allowing admins to control end-user app installs, we are making it possible for more enterprise customers to move to cloud. Once in cloud, these companies will not be blocked from installing 3LO apps, because admins will retain the ability to vet and install the apps at their discretion.
Figure (a) below demonstrates the section of the customer’s admin console where they will now be able to block their users from installing 3LO apps. Figure (b) below shows the new experience when a customer tries to install a 3LO app after their admin has disabled this function.
If a customer attempts to install a 3LO app after their admin has disabled this function, the following error message will appear:
App is blocked by an admin
An admin has not allowed [App Name] to access data from [Your Atlassian Instance] . Select another site to authorize access to or contact your admin for more information.
(a)
(b)
You can now define custom search suggestion providers in Jira custom field and custom field type modules.
See the Jira custom field and Jira custom field type documentation for more details.
We’ve removed and replaced the deprecated field and query param contextId in the Issue custom field configuration (apps) operations.
You should now use:
id — the ID of the configuration entry, which behaves in the same way as the removed contextId. Note, this is not the ID of the field context the configuration is associated with, as might have been suggested by the previous name.
fieldContextId — a reference to the field context ID the configuration is associated with.
The reason for this change is that while contextId was intended to be a reference to a field context ID, in some cases, it wasn't. The field fieldContextId serves this purpose now.
The straightforward way of updating your app is to replace contextId with id, making everything work the same as before. However, do check whether fieldContextId is the field that you should be using.
We’ve introduced the jira:dashboardGadget Forge module as part of the Early Access Program (EAP). With this module, you build dashboard gadgets with UI Kit using Forge. Custom UI support is planned.
The dedicated https://community.developer.atlassian.com/t/about-the-forge-module-jira-dashboardgadget-eap-category/56527 Atlassian Developer Community space is available for your feedback and bug reports.
See the Jira dashboard gadget reference documentation for more details.
All Connect app installs and upgrades will receive a new install payload with a new secret.
installed lifecycle eventYour app may receive installed callbacks in different circumstances. When this occurs, handle the clientKey and/or sharedSecret accordingly:
App installation - A new sharedSecret is created for each installation. When callback is successful, an enabled lifecycle callback event will be sent.
App upgrade - A new sharedSecret is created for every app upgrade. When callback is successful, an enabled lifecycle callback event will be sent.
Secret rotation - A new sharedSecret is created, installed app version does not change for the site.
Site rename - App receives an installed lifecycle callback with a new baseUrl (Atlassian site)
App install following Site Import - New clientKey and sharedSecret are created and shared. If there's an existing installation record for a site (Atlassian product's baseUrl) under a different clientKey, your app should associate the site with the new clientKey and the sharedSecret.
For more information, please see:
We've introduced a value function for Jira custom field and custom field type modules. This function computes the value of a field during the initial render of the page. For example, you could populate the field with the last person to comment on an issue or determine a default value based on information in the issue.
See the Jira custom field and Jira custom field type documentation for more details.
In the coming months, we’ll be replacing the Jira issue glance module with a new Jira issue expandables module. This will improve the way apps are displayed in Jira’s new issue view.
If you’ve been using the Jira issue glance module in your Forge or Connect app, once the new module becomes available, you’ll have 6 months to replace the jiraIssueGlances and jira:issueGlance module definition in your app descriptor.
The original OAuth scopes for Forge and OAuth 2.0 (3LO) apps on Confluence Cloud, Jira Cloud platform, and Jira Service Management Cloud are deprecated.
All Forge and OAuth 2.0 (3LO) apps must use the new scopes by 23 August 2022 PDT / 24 August 2022 AEST. After this date, only apps using the new scopes will function as expected, as the original scopes will have been removed.
See the following documentation for more details:
Jira Cloud platform scopes for OAuth 2.0 (3LO) and Forge apps
Jira Service Management Cloud scopes for OAuth 2.0 (3LO) and Forge apps
Run npm install -g @forge/cli@latest on the command line to install the latest version of @forge/cli.
We’re introducing new scopes for Forge and OAuth 2.0 (3LO) apps that run on Jira Cloud platform, Jira Software Cloud, and Jira Service Management Cloud. This change is part of an Atlassian initiative to enhance security and build customer trust.
The new scopes provide administrators and users with finer-grained information about the data apps can access, enabling them to make better decisions about installing apps.
See the following documentation for more details:
We’ve updated the Forge Jira issue glance so you can use an icon to represent the issue glance status. Jira Cloud also adds support for dynamic properties that enable runtime updates to the issue glance status.