Metabase 代码片段文件夹权限Snippet Folder 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 的 Snippets代码片段 让 SQL 作者可以把可复用的 SQL 片段保存下来跨问题、跨团队复用。而Snippet folders代码片段文件夹则是 Metabase 在付费计划Pro/Enterprise中提供的配套能力把散落的片段组织进文件夹并按用户组对这些文件夹设置可见性与可编辑性。本文以 docs/permissions/snippets.md 为主线结合仓库中src/metabase/native_query_snippets/的源码实现系统讲解文件夹的创建、三种权限级别、权限解析规则与落地建议帮助你用文件夹把片段侧边栏整理干净、把关键 SQL 保护起来。先明确一个前提文件夹权限是组织工具不是安全机制文档开篇就强调了一个关键定位Folder permissions should not be considered a security feature, but instead a feature that helps organize and standardize snippets.文件夹权限不应被视为安全功能它更多是组织与标准化片段的工具。这一点可以从两个层面理解定位类比文件夹与 Collections集合相互独立又功能同构——Collections 负责把仪表盘和问题归组并授权文件夹负责把代码片段归组并授权。两者都是组织 权限的载体但管辖的对象不同。代码层面的佐证在开源CE实现中permissions.clj 的can-read?、can-write?、can-create?、can-update?全部只做一项检查——has-any-native-permissions?即当前用户是否对至少一个数据库拥有 native querySQL 编辑器权限。这意味着默认情况下只要用户能进 SQL 编辑器就能读、写、建所有片段。文件夹权限是 EnterpriseEE通过defenterprise注入的增强实现见 enterprise/backend/src/metabase_enterprise/snippet_collections/models/native_query_snippet/permissions.clj它才会进一步校验片段所在集合collection的读写权限。因此阅读本文时请始终记住文件夹权限能管住侧边栏的可见性和编辑权但无法阻止知道片段名的人通过{{snippet: 名称}}引用它详见下文权限如何工作。文件夹像文件系统一样组织片段文件夹的工作方式类似于文件系统片段可以放进文件夹文件夹可以套文件夹嵌套层级不受软件限制。SQL snippets是片段侧边栏的默认文件夹也是包含所有文件夹和片段的根文件夹。从源码看这个根并非凭空概念NativeQuerySnippet模型声明了自己的集合命名空间:snippets见 native_query_snippet.clj 中的collection/allowed-namespaces而集合的根类型定义中:snippets对应的名称正是 SQL snippets见 collections/models/collection/root.clj。也就是说片段文件夹在数据模型层面是集合系统的一种特殊命名空间这就是它能复用集合权限体系的原因。创建新的 Snippet 文件夹从 SQL 编辑器 顶部的Snippets菜单即可创建文件夹点击Snippets菜单图标图标形似一个带三条不齐横线的文本块/代码块。点击图标选择New folder。为文件夹命名可选地添加描述以及通过Folder this should be in选项把它放到某个已有文件夹中。创建新 Snippet 时放入文件夹在支持片段控制的计划上创建 Snippet 时会额外出现一个Folder this should be in选项让你直接把新片段放进某个文件夹。默认位置是SQL snippets所有片段与文件夹的根目录。你可以在任何时候把片段加入文件夹或把片段移动到另一个文件夹——前提是你对两个文件夹都有编辑Edit权限。注意片段名称必须全局唯一文件夹的划分不会放宽这一要求。这一约束在 API 层有直接实现POST /api/native-query-snippet在创建前会调用check-snippet-name-is-unique若重名则抛出400A snippet with that name already exists. Please pick a different name.见 api.clj模型层的NativeQuerySnippetNameschema 还规定片段名不能以空格开头、不能包含}字符这是为了避免与{{snippet: ...}}模板标签语法冲突见 native_query_snippet.clj。权限只有管理员能设置只有三种级别只有**管理员Administrators**能通过把片段放入文件夹、再为各组groups授予对文件夹的三种权限级别之一来控制片段的可见性与可编辑性。如果你熟悉 集合权限会发现机制高度相似。修改文件夹权限管理员可以点击文件夹旁的省略号...选择Change permissions或者把鼠标移到 Snippets 侧边栏顶部点击左侧的省略号...再选择Change permissions。当停留在SQL snippets根目录时点击侧边栏顶部的...可以对所有片段、文件夹和子文件夹统一设置权限当修改的文件夹含有子文件夹时可以勾选Also change sub-folders把本次权限设置一并应用到其子文件夹这与集合权限中子集合的继承行为一致见 集合权限与子集合。三种权限选项权限级别图标行为说明Edit access编辑绿色对勾默认设置。文件夹创建后所有对至少一个数据库拥有 SQL 编辑器权限的用户都能查看、编辑、归档或取消归档该文件夹中的片段。View access查看黄色眼睛拥有查看权限的用户组只能查看片段不能编辑、归档或取消归档。当然他们可以复制片段代码、创建新片段不影响已有片段。Revoke access撤销红色 X既无编辑也无查看权限的用户组不会在侧边栏看到该文件夹的片段这些片段也不会出现在类型提示typeahead建议中。值得注意的是撤销访问的边界如果某人有权限运行一个使用了其无权访问片段的问题他仍然能拿到该问题的结果。详见下文权限如何工作。归档不影响权限归档或取消归档片段不会改变片段的权限。归档/取消归档本质上是编辑行为因此如果只有一个组例如 Accounting 组对某文件夹拥有编辑权限那么只有该组成员以及管理员能归档/取消归档该文件夹里的片段。权限如何工作加性与数据优先于代码与集合权限一致文件夹权限是**加性additive**的用户属于多个组时更宽松的权限覆盖更严格的权限详见 权限总览 中关于叠加的讨论。但片段文件夹权限需要更多拆解因为它必须与数据权限和集合权限协同工作。核心规则只有一句数据比代码更敏感因此适用于数据的权限优先于适用于代码的权限。权限示例能运行问题但看不到片段文档给出了一个值得细读的典型场景某个组拥有对某个Collection的权限该集合里有一个问题使用了存放在该组没有权限的文件夹中的片段。即组里的人能运行集合中的问题但对该问题用到的片段所在文件夹没有权限。Metabase 会如何解析分三部分该组成员可以运行问题并获得结果。因为他们对该数据问题结果有查看权限所以应该能看到这些数据——组对集合的权限优先于对文件夹片段代码的权限。该片段不会出现在片段侧边栏中。他们虽然能正常运行问题但因为没有片段所在文件夹的权限在侧边栏中看不到、也编辑不了该片段及其文件夹。有 SQL 查询权限的人即使没有文件夹权限只要知道片段名就能在查询中引用它。例如{{snippet: Example snippet I dont have permissions to but can still use}}——他们无法查看或编辑该片段但只要知道名字就能把它写进查询。⚠️ 正因为这种解析规则不要把文件夹权限当作阻止他人访问片段 SQL 代码的手段。想用片段名绕过权限是可行的这属于设计使然。源码视角权限在 CE 与 EE 的差异从代码可以更清楚地看到文件夹权限是分层实现的CE开源版permissions.clj 中的can-read?/can-write?等统一调用has-any-native-permissions?——只要对任一数据库有:perms/create-queries权限即可读写所有片段不区分文件夹。这也解释了为什么文档说 Snippet controls 是付费功能文档顶部有{% include plans-blockquote.html featureSnippet controls %}。EE企业版通过defenterprise挂载的 permissions.clj 在:feature :snippet-collections下实现了真正的文件夹权限can-read?非沙箱用户 有 native 权限 对片段所在集合有read权限can-write?非沙箱 native 权限 对所在集合有write权限 非远程同步只读remote-sync/model-editable?can-update?写权限之外若变更涉及collection_id移动片段还要求目标集合同样有写权限——这与文档移动片段需要对两个文件夹都有 Edit 权限的描述完全对应。这里的关键是perms/perms-objects-set-for-parent-collection snippets ...文件夹权限最终复用集合collection的权限对象模型这就是文档说与集合权限功能相似的底层原因。API 层面的完整权限链路片段的所有操作都收敛到/api/native-query-snippet端点见 api.clj方法/路径说明权限检查点GET /列出当前用户可读的片段支持archived参数逐个执行mi/can-read?过滤对应list-native-query-snippets中的(filter mi/can-read? snippets)GET /:id获取单个片段api/read-checkPOST /新建片段字段content、description、name、collection_id名称唯一性检查 api/create-checkPUT /:id更新片段字段archived、content、description、name、collection_idapi/update-checkEE 下会校验父集合写权限与目标集合写权限其中GET /的过滤逻辑很能说明问题CE 下can-read?只检查 native 权限所以列表会返回全部片段EE 下则只返回用户有 read 权限的文件夹中的片段——这正是无权限组的侧边栏看不到片段的代码落点。实践建议把文件夹权限用在刀刃上基于上述机制官方给出的建议可以总结为三条落地准则把文件夹权限当作整理侧边栏的辅助工具通过文件夹把不同团队导向与其分析领域相关的片段让 Snippet 侧边栏保持整洁减少无关片段的干扰。用编辑权限保护关键 SQL对组织内重要的片段限制编辑权限防止未经审核的修改给 SQL 引入 bug——因为修改一个被多处引用的片段会同时影响所有引用它的问题参考 Snippets 文档 中的警告。不要依赖文件夹权限保密代码既然知道片段名的用户仍可引用片段敏感 SQL 的保密应依赖更底层的机制如数据权限、数据库连接本身的凭据管理而不是片段文件夹权限。延伸阅读Snippets代码片段完整用法创建、引用、编辑、归档、SQL 参数等基础能力。Collection permissions集合权限与文件夹权限机制同源的权限模型。Permissions overview权限总览Metabase 各类权限的全局视图。相关实现源码片段 API、片段模型、CE 权限实现、EE 文件夹权限实现。【免费下载链接】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），仅供参考
