Jira Service Management 5.15.x リリース ノート

Jira Service Management リリース ノート

このページの内容

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

さらに読む

Jira Service Management 5.15.x のアップグレード ノートで、当該リリースに関する重要な詳細情報をご確認ください。また、解決済みの課題の完全なリストをご確認ください。

互換性のあるアプリケーション

互換性のある Jira アプリケーションをお探しの場合、次のページをご参照ください。

Jira Service Management 5.15.0 and 5.15.1 are affected by a bug, which causes random values to appear in the Assets custom field. We're working on fixing this issue in an upcoming bufgix release. More information about this issue is available under the following link:

JSDSERVER-15255 - 課題情報を取得中... ステータス

使用されていないアセット オブジェクトをアーカイブ

対象: 管理者

Declutter your instance and improve the performance of object searches by archiving the assets you no longer need. Previously, you had to permanently delete objects when your available index memory was low to make room for new objects. Now, you can archive objects instead. If you accidentally archive any objects, you can always restore them. Learn more about archiving objects

オブジェクトをアーカイブするには、次の手順を実行します。

  1. アセット マネージャー、アセット管理者、または Jira 管理者としてログインします。
  2. オブジェクトにナビゲートし、[その他のオプション] メニューから [アーカイブ] を選択します。

意図せずアーカイブしてしまったオブジェクトを復元したい場合は、次の手順を実行します。

  1. 上部のナビゲーション バーで、[アセット] > [アーカイブされたオブジェクト] の順に選択します。
  2. フィルターを利用して対象のオブジェクトを検索し、[復元] を選択します。


オブジェクトをアーカイブすると、使用されるメモリ量が減り、インスタンス メモリを追加することなく、より多くのオブジェクトを保存できます。

たとえば、インスタンスで 30 % のオブジェクトをアーカイブすると次のようになります。

  • メモリ使用量を最大 30% 削減
  • 再インデックスの実行やオブジェクト スキーマのリスト ページを開くなど、すべてのオブジェクトに作用する操作を 30% 高速化

Archived objects do not count towards the Assets Objects limits in guardrails.


[アーカイブされたオブジェクト] ページでオブジェクトをアーカイブまたは復元

アセット機能のモーダル ダイアログの改善

対象: 全員

アセット機能の Atlassian User Interface (AUI) ダイアログを AUI Dialog1 からAUI Dialog2 にアップグレードすることで、モーダル ダイアログのユーザー エクスペリエンスを改善し、複数のアクセシビリティの問題に対応しました。

セキュリティ バグ修正ポリシーの変更

対象: 全員

アトラシアンのセキュリティ バグ修正ポリシーが更新されます。変更は 2024 年 3 月 15 日よりすべての Data Center 製品で有効になります。

変更内容をご案内します。

これまでは、アトラシアン サポートのサポート終了ポリシーに従ってサポート対象の長期サポート リリースと、6 か月以内のすべての製品バージョンを対象にバグ修正リリースを提供していました。

新しいポリシーでは、アトラシアン サポートのサポート終了ポリシーに従って、サポート対象の長期サポート リリースを対象にバグ修正リリースを引き続き提供しますが、直近でリリースされた機能リリースのみをサポートするようにポリシーを更新する予定です。

重大な脆弱性が発生した場合は、次のすべての措置を講じます。

  1. 脆弱性の影響を受ける製品の最新の機能リリースを対象にバグ修正をリリースします。

  2. リリース スケジュールに従って、影響を受ける製品を対象に新機能のリリースを行います。

  3. アトラシアン サポートのサポート終了ポリシーに従って、影響を受ける製品のすべてのサポート対象の長期サポート リリースを対象にバグ修正のリリースを行います。

当社では、ソフトウェアのセキュリティを強化し、アップデートをより迅速かつ頻繁に提供するための最も効果的な方法を開発することを目指しています。最新の機能リリースには最新のセキュリティ修正と機能強化が含まれているため、アップグレードの検討時には最も安全で安定した製品バージョンであることを確信できます。

懸念事項がある場合、または更新されたバグ修正ポリシーについて不明点がある場合は、遠慮なく当社のサポート チームまでご連絡ください。

新しいプロセスの詳細については、「お知らせ: セキュリティ バグ修正ポリシーの計画的な変更 | アトラシアン サポート | アトラシアン製品ドキュメント」を参照してください。

事前予告 http-builder ライブラリからネイティブの Groovy の GET および POST への切り替え

対象: 管理者

http-library はアクティブに保守されていないため、Jira Service Management 6.0 で取り除くことを予定しています。Groovy スクリプトでこのライブラリをご利用の場合、ネイティブの Groovy の GET および POST メソッドに切り替えることをおすすめします。

事前予告 Groovy 4 のアップグレード

対象: 管理者

Jira Service Management 6.0 では、セキュリティ、機能、シンタックス サポートの改善のため、Groovy 2 から Groovy 4 へのアップグレードを予定しています。アセット機能で Groovy スクリプトを利用している場合は、Jira Service Management 6.0 の EAP リリースに含まれる Groovy 4 コンソールを利用して既存のスクリプトをテストし、適切に動作することをご確認ください。

重要かつ重大な変更点は次のとおりです。

  • switch ステートメントのシンタックスの変更。
  • 配列の intersect() メソッドのシンタックスの変更。
  • isser/getter のプロパティ解像度の変更
  • picocli パッケージの同梱は行われなくなります。代わりに @Grab を利用します。
  • ImportCustomizer はモジュールごとに一度適用されます (これまではクラスごとに一度)。
  • groovy-jaxbgroovy-bsf、および StaticTypeCheckingVisitor#collectAllInterfacesByName モジュールの提供は終了します。
  • Antir2 ベースのパースは行えなくなります (新しい Parrot パーサーを利用します)。
  • 一部の CLI ヘルプ メッセージのフォーマットの変更。
  • JsonSlurper で次の問題が発生した場合、JsonSlurper を Jackson ObjectMapper で置き換えます。

    java.lang.RuntimeException: Unable to load FastStringService
    	at org.apache.groovy.json.internal.FastStringUtils.getService(FastStringUtils.java:56) ~[?:?]
    	at org.apache.groovy.json.internal.FastStringUtils.toCharArray(FastStringUtils.java:66) ~[?:?]
    	at org.apache.groovy.json.internal.BaseJsonParser.parse(BaseJsonParser.java:114) ~[?:?]
    	at groovy.json.JsonSlurper.parseText(JsonSlurper.java:205) ~[?:?]
  • クラス、パッケージ、モジュール名の変更の一覧を次の表にまとめています。

    クラス/パッケージ/モジュール名Groovy 2Groovy 4
    groovy-xmlgroovy.utilgroovy.xml
    groovygroovy.xml.QNamegroovy.namespace
    groovy-antgroovy.utilgroovy.ant
    groovy-consolegroovy.inspectgroovy.console

    groovy.inpsect.swingui

    groovy.ui

    groovy.console.ui
    groovy.ui.ConsoleApplet非推奨
    groovy-groovysh

    org.codehaus.groovy.tools.shell

    org.apache.groovy.groovysh
    groovy-jmx

    groovy.util.GroovyMBean

    groovy.jmx
    groovy-nio

    org.codehaus.groovy.runtime.NioGroovyMethods

    org.apache.groovy.nio.extensions.NioExtensions

    org.codehaus.groovy.runtime.WritablePath

    org.apache.groovy.nio.runtime
    groovy-swing

    org.codehaus.groovy.binding

    org.apache.groovy.swing.binding

    groovy.model

    groovy.swing.model

    groovy.inspect.swingui

    org.apache.groovy.swing.table
    groovy-test

    org.codehaus.groovy.runtime.ScriptTestAdapter

    org.apache.groovy.test
    groovy.transform.NotYetImplementedgroovy.test.NotYetImplemented
    groovy.utilgroovy.test
    groovy.langgroovy.test
    GroovyClassLoadersourceCacheclassCache のタイプは Map から、より強力なタイプに変わりました

重大な変更の完全な一覧については次のページをご確認ください。

事前予告 Jira Software 10.0 および Jira Service Management 6.0 のデータベース アップグレードに伴って予測されるダウンタイム

対象: 管理者

Jira Software 10.0 および Jira Service Management 6.0 では、操作 (課題の作成、コメントの更新、ステータスの変更など) のタイムスタンプの精度を高めてミリ秒単位にするため、MySQL と Oracle データベースの構造の変更を予定しています。

MySQL または Oracle データベースをご利用の場合、jiraissuejiraaction、および changegroup テーブル内のいくつかのカラムがアップグレード中に移行されるため、アップグレードで追加のダウンタイムが発生します。このダウンタイムは、課題の数が 500 万件未満である場合は 20 分未満になると予想されています。なお、ダウンタイムはご利用のデータベースのパフォーマンスに加えて、jiraissuejiraaction、および changegroup テーブルの行数の影響を受ける点に注意してください。

正確なダウンタイムを把握してアップグレードを計画するには、次の手順を実行します。

  1. ご利用のデータベースで次のコマンドを実行して行数を取得します。

    SELECT COUNT(*) FROM jiraissue;
    SELECT COUNT(*) FROM jiraaction;
    SELECT COUNT(*) FROM changegroup;
  2. Amazon RDS db m6g.8xlarge 用に提供された次のベンチマーク データを利用して、ダウンタイムを予測します。
    1. jiraissue テーブル: 100 万行あたり約 26.527 秒
    2. jiraaction テーブル: 100 万行あたり約 7.592 秒
    3. changegroup テーブル: 100 万行あたり約 9.468 秒

たとえば、jiraissuejiraaction、および changegroup テーブルにそれぞれ 500 万、800 万、および 8,000 万行があった場合、約 16.65 分のダウンタイムが予測されます。


事前予告 アセット機能の内部 GraphQL API を削除

対象: 管理者

Jira Service Management 6.0 では、セキュリティを強化し、Jira Service Management とアセット機能との間で一貫した API パターンを確立させ、コード ベースを整理するため、内部のアセット GraphQL API の削除を予定しています。アセット アイコンの設定に利用されている API は、新しい内部用の REST エンドポイントに移行されます。

次のものが削除されます。

  • GraphQL エンドポイント /insight/graphql
  • GraphQL クエリ:

    クエリ名説明

    findObjectSchemas

    提供されたフィルターでオブジェクト スキーマを検索します。フィルターが提供されていない場合はすべてのオブジェクト スキーマが返されます。

    objectSchema

    オブジェクト スキーマを ID で取得します

    findObjectTypes

    提供されたフィルターでオブジェクト タイプを検索します。フィルターが提供されていない場合はすべてのオブジェクト タイプが返されます。

    findObjectTypeRelations

    関連するオブジェクト タイプを検索します

    objectType

    オブジェクト タイプを ID で取得します

    icon

    アイコンを ID で取得します

    globalIconTheme

    グローバル アイコン テーマを取得します

    findObjects

    提供されたフィルターでオブジェクトを検索します。フィルターが提供されていない場合はすべてのオブジェクトが返されます。

    findObjectReferences

    特定のオブジェクトの内向きまたは外向き参照を検索します。

    findStatusTypes

    提供されたフィルターでステータス タイプを検索します。フィルターが提供されていない場合はすべてのオブジェクト ステータス タイプが返されます。

    findReferenceTypes

    提供されたフィルターで参照タイプを検索します。

    object

    オブジェクトを ID で取得します

    findObjectTypeAttributes

    提供されたフィルターでオブジェクト タイプ属性を検索します。フィルターが提供されていない場合はすべてのオブジェクト タイプ属性が返されます。

    objectTypeAttribute

    オブジェクト タイプ属性を ID で取得します

    findUniqueObjectAttributeValues

    特定のオブジェクト タイプ属性の一意のオブジェクト属性値を検索します

  • GraphQL ミューテーション:

    ミューテーション名説明

    createObjectSchema

    新しいオブジェクト スキーマを作成

    updateObjectSchema

    既存のオブジェクト スキーマの名前または説明を更新

    copyObjectSchema

    既存のオブジェクト スキーマをコピー

    deleteObjectSchema

    既存のオブジェクト スキーマを削除

    createObjectType

    新しいオブジェクト タイプを作成

    updateObjectType

    既存のオブジェクト タイプを更新

    updateObjectTypePosition

    オブジェクト タイプ構造内で 1 つのオブジェクト タイプの位置を変更

    copyObjectType

    既存のオブジェクト タイプをコピー

    deleteObjectType

    既存のオブジェクト タイプを削除

    createObject

    新しいオブジェクトを作成

    updateObject

    既存のオブジェクトを更新

    deleteObject

    既存のオブジェクトを削除

    createObjectTypeAttribute

    新しいオブジェクト タイプ属性を作成

    updateObjectTypeAttribute

    既存のオブジェクト タイプ属性を更新

    configureObjectTypeAttribute

    オブジェクト タイプ属性の設定を変更

    updateObjectTypeAttributePosition

    属性リスト内で 1 つのオブジェクト タイプ属性の位置を変更

    deleteObjectTypeAttribute

    既存のオブジェクト タイプ属性を削除

    createIcon

    新しいアイコンを作成

    updateIcon

    既存のアイコンを更新

    deleteIcon

    既存のアイコンを削除

    configureGlobalIconTheme

    グローバル アイコンテーマを設定

    resetGlobalIconTheme

    グローバル アイコン テーマをデフォルト設定にリセット

次の機能は Jira プラットフォームのものです。つまり、Jira Software と Jira Service Managementで利用できます。

Jira にアップロードできるファイル拡張子を制限

すぐに利用できるセキュリティ機能がもう 1 つ追加されました。Jira インスタンスや組織のインフラストラクチャをマルウェアの脅威から保護するために、管理者は不要なファイル拡張子が課題を通じてアップロードされないように制限できるようになりました。特定のファイル形式を制限するには、禁止または許可すべきファイル拡張子のブロック リストまたは許可リストを作成する必要があります。

ファイル拡張子を制限する方法

websudo 許可リストでアクセス管理を厳格化する

websudo 操作のセキュリティ層を追加するために、Jira 用の独自の IP アドレス/サブネット許可リストを構成し、有効化できます。つまり、特定のスーパーユーザー操作を、事前に承認済みの IP アドレスからのみ実行できるようになります。

websudo 許可リストを作成する方法

Confluence ページ ガジェットに代わる Confluence ページ ビューアー

このリリースでは、従来の人気のある Confluence ページ ガジェットが新しい Confluence ページ ビューアーで置き換えられます。この新しいガジェットはモダンかつセキュアな技術スタック上に構築されており、全体的なエクスペリエンスを向上させるために複数の UI 改善が含まれています。これまでのものと同様に、Confluence ページ ビューアーを利用して、リンクされた Confluence Data Center サイトのページを Jira ダッシュボードに埋め込むことができます。

Jira アプリケーション用のガジェットの詳細

新しい Confluence ページ ビューアー

Jira Software と Jira Service Management に SBOM (Software Bill of Materials) を導入

最も安全な製品をお客様に提供するという取り組みのもと、SBOM (Software Bill of Materials) を Jira Service Management に導入することになりました。 

詳細情報

SBOM の概要と追加の理由

SBOM は、1 つのソフトウェアに含まれるすべてのコンポーネントの詳細な一覧またはインベントリです。これらのコンポーネントには、オープンソース ソフトウェア、プロプライエタリ コード、ライブラリ、フレームワーク、およびソフトウェア内で利用されているその他の要素が含まれます。 

SBOM は米国の Executive Order on Improving the Nation's Cybersecurity、EU の NIS 2 Directive、および Cyber Resilience Act などのさまざまな規制や基準への遵守を確保するために不可欠です。これによって透明性を高め、ソフトウェア コンポーネントやそれらのバージョン、依存関係、セキュリティ脆弱性に対応した更新状況などの理解を深めることができます。

さらに、アプリ開発者や管理者は SBOM を利用して潜在的なセキュリティ リスクを特定し、ライセンスを管理して、ソフトウェアをさらに効果的に保守することができます。たとえば、特定のオープンソースのコンポーネントで脆弱性が見つかった場合、SBOM にアクセスできる人なら誰でも、利用しているソフトウェアが影響を受けているかどうかを確認できます。

SBOM の生成方法

当社ではオープンソース ツールである Syft を使い、製品のビルド プロセス中に SBOM ファイルを自動生成しています。Syft はコードをスキャンし、依存関係を特定して、結果を含む JSON ファイルをコンパイルします。Syft ではさまざまな SBOM フォーマットがサポートされていますが、アトラシアンでは現在、人気のある CycloneDX を選択しています。 

SBOM の確認方法

SBOM を見つけるには、ご利用のアトラシアン製品のインストール ディレクトリの sbom/ フォルダに移動し、次のいずれかのパターンの名前を持つファイルを探します (<product_name>-<version>-cyclonedx-sbom.json または <product_name>-<version>-sbom.cdx.json)。 

Jira Software 9.15 の例

atlassian-jira-software-9.15-cyclonedx-sbom.json

重要事項

当社の製品スイートではプラグインやコンポーネントを基盤とする複雑なアーキテクチャが採用されているため、フロントエンドのすべての依存関係の可視化は段階的に行われています。現在の SBOM にはこれらの依存関係の一部が含まれています。

解決済みの課題

最終更新日 2024 年 5 月 3 日

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

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