自動ルーティングのオーバーライド設定

組織で通常使用される問題検証用のルーティングを、個々のユーザーやグループ全体でオーバーライドできるようにすることが可能です。 たとえば、報告した問題が修正されたかどうかをユーザーが確かめたい場合もあるでしょう。

このようなオーバーライドを許可するには、問題検証の優先設定 権限をユーザーまたはグループに割り当てます。 このセキュリティ権限があれば、ユーザーは 問題 > 設定 > 優先設定 から、以下の 3 つの戦略のいずれかを選択できます。
戦略
説明
常に標準のルーティングを使用する
検証用の標準ルーティング。 問題は適切な QA 用受信箱に送られます。
常に自分の問題を検証する
Issue Manager により、ユーザーが提起した問題が通常の QA 用受信箱ではなく、ユーザー自身の受信箱に送られて検証されるように指定します。
新規の問題ごとに指定する
Issue Manager により、問題が報告されるたびに、通常のルーティングをオーバーライドするオプションがユーザーに提示されるように指定します。

再割り当てによる自動ルーティングのオーバーライド

問題の再割り当ては、自動ルーティング メカニズムをオーバーライドする手動ルーティングの手段の 1 つです。 ユーザーは明示的に再割り当てアクションを取って、問題を別のユーザー (通常は同じグループ内のユーザー) の受信箱に送ることができます。 たとえば、開発者 Bill はこれから休暇を取るので、開発準備完了状態のバグを同僚の開発者 Dan に再割り当てするといった場合です。 このバグは開発準備完了状態のままですが、再割り当てされています。

再割り当てされた問題がワークフローにおける以前の状態に戻ったとき (たとえば、Dan がバグ修正を却下した場合など)、Issue Manager はその再割り当てを記憶しておき、後でその問題が当初送られた受信箱 (この場合は Bill の受信箱) ではなく、手動で送られた受信箱 (この場合は Dan の受信箱) に問題を戻します。

再割り当てがいかに効率的に動作するかを理解するために、ある例について考えます。 この例では、バグが 2 回 ([開発準備完了] 状態のときに 1 回、[QA 準備完了] 状態のときに 1 回) 再割り当てされ、QA エンジニアがバグ修正を却下して、バグをワークフローにおける以前の状態に戻します。
  1. 新しいバグが [開発準備完了] 状態でワークフローに入ります。 ルーティング ルールにより、このバグが開発者 Bill の受信箱に自動的に送られます。
  2. Bill は、このバグを開発者 Dan の受信箱に再割り当てします。
  3. Dan はこのバグを修正した主張し、その結果、バグが [QA 準備完了] 状態に移行します。
  4. ルーティング ルールにより、このバグが QA エンジニア Mike の受信箱に自動的に送られて検証を受けます。
  5. Mike は、このバグを同僚の Sarah の受信箱に再割り当てします。
  6. Sarah は修正結果を却下し、その結果、バグが [開発準備完了] 状態に戻ります。
  7. Issue Manager は、この [開発準備完了] 状態のバグを Dan の受信箱に送り返します。 その状態のバグを最後に処理した開発者は Dan だからです。
  8. Dan はこのバグを再度修正し、[QA 準備完了] 状態に戻します。
  9. Issue Manager は、この [QA 準備完了] 状態のバグを Sarah の受信箱に送り返します。 その状態のバグを最後に処理した QA エンジニア開発者は Sarah だからです。

機能強化されたルーティングがなければ、[開発準備完了] 状態の問題 (ステップ 7) は Bill の受信箱に送られ、そのあと Bill が問題を再度 Dan に再割り当てしているでしょう。 同様に、[QA 準備完了] 状態の問題 (ステップ 9) は Mike の受信箱に送られ、そのあと Mike が問題を再度 Sarah に再割り当てしていることでしょう。