電子メール通知ルールの定義

前提条件

独自のルールを定義するには、以下の条件を満たす必要があります。

電子メール通知の管理権限が必要です。
SQL、特に WHERE 句の書き方を熟知している。
データベーススキーマ、特に問題に関連するビューとテーブル IM_V_Defects および IM_DefectHistory の列を熟知している。
ワークフローとワークフローで使用される値を熟知している。

SQL WHERE 句の書き方のヒント

構文的にも意味的にも正しい WHERE 句を書く上で役に立つ重要なヒントを、ここでいくつか紹介しておきましょう。

IM_V_Defects と IM_DefectHistory 双方への参照

SQL WHERE 句には、おそらく IM_V_Defects と IM_DefectHistory 双方への参照が必要になるでしょう。IM_V_Defects ビューには、問題の最新情報が格納されるのに対して、IM_DefectHistory テーブルには、問題に対して取られたすべてのアクションのほか、それらの変更の結果、問題のいくつかのフィールドにどのような影響があったかが記録されます。

たとえば、IM_DefectHistory には、アクションが取られる前と後の問題の受信箱割り当てが格納されます。これらの列は、アクション実行前の受信箱割り当てについては AssignedIN、新しい受信箱については AssignedOUT です。

問題に対して取られたアクションはすべて、IM_DefectHistory テーブルの ActionCode フィールドに記録されます。これらのアクションは、履歴タブのアクション列にアクションコードとして表示されます。たとえば、サンプルデータベースでは、"解決" や "検証済み" といったコードが表示されます。

自分のデータベースで使用されているアクションの大半について、そのアクションコードを確認するには、各状態の状態 "<状態名>" のアクションの編集ダイアログボックスを開きます ("入力"、"再割り当て"、"変更" はハードコードされていて表示されないので除きます)。ある状態の状態 "<状態名>" のアクションの編集ダイアログにアクセスするには、問題 > 設定 > ワークフローページを開き、ボタンラベル列に表示されているアクション名をクリックします。[履歴アクションコード] フィールドの値を確認します。

エイリアスの使用

ビューとテーブルにはエイリアスが定義されています。IM_V_Defects ビューを参照するにはエイリアス D を、IM_DefectHistory テーブルを参照するにはエイリアス DH をそれぞれ使用する必要があります。

カスタムフィールドの識別

IM_V_Defects ビューでは、カスタムフィールドは、タブ上の位置によって Custom1、Custom2 などで識別されます。各カスタムタブにはフィールドが最大 10 個あります (1 から 10、11 から 20 など)。カスタムタブ 1 では、最初の 5 つのフィールドが左側の列に降順に表示され、フィールド 6 からフィールド 10 までが右側の列に降順に表示されます。

個々のカスタムフィールドのスキーマ名を調べるには、問題 > 設定 > 問題のカスタムタブを選択します。たとえば、サンプルデータベースのダイアログでは、カスタムタブ 1 の左列の第 4 フィールドがリリースノートに追加するチェックボックスになっており、これは問題テーブルの Custom4 に当たります。

注: カスタムフィールドの位置を変更した場合、そのフィールドを参照している電子メール通知ルールをすべて更新する必要があります。

カスタムフィールドの変更は追跡の対象外

Issue Manager では、IM_DefectHistory テーブル内のカスタムフィールドの変更を追跡しません。カスタムフィールドの現在の値を確かめることはできますが、以前の値を参照することはできません。たとえば、WHERE 句では、リリースノートに追加するチェックボックスが選択されているかどうかを検査することはできますが、そのチェックボックスの値がオフからオンに変化したのを捉えることはできません。

チェックボックス値へのアクセス

選択されていないチェックボックスの値は '.'(ピリオド) です。選択されているチェックボックスの値は 'X' (大文字の X) です。

たとえば、リリースノートに追加するチェックボックスがオンの問題をすべて取得するには、WHERE 句の一部に以下のように指定します。

D.Custom4 = 'X'

ルールの例

ここで、ルールを新規作成する状況を 4 つ紹介しましょう。最初の 2 つの状況は、個々の問題の通知でルールが使用される場合です。後の 2 つの状況は、プロジェクト全体の通知でルールが使用される場合です。各例の後に、サンプルデータベースを対象とした WHERE 句を示します。

例 1

Technical Support などのグループは、特定のバグ修正がいつ修正済みと確認されたかを知る必要があります。

この場合、WHERE 句は以下のようになります。

DH.ActionCode = 'VERIFIED'

IM_DefectHistory テーブル内の ActionCode の値はユーザーがアクションを取るたびに更新されるので、Technical Support グループは、"検証" アクションの結果、アクションコード "検証済み" が IM_DefectHistory テーブルと [履歴] タブに入力されたときに 1 回だけ電子メールを受信します。

代わりに、理由コード (データベースでは Disposition) への参照を使ってこの句を書いた場合、以下のようになります。

D.Disposition = 'FIXED'

この場合、データベースでは理由コードが "解決" のままなので、Technical Support グループはほぼ間違いなく複数回電子メールを受け取ることになるでしょう。その後ユーザーが問題にコメントを追加したり問題を保存しても、ルールがやはり一致するので、電子メールがトリガされることになります。

例 2

平均的なユーザーは自分ではバグに対処しないので、自分の報告したバグがどうなったかを知りたくなる場合があります。特に、バグが開発者の注意を引いたときに電子メールを受け取りたいと思います。ワークフロー的に言えば、これは問題がちょうど 開発準備完了 状態を抜けたことを意味するので、WHERE 句では、アクション実行後の状態変化を検査する必要があります。

この場合、WHERE 句は以下のようになります。

DH.StatusIN = 'Dev-Ready'
AND DH.StatusOUT <> 'Dev-Ready'

アクションの実行前は 開発準備完了 状態でしたが、開発者がアクションを取った後、バグは別の状態に移行しました。

例 3

ドキュメント部門では、Issue Manager のドキュメント関連の問題をすべて、ユーザーの受信箱 Judy -- Doc ではなくグループの受信箱 Doc (Product A) に送ってもらっています。ドキュメント管理者は、グループの受信箱に問題が入ったときに電子メールを受け取りたいと考えています。

この場合、WHERE 句は以下のようになります。

DH.AssignedIN <> 'Doc (Product A)'
AND DH.AssignedOUT = 'Doc (Product A)'

これは、アクション実行前には Doc (Product A) でなかった受信箱がアクション実行後には Doc (Product A) になったときに電子メールを送信するように指定しています。電子メールは、ドキュメント関連の問題が Doc (Product A) に送られたときに 1 回だけ送信されます。

なお、WHERE 句の最初の部分がなければ、ドキュメント関連の問題が "Doc (Product A)" に割り当てられている段階でも、それに対して何かアクションが取られたらドキュメント管理者が電子メールを受信することになります。通知をプロジェクト全体に適用する必要があるので、このルールは大量の電子メールを生成しそうですが、WHERE 句の 2 行が相まってルールを単一のイベント、すなわち受信箱が Doc (Product A) になったときに制限しています。

ルールでは、問題の種類を "ドキュメントの問題" に限定して指定する必要がありません。 Doc (Product A) はドキュメント関連の問題だけを保持しているので、それでも不正確にはなりません。

例 4

リリースマネージャは、メジャーリリース前の来月一杯、修正できない最も深刻なバグに関する電子メールを受け取りたいと考えています。WHERE 句では、深刻度、"Product B"、そして開発者が "解決不能" アクションを取ったときに割り当てられる "解決不能" アクションコードを検査する必要があります。

この場合、WHERE 句は以下のようになります。

D.Severity = '1: Fatal/Data Loss'
AND DH.ActionCode = 'Cannot-Fix'
AND D.ProductCode = 'Product B'

深刻度はユーザーが明示的に変更するまで変わらないので、WHERE 句で深刻度だけを検査した場合、問題が変更され保存されるたびにルールが一致するため、こういった制限が必要になります。

特にこのルールがプロジェクト全体の通知で適用された場合、リリースマネージャは、大量の電子メールを受け取る可能性があります。ただし、リリースマネージャはリリースサイクルが終了した後で通知を容易に削除することができます。

WHERE 句の書き方のヒント

一般的なものから特定のものへと取り組みます。まず、電子メール通知ルールが必要になりそうな一般的なビジネス状況を検討します。問題に関する電子メールをいつ受け取りたいかを Issue Manager ユーザー全員に尋ねてみてもよいでしょう。各ユーザーがその電子メールからどのような情報を収集したいと思っているかを正確に把握します。たとえば、ユーザーは、バグがいつ修正されたかを知りたいと言うかもしれません。さらに話を聞いてみると、本当は、修正がいつ QA エンジニアによって検証されたかを知りたいのだということがわかるかもしれません。このわずかな変化で、必要な WHERE 句が変わる可能性があります。

次に、ユーザーの希望を十分理解したと思ったら、その状況を、所属組織のワークフローの言葉に翻訳します。

最後に、SQL WHERE 句を作成します。高度なクエリを通じて WHERE 句をテストしてみて、ちょうど意図したとおりに条件を指定しているかどうかを確かめます。

一般的に言えば、個々の問題に関する通知を対象としたルールは簡単かつ包括的なものとして作成しなければならないのに対して、プロジェクト全体の通知向けのルールは、過剰な電子メールを避けるためにできるだけ正確かつ限定的なものにしなければなりません。

ユーザーが希望する通知の受信頻度 (1 回だけなのか、変化が生じるたびか) について考えます。ユーザーが 1 回だけの通知を希望する場合は、ルールをより限定的なものにします。