ワークフローのトリガー設定

このページで説明しているトリガーについての説明はすべての Jira 製品に適用されますが、トリガーは開発ツールと密接に連動するように設計されており、Jira Software とともに使用したときに最大の効果を発揮します。 

トリガーとは、開発ツール(FishEye/Crucible、Bitbucket、GitHub)の情報と Jira 課題の同期を維持するための強力なツールです。コードのコミット、レビューの完了、またはブランチの作成後に課題のステータスを手動で更新することを開発者に任せる代わりに、開発ツールでこれらのイベントが生じたら、自動的に課題をトランジションするようワークフローにトリガーを設定することができます。たとえば、ブランチが作成されたら課題を「作業前」から「進行中」に自動的にトランジションするようにトリガーを設定することもできます。

このページは、トリガーの使用を開始するのに役立ちます。ワークフローのトリガーを設定する方法と、自動遷移を動作させる方法を示します。トリガーのベストな設定方法と、トリガーのトラブルシューティングに役立ついくつかのガイダンスを提供しています。

はじめる前に

現在、チーム管理対象プロジェクトでワークフロー トリガーを設定できません。このページの説明は、企業管理対象プロジェクトにのみ適用されます。

トリガーの使用を開始する前に、開発ツールを Jira に接続する必要があります。最小構成として、以下のいずれかが必要となります。

これらのツールを Jira に接続する方法の手順については、「開発ツールと連携する」を参照してください。このページには、アトラシアンの開発ツールを接続することで有効化できる他の機能の詳細な説明も含まれます。

ガイド: トリガーのセットアップ

この例では、トリガーを持つ Jira ワークフローを設定します。このセクションを終了すると、トリガーの設定方法と、トリガーを持つ一般的な開発ワークフローがどのように見えるか理解することができます。

はじめに

次のスクリーンショットと表は、以降で構成する内容と同様のワークフローとトリガーを示しています。これらは、ソフトウェア開発のライフサイクルでの Jira と開発ツール間の一般的な連携を反映しています。この例では Jira Software、Bitbucket Server および Fisheye/Crucible (3.5.2) が使用されていますが、他のサポートされている開発ツールを使用して同様に構成することができます。

トランジショントリガー

作業開始
(To Do進行中への課題のトランジション)

ブランチの作成(Bitbucket Server)
コミットの作成 (Bitbucket Server)

レビュー開始
(進行中レビュー中への課題のトランジション)

プルリクエストの作成 (Bitbucket Server)
プルリクエストの再オープン (Bitbucket Server)
レビューの開始(Crucible)

作業再開
(レビュー中進行中への課題のトランジション)

プルリクエストの拒否 (Bitbucket Server)
レビューの却下(Crucible)
レビューの放棄(Crucible)

完了
(レビュー中完了への課題のトランジション)

プル リクエストのマージ (Bitbucket Server)
レビューのクローズ(Crucible)

ステップ 1.ワークフローを作成/編集する

ソフトウェア開発ワークフローを作成する最も簡単な方法は、新しいプロジェクトの作成で関連するプロジェクト タイプを選択することです。これにより、上記で示したものと同一のソフトウェア開発ワークフローを持つ新しいプロジェクトをセットアップします。

既に同様のワークフローがある場合、そこに移動して編集します。

  1. > [課題] を選択します。
  2. [ワークフロー] で [ワークフロー] を選択します。
  3. 編集するワークフローの横にある [編集] をクリックします。

ステップ 2.トランジションにトリガーを追加する

「コミットの作成」トリガーを「開始」トランジションに追加することで始めます。ワークフローを編集(表示ではなく)していることを確認します。

  1. ダイアグラム モードで、ワークフローで "作業開始" トランジションを選択します ("To Do" から "進行中" への線)。パネルにトランジションの詳細が表示されます。
  2. パネルの [トリガー] をクリックします。[トランジション: 作業開始] 画面に [トリガー] タブが表示されます。
  3. [トリガーの追加] をクリックし、表示されるダイアログで [Commit created] を選択します。診断ウィンドウが表示されます。Jira が接続されているすべての開発ツールにトリガーが追加されることがわかります。
  4. [トリガーの追加] をクリックし、トリガーを追加します。このトリガーが [トリガー] タブの一番下にある一覧に表示されるようになります。[詳細を表示する] をクリックすると、トリガーが動作しているかどうかを確認できます。

これで完了です。ワークフローの下書きを公開することを忘れないようにしてください。

ステップ 3.トリガーをテストする

これで「開始」トランジションに「コミットの作成」トリガーを追加したので、コミットしてテストしてみます。

  1. Jira プロジェクトで課題を作成します。このプロジェクトでは、先ほど編集したワークフローを使用する必要があります。新しい課題のステータスは "To Do" になっているはずです。次のステップで必要になるので、課題キーを記録しておきます。
  2. Bitbucket リポジトリにコードをコミットします。任意のコードをコミットできますが、コミット メッセージに課題キーを含める必要があります。
    この例では、課題のキーは TIS-1 であり、スクリーンショットに表示されているコミット メッセージでこれを参照しています。
  3. Jira で再度課題を確認します。ステータスが "To Do" から "進行中" に変更されました。[履歴] タブまたは [アクティビティ] タブをクリックすると、課題のステータスを変更した自動トランジションを確認できます。

ステップ 4.トリガーの残りを追加する

これでトリガーを追加し、テストすることができました。同様の手順で上記の一覧の残りのトリガーを追加します。

おめでとうございます! これで、トリガーを含むワークフローをセットアップできました。

トリガーの設定または動作に問題がある場合、以下の「トラブルシューティング」セクションを確認してください。

トリガーの仕組みについて詳細を知りたい場合は、以下の「トリガーの理解」セクションを参照してください。

トリガーの理解

以下のトピックでは、トリガーの仕組みについての詳細を説明しているため、これらをより効率的に使用することができます。

トリガー イベント

特定の開発ツールを Jira と連携するか、アプリを使用することで、イベント (例: コミット作成) をトリガーとして使用できるようになります。以下の表は、各開発ツールで有効になるイベントの一覧です。

開発ツールBitbucket、GitHub Enterprise、GitHub (アプリ)
CrucibleFisheye
イベント
  • プル リクエストの作成
  • プル リクエストのマージ
  • プル リクエストの拒否(Bitbucket のみ)
  • プル リクエストの再オープン(Bitbucket サーバーのみ)
  • コミットの作成
  • ブランチの作成
  • レビューの開始
  • 承認にサブミット
  • レビューの却下
  • レビューの放棄
  • レビューのクローズ
  • レビューの要約
  • コミットの作成
  • ブランチの作成


トリガーとグローバル トランジション

トリガーによる課題の動作への影響を正確に把握している場合を除き、グローバル トランジションにはトリガーを設定しないことをおすすめします。

グローバル トランジションは、ワークフローの任意のステータスを特定のステータスに遷移できます。これはワークフロー ビューア/エディタで、グローバル トランジションの対象となるステータスを指すすべての黒いひし型で表されます。グローバル トランジションの詳細については、「ワークフローの詳細設定」を参照してください。

グローバル トランジションにトリガーを設定すると、グローバル トランジションの対象のステータスに予期せず遷移するという問題がよく発生するようになります。例えば、「進行中」ステータスに遷移するグローバル トランジションに「コミットの作成」トリガーを設定する場合を考えます。多くの段階で、課題のライフサイクル(例:初期コード作成、レビュー後のコード変更など)中にコードをコミットすることがあります。これにより、「レビュー中」や「完了」などのステータスから「進行中」に不正に遷移するという問題を引き起こす可能性があります。

tip/resting Created with Sketch.

ワークフローにグローバル トランジションを使用する場合、複数のトランジションが 1 つのステータスに遷移する場合があります。これはユーザが課題で複数のワークフロー オプション (例: 「開始」と「進行中」) を持つことを意味しています。このオプションを非表示にするには、「ユーザからトランジションを非表示にする」条件を、関連するトランジションに追加します。

コミット、ブランチ、プル リクエスト、レビューで Jira 課題を参照する

以下の表では、コミット、ブランチ、プル リクエスト、レビューで Jira 課題を、これらのイベントが課題への遷移を開始するように、照する方法を説明しています(トランジションにトリガーをセットアップする方法を提供しています)。

イベント手順
コミットの作成

コミットメッセージに課題キーを含めます。

たとえば、"TIS-1 最初のコミット" のようなコミットメッセージは、TIS-1 課題を「作業前」から「進行中」に自動的に移行します 。

ブランチの作成

ブランチを作成する際に、ブランチ名に課題キーを含めます。

たとえば、ブランチに "TIS-2 feature" と名前をつけると、 TIS-2 課題は「作業前」から「進行中」に自動的に移行します 。

マージプルリクエストの作成/再オープン/拒否

プル リクエストに(コミット メッセージで)課題を参照するコミットを含めます。

たとえば、タイトルが "TIS-3 " のプルリクエストを作成すると、"TIS-3" 課題は「進行中」から「レビュー」に自動的にトランジションします 。プルリクエストを再オープン、却下、またはマージすると、それに応じて "TIS-3" 課題はトランジションします。

レビューの開始/拒否/廃棄/クローズ

レビューを作成するときに、課題キーをレビュータイトルに含めます。

たとえば、レビューに "TIS- 4New story" という名前をつけて、レビューを開始すると、TIS-4 課題は「進行中」から「レビュー」に自動的に遷移します。レビューを拒否、放棄、またはクローズすると、それに応じて "TIS-4" 課題は遷移します。

開発ツールから Jira へユーザをマッピングする

以下のプロセスでは、開発ツールのユーザをワークフロー トリガー用に、Jira ユーザにマッピングする方法を説明しています。これはすべてのイベントに適用されますが、各開発ツールではマッピングに異なるメール アドレスとユーザ名を使用します(以下のプロセスの説明に続く箇条書きを参照してください)。

  • プロセス: 開発ツールのイベントを初期化するユーザは、まずメールアドレスでマッチングし、その後ユーザ名でマッチングして Jira にマッピングされます。つまり、
    • メールアドレスが一致する Jira ユーザが1人 — Jira ユーザとして課題を遷移させます。
    • メールアドレスが一致する Jira ユーザがいない — 匿名ユーザとして課題を遷移させます。
    • メールアドレスが一致する Jira ユーザが複数 — ユーザのグループで一致するユーザ名を検索します。ユーザ名が一致するユーザがいる場合、Jira ユーザとして課題を遷移させます。ユーザ名が一致するユーザがいない場合、匿名ユーザとして課題を遷移させます。
  • ユーザ マッピング用のメールアドレスとユーザ名

Stash
イベントユーザ マッピングに使用されるメールアドレスとユーザ名
すべてのプル リクエスト イベントプル リクエストを操作するユーザの Bitbucket Server メールアドレスとユーザ名
コミットの作成コミットと Bitbucket Server の(メールアドレスがマッピングされる)ユーザ名に関連付けられているメールアドレス。メールアドレスがユーザ名にマッピングされていない場合、コミットから作成者の「名前」が使用されます。
ブランチの作成Bitbucket Server にブランチをプッシュした認証済みユーザの Bitbucket Server メールアドレスとユーザ名
Fisheye/Crucible
イベントユーザ マッピングに使用されるメールアドレスとユーザ名
コミットの作成コミットと FishEye の(メールアドレスがマッピングされる)ユーザ名に関連付けられているメールアドレス。メールアドレスがユーザ名にマッピングされていない場合、コミットから作成者の「名前」が使用されます。
ブランチの作成このイベントは Jira ユーザにマッピングされません。これは、課題が匿名ユーザとして遷移されることを意味しています。 
すべてのレビュー イベントレビューを実施する認証済みユーザの Crucible のメールアドレスとユーザ名
Bitbucket
イベントユーザ マッピングに使用されるメールアドレスとユーザ名
すべてのプル リクエスト イベントプル リクエストを操作するユーザの Bitbucket のメールアドレスとユーザ名注: Bitbucket ユーザ(プロフィールにメールアドレスを設定している)はコミットを少なくとも1つ持っている必要があり、そうでない場合はプル リクエストが Jira ユーザにマッピングできません。これは、課題が匿名ユーザとして遷移されることを意味しています。 
コミットの作成コミットと Bitbucket の(メールアドレスがマッピングされる)ユーザ名に関連付けられているメールアドレス。メールアドレスがユーザ名にマッピングされていない場合、コミットから作成者の「名前」が使用されます。
ブランチの作成 このイベントは Jira ユーザにマッピングされません。これは、課題が匿名ユーザとして遷移されることを意味しています。 
GitHub / GitHub Enterprise
イベントユーザ マッピングに使用されるメールアドレスとユーザ名
プル リクエストの作成 / プル リクエストのマージ プル リクエストを実施するユーザの GitHub のメールアドレスとユーザ名。注: GitHub のユーザ(プロフィールにメールアドレスを設定している)はコミットを少なくとも1つ持っている必要があり、そうでない場合は、プル リクエストが Jira ユーザにマッピングできません。これは、匿名ユーザとして課題が遷移されることを意味しています。 
コミットの作成コミットと GitHub の(メールアドレスがマッピングされる)ユーザ名に関連付けられているメールアドレス。 メールアドレスがユーザ名にマッピングされていない場合、コミットから作成者の「名前」が使用されます。
ブランチの作成  このイベントは Jira ユーザにマッピングされません。これは、課題が匿名ユーザとして遷移されることを意味しています。 

イベントのハンドリングとイベントの制限

多くの場合、開発ツールから自動課題遷移へのイベントの処理はシームレスにする必要があります。しかし、時折、イベントのがハンドリングされたりイベントが制限されたりすることで、課題の遷移が遅延したり、課題が全く遷移しなかったりする場合があります。

  • イベントのハンドリング — イベントは、開発ツールが Jira に DVCS コネクタ経由で接続しているかアプリケーション リンクで接続しているかによって異なるようにハンドリングされます。これは、Jira が利用できない場合にイベントが遅延または消失するかどうかに影響する場合があります。

Bitbucket および GitHub Enterprise

Bitbucket および GitHub Enterprise からのイベントは Jira で DVCS コネクタ経由で処理されます。DVCS コネクタは、webhook のトリガーによる同期とスケジュール同期の 2 つの同期方法で、Bitbucket および GitHub Enterprise からのイベントを処理します。

  • webhook のトリガーによる同期: DVCS コネクタは Bitbucket および GitHub Enterprise で webhook を使用して、イベントが発生した際に Jira にデータを送信します。これはイベントを処理する標準的な方法で、Bitbucket / GitHub イベントのあと、ほぼ即座に課題が自動的に遷移します。
  • スケジュール同期: Bitbucket / GitHub Enterprise イベントが発生したときに Jira に接続できなかった場合、イベントは DVCS コネクタによって保存され、次のスケジュール同期 (既定では 60 分ごと) に送られます。これは webhook トリガーによる同期が失敗した場合のバックアップとなります。
Stash および FishEye/Crucible

 Bitbucket Server および FishEye/Crucible からのイベントはアプリケーション リンク経由で処理されます。しかし、Bitbucket Server および FishEye/Crucible では、イベントが送信されることと、イベントが発生した時に Bitbucket Server および FishEye/Crucible がイベントを送信することを保証します。これはイベントが送信された時に JIRA が利用できない場合は、イベントが消失することを意味しています。

  • イベントの制限 — Jira が多数のイベントで過負荷にならないよう、すべての開発ツールにイベント制限が設定されています。イベントの制限を超えた後に送信されたイベントは失われます。各開発ツールのイベント制限については、以降の一覧をご確認ください。
Bitbucket および GitHub Enterprise
  • ウェブブック トリガ同期: 10件のブランチ、100件のコミット
  • スケジュール同期: 600件のブランチ(同期間隔(分) × 10)、6000件のコミット(同期間隔(分) × 100)
    同期間隔を減らせば、スケジュール同期のイベントの制限は600件のブランチと6000件のコミット未満とすることができますが、
Stash

1回の同期当たり、10件のブランチ、100件のコミットより大きくすることはできません。
10件のブランチおよび100件のコミットの制限の上に適用されるさらなる制約は100、000 課題変更イベントの制限です。例えば、課題キーを1000個より多く参照する100件のコミットの場合、課題変更制限を超過します。

Fisheye/Crucible

1回の同期あたり6000件のイベント

トリガーと他のワークフロー操作/制約との関連

トランジションが自動で開始される場合、トランジションに設定されているすべての条件、バリデータ、権限が無視されます。

ただし、事後操作はそのまま実行されます。事後操作がユーザを必要とする場合、そのトランジションは匿名ユーザには実行されないことに注意する必要があります(上記の「ユーザ マッピング」セクションを参照してください)。


トラブルシューティング

トリガーの設定や動作に問題がある場合、以下の手順に従い問題をトラブルシューティングしてください。

1. トリガー診断を使用する

トリガーのトラブルシューティングの最初の手順は JIRA のトリガー診断を確認することです。診断は開発ツールとの接続に問題がある場合や、課題が期待通りに自動的に遷移しない場合に、問題を教えてくれます。

  1. Jira 管理コンソール > 課題 > ワークフロー > ワークフローの検索に移動し、表示操作列)をクリックします。
  2. テキストモード(図表モードではなく)で、目的のトランジションをクリックします。
  3. トランジション画面(トリガータブが表示されます)で、目的のトリガの詳細を表示をクリックし、診断情報を表示します。 
    • 「トリガー ソース」セクションには Jira と開発ツール間の統合に関する問題が一覧表示されます。たとえば、設定された認証のタイプが正しいかどうか、などが表示されます。
    • 「トランジション失敗」セクションにはトリガーが発火したにも関わらず自動遷移が失敗した課題が一覧表示されます。たとえば、匿名ユーザがトランジションにマッピングされているがトランジションが非匿名ユーザを要求する事後操作を持っているものなどが表示されます。

2. 一般的な問題を確認する

トリガー診断からの情報で問題が解決できない場合、以下の一般的な問題のリストの考えられる原因と解決方法を確認します。

トリガーをトランジションに追加できない:

考えられる原因...
原因ソリューション
JIRA または開発ツールのバージョンが正しくない正しいバージョンをインストールするか、正しいバージョンにアップグレードします。Jira 6.3.3 以降に加えて、ワークフロー トリガーを有効化できる次の開発ツールのいずれかを持っている必要があります: Bitbucket Server (Stash 3.2.0 以降)、 Fisheye / Crucible 3.5.2 以降、Bitbucket、GitHub Enterprise
開発ツールが Jira に正しく接続できない

接続の設定を確認します:

  • Jira + Bitbucket Server/FishEye/Crucible: Oauth を使用して 2LO および 3LO の2種類のアプリケーション リンクを設定する必要があります。
  • Jira + Bitbucket / GitHub Enterprise: DVCS コネクタを適切に設定する必要があります。
  • Jira + Bitbucket / Github: Github アプリが適切にインストールされていることを確認します。

詳細については、「開発ツールと統合する」を参照してください。

追加しようとしているトリガーが既にトランジションに追加されている

何もする必要はありません。

すべてのトリガーはトランジションに対してユニークで、一度だけトリガーをトランジションに追加することができます。

課題が遷移しない:

考えられる原因...
原因ソリューション
プロジェクトが、トリガーが設定されているワークフローを使用していないプロジェクトのサマリ > 管理 > ワークフローに移動し、プロジェクトがトリガーを設定したワークフローを使用していることを確認します。
トリガーを追加したワークフローの変更を保存していないトリガーを追加したワークフローに移動します。ワークフロー トランジションを表示し、表示されたトリガーを確認して公開されていることを確認します。
DVCS が Jira に到達していない

1時間待ちます。1時間待っても到達できない場合、DVCS との接続が正しく設定されていることを確認します(「開発ツールとの統合」を参照してください)。

トリガーが設定されていない、または Jira が Bitbucket / GitHub Enterprise に到達できない場合、最大 1 時間程度の遅延が発生する場合があります。これは、コミット / ブランチ / プル リクエストの同期がトリガー設定にかかわらず、 1 時間ごとに行われるためです。詳細については、上記の「イベントのハンドリングとイベントの制限」セクションを参照してください。

DVCS リポジトリが同期済み DVCS アカウントにリンクされていない

Jira 管理コンソール > アドオン > DVCS アカウントに移動し、リポジトリを有効にします。

Bitbucket または GitHub Enterprise に新しいリポジトリへの自動リンクを設定しなかった場合、リポジトリが有効化されない (ご使用の DVCS アカウントにリンクされる) 可能性があります。リンクされていないリポジトリのイベントは Jira に送信されないため、トリガーを設定していても、課題のトランジションは自動的には発生しません。

コミットが古すぎます

トランジションが生じるのは、経過日数 21 日未満のコミットのみです。これにより、一括アップロードを防止して一括トランジションが生じないようにしています。 

匿名ユーザーにはこの操作は許可されません。

開発ツールの各ユーザーを Jira ユーザーにマッピングしていることを確認します。

特定の課題操作は、匿名ユーザーによってトランジションが実行されると例外を投げます。対象の操作は次のとおりです。

  • CreateIssue イベント (これは、ワークフローでは「作成」または「課題の作成」トランジションに関連している可能性があります)
  • ユーザーがトランジションを実行していると仮定する 事後操作

開発ツール内のイベントを Jira ユーザーにマッピングできない場合、トリガーされたトランジションが匿名ユーザーによって実行されます。詳細は、上記のユーザーマッピングのセクションを参照してください。

1つの課題に許可される自動トランジションの最大数を超えました。

ワークフロートランジションが無限ループで終了していないことを確認します。

自動課題トランジションイベントが開発ツールにより誤って抑制されます。

イベントを送信できるようにリポジトリ/プロジェクト設定を変更します。

重複するイベントが送信されようとしている場合、Jira へのイベント送信を抑制してワークフローをトリガーしないように Bitbucket Server (Stash 3.3 - 3.5) または FishEye (3.5+) リポジトリを設定した可能性があります。 複数の開発ツールによってインデックスを付けられた同一リポジトリがある場合、重複するリポジトリイベントが Jira に送信されることがあります。ただし、Jira は、ワークフロートリガーの処理時に重複するコミットイベント (JIRA 6.3.3+) およびブランチ作成イベント (JIRA 6.3.11+) を自動的に削除します。

重複イベントによってトランジションが誤って実行される問題が生じない限り、Bitbucket Server または FishEye からリポジトリイベントを抑制しないようにしてください。

課題のトランジションが期待したように実行されません。

考えられる原因...
原因ソリューション
グローバルトランジションにトリガーを設定しました。

トリガーイベントが様々なステータスにある課題にどのような影響を与えるか調べます。グローバルトランジションからトリガーを削除することを検討します。

トリガーが課題の動作にどのような影響を与えるか正確に理解しているという自信がない限り、グローバルトランジション用にトリガーを設定しないことをお勧めします。詳細は、上記のトリガーとグローバルトランジションを参照してください。

自動課題トランジションでは、ワークフロー条件、バリデーターおよび権限は意図的に無視されます。

何もする必要はありません。

ワークフロー条件、バリデーターまたは権限が自動課題トランジションに適用されることを期待していた場合、これらのいずれも適用されていないことに留意してください。これに関連して、事後操作が自動課題トランジションに適用されます。

ワークフローが複数のプロジェクトにわたって共有されています。

トリガーをワークフローに適用したいプロジェクトと適用したくないプロジェクトがある場合、ワークフローをコピーする必要がある場合もあります。

トリガーはワークフローに適用されます。ワークフローが複数のプロジェクトにわたって共有されている場合、そのワークフロー用に設定されたすべてのトリガーが適用されることになります。

重複する自動課題トランジションイベントが複数の開発ツールにより送信されています。

開発ツールの1つ (またはそれ以上) のリポジトリ/プロジェクト設定を変更して、イベントが送信されないようにします。

複数の開発ツールによりインデックスが付けられている同一のリポジトリがあると、重複するリポジトリイベントが Jira に送信される場合があります。Jira は重複するコミットイベント (Jira 6.3.3 以降) およびブランチ作成イベント (Jira 6.3.11 以降) を自動的に削除します。

最新の Jira バージョンを使用しておらず、誤った課題トランジションを引き起こしている重複するリポジトリイベントがある場合、Jira へのイベント送信を抑制してワークフロートリガーが生じないように Bitbucket Server (Stash 3.3 - 3.5) および FishEye (3.5+) リポジトリを設定できます。

トランジションについて記録された情報が正しくありません:

考えられる原因...
原因ソリューション
開発ツールのユーザーが Jira のユーザーにマッピングされていません。

開発ツールの各ユーザーを Jira ユーザーにマッピングしていることを確認します。

ユーザーが正しくマッピングされていない場合、課題トランジションを実行するユーザーは匿名になります。詳細は、上記のユーザーマッピングに関するセクションを参照してください。


既知の問題: Jira の課題の [履歴] および [アクティビティ] タブと通知メールにのみ適切なユーザーが表示されます。その他の通知 (課題の [トランジション] タブなど) には匿名ユーザーが表示されます。

何もする必要はありません。

この既知の問題は今後のリリースで修正される予定です。

3. ヘルプを活用する

If you still cannot resolve your problem, there are a number of other help resources available, including our applications forums, Atlassian community, and our support team.


最終更新日 2021 年 11 月 17 日

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

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