組織で通常使用される問題検証用のルーティングを、個々のユーザーやグループ全体でオーバーライドできるようにすることが可能です。 たとえば、報告した問題が修正されたかどうかをユーザーが確かめたい場合もあるでしょう。
このようなオーバーライドを許可するには、
問題検証の優先設定 権限をユーザーまたはグループに割り当てます。 このセキュリティ権限があれば、ユーザーは から、以下の 3 つの戦略のいずれかを選択できます。
- 戦略
- 説明
- 常に標準のルーティングを使用する
- 検証用の標準ルーティング。 問題は適切な QA 用受信箱に送られます。
- 常に自分の問題を検証する
- Issue Manager により、ユーザーが提起した問題が通常の QA 用受信箱ではなく、ユーザー自身の受信箱に送られて検証されるように指定します。
- 新規の問題ごとに指定する
- Issue Manager により、問題が報告されるたびに、通常のルーティングをオーバーライドするオプションがユーザーに提示されるように指定します。
再割り当てによる自動ルーティングのオーバーライド
問題の再割り当ては、自動ルーティング メカニズムをオーバーライドする手動ルーティングの手段の 1 つです。 ユーザーは明示的に再割り当てアクションを取って、問題を別のユーザー (通常は同じグループ内のユーザー) の受信箱に送ることができます。
たとえば、開発者 Bill はこれから休暇を取るので、開発準備完了状態のバグを同僚の開発者 Dan に再割り当てするといった場合です。 このバグは開発準備完了状態のままですが、再割り当てされています。
再割り当てされた問題がワークフローにおける以前の状態に戻ったとき (たとえば、Dan がバグ修正を却下した場合など)、Issue Manager はその再割り当てを記憶しておき、後でその問題が当初送られた受信箱 (この場合は Bill の受信箱) ではなく、手動で送られた受信箱 (この場合は Dan の受信箱) に問題を戻します。
例
再割り当てがいかに効率的に動作するかを理解するために、ある例について考えます。 この例では、バグが 2 回 ([開発準備完了] 状態のときに 1 回、[QA 準備完了] 状態のときに 1 回) 再割り当てされ、QA エンジニアがバグ修正を却下して、バグをワークフローにおける以前の状態に戻します。
- 新しいバグが [開発準備完了] 状態でワークフローに入ります。 ルーティング ルールにより、このバグが開発者 Bill の受信箱に自動的に送られます。
- Bill は、このバグを開発者 Dan の受信箱に再割り当てします。
- Dan はこのバグを修正した主張し、その結果、バグが [QA 準備完了] 状態に移行します。
- ルーティング ルールにより、このバグが QA エンジニア Mike の受信箱に自動的に送られて検証を受けます。
- Mike は、このバグを同僚の Sarah の受信箱に再割り当てします。
- Sarah は修正結果を却下し、その結果、バグが [開発準備完了] 状態に戻ります。
- Issue Manager は、この [開発準備完了] 状態のバグを Dan の受信箱に送り返します。 その状態のバグを最後に処理した開発者は Dan だからです。
- Dan はこのバグを再度修正し、[QA 準備完了] 状態に戻します。
- Issue Manager は、この [QA 準備完了] 状態のバグを Sarah の受信箱に送り返します。 その状態のバグを最後に処理した QA エンジニア開発者は Sarah だからです。
機能強化されたルーティングがなければ、[開発準備完了] 状態の問題 (ステップ 7) は Bill の受信箱に送られ、そのあと Bill が問題を再度 Dan に再割り当てしているでしょう。 同様に、[QA 準備完了] 状態の問題 (ステップ
9) は Mike の受信箱に送られ、そのあと Mike が問題を再度 Sarah に再割り当てしていることでしょう。