GitLab通知邮件

GitLab有一个通知系统，可以将对工作流重要的事件通知用户。

通知设置

您可以在用户配置文件下找到通知设置。

通知设置分为三组:

• 全局设置
• 组设置
• 项目设置

这些设置都有通知级别:

• 禁用-关闭通知
• 参与—接收相关资源的通知
• 观察-接收来自项目或组用户是成员的通知
• 全局-在全局设置中设置的通知
• 自定义用户将收到通知时提到，是参与者和自定义选择的事件。

全局设置

全局设置位于层次结构的底部。此处设置的任何设置都将被组或项目级别的设置覆盖。

组或项目设置可以使用全球通知设置，然后使用在全局设置中设置的任何内容。

组设置

组设置优先于全局设置，但位于项目设置之下。这意味着您可以为每个组设置不同级别的通知，同时仍然能够为每个项目设置更精细的级别。这样的组织适合属于不同组的用户，但不需要为他们所属的每个组收到通知。这些设置可以在组页面上以组的名称进行配置。它将是带有铃铛图标的下拉菜单。也可以在用户配置文件通知下拉菜单中配置它们。

项目设置

项目设置位于最高级别，在此级别放置的任何设置将优先于任何其他设置。这适用于每个项目对通知有不同需求的用户。这些设置可以在项目页面的项目名称下进行配置。它将是带有铃铛图标的下拉菜单。也可以在用户配置文件通知下拉菜单中配置它们。

通知事件

下面是用户可以被通知的事件表:

事件	发送到	设置水平
新增SSH密钥	用户	安全邮件，时时发送。
新增电子邮件	用户	安全邮件，时时发送。
创建新用户	用户	在用户创建时发送，除了omniauth (LDAP)
添加到项目中的用户	用户	用户添加到项目时发送
项目访问级别更改	用户	更改用户项目访问级别时发送
用户加入组	用户	用户加入组时发送
组访问级别更改	用户	修改用户组访问级别时发送
项目的进展	项目成员[1]	[1]未禁用

发布/合并请求事件

在下列大多数情况下，通知将被发送至:

• 参与者:

  • 问题/合并请求的作者和受让人
  • 对问题/合并请求进行评论的作者
  • 有人提到@用户名在问题/合并请求的标题或描述中
  • 有人提到@用户名在问题/合并请求的任何评论中

  …通知级别为“参与”或更高

• 观察者:通知级别为“观察”的用户

• 订阅者:任何手动订阅issue/合并请求的人

• 自定义:通知级别为“自定义”的用户，他们为下表中出现的任何事件打开通知

事件	发送到
新问题
关闭问题
再分配问题	以上，加上老受让人
开放的问题
由于问题	选择此事件的参与者和自定义通知级别
新的合并请求
推送合并请求	选择此事件的参与者和自定义通知级别
重新分配合并请求	以上，加上老受让人
关闭合并请求
重新打开合并请求
合并请求
新的评论	上面提到的，再加上@用户名在评论中，通知级别为“提及”或更高
失败的管道	管道的作者
成功的管道	管道的作者，如果他们为成功的管道设置了自定义通知设置

此外，如果问题或合并请求的标题或描述发生更改，通知将发送到任何新提到的@用户名就好像他们在原文中被提到过一样。

您将不会收到由您自己创建的问题、合并请求或里程碑的通知(除非某个问题到期)。你只会收到自动通知，当有人评论或添加更改，你已经创建或提及你。

邮件标题

通知邮件包括标题，提供关于收到的通知的额外内容:

头	描述
X-GitLab-Project	通知所属项目的名称
X-GitLab-Project-Id	项目ID
X-GitLab-Project-Path	项目的路径
X-GitLab - id(资源)	通知所针对的资源的ID，资源所在的位置问题，MergeRequest，提交等
X-GitLab-Discussion-ID	只有在评论邮件中，评论来自讨论的ID
X-GitLab-Pipeline-Id	只有在管道邮件中，通知所针对的管道ID
X-GitLab-Reply-Key	支持通过电子邮件回复的唯一令牌
X-GitLab-NotificationReason	被通知的原因。“提到的”、“指定的”等等

X-GitLab-NotificationReason

这个报头保存通知发出的原因，原因可以是提到，分配，own_activity等。根据优先级只发送一个原因:

• own_activity
• 分配
• 提到

此标题中的原因也将显示在通知电子邮件的页脚中。比如一封写着原因的电子邮件分配在页脚会有这句话:"您收到此邮件是因为您已在{配置的GitLab主机名}上分配了一个项目"

注意:到目前为止，只实现了上面列出的原因进一步的实现是这里正在讨论