定义电子邮件通知规则

先决条件

要定义您自己的规则，您必须：

• 拥有电子邮件通知规则和系统级通知权限。
• 熟悉 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 字段中。这些操作将在历史记录选项卡的操作列中显示为操作代码。您可能在示例数据库中注意到诸如“已修复”和“已验证”之类的代码。

要在数据库中查看大多数操作的操作代码，请查看每个状态（“已输入”、“已重新分配”和“已修改”除外，它们采用硬编码，无法进行查看）的状态的编辑操作对话框。要访问某个状态的状态的编辑操作对话框，请转至问题 > 配置 > 工作流，然后单击按钮标签列中的状态名称。在历史记录操作代码字段中查看值。

使用别名

视图和表已有别名。您必须使用别名 D 来引用 IM_V_Defects 视图，并使用别名 DH 来引用 IM_DefectHistory 表。

标识自定义字段

自定义字段在 IM_V_Defects 视图中标识为 Custom1、Custom2 等，具体取决于其在表中的位置。每个自定义选项卡最多具有 10 个字段，1-10 、11-20，以此类推。在自定义选项卡 1 上，前 5 个字段在左列按降序显示；字段 6 至字段 10 在右列按降序显示。

要找出特定自定义字段的架构名称，请转至问题 > 配置 > 自定义问题选项卡。例如，在示例数据库的对话框中，添加发行说明？复选框是自定义选项卡 1 左列中的第四个字段，问题表中的 Custom4 也是如此。

注： 如果您更改自定义字段的位置，那么您需要更新引用该字段的任何电子邮件通知规则。

不会跟踪对自定义字段所做的更改

Issue Manager 不会跟踪对 IM_DefectHistory 表中的自定义字段所做的更改。您可以检查自定义字段的当前值，但是不能引用上一个值。例如，WHERE 子句可测试是否已选中添加发行说明？复选框，但是不能捕获复选框值的更改（从未选中变为选中）。

访问复选框值

取消选中的复选框的值为“’.”（句点）。选中的复选框的值为“X”（大写 X）。

例如，要检索已选中添加发行说明？的所有问题，可按以下方式指定 WHERE 子句的一部分：

D.Custom4 = 'X'

规则示例

此处提供您可能希望创建新规则的四种情况。前两种情况建议在单个问题的通知中使用的规则。后两种情况建议在系统级通知中使用的规则。以下每个示例均为根据示例数据库编写的 WHERE 子句。

示例 1

技术支持和其他组想要了解将特定缺陷修复验证为“已修复”的时间。

WHERE 子句类似于：

DH.ActionCode = 'VERIFIED'

IM_DefectHistory 表中的 ActionCode 值将会在用户执行操作时得到更新；因此，当“验证”操作导致 IM_DefectHistory 在表和“历史记录”选项卡中输入“已验证”时，技术支持将只会收到一次邮件。

如果子句是通过引用原因代码（在数据库中称为 Disposition）编写的：

D.Disposition = 'FIXED'

几乎可以确定的是，技术支持将多次收到邮件，因为“原因代码”在数据库中仍为“已修复”。随后添加注释或保存问题的用户将触发电子邮件，因为规则仍匹配。

示例 2

未对缺陷执行操作的普通用户希望了解对其输入的缺陷执行的操作。他尤其希望在缺陷得到开发人员的注意时收到电子邮件。在工作流方面，这表示问题仍处于开发部准备就绪状态，因此 WHERE 子句必须测试执行操作后的状态更改。

此 WHERE 子句为：

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

在执行操作之前，状态为开发部准备就绪，但在开发人员执行操作之后，该缺陷将进入其他状态。

示例 3

文档部门已将所有文档问题发送给组收件箱文档部（产品 A），而不是用户的邮箱 Judy -- 文档部。文档部经理希望在问题进入组收件箱时收到电子邮件。

此 WHERE 子句为：

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

它指定在以下情况下应发送电子邮件：在执行操作之前收件箱并非为文档部（产品 A），但在执行操作之后为文档部（产品 A）。当文档问题路由到文档部（产品 A）时，该电子邮件将只发送一次。

请注意，无 WHERE 子句的第一部分，文档部经理将在对已分配给“文档部（产品 A）”的文档问题执行任何操作时收到电子邮件。虽然该规则很有可能生成大量邮件，但是由于需要在系统级应用通知，两行 WHERE 子句会将规则限制为单个事件：当收件箱变为文档部（产品 A）时。

此规则无需将问题类型指定为 DOC-ISSUE，尽管这可能不正确，因为文档部（产品 A）仅保留与文档相关的问题。

示例 4

发行经理希望在下个月针对无法修复的最严重缺陷发布主要版本之前收到电子邮件。当开发人员执行“无法修复”操作时，WHERE 子句必须测试严重性、产品 B 和已分配的“无法修复”操作代码。

此 WHERE 子句为：

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

这些限制是必需的，因为如果 WHERE 子句仅测试严重性，则规则将在任何时候更改和保存问题时匹配，除非用户明确更改严重性，否则严重性不会发生改变。

发行经理可能会收到大量邮件，尤其是在系统级通知中应用此规则时。但是，他可以在发行周期结束后轻松删除通知。

编写 SQL WHERE 子句的提示

从常规到特定情况的使用。首先，请考虑需要使用电子邮件通知规则的常规业务情况。您可能会询问所有 Issue Manager 用户希望何时收到关于问题的电子邮件。具体了解每个用户希望从电子邮件中获取什么信息。例如，某个用户可能告诉您他想要了解缺陷的修复时间。在进一步讨论后，您可能发现他真正想知道的是质保部工程师验证修复的时间。此细微变化可能需要不同的 WHERE 子句。

其次，如果您满意自己掌握的用户需求信息，请根据组织的工作流转换该情况。

最后，编写 SQL WHERE 子句。尝试通过高级查询测试 WHERE 子句，以确保准确指定所需的条件。

一般而言，用于单个问题通知的规则应该采用简单且常规的方式进行编写，而用于系统级通知的规则则应该准确并且尽可能严格以防止出现过多的电子邮件。

询问您自己用户希望接收通知的频率：仅在一次发生更改后或在每次发生更改后。如果用户希望仅触发一次邮件，则需要使规则变得更加严格。