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 Software Cloud.
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 have updated our security requirements for cloud applications, added new security requirements, and categorized requirements by app type and security requirement type. All cloud applications in the Atlassian Marketplace must adhere to the updated requirements by October 31, 2022.
Please see the blog post and FAQ page accompanying this announcement for more details, as well as this document for specific updates.
We’ve updated the Forge CLI to reflect the changes resulting from pausing the rollout of new scopes. Forge now supports classic and granular scopes. However, if your app doesn’t have all the scopes it needs, the Forge CLI suggests the recommended classic scopes instead of granular scopes.
Run npm install -g @forge/cli@latest on the command line to install the latest version of @forge/cli.
The following @forge/ui library features are being deprecated as of @forge/ui@1.1.0:
the CustomFieldEdit modal on the create issue dialog will be deprecated on Jun 20, 2022.
Run npm install @forge/ui@latest on the command line to install the latest version of @forge/ui.
We’ve added custom UI support for Jira dashboard gadgets built with Forge.
The jira:customField module on the create issue dialog will no longer offer a modal experience. Instead, the edit entry point will be rendered directly on the create issue dialog.
Run npm install @forge/ui@latest on the command line to install the latest version of the UI kit.
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.
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 made the @forge/jira-bridge package available for all Custom UI Jira extensions. This package enables extensions to open an issue create modal.
Also, the Jira admin page, Jira global page, Jira project page, and Jira project settings page extensions can use the package to open an issue view modal.
See the CreateIssueModal and ViewIssueModal documentation for more details.
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)
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 support for subpage rendering with Custom UI in several page modules. This change means you can split a Jira admin, global, project, or project settings page into several pages.
See the documentation of the supported modules – Jira admin page, Jira global page, Jira project page, and Jira project settings page – for more information. Also, the project subpages app provides an example of a subpages implementation for a Jira project module.
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.
Jira custom field and custom field type modules are now available on the new create issue dialog.
See Jira custom field and Jira custom field type documentation for more details.
We're deprecating AP.Host.getSelectedText in Jira and Confluence, due to security and privacy concerns. From Jul 11, 2022 this API will return an empty string ("") under all circumstances. See the CDAC post for full details.