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

Upgrading from 8.x to 9.x triggers full Jira reindex that causes some downtime during the process. If you’re on 8.x now, make sure you’ve estimated the downtime and set the best time for the upgrade.

Learn more about how to handle full reindex and estimate downtime

Quick info

Latest version

Here you can find information about the latest EAPs.

Application/Date numberVersion (Maven)Downloads

Jira Core/Software

 

9.6.0-RC01

9.6.0-m0005


Source files (Core)

Source files (Software)

Jira Service Management

 

5.6.0-RC01

5.6.0-m0005

Source files

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

StatusIMPLEMENTED (eap01)

AppsJIRA SOFTWARE

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.

Expand to see the list of corresponding properties and their values
PropertyDefault valueDescription
crowd.sync.nested.groups.
group.membership.changes.
batching.enabled
true
  • If enabled, the property uses methods that support bulk addition and bulk removal of nested groups.

  • If disabled, the property falls back to the default iterative approach for adding and removing nested groups.

crowd.sync.delete.user.
memberships.batching.
enabled
true
  • If enabled, the property uses new method that support bulk removal of nested groups.

  • if disabled, the property falls back to the default iterative approach for removing nested groups.

crowd.event.transformer.
directory.manager.cache
trueThe feature flag that enables caching of the DirectoryManager in the EventTransformer.
crowd.directory.manager.
cache.size
1000 (set by Crowd)Sets the size of the cache to be used by DirectoryManager.

Cache App API deprecated

StatusIMPLEMENTED (eap01)

AppsJIRA SOFTWARE

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

StatusIN PROGRESS (eap01)

AppsJIRA SOFTWARE

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

StatusIN PROGRESS (eap01)

AppsJIRA SOFTWARE

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.

New versions of Marionette include breaking changes. Check out the change logs and update your apps accordingly before proceeding with the upgrade.

The change log of libraries that we are upgrading to:

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.

Expand to view the list of apps with upgraded versions
AppBackbone
jira-inline-issue-create-plugin1.0.0 → 1.3.3
jira-issue-collector-plugin0.5.1 → 1.3.3
jira-fileviewer-plugin1.0.0 → 1.3.3
jira-user-profile-plugin1.0.0 → 1.3.3
jira-project-templates-pluginajs-backbone → 1.3.3

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

Expand to view the list of apps with upgraded versions
AppBackboneMarionette
atlassian-gadgets

1.0.0 → 1.3.3

ajs-backbone → 1.3.3

(error)

Jira core:

jira-webhooks-plugin

atlassian-webhooks-plugin

1.0.0 → 1.4.1

0.9.2 → 1.4.1

(error)
jira-mail-plugin1.0.0 → 1.3.3(error)

Jira core:

jira-admin-updates-plugin

1.0.0 → 1.3.31.6.4 → 4.1.2
jira-editor-plugin1.0.0 → 1.3.32.1.0 → 4.1.2
jira-importers-plugin1.0.0 → 1.4.1

1.6.4 → 4.1.2

Jira core:

jira-view-issue-plugin

(error)

2.1.0 → 4.1.2

Further auditing improvements DATA CENTER

StatusIN PROGRESS (eap01)

AppsJIRA SERVICE MANAGEMENT

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

StatusIMPLEMENTED (eap01)

AppsJIRA SERVICE MANAGEMENT

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

Status: IN PROGRESS (eap02)

AppsJIRA SERVICE MANAGEMENT

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

Status: IN PROGRESS (eap02)

AppsJIRA SERVICE MANAGEMENT

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.

IssueSolution

JIRA SOFTWARE Closed and completed sprints get automatically removed from the Sprint issue field when you’re moving issues to a new project.

Since Jira 8.8, all sprints in the status “Closed“ have been automatically removed from the Sprint issue field when the user is moving issues to a different project. The goal of this behavior has been to remove irrelevant sprints from the velocity report.

The user isn’t notified about the removal of closed or completed sprints, which results in data loss.

Although now, the user can decide whether irrelevant sprints should display in the velocity report, the issues of data loss and insufficient transparency of the system behavior remain.

This is a known issue tracked in the ticket JSWSERVER-13333 - Getting issue details... STATUS

We’ve come up with the following solutions for the issue and would like to know your opinion on them:

  1. When moving issues to another project, you’ll be able to choose whether you want to keep or remove closed or completed sprints in them. Vote for this solution and leave your feedback in JSWSERVER-11992 - Getting issue details... STATUS

  2. Before moving issues to another project, you’ll be able to manually remove closed or completed sprints from them. Vote for this solution and leave your feedback in JSWSERVER-15615 - Getting issue details... STATUS

We’ll consider your feedback to develop and implement the optimal solution.

Last modified on Jan 18, 2023

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.