企业官网建设流程全解析

Metabase 通知权限（Notification Permissions）完全指南：谁可以创建、编辑订阅与警报，收件人又能看到什么

【免费下载链接】metabaseThe easy-to-use open source Business Intelligence and Embedded Analytics tool that lets everyone work with data :bar_chart:项目地址: https://gitcode.com/GitHub_Trending/me/metabase

Metabase 的通知功能由**警报（Alerts）与仪表板订阅（Dashboard Subscriptions）**两类构成，本文聚焦其背后的权限模型：不同权限组（All Users、管理员、启用了数据模拟或行列安全的高级权限组）分别能对通知做什么，以及通知收件人实际能看到哪些数据。读完本文，你将掌握 Metabase 通知权限的完整判定规则、创建者权限原则（Creator's Permissions）以及企业版 / 专业版中可用的邮件通知管控手段，并能对照后端源码理解其实现机制。

通知权限概览：Alerts 与 Dashboard Subscriptions

在深入权限细节之前，需要先明确 Metabase 中"通知"一词的具体范围。按 docs/permissions/notifications.md 的定义，通知（Notifications）只包括两种功能：

• 警报（Alerts）：针对单个问题（Question）的结果设置触发条件，当问题返回结果、时间序列越过目标线或进度条达到目标时，通过 email、Slack 或 webhook 通知相关人员。
• 仪表板订阅（Dashboard Subscriptions）：按小时、每天、每周或每月定期把仪表板上各卡片的结果发送给指定收件人（email 或 Slack），甚至可以发给没有 Metabase 账号的人。

两类功能的启用前提一致：管理员必须先在 Metabase 中配置好至少一个通知渠道——email、Slack 或 webhook（webhook 仅限管理员及拥有 设置访问权限 的人使用）。

权限模型围绕三个核心问题展开：

1. 谁能创建、编辑、删除通知？
2. 谁可以作为收件人被添加？
3. 收件人在通知邮件里能看到什么数据？

谁可以编辑仪表板订阅和警报

你对警报和仪表板订阅的编辑能力，取决于你所在的权限组类型。Metabase 将用户分为三类场景分别对待：

• All Users 组（所有用户都在其中）
• 启用了模拟（Impersonation）或行列安全（Row and Column Security）的组
• 管理员组（Administrators）

All Users 组：人人皆可创建通知

Metabase 中每个人都是 All Users 组的成员，因此每个人默认都可以：

• 创建警报 和 仪表板订阅。
• 为自己创建的警报或订阅添加新收件人。
• 在账户设置（Account settings）中退订任何自己订阅或被添加的警报或订阅。入口为：点击右上角的个人资料图标，进入 账户设置 中的Notifications页面，可以查看并管理所有与自己相关的通知。

这里有一个关键行为需要注意：当通知创建者向警报或订阅添加新收件人时，Metabase 会以创建者的数据权限和集合权限来决定展示给收件人的数据（详见下文"创建者权限原则"）。也就是说，收件人看到的数据量与创建者能看到的完全一致，而不是收件人自己权限范围的数据。

启用了模拟或行列安全的组：Slack 通知受限

对于启用了 模拟权限（Impersonation） 或 行列安全（Row and Column Security） 的组，存在一条重要限制：

这些组的人不能创建 Slack 警报或 Slack 仪表板订阅，但仍然可以设置email警报和订阅。

这条规则在相关文档中反复出现并被明确相互引用：

• docs/permissions/impersonation.md 中的"Impersonation and Slack notifications"一节明确写道：处于模拟访问组的用户无法创建 Slack 警报或 Slack 仪表板订阅，email 警报与订阅仍然可用，并直接指向通知权限文档。
• docs/permissions/row-and-column-security.md 的"People with row and column security can't create Slack subscriptions or alerts"一节也有完全一致的表述。

为什么会有这条限制？原因在于权限粒度：模拟与行列安全都属于数据级细粒度控制。Slack 通知是面向频道（如#general）或单个 Slack 用户的，Metabase 无法像 email 那样按收件人逐一映射其细粒度数据权限，因此直接禁止这类组创建 Slack 通知，以避免细粒度数据被间接暴露。

此外，对于 email 警报和订阅，这些组的人在收件人列表中只能看到自己——即列表不会向他们展示其他 Metabase 用户的姓名以供添加。

管理员组：拥有通知的完全控制权

管理员组成员在通知方面拥有最高权限，可以：

• 查看所有订阅和警报（无论谁创建的）。
• 添加或移除任意现有订阅或警报的收件人——包括他人创建的通知。关键点在于：管理员这样做时不会改变该警报或订阅的权限基线。例如，管理员给 Beau 创建的订阅添加收件人 Anya，Anya 收到的邮件中数据仍是Beau 能看到的数据，而不是管理员能看到的数据。
• 删除任意订阅或警报。

从管理视角看，管理员还有两个批量管理入口：

• 在Admin 设置 > People菜单中按人批量管理：可一键退订某个用户的全部订阅和警报，参见 docs/people-and-groups/managing.md。
• 在Monitor > Alerts management中批量管理实例内全部警报，参见 docs/monitor/alerts-management.md。

创建者权限原则：通知收件人能看到什么

通知权限模型中最核心、也最容易被误解的一条原则是：

通知收件人看到的数据 = 通知创建者能看到的数据。

官方文档给出了一个非常直观的例子：

1. Beau 创建了一个指向自己**个人收藏（Personal Collection）**中某个仪表板的订阅（个人收藏说明见 docs/exploration-and-organization/collections.md）。
2. Beau 把 Anya 添加为该仪表板订阅的收件人。
3. 结果：Anya 虽然没有查看 Beau 个人收藏中该仪表板的权限，却会在邮件中收到该仪表板的结果。

换句话说，通知投递时使用的"数据视角"完全基于创建者，与收件人自己的数据权限、集合权限无关。这既是便利（可以跨权限边界分享数据快照），也是安全风险点——因此在向通知添加外部收件人前，创建者应当充分意识到：收件人将看到你所能看到的一切（在通知所涉及问题/仪表板范围内）。

这一原则在 docs/questions/alerts.md 中还有若干旁证式的安全细节：

• 嵌入式问题中的警报会移除链接：由于查看嵌入式问题的人通常无法直接访问 Metabase，嵌入问题发出的警报邮件会省略指向 Metabase 条目的链接，避免收件人收到失效链接。
• 自定义可视化回退到默认图表：Metabase 渲染警报时没有用户登录态，使用自定义可视化的问题会回退到默认可视化。
• 创建者账号停用不影响已存在的通知：只要警报面向多个收件人或 Slack 频道，即使创建者账号已被停用，警报仍会继续工作（只是不再向停用的账号发送）。

创建、编辑与退订的完整能力矩阵

综合 docs/permissions/notifications.md 与 docs/questions/alerts.md、docs/dashboards/subscriptions.md，可将通知操作能力归纳为下表：

补充说明：普通用户可以编辑自己创建的警报（但不能编辑他人创建的）；任何人可以点击右上角个人资料进入账户设置，在Notifications页面查看并退订所有自己收到的通知。管理员则可以对任何警报进行编辑与删除（该操作不可撤销），也可以在任何警报上添加或移除收件人。

企业版 / 专业版：更细粒度的邮件通知管控

在 Metabase 的企业版（Enterprise）和专业版（Pro）计划中，管理员还可以进一步管控 email 通知的收件人边界，相关设置位于Admin > Settings > Email，完整说明见 docs/configuring-metabase/email.md。

通知的批准域名（Approved domains for notifications）

管理员可以配置允许的 email 地址域名，从而限制人们能把通知（订阅和警报）发送给哪些邮箱：

• 该限制仅针对没有 Metabase 账号的外部邮箱地址；对已有账号的用户不生效——未被行列安全限制的账号用户可以给同一 Metabase 中的任何其他账号用户发通知。
• 配置方式：Admin > Settings > Email > Allowed domains for notifications。
  • 留空表示允许所有域名（默认行为）。
  • 多个域名用英文逗号分隔且不加空格，例如domain1,domain2。
• 自托管部署也可通过环境变量MB_SUBSCRIPTION_ALLOWED_DOMAINS设置。
• 注意：修改该设置不会影响已存在的订阅和警报，只约束新建的通知。

限制通知中的建议收件人（Suggested recipients）

管理员还可以控制人们在新建仪表板订阅或警报时能看到哪些建议收件人，选项有三档：

• Suggest all users：建议所有用户。
• Only suggest users in the same groups：只建议与创建者同组的用户（例如可用来把收件人限制在同组成员范围内）。
• Don't show suggestions：不显示任何建议。

特别地，受行列安全限制的用户不会看到任何建议——这与"收件人列表只见自己"的规则一脉相承。

源码视角：通知权限在后端如何落地

从源码层面可以印证上述权限模型的实现位置。通知相关的权限校验集中在 src/metabase/notification/models.clj 中，核心逻辑如下：

;; 创建通知时校验当前用户权限（src/metabase/notification/models.clj） ;; 如果启用了 advanced-permissions（企业级权限），要求用户具备 :subscription 应用权限 (or (not (premium-features/has-feature? :advanced-permissions)) (perms/current-user-has-application-permissions? :subscription))

这段代码在创建（can-create?）、更新（can-update?）以及读取通知负载（can-read-payload?）等多个检查点出现，含义是：

• **未启用高级权限功能（非企业版）**时，不额外校验:subscription权限，即符合"All Users 人人可创建"的默认行为；
• 启用高级权限功能后，则要求当前用户具备名为subscription的应用级权限（Application Permissions）才能创建、编辑或读取通知内容。

也就是说，通知权限在 Metabase 权限体系中属于**应用权限（Application Permissions）**的一种（对应 docs/permissions/application.md），而数据可见范围则由创建者的数据权限与集合权限决定——这与文档所述的"创建者权限原则"完全一致。理解这一点有助于排查通知相关的权限问题：若某用户无法创建订阅，优先检查其所在组的应用权限是否包含subscription。

通知权限与安全的最佳实践

综合文档与源码，实践中的关键建议如下：

1. 向通知添加收件人前先想清楚数据范围：收件人看到的是创建者的数据视角。创建者权限越大，通知邮件中泄露数据的风险越高。
2. 对高级权限组慎用 Slack 通知：模拟与行列安全组无法创建 Slack 通知，这是刻意的安全设计；如需为其发送通知，请使用 email 渠道。
3. 管理员添加收件人不会改变数据基线：管理员给通知加人，数据仍按原创建者的权限渲染，不会因为管理员权限更高而扩大收件人的可见范围——这一点对审计特别重要。
4. 利用批准域名与建议收件人限制：企业版 / 专业版可通过 email 设置 中的批准域名与建议收件人选项，把通知投递范围约束在受控邮箱域与用户组内。
5. 结合集合权限保护敏感数据：行列安全不适用于 SQL 问题结果，若某列数据可能通过警报或订阅被间接共享，参见 docs/permissions/row-and-column-security.md 中的冲突规避章节（"Someone else in a non-secured group shares the Email column from... an alert, or dashboard subscription"）。

进一步阅读

• 警报（Alerts）完整指南
• 仪表板订阅（Dashboard Subscriptions）完整指南
• 设置 email
• 模拟权限（Impersonation）
• 行列安全（Row and Column Security）
• 账户设置与通知管理
• 数据权限（Data Permissions）
• 集合权限（Collection Permissions）

【免费下载链接】metabaseThe easy-to-use open source Business Intelligence and Embedded Analytics tool that lets everyone work with data :bar_chart:项目地址: https://gitcode.com/GitHub_Trending/me/metabase