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/metabaseMetabase 的通知功能由**警报Alerts与仪表板订阅Dashboard Subscriptions**两类构成本文聚焦其背后的权限模型不同权限组All Users、管理员、启用了数据模拟或行列安全的高级权限组分别能对通知做什么以及通知收件人实际能看到哪些数据。读完本文你将掌握 Metabase 通知权限的完整判定规则、创建者权限原则Creators Permissions以及企业版 / 专业版中可用的邮件通知管控手段并能对照后端源码理解其实现机制。通知权限概览Alerts 与 Dashboard Subscriptions在深入权限细节之前需要先明确 Metabase 中通知一词的具体范围。按 docs/permissions/notifications.md 的定义通知Notifications只包括两种功能警报Alerts针对单个问题Question的结果设置触发条件当问题返回结果、时间序列越过目标线或进度条达到目标时通过 email、Slack 或 webhook 通知相关人员。仪表板订阅Dashboard Subscriptions按小时、每天、每周或每月定期把仪表板上各卡片的结果发送给指定收件人email 或 Slack甚至可以发给没有 Metabase 账号的人。两类功能的启用前提一致管理员必须先在 Metabase 中配置好至少一个通知渠道——email、Slack 或 webhookwebhook 仅限管理员及拥有 设置访问权限 的人使用。权限模型围绕三个核心问题展开谁能创建、编辑、删除通知谁可以作为收件人被添加收件人在通知邮件里能看到什么数据谁可以编辑仪表板订阅和警报你对警报和仪表板订阅的编辑能力取决于你所在的权限组类型。Metabase 将用户分为三类场景分别对待All Users 组所有用户都在其中启用了模拟Impersonation或行列安全Row and Column Security的组管理员组AdministratorsAll 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 cant create Slack subscriptions or alerts一节也有完全一致的表述。为什么会有这条限制原因在于权限粒度模拟与行列安全都属于数据级细粒度控制。Slack 通知是面向频道如#general或单个 Slack 用户的Metabase 无法像 email 那样按收件人逐一映射其细粒度数据权限因此直接禁止这类组创建 Slack 通知以避免细粒度数据被间接暴露。此外对于 email 警报和订阅这些组的人在收件人列表中只能看到自己——即列表不会向他们展示其他 Metabase 用户的姓名以供添加。管理员组拥有通知的完全控制权管理员组成员在通知方面拥有最高权限可以查看所有订阅和警报无论谁创建的。添加或移除任意现有订阅或警报的收件人——包括他人创建的通知。关键点在于管理员这样做时不会改变该警报或订阅的权限基线。例如管理员给 Beau 创建的订阅添加收件人 AnyaAnya 收到的邮件中数据仍是Beau 能看到的数据而不是管理员能看到的数据。删除任意订阅或警报。从管理视角看管理员还有两个批量管理入口在Admin 设置 People菜单中按人批量管理可一键退订某个用户的全部订阅和警报参见 docs/people-and-groups/managing.md。在Monitor Alerts management中批量管理实例内全部警报参见 docs/monitor/alerts-management.md。创建者权限原则通知收件人能看到什么通知权限模型中最核心、也最容易被误解的一条原则是通知收件人看到的数据 通知创建者能看到的数据。官方文档给出了一个非常直观的例子Beau 创建了一个指向自己**个人收藏Personal Collection**中某个仪表板的订阅个人收藏说明见 docs/exploration-and-organization/collections.md。Beau 把 Anya 添加为该仪表板订阅的收件人。结果Anya 虽然没有查看 Beau 个人收藏中该仪表板的权限却会在邮件中收到该仪表板的结果。换句话说通知投递时使用的数据视角完全基于创建者与收件人自己的数据权限、集合权限无关。这既是便利可以跨权限边界分享数据快照也是安全风险点——因此在向通知添加外部收件人前创建者应当充分意识到收件人将看到你所能看到的一切在通知所涉及问题/仪表板范围内。这一原则在 docs/questions/alerts.md 中还有若干旁证式的安全细节嵌入式问题中的警报会移除链接由于查看嵌入式问题的人通常无法直接访问 Metabase嵌入问题发出的警报邮件会省略指向 Metabase 条目的链接避免收件人收到失效链接。自定义可视化回退到默认图表Metabase 渲染警报时没有用户登录态使用自定义可视化的问题会回退到默认可视化。创建者账号停用不影响已存在的通知只要警报面向多个收件人或 Slack 频道即使创建者账号已被停用警报仍会继续工作只是不再向停用的账号发送。创建、编辑与退订的完整能力矩阵综合 docs/permissions/notifications.md 与 docs/questions/alerts.md、docs/dashboards/subscriptions.md可将通知操作能力归纳为下表操作普通用户All Users模拟/行列安全组用户管理员创建警报 / 仪表板订阅✅email / Slack✅ 仅 email不能 Slack✅给自己创建的通知添加收件人✅✅ 仅 email且收件人列表只见自己✅编辑自己创建的通知✅✅ 仅 email✅编辑他人创建的通知❌❌✅删除他人创建的通知❌❌✅退订任何自己相关的通知账户设置✅✅✅在收件人列表中看到其他用户✅❌只见自己✅使用 webhook 作为通知渠道❌需设置访问权限❌✅补充说明普通用户可以编辑自己创建的警报但不能编辑他人创建的任何人可以点击右上角个人资料进入账户设置在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只建议与创建者同组的用户例如可用来把收件人限制在同组成员范围内。Dont 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。通知权限与安全的最佳实践综合文档与源码实践中的关键建议如下向通知添加收件人前先想清楚数据范围收件人看到的是创建者的数据视角。创建者权限越大通知邮件中泄露数据的风险越高。对高级权限组慎用 Slack 通知模拟与行列安全组无法创建 Slack 通知这是刻意的安全设计如需为其发送通知请使用 email 渠道。管理员添加收件人不会改变数据基线管理员给通知加人数据仍按原创建者的权限渲染不会因为管理员权限更高而扩大收件人的可见范围——这一点对审计特别重要。利用批准域名与建议收件人限制企业版 / 专业版可通过 email 设置 中的批准域名与建议收件人选项把通知投递范围约束在受控邮箱域与用户组内。结合集合权限保护敏感数据行列安全不适用于 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Metabase 通知权限（Notification Permissions）完全指南：谁可以创建、编辑订阅与警报，收件人又能看到什么
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/metabaseMetabase 的通知功能由**警报Alerts与仪表板订阅Dashboard Subscriptions**两类构成本文聚焦其背后的权限模型不同权限组All Users、管理员、启用了数据模拟或行列安全的高级权限组分别能对通知做什么以及通知收件人实际能看到哪些数据。读完本文你将掌握 Metabase 通知权限的完整判定规则、创建者权限原则Creators Permissions以及企业版 / 专业版中可用的邮件通知管控手段并能对照后端源码理解其实现机制。通知权限概览Alerts 与 Dashboard Subscriptions在深入权限细节之前需要先明确 Metabase 中通知一词的具体范围。按 docs/permissions/notifications.md 的定义通知Notifications只包括两种功能警报Alerts针对单个问题Question的结果设置触发条件当问题返回结果、时间序列越过目标线或进度条达到目标时通过 email、Slack 或 webhook 通知相关人员。仪表板订阅Dashboard Subscriptions按小时、每天、每周或每月定期把仪表板上各卡片的结果发送给指定收件人email 或 Slack甚至可以发给没有 Metabase 账号的人。两类功能的启用前提一致管理员必须先在 Metabase 中配置好至少一个通知渠道——email、Slack 或 webhookwebhook 仅限管理员及拥有 设置访问权限 的人使用。权限模型围绕三个核心问题展开谁能创建、编辑、删除通知谁可以作为收件人被添加收件人在通知邮件里能看到什么数据谁可以编辑仪表板订阅和警报你对警报和仪表板订阅的编辑能力取决于你所在的权限组类型。Metabase 将用户分为三类场景分别对待All Users 组所有用户都在其中启用了模拟Impersonation或行列安全Row and Column Security的组管理员组AdministratorsAll 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 cant create Slack subscriptions or alerts一节也有完全一致的表述。为什么会有这条限制原因在于权限粒度模拟与行列安全都属于数据级细粒度控制。Slack 通知是面向频道如#general或单个 Slack 用户的Metabase 无法像 email 那样按收件人逐一映射其细粒度数据权限因此直接禁止这类组创建 Slack 通知以避免细粒度数据被间接暴露。此外对于 email 警报和订阅这些组的人在收件人列表中只能看到自己——即列表不会向他们展示其他 Metabase 用户的姓名以供添加。管理员组拥有通知的完全控制权管理员组成员在通知方面拥有最高权限可以查看所有订阅和警报无论谁创建的。添加或移除任意现有订阅或警报的收件人——包括他人创建的通知。关键点在于管理员这样做时不会改变该警报或订阅的权限基线。例如管理员给 Beau 创建的订阅添加收件人 AnyaAnya 收到的邮件中数据仍是Beau 能看到的数据而不是管理员能看到的数据。删除任意订阅或警报。从管理视角看管理员还有两个批量管理入口在Admin 设置 People菜单中按人批量管理可一键退订某个用户的全部订阅和警报参见 docs/people-and-groups/managing.md。在Monitor Alerts management中批量管理实例内全部警报参见 docs/monitor/alerts-management.md。创建者权限原则通知收件人能看到什么通知权限模型中最核心、也最容易被误解的一条原则是通知收件人看到的数据 通知创建者能看到的数据。官方文档给出了一个非常直观的例子Beau 创建了一个指向自己**个人收藏Personal Collection**中某个仪表板的订阅个人收藏说明见 docs/exploration-and-organization/collections.md。Beau 把 Anya 添加为该仪表板订阅的收件人。结果Anya 虽然没有查看 Beau 个人收藏中该仪表板的权限却会在邮件中收到该仪表板的结果。换句话说通知投递时使用的数据视角完全基于创建者与收件人自己的数据权限、集合权限无关。这既是便利可以跨权限边界分享数据快照也是安全风险点——因此在向通知添加外部收件人前创建者应当充分意识到收件人将看到你所能看到的一切在通知所涉及问题/仪表板范围内。这一原则在 docs/questions/alerts.md 中还有若干旁证式的安全细节嵌入式问题中的警报会移除链接由于查看嵌入式问题的人通常无法直接访问 Metabase嵌入问题发出的警报邮件会省略指向 Metabase 条目的链接避免收件人收到失效链接。自定义可视化回退到默认图表Metabase 渲染警报时没有用户登录态使用自定义可视化的问题会回退到默认可视化。创建者账号停用不影响已存在的通知只要警报面向多个收件人或 Slack 频道即使创建者账号已被停用警报仍会继续工作只是不再向停用的账号发送。创建、编辑与退订的完整能力矩阵综合 docs/permissions/notifications.md 与 docs/questions/alerts.md、docs/dashboards/subscriptions.md可将通知操作能力归纳为下表操作普通用户All Users模拟/行列安全组用户管理员创建警报 / 仪表板订阅✅email / Slack✅ 仅 email不能 Slack✅给自己创建的通知添加收件人✅✅ 仅 email且收件人列表只见自己✅编辑自己创建的通知✅✅ 仅 email✅编辑他人创建的通知❌❌✅删除他人创建的通知❌❌✅退订任何自己相关的通知账户设置✅✅✅在收件人列表中看到其他用户✅❌只见自己✅使用 webhook 作为通知渠道❌需设置访问权限❌✅补充说明普通用户可以编辑自己创建的警报但不能编辑他人创建的任何人可以点击右上角个人资料进入账户设置在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只建议与创建者同组的用户例如可用来把收件人限制在同组成员范围内。Dont 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。通知权限与安全的最佳实践综合文档与源码实践中的关键建议如下向通知添加收件人前先想清楚数据范围收件人看到的是创建者的数据视角。创建者权限越大通知邮件中泄露数据的风险越高。对高级权限组慎用 Slack 通知模拟与行列安全组无法创建 Slack 通知这是刻意的安全设计如需为其发送通知请使用 email 渠道。管理员添加收件人不会改变数据基线管理员给通知加人数据仍按原创建者的权限渲染不会因为管理员权限更高而扩大收件人的可见范围——这一点对审计特别重要。利用批准域名与建议收件人限制企业版 / 专业版可通过 email 设置 中的批准域名与建议收件人选项把通知投递范围约束在受控邮箱域与用户组内。结合集合权限保护敏感数据行列安全不适用于 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
