Preparing for Jira 9.7

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

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.7.0-RC01

9.7.0-m0005


Source files (Core)

Source files (Software)

Jira Service Management

 

5.7.0-RC01

5.7.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.

Deprecating API endpoints for accessing avatars and issue attachments DATA CENTER

Status: IN PROGRESS (eap01)

Apps: JIRA SOFTWARE JIRA SERVICE MANAGEMENT

In this release, we’re deprecating several API endpoints related to Jira attachments and avatars.

These changes are made as part of a major update planned for Jira 10 — introducing the support of Amazon S3 to store attachment and avatar files, instead of keeping them locally in the <sharedhome> directory.

As we stop supporting deprecated endpoints in Jira 10 or earlier, some features may no longer be available or may change. We encourage you check the upcoming changes to the API and start preparing your applications in advance.

Deprecated API methods and recommended actions

The following endpoint is being deprecated in Jira 9.7 and will be removed from the API before Jira 10.

Deprecated endpointAlternative endpointRecommended action
AvatarManager#
getAvatarBaseDirectory()
Not providedUse AvatarManager#readAvatarData() to access avatar data directly.

If you don't plan to migrate to S3 for storing avatars before Jira 10, you can still use the AvatarManager#getAvatarBaseDirectory() endpoint until it's permanently removed from the API. However, once you migrate to S3 as an avatar storage method, you can no longer use this endpoint and it’ll return the “unused directory” response.

The following endpoints are deprecated in Jira 9.7. You can still use them until we completely remove these endpoints from the API in Jira 10.

Deprecated enpoint

Alternative endpoint

Recommended action

AttachmentPathManager

Not provided

Use the methods available in AttachmentManager to create/read/delete attachment data directly. For the settings related methods, use the new endpoints provided in AttachmentConfigManager.

AttachmentConfig

AttachmentConfigManager
#getTemporaryAttachment
Directory()

Use the alternative endpoint.

AttachmentManager
#attachmentsEnabled()

AttachmentConfigManager
#isAttachmentsEnabled()

Use the alternative endpoint.

What if your application stores files in the Jira home, in attachments and avatar directories?

Though we don't recommend storing application-related files in Jira’s attachments and avatar data directories, we understand that some applications might keep their data there.

If your application stores files in the directories provided by AvatarManager#getAvatarBaseDirectory() or AttachmentPathManager#getAttachmentPath(), you’ll need to replace these method calls with hardcoded references to the relevant directory path. You can use JiraHome#getHome() to find the base home directory. There are currently no plans to migrate app data to S3, so it will remain safe to access files created by your application via the file system.

Performance improvements on jira-agile pages DATA CENTER

Status: IN PROGRESS (eap01)

Apps: JIRA SOFTWARE

These updates contain some breaking changes, make sure that you prepare your apps in advance. See Required updates for guidelines. 

Going forward with the Jira codebase optimization, we’re introducing another batch of updates to make jira-agile pages faster and more performant. With these changes altogether, we're building a foundation for further client-side performance improvements.

Read more about the changes and why we decided to proceed with the current approach:

Introduced breaking changes

  • We are now exposing only a small subset of previously available AMD modules.
  • We’ve left global variables intact. However, they are also non-API parts and we don’t recommend using them in your apps.

We’re gathering feedback on the usage of jira-agile AMD module names for another week, so you can still share your use cases. Comment on this ticket:  JSWSERVER-21430 - Getting issue details... STATUS  or under related Community posts: Topics tagged j9-frontend-api. We’ll consider every case to prepare better contracts for Jira Agile modules.

Required updates

If your app uses an Agile module, it’s important to make the dependency explicit and don’t rely on transitive dependencies. The following table provides examples of how you can express those dependencies and put the app’s code in the appropriate place.

WR keys and contexts
Expand to view the details

Agile page

web-resource key
(for the full web-resource key prepend com.pyxis.greenhopper.jira: to each entry)

web-resource context

Board

gh-rapid-common or
gh-rapid

gh-rapid-work

Backlog

gh-rapid-common or
gh-rapid

gh-rapid-plan

Board or backlog with open issue details view

entrypoint-jira-agile-issue-details-view

gh-rapid-detailsview

Printing cards from board or backlog

entrypoint-gh-cards-printing

gh-cards-printing

Reports

entrypoint-jira-agile-reports

gh-rapid-report

Configure board

gh-rapid-config

gh-rapid-config

Manage boards

entrypoint-gh-manage-boards

gh-manage-boards

Software gadgets or dashboard

gh-gadget-common or
gh-gadget-rapid-view-resources

atl.dashboard (it’s not needed when using <dashboard-item> with <web-resource-key> and <amd-module> elements)

Cases for using a dependency on a web-resource key or putting the app's web-resource into the context:

  • use a dependency on a web-resource key when the app's code uses Jira's code. For instance, it calls an AMD module or a global variable.

  • use a web-resource context to load the app’s code on a desired page.

Use both to satisfy both cases at the same time.

Your app should use the most suitable context, such as gh-rapid-plan for Backlog (not atl.general). This is necessary for not polluting other pages with excessive JavaScript code, leading to bloated page weights and potential side-effects.

Available AMD modules
Expand to view the details

Module

Path to import AMD module

web-resource key

BacklogController

jira-agile/rapid/ui/plan/backlog-controller

  • gh-rapid

PlanController

jira-agile/rapid/ui/plan/plan-controller

  • gh-rapid

PlanControls

jira-agile/rapid/ui/plan/plan-controls

  • gh-rapid

PlanDragAndDrop

jira-agile/rapid/ui/plan/plan-drag-and-drop

  • gh-rapid
  • gh-gadget-rapid-view-resources

SprintBacklogView

jira-agile/rapid/ui/plan/sprint-backlog-view

  • gh-rapid
  • gh-gadget-rapid-view-resources

SprintView

jira-agile/rapid/ui/plan/sprint-view

  • gh-rapid
  • gh-gadget-rapid-view-resources

backlog-model

jira-agile/rapid/ui/plan/backlog-model

  • gh-rapid
  • gh-gadget-rapid-view-resources

State

jira-agile/rapid/state/State

  • gh-rapid
  • gh-rapid-config
  • gh-rapid-common
  • gh-gadget-rapid-view-resources

Rapid Util

jira-agile/rapid/util

  • gh-core
  • gh-rapid-config

Rapid Validation

jira-agile/rapid/validation

  • gh-core
  • gh-rapid-config

KanPlanFeatureService

jira-agile/rapid/ui/kanplan/kan-plan-feature-service

  • gh-rapid
  • gh-gadget-rapid-view-resources

InlineEditField

jira-agile/rapid/configuration/inline-edit-field

  • gh-rapid
  • gh-rapid-config
  • gh-gadget-rapid-view-resources

inlined-code

jira-agile/lib/jquery/inlined-code

  • gh-rapid
  • gh-jquery-ui
  • gh-rapid-common
  • gh-core

ColumnConfig

jira-agile/rapid/configuration/column-config

  • gh-rapid-config
rapid-view-configjira-agile/rapid/rapid-view-config
  • gh-rapid
Code examples
<dependency> tag in a plugin xml inside the app's web-resource element

In this example, app-logic-relying-on-jira-agile-modules web-resource will be loaded with com.pyxis.greenhopper.jira:gh-rapid-common web-resource loaded first. The specified useResourcesFromJSW.js will come later.

<web-resource key="app-logic-relying-on-jira-agile-modules" ...>
  ...
  <dependency>com.pyxis.greenhopper.jira:gh-rapid-common</dependency>
  ...
  <resource type="download" name="useResourcesFromJSW.js" location="useResourcesFromJSW.js"/>
  ...
</web-resource>

There's a guarantee that the app's code (useResourcesFromJSW.js) will execute after any <dependency> code.


<context> tag in a plugin xml inside the app's web-resource element

In this example, app-logic-being-loaded-on-Backlog web-resource will be loaded whenever gh-rapid-plan context is loaded on the page.

<web-resource key="app-logic-being-loaded-on-Backlog" ...>
  ...
  <context>gh-rapid-plan</context>
  ...
</web-resource>

There's no guarantee that the app's code will execute after any code included in gh-rapid-plan context.

You need to use the <dependency> tags to ensure the order. If the app's logic calls Jira's code, we recommend adding the explicit <dependency> on the desired web-resource, or at least using an additional guard or delay when calling Jira's code.

However, keeping the context only is completely fine when you just want to load your app's code on a desired page, with logic independent from Jira’s code.

We also recommend splitting the app’s code into the init chunk that’s loaded on the page load, either required explicitly or via context. The rest of the app’s code should be lazy-loaded using client or other techniques.

Expand to view the details
// init-chunk.js

// import/require necessary assets, such as critical path  or 
// lazy-load the rest via, for example:
// a) wrm/require - when lazy-loading another web-resource or context
// b) wrm/require-lazily - as above, but in the Interaction phase
// c) dynamic import - when lazy-loading your code, depending on your build and bundler
// atlassian-plugin.xml - then, in the 'app-init' web-resource let's include only that init-chunk.js
// a note: if you're using atlassian-webresource-webpack-plugin, no need to write anything in atlassian-plugin.xml
//         you'd create the entry(point) pointing at the init-chunk.js and specify `gh-rapid-plan` in the 'contextMap' setting

<web-resource key="app-init" ...>
  ...
  <context>gh-rapid-plan</context>
  ...
  <resource type="download" name="app-init-chunk.js" location="init-chunk.js"/>
</web-resource>

Troubleshooting

Problem

Getting an empty object or undefined for a certain global variable, AMD module, or a dependency instead of a properly filled object.

Potential causes
  • A missing dependency on Jira’s code.
  • There’s a circular dependency, emerging from a different Agile dependency graph that’s altered by apps' dependencies on Agile’s code. It has the potential to break a built-in Agile screen or the app functionality.
Solutions
  • Revisit assets' dependencies in your app as well as dependencies between your app’s and Agile’s code.
  • Split the app’s code to the init chunk, with minimal dependencies on Agile's code, and lazy-load remaining code. This should help with restoring the dependency graph to its working state.

Let us know about the problems in this ticket: JSWSERVER-21430 - Getting issue details... STATUS  Make sure to provide enough information so we can reproduce the issue.

Backbone library upgrades

Status: IN PROGRESS (eap01)

Apps: JIRA SOFTWARE JIRA SERVICE MANAGEMENT

These updates contain some breaking changes, make sure that you prepare your apps in advance. See Breaking changes and required updates for guidelines.

As we proceed with Jira performance improvements and security updates, more Jira-bundled apps get newer versions of Backbone and Marionette.

Expand to view the list of apps with upgraded Backbone versions

App

Backbone

Jira Software: Jira bamboo plugin

1.0.0 → 1.3.3

Jira Core: Jira frontend plugin

1.0.0 → 1.3.3

Jira Core: jira-gadgets-plugin

1.0.0 → 1.3.3

workflow-designer-plugin

1.0.0 → 1.3.3

Jira Core: jira-project-config-plugin

1.0.0 → 1.4.1

jira-projects-plugin

1.0.0 → 1.4.1

Jira core

1.0.0 → 1.3.3

Jira Software: Jira agile

1.0.0 → 1.3.3

Expand to view the app with upgraded Marionette version

App

Marionette

workflow-designer-plugin

1.1.0 → 4.1.2

Jira mobile gets upgrades as well! Jira mobile gets upgrades as well! As part of Backbone library updates, we’re upgrading Backbone to 1.4.0 and Underscore to 1.13.1, which are provided by .

Breaking changes and required updates

This version contains breaking changes to the Jira WebResourceManager:

  • Since Jira 9.7, the <jira.webresources:ajs-backbone-amd-shim> from <web-resource key="util">  will be no longer available.
  • To ensure that your apps work correctly with Backbone 1.3.3, update the <web-resource key="util"> to use <jira.webresources:backbone-1.3.3> instead.

Enhance your approvals with comments DATA CENTER

Status: IN PROGRESS (eap01)

Apps: JIRA SERVICE MANAGEMENT

We’re refreshing approvals in Jira Service Management and adding a new feature. Approvers will now see a transition screen after they select Approve or Decline on a request. They’ll be able to leave a comment explaining their decision on the new screen. In this release, the transition screen will appear when approving requests in the customer portal and the agent view.

Commenting on approvals comes with an extra perk—making the comments required. Jira admins will have access to new settings when editing or adding approval steps in workflows. By selecting the Comment required when approving and Comment required when declining checkboxes, you’re guaranteed to get some important input from approvers.

To accommodate the changes we’re making to approvals, we’re also updating our API and Java API.

Rest API changes:

  • The Answer approval endpoint (POST /rest/servicedeskapi/request/<issue-key>/approval/<approval ID>) is getting two new optional fields, comment and commentPublic (a boolean), to approve a request with a scope-specified comment.
  • We're adding a new endpoint to get approval configuration by approval ID (GET /rest/servicedeskapi/request/<issue-key>/approval/<approval ID>/config), which you can use to get information about the comment configuration for an approval.

Java API change:

  • We're extending ApprovalService with two new methods to answer an approval with comment and retrieve the configuration of the approval request.

Learn more about configuring approvals in Jira Service Management

Mandatory comments for approvals are not supported in the Jira Data Center and Server mobile app yet.

New settings for Groovy scripts in Assets DATA CENTER

Status: IMPLEMENTED (eap01)

Apps: JIRA SERVICE MANAGEMENT

With our updates to the Groovy script settings, Jira system admins can now choose who has access to the Assets script console. You can limit access to Jira system admins only, or to both system admins and Jira admins. The new settings will let you have more control over who can execute the scripts in your instance.

To use the updated settings (and previously existing ones, too), go to Administration > Manage apps > Assets script configuration.

Learn more about Groovy scripts in Assets

Performance improvements in Assets

Status: IMPLEMENTED (eap01)

Apps: JIRA SERVICE MANAGEMENT

We’re constantly striving to enhance the performance and reliability of Assets. In this release, we tackled the first subset of a series of improvements we’re planning to ship. The main focus of these improvements is Assets imports. Here’s an overview of the updates we’re making in this release:

  • We’ve implemented a new method of calculating the import, so that it’s shared across all import configurations.
  • We’ve ensured that the doesn’t time out when waiting for bulk deletions.
  • We’ve changed the import configuration process and disabled automatic synchronization by default, letting you make informed decisions about your import jobs.
  • We’ve improved the performance of importing objects with unique attributes.
  • We’ve improved the performance of the Force view of object graphs.

Guardrails for Jira Service Management DATA CENTER

Status: IMPLEMENTED (eap01)

Apps: JIRA SERVICE MANAGEMENT

In an effort to give you more information about getting the best performance out of your Jira Service Management instance, we’ve recently published our Jira Service Management guardrails. Read the document to learn more about our recommendations, which are designed to help you identify potential risks and aid you in making decisions about the next steps in your instance optimization journey. We’ll guide you through assessing the current state your instance is in, and we’ll show you how to reduce the risk of potential problems.

We tested these guardrails with our latest Long Term Support release, Jira Service Management 5.4. We’ll update the document for each LTS release.

The data we provided is focused on entities that are unique to Jira Service Management. If you’re looking for guardrails that are shared with Jira, check out Jira Software guardrails.

Learn more about Jira Service Management guardrails

Accessibility improvements for low-vision and keyboard-only users

Status: IMPLEMENTED (eap01)

Apps: JIRA SERVICE MANAGEMENT

This release contains more accessibility fixes for our screen reader and keyboard-only cohort to improve their experience and ability to perform basic tasks in Jira Service Management. We’ve highlighted some fixes you can expect:

  • We’ve added attributes like roles, names, and href values to buttons and links, making them accessible for keyboard-only and screen reader users.
  • We’ve fixed the focus indicator as well as its color contrast ratio for several elements like buttons and expandable icons.
  • We’ve updated the Create another checkbox in the Create new object modal dialog by adding the role and state attributes.

Check out the full list of fixed issues

End of support announcements

SQL Server 2016

In Jira 9.7, we’re permanently removing support for SQL Server 2016. End of support means that we won’t fix bugs related to this platform in Jira 9.7 and later.

At the same time, we continue supporting SQL Server 2017 and SQL Server 2019.

Java 8

We’re planning to stop supporting Java 8 in upcoming releases. You can use it with Jira 9.7 until we announce the deprecation of Java 8.

Follow the updates in supported platforms and the announcements about the end of platform support.

Last modified on Apr 20, 2023

Was this helpful?

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