課題のトランジション
共通のテーマは、エラー「特定のステータスへのどのトランジションでも課題が見つかりませんでした」に関する混乱です。このエラー メッセージはそのステータスが存在しないことを意味していそうですが、多くの場合は別の何かを示唆しています。
トランジションはワークフローに従う必要がある
よくある間違いの 1 つは、プロジェクトのワークフローに従わずに課題を移行するルールを作成することです。ワークフローに不慣れな場合は、Jira ドキュメントの説明をご参照ください。
次のワークフローの例は、バグを調査して処理するためのカスタム ワークフローです。
このワークフローは [課題をトランジション] アクションで実行できる操作を制限します。
たとえば、バグが重複している際にコメントして、それを「完了」に移行してクローズする手動トリガーを含むルールを考えてみましょう。
ワークフロー図では、この例のルールは「トリアージ待ち」状態の課題では適切に実行されません。なぜなら、課題は「調査中」にしか移動できないからです。
このステータスのチケットでルールを実行すると、エラー ステータスで終わることになります。
ただし、「調査中」と「進行中」の各ステータスの課題に対しては、このルールが実行されます。これは、ワークフローがこれらのステータスから「完了」への移行を許可しているからです。
ルールの実行者には適切な権限が必要
もう 1 つのよくある間違いは、ルール アクターの権限を考慮していないことです。ルール アクターは、ルールのルール詳細セクションに設定されている、ルールを実行するユーザーです。ルール アクターは自分とは別の一連のグループに属していて、課題を移行するための適切な権限を持っていない可能性があります。
前述のセクションの例によって「開発用に選択済み」から「進行中」へのトランジションの詳細をご確認ください。このトランジションを行うには、条件が付随していることが分かります。
開発者はバグを修正する唯一のユーザーなので、この条件によってこのトランジションを行えるのが開発者だけであることが保証されます。
次に示すのは、開発者が GitHub にブランチを作成した際に、Webhook によって課題を「進行中」に移行させるルールの一例です。
現在の形式ではルール アクターは開発者グループの一部ではないため、このルールは失敗します。
ルール アクターを開発者グループに変更すると、ルールは正常に実行されます。