Metabase 集合权限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导读集合Collection是 Metabase 中组织问题Questions、仪表板Dashboards、模型Models、时间线Timelines等内容的文件夹式容器而集合权限决定了哪些用户组可以查看、编辑和整理这些内容。本指南以 docs/permissions/collections.md 为核心系统讲解 Metabase 的三级集合权限模型Curate / View / No access、集合权限与数据权限的边界、子集合继承规则、多集合仪表板的权限叠加效应并结合仓库源码深入剖析集合权限图Permissions Graph的底层实现帮助管理员正确规划并落地一套安全、可维护的权限体系。集合权限概述Metabase 默认提供Our analytics顶层集合所有其他集合都被保存在其中。你可以用 集合 来组织问题、仪表板、模型、时间线以及其他子集合并为每个 用户组 配置对某个集合的访问级别从而决定该组能看什么、能改什么。集合权限的本质从源码看是围绕/collection/路径构造的权限对象。在 src/metabase/permissions/models/permissions.clj 中可以看到权限路径定义/collection/:id/—— 对某个集合及其非集合子项如问题、仪表板的读写权限/collection/:id/read/—— 对某个集合及其非集合子项的只读权限/collection/root/与/collection/root/read/—— 对根集合Our analytics的读写 / 只读权限/collection/namespace/:namespace/root/—— 非默认命名空间例如 SQL 片段根集合的读写权限。也就是说集合权限最终落库为一张组 → 集合 → 读写/只读的授权图前端的管理界面只是这张图的编辑入口。集合权限的三种级别Metabase 为集合提供三个权限级别Curate access策展访问View access查看访问[No access](#no access)无访问权限三种级别对集合内具体操作的能力矩阵如下操作Curate AccessView AccessNo Access查看条目✅✅❌编辑条目的标题与描述✅❌❌移动条目✅❌❌删除条目✅❌❌置顶Pin条目✅❌❌查看事件与时间线✅✅❌编辑事件与时间线✅❌❌Curate access策展访问拥有 Curate 权限的组可以查看、编辑、移动、删除、置顶该集合中保存的条目向该集合保存或移入新条目在该集合内部创建新的子集合创建和编辑事件与时间线。注意Curate 权限包含 View 权限即拥有 Curate 的用户一定可以查看集合内容。View access查看访问拥有 View 权限的组可以看到集合中的所有问题、仪表板、模型以及事件与时间线但无法修改任何内容也无法向集合中放入新条目。用文档原文的话说Curate access includes View accessCurate 是 View 的超集。No access无访问权限该组看不到这个集合在侧边栏中的条目也无法访问其中保存的任何内容。被授予 No access 的集合对用户来说完全不可见。从源码实现看这三种级别在权限图中被编码为三个枚举值。在 src/metabase/permissions/models/collection/graph.clj 中(def ^:private CollectionPermissions [:enum :write :read :none])其中:write对应 Curate可读可写、:read对应 View只读、:none对应 No access。权限图更新逻辑 update-collection-permissions! 会先撤销该组在目标集合上已有的权限条目再按新值写入(case new-collection-perms :write (perms/grant-collection-readwrite-permissions! group-id collection-id) :read (perms/grant-collection-read-permissions! group-id collection-id) :none nil)集合权限 vs 数据权限一个经常被混淆的边界集合权限只决定能否查看和策展已有的问题、模型、仪表板它不决定能否基于底层数据新建或修改查询。修改已有问题的查询或创建新问题都需要该组对底层数据拥有对应的数据权限。有一个重要的例外当某个组对某个数据库或表的数据权限被设置为 Block 时即使该组对保存这些问题的集合拥有 Curate 权限也无法查看基于这些数据的问题。也就是说数据权限的 Block 会覆盖集合权限中的可见性这是权限体系中的一道强制隔离闸门。这一集合权限管内容组织、数据权限管数据访问的分层设计与源码中的权限路径体系一一对应数据权限作用于数据库/模式/表的路径集合权限作用于/collection/...路径二者独立落库、独立校验。包含多集合问题的仪表板如果一个仪表板中包含了保存在其他集合里的问题卡片那么用户需要对这些所有集合都拥有 View 或 Curate 权限才能看到这些卡片。如果用户缺少其中某个集合的权限Metabase 会显示权限不足的提示信息而不是渲染该卡片的内容。因此从权限管理的角度讲把仪表板的所有问题都保存在同一个集合里管理起来会简单得多。设置集合权限集合权限的配置入口打开某个集合页面点击页面右上角的锁形图标点击Edit permissions编辑权限。只有**管理员Administrators**可以编辑集合权限。每个用户组对每个集合只能被授予 View、Curate 或 No access 三者之一。如果想总览所有用户组对所有集合的权限可以点击See all collection permissions查看所有集合权限链接进入管理后台Admin Panel。左侧会列出所有集合点击任一集合即可看到每个组的权限设置。权限是可叠加的Additive与数据访问权限类似集合权限是**叠加additive**的如果用户属于多个组当这些组对该集合的权限设置不同时用户将获得其中**最宽松more permissive**的那个权限。这一点在涉及All users所有用户组时尤其关键由于每个用户都是 All users 组的成员一旦给 All users 组授予某个集合的 Curate 权限那么所有用户都会获得该集合的 Curate 权限——即使他们同时还属于权限更受限的其他组。从源码角度看这种取并集的行为体现在权限校验的路径匹配上只要当前用户所属的任一组的权限对象集合中包含目标集合的读/写路径见 src/metabase/permissions/util.clj 中的collection-read-path/collection-readwrite-path该用户就被判定为可读/可写。换言之集合权限的判定天然是任一组成员命中即放行。权限与子集合集合的嵌套让权限管理多了一层继承语义规则如下更改父集合的权限不会自动更改已有子集合的权限但所有新建的子集合会继承父集合的访问级别。例如有一个Campaigns集合内含子集合2025 reports。当你把 Data team 组对Campaigns的权限从 View 改为 Curate 后默认情况下 Data team 对Campaigns获得 Curate 权限但对2025 reports仍保留 View 权限。不过如果之后有人新建了子集合2026 reportsData team 会自动获得该新子集合的 Curate 权限——因为新子集合从父集合继承权限。如果希望已有子集合也一并变更可以在修改集合权限时勾选Also change sub-collections同时更改子集合选项。组可以被授予位于多层子集合深处的某个集合的权限而无需拥有其所有上级集合的权限。例如某个组对藏在Marketing集合深处数层的 Super Secret Collection 有访问权限但对Marketing本身无权限。此时 Super Secret Collection 会在该组实际拥有权限的最顶层显示出来。从源码实现看集合权限图与数据权限图的一个显著差异在于继承语义。在 graph.clj 的注释中明确写道Collections do not inherit permissions from ancestor Collections in the same way data permissions are inherited (e.g. full:readperms for a Database implies:readperms for all its schemas); a child object cannot have more restrictive permissions than its parent. Child Collectionscanhave more restrictive permissions than their parent.即数据权限是父强则子强的自上而下继承而集合权限中子集合可以拥有比父集合更严格的权限例如父集合为 View、子集合为 No access权限图在构建时会把所有集合平铺在同一层collection-id → :read | :write | :none并不要求祖先关系的权限一致性。删除集合对某个集合拥有 Curate 权限的用户可以把集合移入回收站Trash。回收站内可以恢复或彻底删除集合详见删除与恢复。在集合中置顶条目拥有 Curate 权限的用户可以在集合中**置顶Pin**条目。置顶后该条目会以醒目的卡片形式展示在集合页面的顶部。置顶操作点击条目名称旁边的图钉图标即可。需要注意集合本身不能被置顶在 Pro 或 Enterprise 计划中管理员可以将某些集合指定为 Official Collections官方集合官方集合带有黄色徽章其内容在搜索结果中拥有更高优先级可与内容验证配合形成可信内容源。特殊集合Our analyticsOur analytics 集合以及每个用户的个人集合是不可破坏的它们不能被归档、删除或修改权限永远存在。Usage analytics使用情况分析集合的权限说明参见 Usage analytics。个人集合Personal collections每个用户都拥有一个个人集合即使该用户对任何其他集合都没有 Curate 权限也始终可以在自己的个人集合中保存内容。关于个人集合的权限要点管理员可以查看和编辑每个用户的个人集合内容包括其他管理员的个人集合方法是查看 Our analytics 时点击侧边栏底部的Other users personal collections其他用户的个人集合链接。个人集合与其他集合的工作方式相同但权限是固定的无法更改。如果个人集合中的某个子集合被移动到其他集合该子集合将继承新父集合的权限。从源码看个人集合在权限系统中被特殊对待在 src/metabase/permissions/models/collection/graph.clj 中个人集合及其后代集合的 ID 会被从权限图中移除且更新权限图时会自动过滤掉它们——尝试修改个人集合权限的请求会被静默忽略。同时在集合列表 APIsrc/metabase/collections_rest/api.clj中非本人的其他用户个人子集合也会被过滤确保隐私隔离。Library 集合关于 Library 及其子集合的权限参见 Data Studio 的 Library 权限说明。重要提醒不要使用Library Data的集合权限来控制已发布表中数据的访问。对发布数据的访问控制应当使用数据权限Data permissions。外部集合External collections多租户场景下的外部集合类型及权限行为参见 Tenants External collections。集合权限的底层实现权限图Permissions Graph为了更透彻地理解上述规则这里补充一段源码层面的实现剖析。权限图的数据结构Metabase 用一个稀疏权限图sparse graph表示集合权限状态其结构为见 graph.clj{:revision int :groups {group-id {collection-id :read|:write :root :read|:write}}}要点图是稀疏的只包含具有显式权限:read或:write的组与集合条目没有权限的组和集合不会出现在图中个人集合及其后代永远不会出现在图中已归档、已进入回收站的集合会被排除指定collection-namespace时其他命名空间的集合会被排除权限图会记录revision修订号用于并发更新时的一致性检查。权限图的更新流程更新入口为update-graph!graph.clj其核心步骤包括过滤非法条目自动移除个人集合及其后代、其他命名空间的集合保证命名空间隔离计算差异将旧图与新图做 diff只对有变化的(group-id, collection-id)执行授权/撤销校验 Library 权限check-data-analyst-library-permissions会阻止修改 Data Analysts 组对 Library 集合的权限该组对 Library 始终拥有完整读写权限违规时返回 HTTP 400修订号检查check-revision-numbers防止并发修改冲突除非显式force?事务与审计所有变更在事务内写入并通过create-perms-revision!递增修订号同时异步记录变更前后的快照fill-revision-details!用于审计日志。其中授权动作:write/:read分别调用grant-collection-readwrite-permissions!/grant-collection-read-permissions!:none则仅撤销已有权限graph.clj。与个人集合、Library 的强制约束个人集合personal-collection-ids会找出所有个人集合及其后代更新时整体从图中剔除因此前端无法通过权限图 API 修改个人集合的权限——这与文档中个人集合权限固定、不可更改的描述完全一致LibraryData Analysts 组对 Library 集合拥有强制读写权限任何尝试削减该权限的变更都会被拒绝。实践建议与常见误区结合文档与源码整理几条落地建议从 All users 组入手由于 All users 组覆盖所有用户且权限取最宽松值建议先把 All users 组对共享集合设为 No access再为具体业务组逐级授予 View / Curate避免所有用户都能改的失控局面参考权限总览中的告警机制。区分集合权限与数据权限集合权限只控制内容组织与策展数据的读写由数据权限控制对敏感表务必配置数据权限的 Block即使某组拥有集合 Curate 权限也无法绕过。谨慎对待子集合继承修改父集合权限时注意默认不会级联到已有子集合如需批量变更勾选Also change sub-collections。仪表板与问题尽量同集合存放跨集合引用会要求用户对所有涉及的集合都有权限否则卡片无法渲染。个人集合适合个人草稿需要共享的内容应移动到公共集合管理员可以通过 Other users personal collections 查看所有用户的个人集合。延伸阅读集合Collections使用指南集合的创建、移动、置顶、清理与个人集合操作数据权限Data permissions数据库、模式、表的访问控制权限总览Permissions introduction组、数据权限、应用权限、SQL 片段权限的整体框架事件与时间线集合中事件的创建与权限删除与恢复集合与条目的回收站机制Library 权限官方内容源集合的权限约束多租户与外部集合Embedding 场景下的集合权限形态【免费下载链接】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 集合权限（Collection Permissions）完全指南：三级权限模型、继承规则与最佳实践
Metabase 集合权限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导读集合Collection是 Metabase 中组织问题Questions、仪表板Dashboards、模型Models、时间线Timelines等内容的文件夹式容器而集合权限决定了哪些用户组可以查看、编辑和整理这些内容。本指南以 docs/permissions/collections.md 为核心系统讲解 Metabase 的三级集合权限模型Curate / View / No access、集合权限与数据权限的边界、子集合继承规则、多集合仪表板的权限叠加效应并结合仓库源码深入剖析集合权限图Permissions Graph的底层实现帮助管理员正确规划并落地一套安全、可维护的权限体系。集合权限概述Metabase 默认提供Our analytics顶层集合所有其他集合都被保存在其中。你可以用 集合 来组织问题、仪表板、模型、时间线以及其他子集合并为每个 用户组 配置对某个集合的访问级别从而决定该组能看什么、能改什么。集合权限的本质从源码看是围绕/collection/路径构造的权限对象。在 src/metabase/permissions/models/permissions.clj 中可以看到权限路径定义/collection/:id/—— 对某个集合及其非集合子项如问题、仪表板的读写权限/collection/:id/read/—— 对某个集合及其非集合子项的只读权限/collection/root/与/collection/root/read/—— 对根集合Our analytics的读写 / 只读权限/collection/namespace/:namespace/root/—— 非默认命名空间例如 SQL 片段根集合的读写权限。也就是说集合权限最终落库为一张组 → 集合 → 读写/只读的授权图前端的管理界面只是这张图的编辑入口。集合权限的三种级别Metabase 为集合提供三个权限级别Curate access策展访问View access查看访问[No access](#no access)无访问权限三种级别对集合内具体操作的能力矩阵如下操作Curate AccessView AccessNo Access查看条目✅✅❌编辑条目的标题与描述✅❌❌移动条目✅❌❌删除条目✅❌❌置顶Pin条目✅❌❌查看事件与时间线✅✅❌编辑事件与时间线✅❌❌Curate access策展访问拥有 Curate 权限的组可以查看、编辑、移动、删除、置顶该集合中保存的条目向该集合保存或移入新条目在该集合内部创建新的子集合创建和编辑事件与时间线。注意Curate 权限包含 View 权限即拥有 Curate 的用户一定可以查看集合内容。View access查看访问拥有 View 权限的组可以看到集合中的所有问题、仪表板、模型以及事件与时间线但无法修改任何内容也无法向集合中放入新条目。用文档原文的话说Curate access includes View accessCurate 是 View 的超集。No access无访问权限该组看不到这个集合在侧边栏中的条目也无法访问其中保存的任何内容。被授予 No access 的集合对用户来说完全不可见。从源码实现看这三种级别在权限图中被编码为三个枚举值。在 src/metabase/permissions/models/collection/graph.clj 中(def ^:private CollectionPermissions [:enum :write :read :none])其中:write对应 Curate可读可写、:read对应 View只读、:none对应 No access。权限图更新逻辑 update-collection-permissions! 会先撤销该组在目标集合上已有的权限条目再按新值写入(case new-collection-perms :write (perms/grant-collection-readwrite-permissions! group-id collection-id) :read (perms/grant-collection-read-permissions! group-id collection-id) :none nil)集合权限 vs 数据权限一个经常被混淆的边界集合权限只决定能否查看和策展已有的问题、模型、仪表板它不决定能否基于底层数据新建或修改查询。修改已有问题的查询或创建新问题都需要该组对底层数据拥有对应的数据权限。有一个重要的例外当某个组对某个数据库或表的数据权限被设置为 Block 时即使该组对保存这些问题的集合拥有 Curate 权限也无法查看基于这些数据的问题。也就是说数据权限的 Block 会覆盖集合权限中的可见性这是权限体系中的一道强制隔离闸门。这一集合权限管内容组织、数据权限管数据访问的分层设计与源码中的权限路径体系一一对应数据权限作用于数据库/模式/表的路径集合权限作用于/collection/...路径二者独立落库、独立校验。包含多集合问题的仪表板如果一个仪表板中包含了保存在其他集合里的问题卡片那么用户需要对这些所有集合都拥有 View 或 Curate 权限才能看到这些卡片。如果用户缺少其中某个集合的权限Metabase 会显示权限不足的提示信息而不是渲染该卡片的内容。因此从权限管理的角度讲把仪表板的所有问题都保存在同一个集合里管理起来会简单得多。设置集合权限集合权限的配置入口打开某个集合页面点击页面右上角的锁形图标点击Edit permissions编辑权限。只有**管理员Administrators**可以编辑集合权限。每个用户组对每个集合只能被授予 View、Curate 或 No access 三者之一。如果想总览所有用户组对所有集合的权限可以点击See all collection permissions查看所有集合权限链接进入管理后台Admin Panel。左侧会列出所有集合点击任一集合即可看到每个组的权限设置。权限是可叠加的Additive与数据访问权限类似集合权限是**叠加additive**的如果用户属于多个组当这些组对该集合的权限设置不同时用户将获得其中**最宽松more permissive**的那个权限。这一点在涉及All users所有用户组时尤其关键由于每个用户都是 All users 组的成员一旦给 All users 组授予某个集合的 Curate 权限那么所有用户都会获得该集合的 Curate 权限——即使他们同时还属于权限更受限的其他组。从源码角度看这种取并集的行为体现在权限校验的路径匹配上只要当前用户所属的任一组的权限对象集合中包含目标集合的读/写路径见 src/metabase/permissions/util.clj 中的collection-read-path/collection-readwrite-path该用户就被判定为可读/可写。换言之集合权限的判定天然是任一组成员命中即放行。权限与子集合集合的嵌套让权限管理多了一层继承语义规则如下更改父集合的权限不会自动更改已有子集合的权限但所有新建的子集合会继承父集合的访问级别。例如有一个Campaigns集合内含子集合2025 reports。当你把 Data team 组对Campaigns的权限从 View 改为 Curate 后默认情况下 Data team 对Campaigns获得 Curate 权限但对2025 reports仍保留 View 权限。不过如果之后有人新建了子集合2026 reportsData team 会自动获得该新子集合的 Curate 权限——因为新子集合从父集合继承权限。如果希望已有子集合也一并变更可以在修改集合权限时勾选Also change sub-collections同时更改子集合选项。组可以被授予位于多层子集合深处的某个集合的权限而无需拥有其所有上级集合的权限。例如某个组对藏在Marketing集合深处数层的 Super Secret Collection 有访问权限但对Marketing本身无权限。此时 Super Secret Collection 会在该组实际拥有权限的最顶层显示出来。从源码实现看集合权限图与数据权限图的一个显著差异在于继承语义。在 graph.clj 的注释中明确写道Collections do not inherit permissions from ancestor Collections in the same way data permissions are inherited (e.g. full:readperms for a Database implies:readperms for all its schemas); a child object cannot have more restrictive permissions than its parent. Child Collectionscanhave more restrictive permissions than their parent.即数据权限是父强则子强的自上而下继承而集合权限中子集合可以拥有比父集合更严格的权限例如父集合为 View、子集合为 No access权限图在构建时会把所有集合平铺在同一层collection-id → :read | :write | :none并不要求祖先关系的权限一致性。删除集合对某个集合拥有 Curate 权限的用户可以把集合移入回收站Trash。回收站内可以恢复或彻底删除集合详见删除与恢复。在集合中置顶条目拥有 Curate 权限的用户可以在集合中**置顶Pin**条目。置顶后该条目会以醒目的卡片形式展示在集合页面的顶部。置顶操作点击条目名称旁边的图钉图标即可。需要注意集合本身不能被置顶在 Pro 或 Enterprise 计划中管理员可以将某些集合指定为 Official Collections官方集合官方集合带有黄色徽章其内容在搜索结果中拥有更高优先级可与内容验证配合形成可信内容源。特殊集合Our analyticsOur analytics 集合以及每个用户的个人集合是不可破坏的它们不能被归档、删除或修改权限永远存在。Usage analytics使用情况分析集合的权限说明参见 Usage analytics。个人集合Personal collections每个用户都拥有一个个人集合即使该用户对任何其他集合都没有 Curate 权限也始终可以在自己的个人集合中保存内容。关于个人集合的权限要点管理员可以查看和编辑每个用户的个人集合内容包括其他管理员的个人集合方法是查看 Our analytics 时点击侧边栏底部的Other users personal collections其他用户的个人集合链接。个人集合与其他集合的工作方式相同但权限是固定的无法更改。如果个人集合中的某个子集合被移动到其他集合该子集合将继承新父集合的权限。从源码看个人集合在权限系统中被特殊对待在 src/metabase/permissions/models/collection/graph.clj 中个人集合及其后代集合的 ID 会被从权限图中移除且更新权限图时会自动过滤掉它们——尝试修改个人集合权限的请求会被静默忽略。同时在集合列表 APIsrc/metabase/collections_rest/api.clj中非本人的其他用户个人子集合也会被过滤确保隐私隔离。Library 集合关于 Library 及其子集合的权限参见 Data Studio 的 Library 权限说明。重要提醒不要使用Library Data的集合权限来控制已发布表中数据的访问。对发布数据的访问控制应当使用数据权限Data permissions。外部集合External collections多租户场景下的外部集合类型及权限行为参见 Tenants External collections。集合权限的底层实现权限图Permissions Graph为了更透彻地理解上述规则这里补充一段源码层面的实现剖析。权限图的数据结构Metabase 用一个稀疏权限图sparse graph表示集合权限状态其结构为见 graph.clj{:revision int :groups {group-id {collection-id :read|:write :root :read|:write}}}要点图是稀疏的只包含具有显式权限:read或:write的组与集合条目没有权限的组和集合不会出现在图中个人集合及其后代永远不会出现在图中已归档、已进入回收站的集合会被排除指定collection-namespace时其他命名空间的集合会被排除权限图会记录revision修订号用于并发更新时的一致性检查。权限图的更新流程更新入口为update-graph!graph.clj其核心步骤包括过滤非法条目自动移除个人集合及其后代、其他命名空间的集合保证命名空间隔离计算差异将旧图与新图做 diff只对有变化的(group-id, collection-id)执行授权/撤销校验 Library 权限check-data-analyst-library-permissions会阻止修改 Data Analysts 组对 Library 集合的权限该组对 Library 始终拥有完整读写权限违规时返回 HTTP 400修订号检查check-revision-numbers防止并发修改冲突除非显式force?事务与审计所有变更在事务内写入并通过create-perms-revision!递增修订号同时异步记录变更前后的快照fill-revision-details!用于审计日志。其中授权动作:write/:read分别调用grant-collection-readwrite-permissions!/grant-collection-read-permissions!:none则仅撤销已有权限graph.clj。与个人集合、Library 的强制约束个人集合personal-collection-ids会找出所有个人集合及其后代更新时整体从图中剔除因此前端无法通过权限图 API 修改个人集合的权限——这与文档中个人集合权限固定、不可更改的描述完全一致LibraryData Analysts 组对 Library 集合拥有强制读写权限任何尝试削减该权限的变更都会被拒绝。实践建议与常见误区结合文档与源码整理几条落地建议从 All users 组入手由于 All users 组覆盖所有用户且权限取最宽松值建议先把 All users 组对共享集合设为 No access再为具体业务组逐级授予 View / Curate避免所有用户都能改的失控局面参考权限总览中的告警机制。区分集合权限与数据权限集合权限只控制内容组织与策展数据的读写由数据权限控制对敏感表务必配置数据权限的 Block即使某组拥有集合 Curate 权限也无法绕过。谨慎对待子集合继承修改父集合权限时注意默认不会级联到已有子集合如需批量变更勾选Also change sub-collections。仪表板与问题尽量同集合存放跨集合引用会要求用户对所有涉及的集合都有权限否则卡片无法渲染。个人集合适合个人草稿需要共享的内容应移动到公共集合管理员可以通过 Other users personal collections 查看所有用户的个人集合。延伸阅读集合Collections使用指南集合的创建、移动、置顶、清理与个人集合操作数据权限Data permissions数据库、模式、表的访问控制权限总览Permissions introduction组、数据权限、应用权限、SQL 片段权限的整体框架事件与时间线集合中事件的创建与权限删除与恢复集合与条目的回收站机制Library 权限官方内容源集合的权限约束多租户与外部集合Embedding 场景下的集合权限形态【免费下载链接】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），仅供参考
