Preparing for Jira 9.6

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

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.

Crowd membership changes are now batched during full and incremental directory syncs

To improve the performance of Crowd membership changes, we’ve started batching them during full and incremental directory syncs. Besides, the requests for DirectoryManager lookups are now cached to boost the efficiency of the feature.

What’s supported?

During full and incremental directory sync, the following operations are supported:

• Bulk addition of nested group memberships to a group
• Bulk removal of nested group memberships from a group
• Bulk removal of user memberships from a group

How does DirectoryManager caching work?

ApplicationServiceGeneric.processUserMembershipEvent is used during incremental syncs and requires a significant amount of time when there are many membership changes. The EventTransformer class is used in parallel to enrich events with missing attributes by fetching parent groups, child groups, and users from calls to the directory via the DirectoryManager.

The result can be cached even when it’s fetched for the first time. The cached result can be used for subsequent calls to the directory, removing instances of duplicate calls to the directory for the same entry during syncs.

The cache size is 1000 by default. But you can change it with the crowd.directory.manager.cache.size property in the jira-features.properties file.

This cache works on the first oldest eviction policy using the accessOrder flag on LinkedHashMap. The improvement will only be seen during syncs where there are multiple calls for the same entry, but not where each call is distinct.

Can I disable the feature?

By default, batching and caching are enabled. You can disable them by making changes to or removing values in the jira-features.properties file.

Cache App API deprecated

We’ve deprecated the Cache App API endpoint and hidden it behind the com.atlassian.jira.cacheResource dark feature flag. If needed, you can enable it. In future versions, the endpoint will be removed permanently.

Cache App API wasn’t intended to be used to flush all caches and is considered unsafe to be used in a production environment.

You might have used this API endpoint to avoid a full shutdown. But the implication that the endpoint can have on Data Center may be equivalent to a full shutdown. Moreover, there’s no guarantee that an underlying issue will be fixed.

Now, for a cache flush event, we recommend performing a full restart. For Data Center, this means you should first shut down all nodes and then restart them.

Faster page load time for backlog and board views

As announced in Preparing for Jira 9.2, we’re making changes to how we bundle and serve client-side code in Jira Software, aiming to modernize the codebase and speed up page loading time in the app.

We plan to release these changes in Jira 9.7 and now finalizing all the received feedback. Please share with us any dependencies that your app has in Jira Software views (Board, Backlog, Reports, Configure board, and View all boards), especially on AMD modules or global variables. 

You can still let us know here: JSWSERVER-21430 - Getting issue details... STATUS

We’ll consider your front-end dependencies on Jira’s code to make sure that after the upgrade these changes won’t affect your apps’ work or there’ll be a clear migration path at least.

Upgrading the Backbone library to recent versions

We’re upgrading Backbone and Marionette versions used in Jira, aiming to support only three versions of the libraries across the entire Jira codebase. This will help us ship less code to our users and ensure better performance and security of the application.

What do you need to know?

We’re upgrading libraries to the following versions:

• Marionette 4.1.2
• Backbone 1.3.3 and 1.4.1

We’ve started making changes since Jira 9.5.0 and already upgraded several apps to Backbone 1.3.3 and 1.4.1. See a list of apps that contain upgraded Backbone and Marionette versions.

The change log of libraries that we are upgrading to:

• Backbone: Backbone.js
• Marionette:
  • Upgrade Guide from v3 to v4
  • Upgrade Guide from v2 to v3
  • Upgrade Guide

Jira apps with upgraded versions of libraries

In Jira 9.5, we’ve only made Backbone upgrades, bumping all the versions to 1.3.3.

In Jira 9.6, we’re making both Backbone and Marionette upgrades.

Further auditing improvements DATA CENTER

We’re making more progress in improving the coverage of audit logs across Jira Service Management. This time around, we’re adding logs that will let admins track events related to the customer portal, help center, and Assets. We’re also updating the categories of some existing audit logs. 

Learn more about audit logs in Jira Software and in Jira Service Management

Email channels support mailbox folders

We’ve improved the way email channels are set up. You’ll now be able to specify the name of the folder in your mailbox that you want Jira Service Management to monitor for incoming emails. This means that the mailbox that you’re using doesn’t have to have a folder named “Inbox” and even if it does — you don’t have to use it for your email channel needs. To use these new settings, head over to your project settings, then go to Email channels and either set up a brand new channel or update an existing one.

Learn more about receiving requests by email

Support for Assets referenced object fields in approvals

You now have more flexibility when setting up approvals in Jira Service Management. If you want to add approvers from Assets, you can use Assets referenced objects fields as a source for the names of your approvers. Previously, only three of the Assets custom field types were supported.

Learn more about adding approvers from Assets to requests in Jira

Linking issues no longer limited to agents

In service projects, linking issues that originate from different projects was previously only limited to licensed agents. This meant that if a user wanted to create an issue that would be linked to an issue from another project, they would need to be agents in both of these projects. We’ve removed this limitation and all users who have Create Issue and Link Issue permissions can now link issues between different projects.

Known issues

The following table lists the issues that you might face in Jira Software 9.6 and Jira Service Management 5.6. You’ll also find a workaround or temporary solution for each of them.

We are aware of these issues and have planned their resolution in future releases.