Jira Cloud 製品のご紹介
Jira Cloud の製品、機能、プラン、および移行の詳細をご確認ください。
ワークフロー トリガーの設定
このページで説明しているトリガーについての説明はすべての Jira 製品に適用されますが、トリガーは開発ツールと密接に連動するように設計されており、Jira Software とともに使用したときに最大の効果を発揮します。
トリガーとは、開発ツール (Fisheye/Crucible、Bitbucket Cloud、GitHub) の情報と Jira 課題の同期を維持するための強力なツールです。コードのコミット、レビューの完了、ブランチの作成後に課題のステータスを手動で更新することを開発者に任せる代わりに、開発ツールでこれらのイベントが生じた際に課題が自動的にトランジションするよう、ワークフローにトリガーを設定できます。たとえば、ブランチが作成されたら、課題を「作業前」から「進行中」に自動的にトランジションするようトリガーを設定できます。
このページは、トリガーの使用を開始するのに役立ちます。ワークフローのトリガーを設定する方法と、自動遷移を動作させる方法を示します。トリガーのベストな設定方法と、トリガーのトラブルシューティングに役立ついくつかのガイダンスを提供しています。
はじめる前に
現在、チーム管理対象プロジェクトでワークフロー トリガーを設定できません。このページの説明は、企業管理対象プロジェクトにのみ適用されます。
トリガーの使用を開始する前に、開発ツールを Jira に接続する必要があります。最小構成として、以下のいずれかが必要となります。
Bitbucket Cloud
GitHub (アプリを使用)
Bitbucket Server (すべての最新バージョン)
FishEye/Crucible (すべての最新バージョン)
GitHub Enterprise 11.10.290 (以上)
これらのツールを Jira に接続する方法については、「開発ツールと連携する」をご参照ください。また、このページには、アトラシアンの開発ツールを接続することで有効化できる他の機能に関する詳細な説明も掲載しています。
ガイド： トリガーのセットアップ
この例では、トリガーを持つ Jira ワークフローを設定します。このセクションを終了すると、トリガーの設定方法と、トリガーを持つ一般的な開発ワークフローがどのように見えるか理解することができます。
はじめに
次のスクリーンショットと表は、以降で構成する内容と同様のワークフローとトリガーを示しています。これらは、ソフトウェア開発のライフサイクルでの Jira と開発ツール間の一般的な連携を反映しています。この例では Jira Software、Bitbucket Server および Fisheye/Crucible (3.5.2) が使用されていますが、他のサポートされている開発ツールを使用して同様に構成することができます。
トランジション | トリガー |
|---|---|
進行開始 | ブランチの作成（Bitbucket Server） |
レビュー開始 | プルリクエストの作成 （Bitbucket Server） |
作業再開 | プルリクエストの拒否 （Bitbucket Server） |
完了 | プル リクエストのマージ （Bitbucket Server） |
ステップ 1. ワークフローを作成/編集する
ソフトウェア開発ワークフローを作成する最も簡単な方法は、新しいプロジェクトを作成して関連するプロジェクト タイプを選択することです。これによって、上記で示したものと同一のソフトウェア開発ワークフローを持つ新しいプロジェクトをセットアップします。
既に同様のワークフローがある場合、そこに移動して編集します。
> [課題] の順に選択します。
[ワークフロー] で [ワークフロー] を選択します。
編集するワークフローの横にある [編集] をクリックします。
ステップ 2. トランジションにトリガーを追加する
「コミットの作成」トリガーを「開始」トランジションに追加することで始めます。ワークフローを編集（表示ではなく）していることを確認します。
ダイアグラム モードで、ワークフローで "作業開始" トランジションを選択します ("To Do" から "進行中" への線)。パネルにトランジションの詳細が表示されます。
パネルの [トリガー] をクリックします。[トランジション: 作業開始] 画面に [トリガー] タブが表示されます。
[トリガーの追加] をクリックし、表示されるダイアログで [Commit created] を選択します。診断ウィンドウが表示されます。Jira が接続されているすべての開発ツールにトリガーが追加されることがわかります。
[トリガーの追加] をクリックし、トリガーを追加します。このトリガーが [トリガー] タブの一番下にある一覧に表示されるようになります。[詳細を表示する] をクリックすると、トリガーが動作しているかどうかを確認できます。
これで完了です。ワークフローの下書きを公開することを忘れないようにしてください。
ステップ 3. トリガーをテストする
これで「開始」トランジションに「コミットの作成」トリガーを追加したので、コミットしてテストしてみます。
Jira プロジェクトで課題を作成します。このプロジェクトでは、先ほど編集したワークフローを使用する必要があります。新しい課題のステータスは "To Do" になっているはずです。次のステップで必要になるので、課題キーを記録しておきます。
Bitbucket Cloud リポジトリにコードをコミットします。任意のコードをコミットできますが、コミット メッセージに課題キーを含める必要があります。
この例では、課題キーは TIS-1 です。スクリーンショットに表示されているコミット メッセージでこれを参照しています。
3. Jira で課題を再確認します。ステータスが「To Do」から「進行中」に変更されました。[履歴] または [アクティビティ] の各タブをクリックすると、課題のステータスを変更した自動トランジションを確認できます。
ステップ 4. トリガーの残りを追加する
これでトリガーを追加してテストできました。同様の手順で上記のリストの残りのトリガーを追加します。
おめでとうございます! これで、トリガーを含むワークフローをセットアップできました。
トリガーの設定または動作に問題がある場合は、以下の「トラブルシューティング」セクションをご確認ください。
トリガーの仕組みに関する詳細について確認するには、以下の「トリガーの理解」セクションをご確認ください。
トリガーの理解
以下のトピックでは、トリガーの仕組みについての詳細を説明しているため、これらをより効率的に使用することができます。
トリガー イベント
特定の開発ツールを Jira と連携するか、アプリを使用することで、イベント (例: コミット作成) をトリガーとして使用できるようになります。以下の表は、各開発ツールで有効になるイベントの一覧です。
開発ツール | Bitbucket、GitHub Enterprise、GitHub (アプリ) | Crucible | Fisheye |
|---|---|---|---|
イベント |
|
|
|
トリガーとグローバル トランジション
トリガーによる課題の動作への影響を正確に理解している場合を除き、グローバル トランジションにはトリガーを設定しないことをお勧めします。
グローバル トランジションによって、ワークフローの任意のステータスを特定のステータスにトランジションします。これはワークフロー ビューアー/エディターで、グローバル トランジション先となるステータスを指す黒の「すべて」バッチで表されます。グローバル トランジションの詳細については「ワークフローの詳細設定」をご確認ください。
グローバル トランジションにトリガーを設定すると、グローバル トランジションの対象のステータスに予期せず遷移するという問題がよく発生するようになります。例えば、「進行中」ステータスに遷移するグローバル トランジションに「コミットの作成」トリガーを設定する場合を考えます。多くの段階で、課題のライフサイクル（例：初期コード作成、レビュー後のコード変更など）中にコードをコミットすることがあります。これにより、「レビュー中」や「完了」などのステータスから「進行中」に不正に遷移するという問題を引き起こす可能性があります。
ワークフローにグローバル トランジションを使用する場合、複数のトランジションが 1 つのステータスに遷移する場合があります。これはユーザが課題で複数のワークフロー オプション (例: 「開始」と「進行中」) を持つことを意味しています。このオプションを非表示にするには、「ユーザからトランジションを非表示にする」条件を、関連するトランジションに追加します。
コミット、ブランチ、プル リクエスト、レビューで Jira 課題を参照する
以下の表では、コミット、ブランチ、プル リクエスト、レビューで Jira 課題を、これらのイベントが課題への遷移を開始するように、照する方法を説明しています（トランジションにトリガーをセットアップする方法を提供しています）。
イベント | 手順説明 |
|---|---|
コミットの作成 | コミットメッセージに課題キーを含めます。 たとえば、"TIS-1 最初のコミット" のようなコミットメッセージは、TIS-1 課題を「作業前」から「進行中」に自動的に移行します 。 |
ブランチの作成 | ブランチを作成する際に、ブランチ名に課題キーを含めます。 たとえば、ブランチに "TIS-2-feature" と名前をつけると、TIS-2 課題は「作業前」から「進行中」に自動的に移行します。 |
マージプルリクエストの作成/再オープン/拒否 | プル リクエストに（コミット メッセージで）課題を参照するコミットを含めます。 たとえば、タイトルが "TIS-3" のプル リクエストを作成すると、"TIS-3" 課題は「進行中」から「レビュー」に自動的にトランジションします。プル リクエストを再オープン、却下、またはマージすると、それに応じて "TIS-3" 課題はトランジションします。 |
レビューの開始/拒否/廃棄/クローズ | レビューを作成するときに、課題キーをレビュータイトルに含めます。 たとえば、レビューに "TIS-4 New story" という名前をつけて、レビューを開始すると、TIS-4 課題は「進行中」から「レビュー」に自動的に遷移します。レビューを拒否、放棄、またはクローズすると、それに応じて "TIS-4" 課題は遷移します。 |
開発ツールから Jira へユーザをマッピングする
以下のプロセスでは、開発ツールのユーザをワークフロー トリガー用に、Jira ユーザにマッピングする方法を説明しています。これはすべてのイベントに適用されますが、各開発ツールではマッピングに異なるメール アドレスとユーザ名を使用します（以下のプロセスの説明に続く箇条書きを参照してください）。
プロセス： 開発ツールのイベントを初期化するユーザは、まずメールアドレスでマッチングし、その後ユーザ名でマッチングして Jira にマッピングされます。つまり、
1 人の Jira ユーザーのメール アドレスが一致する — その Jira ユーザとして課題をトランジションします。
メール アドレスが一致する Jira ユーザーがいない — 匿名ユーザーとして課題をトランジションします。ユーザーをトリガーに一致させられない場合は、匿名ユーザーとして課題を移動します。これは、Jira サイトにアクセスできる匿名ユーザーがいるという意味ではありません。
メール アドレスが一致する Jira ユーザーが複数いる — そのユーザー グループで一致するユーザー名を検索します。ユーザー名が一致する Jira ユーザーがいる場合、その Jira ユーザとして課題をトランジションします。ユーザー名が一致するユーザーがいない場合、匿名ユーザーとして課題をトランジションします。
ユーザ マッピング用のメールアドレスとユーザ名
Bitbucket Server
イベント | ユーザ マッピングに使用されるメールアドレスとユーザ名 | Bitbucket Server 7.14 以降のユーザー マッピングに使用されるメール アドレスとユーザー名 (OAuth を使用する場合) |
|---|---|---|
すべてのプル リクエスト イベント | プル リクエストを操作するユーザの Bitbucket Server メールアドレスとユーザ名 | プル リクエストを操作するユーザの Bitbucket Server メールアドレスとユーザ名 Bitbucket ユーザーは、プロファイルに設定されたメール アドレスで少なくとも 1 回コミットする必要があります。そうでない場合は、プル リクエストが Jira ユーザーにマッピングできません。これは、匿名ユーザーとして課題がトランジションされることを意味します。 |
作成されたコミット | コミットと Bitbucket Server の（メールアドレスがマッピングされる）ユーザ名に関連付けられているメールアドレス。メールアドレスがユーザ名にマッピングされていない場合、コミットから作成者の「名前」が使用されます。 | コミットに関連付けられているメール アドレスとそのメール アドレスがマッピングされている Bitbucket Server のユーザー名。メール アドレスがユーザー名に対応していない場合は、課題は匿名ユーザーとして移行されます。 |
作成されたブランチ | Bitbucket Server にブランチをプッシュした認証済みユーザの Bitbucket Server メールアドレスとユーザ名 | ブランチで最後にコミットした Bitbucket Server ユーザーに関連付けられているメール アドレス。メール アドレスが Jira ユーザーにマッピングされていない場合、課題は匿名ユーザーとしてトランジションされます。 |
Fisheye / Crucible
イベント | ユーザ マッピングに使用されるメールアドレスとユーザ名 |
|---|---|
作成されたコミット | コミットと FishEye の（メールアドレスがマッピングされる）ユーザ名に関連付けられているメールアドレス。メールアドレスがユーザ名にマッピングされていない場合、コミットから作成者の「名前」が使用されます。 |
作成されたブランチ | このイベントは Jira ユーザにマッピングされません。これは、課題が匿名ユーザとして遷移されることを意味しています。 |
すべてのレビュー イベント | レビューを実施する認証済みユーザの Crucible のメールアドレスとユーザ名 |
Bitbucket Cloud
イベント | ユーザ マッピングに使用されるメールアドレスとユーザ名 |
|---|---|
すべてのプル リクエスト イベント | プル リクエストを操作するユーザの Bitbucket のメールアドレスとユーザ名注： Bitbucket ユーザ（プロフィールにメールアドレスを設定している）はコミットを少なくとも1つ持っている必要があり、そうでない場合はプル リクエストが Jira ユーザにマッピングできません。これは、課題が匿名ユーザとして遷移されることを意味しています。 |
作成されたコミット | コミットと Bitbucket の（メールアドレスがマッピングされる）ユーザ名に関連付けられているメールアドレス。メールアドレスがユーザ名にマッピングされていない場合、コミットから作成者の「名前」が使用されます。 |
作成されたブランチ | このイベントは Jira ユーザにマッピングされません。これは、課題が匿名ユーザとして遷移されることを意味しています。 |
GitHub / GitHub Enterprise
イベント | ユーザ マッピングに使用されるメールアドレスとユーザ名 |
|---|---|
プル リクエストが作成/マージされた | プル リクエストを実行したユーザーの GitHub メール アドレスとユーザー名。注: GitHub のユーザー (プロファイルにメール アドレスを設定している) は、少なくとも 1 つのコミットを行っている必要があります。そうでない場合、プル リクエストは Jira ユーザーにマッピングできません。これは、匿名ユーザーとして課題がトランジションされることを意味します。 |
作成されたコミット | コミットと、メール アドレスがマッピングされる GitHub ユーザー名に関連付けられているメール アドレス。メール アドレスがユーザー名にマッピングされていない場合は、コミットにある作成者の「名前」が使用されます。 |
作成されたブランチ | ブランチで最後にコミットした Bitbucket Server ユーザーに関連付けられているメール アドレス。メール アドレスが Jira ユーザーにマッピングされていない場合、課題は匿名ユーザーとしてトランジションされます。 |
イベントのハンドリングとイベントの制限
多くの場合、開発ツールから自動課題遷移へのイベントの処理はシームレスにする必要があります。しかし、時折、イベントのがハンドリングされたりイベントが制限されたりすることで、課題の遷移が遅延したり、課題が全く遷移しなかったりする場合があります。
イベントのハンドリング — イベントは、開発ツールが Jira に DVCS コネクタ経由で接続しているかアプリケーション リンクで接続しているかによって異なるようにハンドリングされます。これは、Jira が利用できない場合にイベントが遅延または消失するかどうかに影響する場合があります。
Bitbucket Cloud と GitHub Enterprise
Bitbucket Cloud と GitHub Enterprise からのイベントは、Jira の DVCS コネクタ経由で処理されます。DVCS コネクタは、Webhook のトリガーによる同期とスケジュールされた同期という 2 つの同期メカニズムで、Bitbucket Cloud と GitHub Enterprise からのイベントを処理します。
Webhook のトリガーによる同期: イベントが発生すると、DVCS コネクタが Bitbucket と GitHub Enterprise で Webhook を使用して Jira にデータを送信します。これはイベントを処理するための標準的なメカニズムです。Bitbucket Cloud/GitHub イベントのあと、ほぼ即座に課題が自動的にトランジションします。
スケジュールされた同期: Bitbucket Cloud/GitHub Enterprise イベントの発生時に Jira に送信できなかった場合、イベントは DVCS コネクタによって保存され、次のスケジュールされた同期 (初期設定では 60 分ごと) に送られます。これは Webhook トリガーによる同期が失敗した場合のバックアップ メカニズムです。
Bitbucket Server と Fisheye/Crucible
Bitbucket Server と FishEye/Crucible からのイベントは、アプリ リンク経由で処理されます。ただし、Bitbucket Server と FishEye/Crucible では、イベントを確実に送信するとともに、イベント発生時に 1 回だけイベントを送信するようになっています。これは、イベントが送信された時に Jira が利用できない場合は、イベントが消失することを意味しています。
イベントの制限 — 多数のイベントで Jira が過負荷にならないように、イベントには制限が課せられています。イベントの制限を超えた後に送信されるイベントは消失します。各開発ツールにおけるイベントの制限については、以下のリストをご参照ください。
Bitbucket Cloud と GitHub Enterprise
Webhook トリガー同期: 10 件のブランチ、100 件のコミット
スケジュール同期: 600 件のブランチ (同期間隔 (分) × 10)、6000 件のコミット (同期間隔 (分) × 100)
同期間隔を減らせば、スケジュール同期のイベントの制限は 600 件のブランチと 6000 件のコミット未満とすることができますが、
Bitbucket Server
1 回の同期当たり、10 件のブランチ、100 件のコミットより大きくすることはできません。
10 件のブランチおよび 100 件のコミットの制限の上に適用されるさらなる制約は 100,000 課題変更イベントの制限です。例えば、課題キーを 1000 個より多く参照する 100 件のコミットの場合、課題変更制限を超過します。
Fisheye / Crucible
1 回の同期あたり 6000 件のイベント
トリガーと他のワークフロー操作/制約との関連
トランジションが自動で開始される場合、トランジションに設定されているすべての条件、バリデータ、権限が無視されます。
ただし、事後操作はそのまま実行されます。事後操作でユーザー操作が必要な場合は、トランジションを匿名ユーザーが行わないことを確認します (上記「ユーザ マッピング」セクション参照)。
トラブルシューティング
トリガーの設定や動作に問題がある場合、以下の手順に従い問題をトラブルシューティングしてください。
1. トリガー診断を使用する
トリガーのトラブルシューティングの最初の手順は JIRA のトリガー診断を確認することです。診断は開発ツールとの接続に問題がある場合や、課題が期待通りに自動的に遷移しない場合に、問題を教えてくれます。
Jira 管理コンソール > [課題] > [ワークフロー] > [ワークフローを検索] の順に移動して [表示] ([操作] 列) をクリックします。
ダイアグラム モードではなくテキスト モードで、対象のトランジションをクリックします。
トランジション画面 ([トリガー] タブが表示されます) で対象のトリガーの [詳細を表示] をクリックし、診断情報を表示します。
「トリガー ソース」セクションには Jira と開発ツール間の統合に関する問題が一覧表示されます。たとえば、設定された認証のタイプが正しいかどうか、などが表示されます。
「トランジション失敗」セクションにはトリガーが発火したにも関わらず自動遷移が失敗した課題が一覧表示されます。たとえば、匿名ユーザがトランジションにマッピングされているがトランジションが非匿名ユーザを要求する事後操作を持っているものなどが表示されます。
2. 一般的な問題を確認する
トリガー診断からの情報で問題が解決できない場合、以下の一般的な問題のリストの考えられる原因と解決方法を確認します。
トリガーをトランジションに追加できない：
考えられる原因...
原因 | ソリューション |
|---|---|
JIRA または開発ツールのバージョンが正しくない | 正しいバージョンをインストールするか、アップグレードします。Jira 6.3.3 以降に加えて、ワークフロー トリガーを有効化できる開発ツールである Bitbucket Server (Bitbucket Server 3.2.0 以降)、Fisheye/Crucible 3.5.2 以降、Bitbucket、GitHub Enterprise のいずれかが必要です。 |
開発ツールが Jira に正しく接続できない | 接続の設定を確認します：
詳細については「開発ツールとの統合」をご確認ください。 |
追加しようとしているトリガーが既にトランジションに追加されている | 何もする必要はありません。 すべてのトリガーはトランジションに対してユニークで、一度だけトリガーをトランジションに追加することができます。 |
課題が遷移しない：
考えられる原因...
原因 | ソリューション |
|---|---|
プロジェクトが、トリガーが設定されているワークフローを使用していない | プロジェクトの要約 [管理] > [ワークフロー] の順に移動して、プロジェクトがトリガーを設定したワークフローを使用していることを確認します。 |
トリガーを追加したワークフローの変更を保存していない | トリガーを追加したワークフローに移動します。ワークフロー トランジションを表示し、表示されたトリガーを確認して公開されていることを確認します。 |
DVCS が Jira に到達していない | 1 時間程度待ちます。1 時間後に到達していない場合は、DVCS との接続が正しく設定されていることを確認します。「開発ツールとの統合」をご確認ください。 トリガーが設定されていない、または Jira が Bitbucket Cloud/GitHub Enterprise に到達できない場合は、最大 1 時間程度の遅延が発生する可能性があります。これは、コミット/ブランチ/プル リクエストの同期がトリガー設定にかかわらず、1 時間ごとに行われるためです。詳細は、上記の「イベントのハンドリングとイベントの制限」セクションをご参照ください。 |
DVCS リポジトリが同期済み DVCS アカウントにリンクされていない | Jira 管理コンソール > [アドオン] > [DVCS アカウント] の順に移動して、リポジトリを有効にします。 Bitbucket Cloud または GitHub Enterprise に新しいリポジトリへの自動リンクを設定していない場合は、リポジトリが有効化されていない (ご利用の DVCS アカウントにリンクされている) 可能性があります。つまり、リンクされていないリポジトリのイベントは Jira に送信されないため、トリガーを設定していても課題のトランジションが自動的に行われません。 |
コミットが古すぎます | トランジションが生じるのは、経過日数 21 日未満のコミットのみです。これにより、一括アップロードを防止して一括トランジションが生じないようにしています。 |
匿名ユーザーにはこの操作は許可されません。 | 開発ツールの各ユーザーを Jira ユーザーにマッピングしていることを確認します。 特定の課題操作は、匿名ユーザーによってトランジションが実行されると例外を投げます。対象の操作は次のとおりです。
開発ツール内のイベントを Jira ユーザーにマッピングできない場合は、トリガーされたトランジションが匿名ユーザーによって実行されます。詳細は、上記のユーザー マッピングのセクションをご確認ください。 |
１つの課題に許可される自動トランジションの最大数を超えました。 | ワークフロートランジションが無限ループで終了していないことを確認します。 |
自動課題トランジションイベントが開発ツールにより誤って抑制されます。 | イベントを送信できるようにリポジトリ/プロジェクト設定を変更します。 重複するイベントが送信されていた場合は、ワークフローをトリガーするイベントを Jira に送信しないように、Bitbucket Server (Bitbucket Server 3.3 - 3.5) リポジトリまたは Fisheye (3.5 以降) リポジトリを設定している可能性があります。同じリポジトリが複数の開発ツールによってインデックス化されている場合は、重複するリポジトリ イベントが Jira に送信されることがあります。注: Jira はワークフロー トリガーを処理する際に、重複するコミット イベント (Jira 6.3.3 以降) とブランチ作成イベント (Jira 6.3.11 以降) を自動で削除します。 重複イベントによってトランジションが誤って実行される問題が生じない限り、Bitbucket Server または FishEye からリポジトリイベントを抑制しないようにしてください。 |
課題のトランジションが期待したように実行されません。
考えられる原因...
原因 | ソリューション |
|---|---|
グローバルトランジションにトリガーを設定しました。 | トリガーイベントが様々なステータスにある課題にどのような影響を与えるか調べます。グローバルトランジションからトリガーを削除することを検討します。 トリガーが課題の動作にどのような影響を与えるか正確に理解しているという自信がない限り、グローバル トランジション用にトリガーを設定しないことをお勧めします。詳細は、上記のトリガーとグローバル トランジションをご確認ください。 |
自動課題トランジションでは、ワークフロー条件、バリデーターおよび権限は意図的に無視されます。 | 何もする必要はありません。 ワークフロー条件、バリデーターまたは権限が自動課題トランジションに適用されることを期待していた場合、これらのいずれも適用されていないことに留意してください。これに関連して、事後操作が自動課題トランジションに適用されます。 |
ワークフローが複数のプロジェクトにわたって共有されています。 | トリガーをワークフローに適用したいプロジェクトと適用したくないプロジェクトがある場合、ワークフローをコピーする必要がある場合もあります。 トリガーはワークフローに適用されます。ワークフローが複数のプロジェクトにわたって共有されている場合、そのワークフロー用に設定されたすべてのトリガーが適用されることになります。 |
重複する自動課題トランジションイベントが複数の開発ツールにより送信されています。 | 開発ツールの１つ (またはそれ以上) のリポジトリ/プロジェクト設定を変更して、イベントが送信されないようにします。 複数の開発ツールでインデックスされている同一のリポジトリがある場合、Jira にリポジトリ イベントが重複して送信される可能性があります。Jira は重複するコミット イベント (Jira 6.3.3 以降) およびブランチ作成イベント (Jira 6.3.11 以降) を自動的に削除します。 最新の Jira バージョンを使用しておらず、誤った課題トランジションを引き起こしている重複するリポジトリ イベントがある場合は、ワークフローをトリガーするイベントを Jira に送信しないよう Bitbucket Server (Bitbucket Server 3.3 - 3.5) リポジトリと Fisheye (3.5+) リポジトリを設定できます。 |
トランジションについて記録された情報が正しくありません:
考えられる原因...
原因 | ソリューション |
|---|---|
開発ツールのユーザーが Jira のユーザーにマッピングされていません。 | 開発ツールの各ユーザーを Jira ユーザーにマッピングしていることを確認します。 ユーザーが正しくマッピングされていない場合は、課題トランジションを実行するユーザーは匿名になります。詳細については、上記のユーザー マッピング セクションをご確認ください。 |
既知の問題: Jira の課題の [履歴] および [アクティビティ] タブと通知メールにのみ適切なユーザーが表示されます。その他の通知 (課題の [トランジション] タブなど) には匿名ユーザーが表示されます。 | 何もする必要はありません。 この既知の問題は今後のリリースで修正される予定です。 |
3. ヘルプの確認
問題を解決できない場合は、アプリケーション フォーラム、アトラシアン コミュニティ、サポート チームなど、さまざまなヘルプ リソースをご利用いただけます。
トランジションが自動で開始される場合、トランジションに設定されているすべての条件、バリデータ、権限が無視されます。
ただし、事後操作はそのまま実行されます。事後操作でユーザー操作が必要な場合は、トランジションを匿名ユーザーが行わないことを確認します (上記「ユーザ マッピング」セクション参照)。
この内容はお役に立ちましたか?