从传统权限迁移
在 Metabase 50 中,我们彻底改革了数据权限系统,使其更具表达力,也更容易理解。本页面解释了具体变化和原因。
TL;DR(太长不看版):我们将旧的“数据访问”设置拆分为两个设置:查看数据和创建查询。您的数据权限可能看起来不同,但实际访问权限并未改变。
Metabase 如何迁移您的权限
如果您从 Metabase 50 或更早版本迁移,Metabase 将(一个例外除外)自动将您的权限更新到新系统。虽然群组权限会略有不同(我们希望更易于理解),但您的群组将拥有与以前相同的访问级别。
我们为什么要更新权限系统
原始的“数据访问”权限设置包含五个访问级别:无限制、模拟、精细、无自助服务和阻止。这些级别不在同一个维度上。它们在一个维度上结合了您是否可以查看数据,在另一个维度上结合了您是否可以查询数据。这创建了一个二维设置
- 无自助服务。 限制群组使用查询构建器创建或编辑问题。
- 沙盒和阻止。 限制对底层数据的查看和查询构建器访问。
将两个维度(查询+查看)混入单个权限设置可能会导致意外行为。例如,通过将访问权限从“沙盒化”更改为“无自助服务”,管理员可能认为他们正在限制该群组对数据的访问。但在这种情况下,如果该群组还可以访问包含现有模型、问题或仪表板的集合,他们可能会看到更多数据。
我们对数据权限的全面改革实现了什么
- 将查看访问和查询访问拆分为两个权限维度。这种拆分允许管理员例如在有或没有查询构建器访问权限的情况下沙盒化表(以前无法将沙盒配置为仅查看)。
- 使权限更容易理解。更严格的权限绝不会比不那么严格的权限提供更多访问权限。
旧权限到新权限的迁移表
如果您对 Metabase 的历史演变感兴趣,可以查看此表。Metabase 会为您处理迁移。
此前,Metabase 有数据访问和原生查询编辑。现在,Metabase 有查看数据和创建查询。以下是 Metabase 如何将每个配对迁移到新系统的方式。
数据访问 | 原生查询编辑 | > | 查看数据 | 创建查询 |
---|---|---|---|---|
无限制 | 是 | > | 可以查看 | 查询构建器和原生代码 |
无限制 | 否 | > | 可以查看 | 查询构建器 |
无自助服务 | 否 | > | 可以查看 | 否 |
已阻止 | 否 | > | 已阻止 | 否 |
模拟 | 是 | > | 模拟 | 查询构建器和原生代码 |
模拟 | 否 | > | 模拟 | 查询构建器 |
无限制(精细) | 否 | > | 可以查看 | 查询构建器(精细) |
沙盒化(精细) | 否 | > | 沙盒化(精细) | 查询构建器(精细) |
无自助服务(精细) | 否 | > | 可以查看 | 否(精细) |
“No self-service (deprecated)
”查看访问级别
如果您在任何群组的查看数据中看到No self-service (deprecated)
权限设置,您应在某个时候手动更改它。
对于任何将查看数据访问设置为No self-service (deprecated)
的群组,您需要将查看数据权限更改为以下新选项之一
如果您不采取任何行动,Metabase 将在未来版本中把查看数据设置为No self-service (deprecated)
的任何群组更改为Blocked
。我们默认设置为“Blocked”,这是限制性最小的查看数据访问,以防止任何意外的数据访问。但这种更改为“Blocked”可能会导致用户失去之前拥有访问权限的数据。
为什么我们无法手动迁移此设置
在旧的权限系统中,考虑一个人在多个群组中的情况。
- “无限制”数据访问意味着您不会受到其他群组的阻止、沙盒或模拟设置的影响。
- “无自助服务”数据访问意味着您会受到其他群组的阻止、沙盒或模拟设置的影响。
假设您在旧的权限框架中有以下群组
群组 A | 群组 B | 群组 C | 群组 D | 群组 E | |
---|---|---|---|---|---|
数据访问 | 无限制 | 无自助服务 | 已阻止 | 沙盒化 | 模拟 |
如果您是群组 A 以及群组 C、D 或 E 之一的成员,您将对数据拥有完全无限制的访问权限,不受任何阻止、沙盒或模拟的影响。
如果您是群组 B 以及群组 C、D 或 E 之一的成员,您将对数据拥有有限的访问权限:可能是被阻止、沙盒化或模拟。
我们可以这样迁移权限
群组 A | 群组 B | 群组 C | 群组 D | 群组 E | |
---|---|---|---|---|---|
查看数据 | 可以查看 | ? | 已阻止 | 沙盒化 | 模拟 |
创建查询 | 仅查询构建器 | 否 | 否 | 仅查询构建器 | 仅查询构建器 |
我们无法真正决定群组 B 的“查看数据”应该是什么。如果我们将其切换到“可以查看”,则该人员将不受其其他群组中“Blocked”、“Sandboxed”或“Impersonated”设置的影响。如果我们将其设置为“Blocked”,他们可能会失去您认为他们应该有权访问的数据。因此,我们创建了一个临时设置,No self-service (legacy)
来管理这个(临时)尴尬的过渡。
对于某些具有“无自助服务”和“沙盒化”数据访问权限的群组权限设置,您可能需要创建一个新群组来复制 Metabase 50 或更高版本中的设置
在 Metabase 49 中,(更宽松的)“无自助服务”数据访问无法覆盖(限制性更强的)“沙盒化”访问,您可以以难以理解的方式设置 Metabase 49。
然而,从 Metabase 50 开始的新权限系统中,更宽松的设置总是覆盖限制性更强的设置。这种一致的行为使权限变得更容易理解。然而,这种改进的一个结果是,为了在升级到 Metabase 50 时重新创建某些权限设置,您可能需要创建一个额外的群组。
例如,假设在旧的数据访问权限下,Metabase 49 中有两个群组:All users 群组和 Foo 群组。
Metabase 49 中的权限设置
- All users 群组对示例数据库中的所有表具有“无自助服务”数据访问权限。
- Foo 群组对示例数据库中的表具有“沙盒化”访问权限。
Metabase 49 中的这种数据访问设置将允许用户查看他们有权访问的集合中的问题和仪表板。但是,Foo 群组中的用户将获得项目的沙盒视图。在这种情况下,Foo 群组中限制性较小的“Sandboxed”数据访问覆盖了 All users 群组中限制性较大的“No self-service”权限。
然而,从 Metabase 50 开始,更宽松的设置总是覆盖限制性更强的设置。因此,为了保持 Foo 的沙盒完整,我们需要将 All users 群组的“查看数据”权限设置为比“Sandboxed”设置更低的限制性。因此,我们需要将 All users 的“查看数据”权限设置为“Blocked”。
但是,如果您仍然希望不在 Foo 群组中的其他人能够查看他们有权访问的集合中的项目,您需要创建一个额外的群组,Bar,其中包含除了 Foo 群组中的人员之外的所有人,并授予该 Bar 群组对示例数据库的“Can view”访问权限。Bar 群组的“Can view”访问权限将覆盖 All Users 群组的“Blocked”设置,他们将能够查看问题和仪表板。同时,Foo 群组仍然有其沙盒。以下是您需要为 Metabase 50 设置的总结:
Metabase 50 中的权限设置
- All users 群组对示例数据库中的所有表均“Blocked”。
- Foo 群组对示例数据库中的所有表具有“Sandboxed”的查看数据权限。
- 创建一个新群组,Bar,其中包含 All users 群组中除了 Foo 群组中的人员之外的所有人。将此 Bar 群组的“查看数据”权限设置为对示例数据库“Can view”。
进一步阅读
阅读其他Metabase 版本的文档。