Preparing for Jira 8.22

This documentation is intended for Jira developers who want to ensure that their existing apps are compatible with Jira 8.22 

Summary of changes

In this section we'll provide an overview of the changes we intend to make, so you can start thinking how it might impact your apps. Once they're ready, we'll indicate when a change has been implemented, and in which milestone. 

Configure Jira as an OAuth 2.0 provider

Status: IMPLEMENTED (eap 01)

To complete our OAuth 2.0 functionality, we’ve now added a way to configure Jira as an OAuth 2.0 provider, allowing you to exchange data with external applications in both directions – either by giving external applications access to Jira data or letting Jira request data from these applications.

That’s an addition to the OAuth 2.0 client functionality that we introduced in Jira 8.10. You can configure your OAuth 2.0 integrations in Administration > Application links. We’ve also used this opportunity to improve the user experience around application links.

Changes to current OAuth 2.0 client integrations

OAuth 2.0 client integrations used to live in the OAuth 2.0 page in Administration. We’ve now moved them to application links where you can manage your current integrations and create new ones. No action is required from users.

Configuring Jira as an OAuth 2.0 provider

If you’d like to switch to using OAuth 2.0, you’ll most likely need to update your current integrations that use OAuth 1.0 or build new ones, compatible with Jira. To understand what OAuth 2.0 flows are available and what data you need, see the details of our OAuth 2.0 provider implementation in Jira OAuth 2.0 provider API.

Configuring OAuth 1.0 integrations

We’ve kept the original OAuth 1.0 mechanism coming from application links so current integrations continue working. You can create new integrations in application links by selecting the Atlassian product option (works both for Atlassian products and external applications) and pasting the URL like before.

Popper replaces Tipsy in AUI 9.3.5

Status: IMPLEMENTED (eap 01)

We’ve upgraded AUI to version 9.3.5, which replaces the Tipsy tooltip generation library with Popper. To make sure that your tooltips still work with the upgraded AUI, you may need to make some changes:

• AUI no longer supports the data-tooltip attribute. Instead, use the title attribute on the element to which a tooltip should be attached.

• Tooltips will appear even if the title is empty. To prevent that from happening, destroy the tooltip by calling the $el.tooltip('destroy') function.

• To pass HTML markup to the tooltip, call $el.tooltip({ html: true }).

Replace the tipsy.revalidate() method with $el.tooltip('destroy').

Web Resource Management 5.0

Status: IMPLEMENTED (eap 01)

Web Resource Management (WRM) is a tool that takes care of serving static assets for the whole Jira, including plugins. With the upgraded version we can provide better page loading performance.

What’s changed?

You can find all WRM-related changes here: CHANGELOG.md

User login process performance improvements

Status: IMPLEMENTED (eap 01)

We've improved the basic authentication process. Authentications are now cached inside Jira for 15 minutes or until first unsuccessful attempt. This will improve the performance and reduce the load on external directories.

What do I need to know?

If for any reasons you decide to change the default session timeout to value lower then 15 minutes, you need to update the system property com.atlassian.jira.user.crowd.service.authenticate.cache.minutes accordingly. There’s no need to do it if session timeout has been reduced due to performance reasons (e.g. on “rest nodes” where you want to recycle sessions faster).

XStream 1.4.17 vulnerability mitigation

Status: IMPLEMENTED (eap 01)

We've upgraded com.thoughtworks.xstream to version 1.4.18. XStream is a library used for serialization/deserialization of Java objects to/from XML. This update limits the range of types that can be serialized/deserialized to increase security. The update can impact custom fields in apps, as their default values are stored as XML in the database. There is a very small chance that the newly blocked types are part of your default values, so please make sure that your custom fields still work correctly.

Multiple email channels (Data Center)

Status: IMPLEMENTED (eap 01)

App: JIRA SERVICE MANAGEMENT

Previously released as a Beta feature, multiple email channels are now fully implemented in Jira Service Management. You can now configure as many dedicated email channels as you need for better communication with customers. Their emails will turn into requests or comments, personalizing and speeding up the process.

SLA configuration interface (Data Center)

Status: IMPLEMENTED (eap 01)

App: JIRA SERVICE MANAGEMENT

We’re introducing a brand new SLA configuration interface so that all settings related to SLAs live in the same space for easier management and monitoring. The new interface enables the configuration of:

• SLA names permissions

• debug log details and cleanup method

• SLA time format

Auto-populated request fields (Data Center)

Status: IMPLEMENTED (eap 01)

App: JIRA SERVICE MANAGEMENT

From now on, you’ll be able to generate URLs that will automatically populate selected request fields. To save customers from filling it all out from scratch, you can use the outside contextual data and bring the details over to Jira Service Management.

What do I need to know?

URLs can fill in the following field types: