Jira实战 | 通知方案

Jira策略管理实战手册: 为应用程序管理员提供配置、清理和维护Jira的模板。

文末提供Kindle版和印刷版获取方式。

通知方案是用来控制在标准问题事件上谁能收到电子邮件，这些事件包括“问题创建”、“问题更新”、“工作日志”，等等。当我们尝试在项目间共享设置的时候，有可能每个JIRA项目都有自己的通知设定，项目级管理员能在项目管理部分查看他们项目的“通知”页面，用来查看当前的设置，然而，任何通知的变更需经由JIRA应用管理员进行处理。

通知方案– 在问题生命周期事件中，发送电子邮件消息的设置。

示例: 问题创建、问题更新、问题分配，等等。
属性:

• 名称

• 描述

• 通知设置 

最佳实践

应该这么做

为每个通知策略创建一个方案，而不是为每一个项目都创建个别的方案。

• 示例: “通知用户”方案或“通知项目用户和C-Level领导”的通知方案。

尽可能的控制“问题垃圾”。

• 如果你在每一个步骤都通知用户，会产生过量的电子邮件，用户会过滤消息，最终可能会忽略这些通知。

注意JIRA电子邮件队列会影响公司邮箱服务器。

重用现有的通知方案。

• 除了少部分的项目之外，大多数都具备相同的通知方案需求。

不该这么做

设置不必要的通知，只有少数的项目需要定制化的通知或一般事件处理器。

• 在每一个步骤都通知用户会产生大量的电子邮件，用户会过滤消息，最终可能会忽略这些通知。

添加不可能或无用的通知。

• 示例: 如果在创建界面上没有添加关注人的功能，请不要“在问题创建的时候通知关注人”。

通知用户自己的操作行为。

不要在问题创建的时候通知报告人，这会创建很多无用的邮件流量。

在所有的行栏目添加"jira-users"组。

工作表：通知方案

下面的工作表包含了简易的通知方案的建议，根据你的需要修改这个工作表，由于大多数的最终用户不能够看到通知相关的设置，可以添加相关信息到用户帮助文件和文档。

这个例子引用了一个自定义的角色，叫做"Observers"，这个角色可能是你的合规团队、财务团队、稽核员或是其他相关的非项目正规成员。

下表呈现了建议的通知设置：

标准和自定义通知

每个问题级别的活动都关联到一个事件，例如，每一次创建新的JIRA问题时，都会触发叫做"问题创建"的事件。当标准事件被触发的时候，JIRA会自动寄送邮件通知。标准案例：问题创建、分配、更新、解决等。某些事件的规则存储在JIRA内部，其他的存储在工作流转换的后处理功能里。

建议

不要忘记在工作流的“问题关闭”转换的后处理转换上设置“问题关闭”通知，将默认的功能从“一般事件”变成“问题关闭”。

此外，你能在自己自定义通知点上提醒收件人，这个自定义事件的触发器是在一些特定事件发生时用来提醒用户的。

示例

• 提醒研发主管，问题已经预备进行代码审查。

• 提醒测试团队，问题已经预备要验证

• 提醒高级主管需要批准

我们可以通过三个步骤添加自定义通知，第一，在管理页面系统->事件创建一个新的事件并选择"通用"模版，新的事件就能够在新的方案中被使用。第二，将用户、角色、组添加到关联的通知方案的新事件中。第三，在关联的工作流上添加一个后处理转换，以触发事件通知。

在下面示例中，让我们用这三个步骤来添加称为"Ready for Verification"自定义通知。

新事件

通知方案分配

工作流后处理功能

批量变更通知

“批量变更”功能可以一次修改多个问题，例如，一步骤解决五十个问题，在全局权限中定义了谁可以使用这个功能。

建议

当基于管理原因进行批量变更问题的时候，在“步骤3/4:操作细节”页面时出现时，取消选择"Send mail for this update"选项。注意：这个复选框只有具备项目等级的管理权限的用户才能看到，允许管理员在“幕后”进行批量变更而不会产生多余的通知邮件。这个变动预期会记录在数据库中并且显示在问题“活动”区域里。

关于《JIRA策略管理实战手册》

本文节选自《JIRA策略管理实战手册》，为Jira管理员提供配置、清理和维护Jira的模板。

此实战手册包含：

• 152条建议- 帮助您设置、清理和维护Jira

• 50个工作表，以及其他相关模板、代码片段和示例

• 33个需避免的反面真实案例

• 每个管理区域的最佳实践和注意事项

• 作者作为管理员犯下的十大错误

关于翻译，编辑和审稿人