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

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

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.

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.

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.

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

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:

• Jira DC Front-end API Announcement
• Jira 9.2 changes to Agile front-end modules
• Jira 9.7 changes to Agile front-end modules

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

Available AMD modules

Code examples

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

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

// 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

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

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

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

New settings for Groovy scripts in Assets DATA CENTER

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

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

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

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.