Jira 9.7 への準備

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

8.x から 9.x へのアップグレードでは Jira の完全な再インデックスがトリガーされるため、プロセス中にダウンタイムが発生します。現在 8.x をご利用の場合、ダウンタイムを予測したうえでアップグレードに最適な時間枠を選ぶようにしてください。

完全な再インデックスやダウンタイムの予測方法の詳細の確認

概要

最新バージョン

ここでは最新の EAP についての情報をご案内します。

Application/Date Number (番号)バージョン (Maven)ダウンロード

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

ソース ファイル

変更の概要

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

ボード

gh-rapid-common or
gh-rapid

gh-rapid-work

バックログ

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

レポート

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
コー​​ドの例
<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>

トラブルシューティング

問題

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.
ソリューション
  • 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

アプリ

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

アプリ

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

Jira Service Management における承認が更新され、新しい機能が追加されました。承認者がリクエストで [承認] または [却下] を選択すると、トランジション画面が表示されるようになりました。新しい画面に、その決定を説明するコメントを残すことができます。今回のリリースでは、カスタマー ポータルとエージェント ビューでリクエストを承認すると、トランジション画面が表示されます。

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 の変更点:

  • ApprovalService が拡張され、コメント付きの承認に回答するためのメソッドおよび承認リクエストの設定を取得するためのメソッドの 2 つが追加されています。

Jira Service Management での承認の設定の詳細をご確認ください。

承認のための必須コメントは、Jira Data Center および Server モバイル アプリではまだサポートされていません。

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.

更新された設定 (および既存の設定) を使用するには、[管理] > [アプリの管理] > [アセット スクリプト設定] に移動します。

アセットにおける Groovy スクリプトの詳細をご確認ください。

アセットのパフォーマンス改善

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.
  • インポート設定プロセスが変更され、既定では自動同期が無効になっています。そのため、インポート ジョブについて十分な情報に基づいて決定を下すことができます。
  • 一意の属性を持つオブジェクトをインポートする際のパフォーマンスが向上しています。
  • オブジェクト グラフの力学ビューのパフォーマンスが向上しています。

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.

アトラシアンが提供したデータは、Jira Service Management に固有のエンティティに焦点を当てています。Jira と共有するガードレールを探している場合は、Jira Software のガードレールをご確認ください

Jira Service Management のガードレールの詳細をご確認ください。

弱視やキーボードのみのユーザーのアクセシビリティを向上

Status: IMPLEMENTED (eap01)

Apps: JIRA SERVICE MANAGEMENT

このリリースでは、スクリーン リーダーやキーボードのみで操作を行うユーザーのエクスペリエンスが改善され、このようなユーザーが Jira Service Management で基本タスクを実行できるようアクセシビリティが修正されています。ここでは、一部の修正を取り上げています。

  • ボタンやリンクにロール、名前、href 値などの属性が追加され、キーボードのみのユーザーやスクリーン リーダーのユーザーがアクセスできるようになりました。
  • ボタンや展開可能なアイコンなどのいくつかの要素のフォーカス インジケーターとそのカラー コントラスト比が修正されました。
  • [新しいオブジェクトを作成] モーダル ダイアログの [さらに作成] チェックボックスが更新され、ロール属性と状態属性が追加されました。

解決された問題の全リストをご確認ください。

サポート終了のお知らせ

SQL Server 2016

Jira 9.7 では、SQL Server 2016 のサポートが完全に終了します。サポート終了とは、Jira 9.7 以降、アトラシアンがこのプラットフォームに関連するバグの修正を行わないことを意味します。

同時に、アトラシアンは SQL Server 2017 と SQL Server 2019 のサポートを継続します。

Java 8

今後のリリースでは Java 8 のサポートが停止される予定です。ただし、Java 8 の廃止が正式に発表されるまでは Jira 9.7 と併用できます。

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

最終更新日 2023 年 4 月 20 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.