Jira 9.6 への準備

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

変更の概要

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

Crowd メンバーシップ変更のパフォーマンスを改善するために、ディレクトリの完全同期/インクリメンタル同期中に変更を一括処理するようになりました。また、機能の効率性を高めるため、DirectoryManager のルックアップ リクエストがキャッシュされるようになっています。

サポート内容

ディレクトリの完全同期やインクリメンタル同期中に次の処理がサポートされます。

• グループへのネスト グループ メンバーシップの一括追加
• グループからのネスト グループ メンバーシップの一括削除
• グループからのユーザー メンバーシップの一括削除

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 の廃止

Cache App API エンドポイントを廃止し、com.atlassian.jira.cacheResource ダーク機能フラグの背後に設定しました。これは必要に応じて有効化できます。このエンドポイントは今後のリリースで永続的に取り除かれます。

Cache App API はすべてのキャッシュをフラッシュするための利用は想定されておらず、本番環境で利用するには安全ではないと判断しました。

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.

今後はキャッシュをフラッシュする際には完全な再起動を行うことを推奨します。Data Center 版では一度すべてのノードをシャットダウンし、その後それらを再起動します。

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.

ご確認いただきたい内容

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

メール チャンネルでメールボックス フォルダーをサポート

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.

メールでのリクエスト受信の詳細を確認

Support for Assets referenced object fields in approvals

Jira Service Management で承認をセットアップする際にさらなる柔軟性を活用できるようになりました。アセット機能から承認者を追加したい場合に、承認者の名前の取得元としてアセット機能が参照するオブジェクト フィールドを利用できます。これまではアセットのカスタム フィールド タイプは 3 つのみサポートされてました。

Jira でアセット機能からリクエストに承認者を追加する方法を確認

エージェント以外も課題をリンク可能

これまで、エージェントのみがサービス プロジェクトで別のプロジェクトの課題と課題をリンクできていました。つまり、ユーザーが別のプロジェクトの課題とリンクする課題を作成したい場合に、両方のプロジェクトのエージェントになる必要がありました。この制限をなくしたため、課題の作成および課題のリンク権限を持つすべてのユーザーが異なるプロジェクト間で課題をリンクできるようになりました。

既知の問題

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.

当社ではこのような問題を認識しており、今後のリリースでの解決を予定しています。