Metabase 多租户（Tenants）架构实战：一套共享仪表盘服务多个客户，并实现数据隔离-二趣网

Metabase 多租户（Tenants）架构实战：一套共享仪表盘服务多个客户，并实现数据隔离

【免费下载链接】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 开源仓库中的docs/embedding/tenants.md展开，结合enterprise/backend/src/metabase_enterprise/tenants/下的源码实现，系统讲解 Metabase 多租户（Tenants）功能的完整概念、启用方式、租户/租户组/租户用户的创建流程、共享集合与租户集合的权限模型、租户属性驱动的数据隔离，以及基于 JWT 的租户自动预置方案。读完本文，你将能够在自建 SaaS 应用中，用一套 Metabase 仪表盘内容服务所有客户，同时保证每个客户只能看到属于自己的数据。

多租户的核心价值

Tenants（租户）是 Metabase 中一个抽象概念，代表共享某些属性、但彼此数据必须隔离的用户群体。典型场景是：你在构建一个带嵌入式 Metabase 仪表盘的 SaaS 应用，你的每个 SaaS 客户就是一个租户。

把用户分组到租户中的最大好处是：所有租户可以复用同一套内容与同一套权限模板，你不需要为每个客户单独创建仪表盘、单独配置权限——每个租户始终只能看到自己的数据。

使用租户可以做到：

通过**租户组（Tenant groups）和租户属性（Tenant attributes）**简化批量权限配置；
通过**共享集合（Shared collections）**复用仪表盘资产，避免为每个客户重复创建；
通过SSO（JWT）自动预置租户与租户用户。

从源码角度看，多租户能力是 Metabase 的企业版（EE）特性。开源版（OSS）在 src/metabase/tenants/core.clj 中提供了一个 shim 命名空间，其中create-tenant!直接抛出 "Cannot create tenant in OSS." 异常，而真正的实现位于 enterprise/backend/src/metabase_enterprise/tenants/core.clj，由:feature :tenants门控。因此，要使用本文介绍的全部功能，需要运行企业版并具备相应许可。

启用租户的总体步骤：

熟悉租户核心概念。
启用多租户策略。
在 Metabase 中创建租户与租户用户，或通过 JWT 自动预置。
创建共享集合。
配置数据权限与集合权限。

核心概念：用户、组、集合的类型

在 Metabase 中操作租户时，会接触到多种用户类型、组类型和特殊的集合类型。先建立统一的术语体系。

用户类型

租户用户（Tenant users）：最终用户。在 B2B SaaS 场景中，就是你的客户的用户。租户用户通常通过中间应用与 Metabase 交互（例如查看嵌入的仪表盘）。
内部用户（Internal users）：不属于任何租户的"普通" Metabase 用户，例如 Metabase 管理员，或负责开发将共享给租户的仪表盘的开发者。

组类型

租户用户与内部用户都可以被组织进 Metabase 用户组。

All tenant users（所有租户用户）：一个特殊组，代表所有租户下的全部终端用户。
这个组可用来为所有租户用户统一配置数据权限。如果需要在每个租户内部做更细粒度的权限控制，还可以创建租户组。
Tenant groups（租户组）：为租户用户提供额外的权限层级。
举例：如果你在做招聘软件，每个终端用户要么是招聘专员（recruiter，可访问所有开放职位的数据），要么是招聘经理（hiring manager，只能访问特定职位的分析数据）。那么可以在 Metabase 中创建 "Recruiters" 和 "Hiring managers" 两个租户组并分别配置权限。每个租户都能使用这些租户组——即每个客户都可以有各自的 "Recruiters" 和 "Hiring managers" 成员。
All internal users（所有内部用户）：代表所有不属于任何租户的人员的特殊组。
这些人是直接在 Metabase 内工作的人。未启用多租户时，这个组等价于 "All users" 组。
Internal groups（内部组）：供内部用户使用的额外组。
例如，你可以创建一个内部组 "Analytics developers"，只允许他们创建日后要共享给租户的仪表盘，而不授予对整个 Metabase 的管理员权限。

租户用户与内部用户完全隔离：租户用户不能被加入内部用户组，内部用户也不能被加入租户组。

集合类型

集合（Collections）类似于文件夹，可以容纳图表、仪表盘和模型，同时是权限管理的组织单元：如果某组人应该能访问某一组资产，就应该把这些资产放进一个集合。

共享集合（Shared collections）：包含所有租户之间共享的仪表盘和图表。
例如，招聘应用的每个租户都应该能看到"按日期统计的职位申请数"。你可以创建一个 Metabase 问题 "Count of applications by date" 并保存到共享集合中。同时必须配置数据权限，让每个租户只能看到自己的职位申请，而不是所有人的申请。
共享集合可以有多个（也可以完全没有）。例如可以有一个围绕招聘分析（recruitment）的共享集合，再加一个围绕面试分析（interviews）的共享集合。共享集合还支持可选地同步到 GitHub。
租户集合（Tenant collections）：每个租户专属的集合，创建租户时会自动创建。
如果有特殊客户需要定制化分析，可以把只给该客户的仪表盘和图表放进它的租户集合。租户集合也可以作为租户用户创建和保存新问题的空间——这些新问题可以在本租户用户之间共享，但不能与其他租户的用户共享。
源码层面，这一自动创建逻辑在 enterprise/backend/src/metabase_enterprise/tenants/models.clj 的define-before-insert :model/Tenant钩子中实现：插入租户记录前，会先创建一个:type为tenant-specific-root-collection-type、namespace为"tenant-specific"的集合，名称形如Tenant Collection: <租户名>，并将其 ID 写入租户的tenant_collection_id字段。
内部集合（Internal collections）：纯粹属于内部用户。这些是"普通"集合，你和 Metabase 内部的其他用户可以把不希望终端用户看到的东西放进去（开发中的仪表盘、内部指标，甚至关于你的租户的分析数据）。租户用户无法访问任何内部集合。
个人集合（Personal collection）：每个 Metabase 用户（包括租户用户）都有自己的个人集合——用来保存新问题和仪表盘的私有空间（前提是用户拥有构建和保存新问题的权限）。

终端用户体验

作为租户成员的终端用户不会知道自己是租户成员。在会向用户暴露 Metabase 集合的交互中（例如全应用嵌入 full-app embedding、启用了保存功能的模块化嵌入 modular embedding，或租户用户直接登录 Metabase），租户用户看到的只是自己有权访问的租户集合与共享集合，表现为普通集合，没有任何多租户痕迹。

启用多租户策略

入口：Admin settings > People（管理设置 > 人员）

无论你打算用 Metabase UI 手动管理租户，还是通过 SSO 自动预置，都需要先在 Metabase 中启用多租户策略。

启用步骤：

进入Admin settings（管理设置）> People（人员）。
点击人员列表上方的齿轮图标。
选择Multi-tenant strategy（多租户策略）。

切换为多租户策略后，Metabase 会启用特殊的用户类型和集合类型，你可以创建租户、租户组和集合，并在 People 与 Permissions 标签页获得额外的管理设置。

如果你已有既定的权限与集合配置想迁移到租户体系，参见切换租户策略。

启用后需要注意：从多租户切回单租户是破坏性操作——所有租户用户和租户/共享集合都会被停用/删除。详见切换租户策略。

在 Metabase 中创建租户

入口：Admin settings > People > Tenant

创建租户步骤：

先启用多租户策略（如果还没启用）。
进入Admin settings > People。
在左侧边栏选择Tenants（租户），点击New tenant（新建租户）。
填写租户信息：
- Tenant name（租户名称）：显示给内部用户的租户显示名，不会暴露给外部用户，之后可以修改。
- Tenant slug（租户标识）：租户的唯一标识符。可用于匹配 JWT 声明以及配置数据权限。详见特殊租户 slug 属性。
- Tenant attributes（租户属性）：可定义会被每个租户用户继承的属性，详见租户属性。

关于 slug 的格式约束，源码在 enterprise/backend/src/metabase_enterprise/tenants/models.clj 中定义为正则^[-_a-z0-9]{1,255}$，即只能包含小写字母、数字、连字符和下划线，最长 255 个字符。在 enterprise/backend/src/metabase_enterprise/tenants/api.clj 的create-tenant!中，创建时还会校验租户名或 slug 是否已被占用（返回 400 "This tenant name or slug is already taken."），并要求操作者为超级用户（403 校验）。

同样在 enterprise/backend/src/metabase_enterprise/tenants/api.clj 中，租户的 REST 路由挂载于/api/ee/tenant，支持：

POST /api/ee/tenant：创建租户（参数为name、slug、可选attributes）；
GET /api/ee/tenant：列出租户，可按status（all/active/deactivated）过滤并分页；
GET /api/ee/tenant/:id：查看单个租户；
PUT /api/ee/tenant/:id：更新租户的名称、属性或is_active状态。

其中更新接口内部使用事务（t2/with-transaction）：当把is_active置为false时，会调用deactivate-tenant-users!停用该租户全部用户，并归档租户集合；置回true时则重新激活用户并取消归档集合（见 enterprise/backend/src/metabase_enterprise/tenants/db.clj）。这与下文停用租户一节的行为完全一致。

你也可以通过 JWT 预置租户来避免在 Metabase 中手动创建租户。

创建租户组

入口：Admin settings > People > Tenant groups

租户组在所有租户间通用。例如你可以创建 "Basic users" 和 "Premium users" 两个租户组，每个租户都能使用这两个组，从而在租户内部区分基础权限与高级权限的用户。

创建租户组步骤：

先启用多租户策略（如果还没启用）。
进入Admin settings > People。
在左侧边栏选择Tenant groups（租户组），点击Create a group（创建组）。
为组命名。

向租户组添加成员的方法，参见向组添加人员。

创建租户用户

入口：Admin settings > People > Tenant users

租户用户是租户内的终端用户。在 B2B SaaS 场景中，就是你的客户的用户，通常通过中间应用（如嵌入式仪表盘）与 Metabase 交互。

添加租户用户步骤：

先创建租户。
进入Admin settings > People。
在左侧边栏选择Tenant users（租户用户），点击New tenant user（新建租户用户）。
填写用户信息，包括所属租户（Tenant）和租户组（Tenant groups）。
如果租户配置了租户属性，这些属性会被该用户继承，但你可以在 "Attributes" 中覆盖其值。

你也可以通过 JWT 预置租户用户。

从数据模型看，租户与用户之间通过tenant_id关联：租户用户记录上带有tenant_id字段，enterprise/backend/src/metabase_enterprise/tenants/core.clj 中的user->tenant就是根据用户的tenant_id查询对应租户。用户还可以带有deactivated_with_tenant标记，用于记录"随租户停用而停用"的状态（见 enterprise/backend/src/metabase_enterprise/tenants/db.clj 的deactivate-tenant-users!/reactivate-tenant-users!）。

创建共享集合

共享集合存放所有租户共享的仪表盘和图表。如果使用共享集合，请务必配置好数据权限，确保租户在共享集合中只能看到自己的数据。

创建共享集合步骤：

先启用多租户策略（如果还没启用）。
打开 Metabase 导航侧边栏（点击左上角的三条横线，注意这是普通 Metabase 界面，不是 Admin settings）。
在侧边栏中应该能看到 "External collections（外部集合）"。如果看不到，请确认已启用多租户策略。
点击 "External collections" 旁边的+创建共享集合。

可以创建多个共享集合，也支持嵌套的共享集合。共享集合还支持同步到 GitHub。

将共享集合同步到 GitHub

入口：Admin settings > Remote Sync

可以为共享集合配置 Remote sync（远程同步）。这意味着你可以在一个 Metabase 中开发共享内容，推送到 GitHub 仓库，然后让生产环境的 Metabase 共享内容始终与该仓库保持同步。详细配置方式参见 Remote sync 文档。

租户属性

入口：Admin settings > People > Tenants

你可以创建租户级别的用户属性，该租户的所有用户都会继承这些属性。这在配置基于属性的数据权限时非常有用，例如行级安全 row-level security、用户模拟 impersonation 或数据库路由 database routing。

在 Metabase UI 中手动创建租户属性：

进入Admin settings > People。
在左侧边栏选择Tenants（租户）。
点击租户旁边的三个点。
输入属性键（key）和值（value）。

也可以通过 JWT 声明自动设置租户属性，参见下文使用租户声明设置租户属性。

添加租户属性后，该租户的所有用户都会继承该属性，但任何特定用户的值都可以被覆盖，参见编辑用户属性。

从实现上看，租户属性保存在 Tenant 记录的attributes列（JSON），其 schema 见 enterprise/backend/src/metabase_enterprise/tenants/schema.clj：属性值为字符串、数字或布尔值。同时 enterprise/backend/src/metabase_enterprise/tenants/models.clj 中的StrictAttributes校验规定：属性键不能以@开头（@前缀保留给系统属性），否则 API 会返回 400。

在登录环节，enterprise/backend/src/metabase_enterprise/tenants/core.clj 的login-attributes会把租户的attributes与系统属性@tenant.slug合并进租户用户的登录属性。而属性合并的优先级逻辑位于开源侧 src/metabase/tenants/core.clj 的combine函数：租户属性（:tenant）与用户属性（:user）发生冲突时，用户属性覆盖租户属性并保留原值记录（shadow），而系统属性（:system）优先级最高且不可被覆盖（frozen）。

特殊租户 slug 属性

每个租户用户都会获得一个系统定义的属性@tenant.slug，其值对应该租户的 slug。例如，如果你创建了一个名为 "Meowdern Solutions"、slug 为meowdern_solutions的租户，那么该租户的每个用户都会获得特殊属性@tenant.slug : "meowdern_solutions"。

如果通过 Metabase UI 创建租户，可以在创建时选择 slug；如果通过 JWT 预置租户，租户 slug 就是 JWT 中@tenant声明的值（或你选择的其它租户分配属性）。slug 之后不能修改。
特殊属性@tenant.slug可以像普通属性一样用于配置基于属性的权限，例如行级安全、用户模拟或数据库路由。你的租户 slug 应当与租户在你的系统中实际的标识方式保持一致。

例如，如果你要用行级安全，而你的表中租户是用 ID（而非名称）标识的，那么租户 slug 也应该是 ID。假设数据长这样：

| Customer ID | Order number | Order date | Order total | | ----------- | ------------ | ---------- | ----------- | | 175924 | 3 | 2025-10-13 | 175.34 | | 680452 | 7 | 2025-10-13 | 34.56 |

并且你想按Customer ID实施行级安全，那么租户 slug 就应当形如175924，以便与表中的 Customer ID 匹配。

同理，如果要用租户 slug 做用户模拟（impersonation），需要把租户 slug 映射到数据库角色；如果要用做数据库路由（database routing），则需要把租户 slug 映射到数据库。

使用 JWT 预置与分配租户

使用租户声明登录用户

你可以配置 JWT SSO，并使用 JWT 登录租户用户。

一旦启用多租户策略，Metabase 会在 JWT 中查找@tenant声明来判断用户是否是租户用户、属于哪个租户。@tenant键的值应为租户的 slug。下面是一个用于登录租户用户的 JWT 声明示例：

{ "email": "mittens@example.com", "first_name": "Mister", "last_name": "Mittens", "@tenant": "meowdern_solutions" }

如果用户已经被分配了租户（例如通过 Metabase UI 分配），那么 JWT 中必须包含租户声明才能登录该用户。

自定义租户声明

默认情况下，Metabase 查找 JWT 中的@tenant键。要改为其它键：

进入Admin > Settings > Authentication（身份验证）> JWT > User attribute configuration（用户属性配置）。
将Tenant assignment attribute（租户分配属性）键改为你偏好的标识符。

源码层面，该可配置项对应 enterprise/backend/src/metabase_enterprise/sso/providers/jwt.clj 中读取的jwt-attribute-tenant设置；启用多租户后，JWT 解析会额外提取租户分配属性与租户属性声明（@tenant.attributes）。若@tenant值不是字符串，会返回 400 错误invalid-tenant。

预置租户与用户

你可以开启 JWT 用户预置，让 Metabase 自动创建 JWT 中提到的用户与租户。

开启 JWT 用户预置后：

Metabase 从 JWT 声明中读取租户标识符（默认是@tenant键，可配置）。
如果租户不存在，Metabase 自动创建它，并将@tenant键（或你选择的分配属性）的值作为租户 slug。
新用户自动从 JWT 分配到对应租户。

使用租户声明设置租户属性

要从 JWT SSO 创建租户属性，在 JWT 中包含@tenant.attributes声明：

{ "@tenant": "meowdern_solutions", "@tenant.attributes": { "id": "13371337", "name": "Mammoth Solutions" }, "email": "mittens@example.com", "first_name": "Mister", "last_name": "Mittens" }

如果该名称的租户属性不存在，Metabase 会创建该属性并赋上 JWT 声明中的值；但如果租户属性已存在，Metabase不会更新其值。

JWT 身份验证常见报错排查

一些常见的认证错误消息及其含义：

Cannot add tenant claim to internal user（不能向内部用户添加租户声明）：JWT 包含租户声明，但该用户是内部用户。只有租户用户才能有租户。
Tenant claim required for external user（外部用户必须提供租户声明）：JWT 缺少租户声明，但该用户是外部（租户）用户。
Tenant ID mismatch with existing user（租户 ID 与既有用户不匹配）：JWT 中的租户与用户已分配的租户不同。
Tenant is not active（租户未激活）：租户存在但已被停用。

这些校验逻辑在 enterprise/backend/src/metabase_enterprise/tenants/core.clj 的tenant-is-active?中有对应实现：仅当租户 ID 为空，或该 ID 的租户存在且is_active为true时才返回真。相关集成测试可参见 enterprise/backend/test/metabase_enterprise/sso/integrations/jwt_test.clj。

租户的数据权限

入口：Admin settings > Permissions

数据权限控制人们能在图表和仪表盘上看到哪些数据，以及能用这些数据做什么。要控制人们能看到哪些图表，应改用集合权限。

数据权限概览

关于 Metabase 数据权限如何工作的完整说明，参见数据权限。以下是关键要点（但仍建议阅读完整文档）：

"View data"（查看数据）：控制每个用户组能在仪表盘和图表上看到哪些数据。
例如，如果所有租户的数据混在同一个数据库中，可以结合Row and column security（行与列安全）或Impersonation（用户模拟）的 "View data" 权限，让租户用户只能访问特定的行和列。
如果每个租户的数据在各自独立的数据库中，那么可以不依赖数据访问控制权限，改用database routing（数据库路由）直接把查询路由到对应数据库。
关于数据隔离方式的对比，参见选择数据隔离方式。
Create queries（创建查询）：控制租户用户是否能在其可见数据上创建查询。如果希望租户用户能够进行下钻（drill-through，例如通过模块化嵌入 modular embedding 中的drills参数），需要授予 "Create queries" 权限，因为下钻本质上是发起一条新查询。
Download results（下载结果）：控制人们是否能下载查询结果。如果希望用户可以把数据下载为电子表格（例如通过模块化嵌入中的with-downloads参数），需要设置下载权限。

Metabase 的数据权限可以在数据库或表级别指定，并授予用户组。你需要使用特殊的All tenant users组以及租户组（如有）来分配数据权限。请记住，Metabase 权限是叠加（additive）的：如果一个人同时属于两个组，他将获得更宽松的访问权限。特别地，如果 "All tenant users" 对整个表拥有 "Can view" 权限，而另一个租户组只有受限访问权限（如行级安全），那么该租户组的用户仍能看到表中的全部数据（因为通过 "All tenant users" 组获得了权限）。如果使用租户组，建议撤销 "All tenant users" 的访问权限，按组逐一配置访问。

使用租户属性做数据权限

行与列安全、用户模拟和数据库路由都需要用户属性。你可以自定义租户属性，基于属性值配置数据权限。

租户的集合权限

集合权限控制人们能看到哪些实体（仪表盘、问题、模型等）。要配置这些实体中能看到哪些数据以及能用数据做什么，参见数据权限。

Metabase 的集合权限分多个级别：**No（无）**访问、**View（仅查看）**访问和 **Curate（策展）**访问（允许创建和保存新实体，如仪表盘）。更通用的集合权限说明参见集合权限。

权限授予用户组。每个组可获得的权限取决于组的类型（外部/租户或内部）和集合的类型。

租户用户的集合权限

对内部集合，租户用户**始终为 No（无）**访问。
对共享集合，租户用户**只能有 View（仅查看）或 No（无）**访问。这意味着租户用户最多只能查看既有实体，不能创建新实体。
不同的租户组可以对不同的共享集合拥有不同级别的访问。例如，可以有一个所有用户都能查看的 "Basic analytics" 共享集合，以及只有 "Premium users" 租户组能查看的 "Advanced analytics" 集合。参见配置共享集合权限。
对租户集合，租户用户**始终拥有 Curate（策展）**权限，即租户用户总是可以在自己的租户集合中保存新问题。
如果不希望租户用户创建和保存自己的图表，需要禁用租户用户的 "Create queries"数据权限；如果是嵌入场景，还要配置嵌入式 UI 组件禁用保存功能。
对个人集合，租户用户**始终拥有 Curate（策展）**权限。

内部用户的集合权限

Metabase 管理员对所有共享集合和所有租户集合拥有Curate访问权限。
其他内部用户和非管理员组默认无访问权限，但可以被授予对共享或租户集合的View或Curate访问权限，详见配置共享集合权限。

内部用户对内部集合的权限配置，参见集合权限通用文档。

配置共享集合权限

入口：Admin settings > Permissions

要配置租户组和内部组对共享集合的访问，进入Admin settings > Permissions > Shared collections（共享集合）。

你可以为每个共享集合及其子集合配置内部用户和外部（租户）用户的访问权限。通用说明参见集合权限文档。

特殊的Root shared collection（根共享集合）控制谁有权访问所有共享集合。例如，如果你希望确保内部用户无权访问任何租户共享集合，可以撤销 Root shared collection 的权限。

配置权限时请记住：Metabase 中所有权限都是叠加的，如果某人属于两个组，他将获得最宽松的访问权限。特别是，如果 "All tenant users" 对某个共享集合有 "View" 权限，而另一个租户组在权限设置中被明确设为 "No"，该租户组的用户仍会获得 "View" 权限（因为他们通过 "All tenant users" 组获得）。如果使用租户组，建议撤销 "All tenant users" 的权限，按组逐一配置。

租户的订阅权限

入口：Admin settings > Permissions

默认情况下，所有租户用户创建时没有订阅权限（订阅与提醒）。如果你希望用户能创建订阅（无论是在全应用嵌入、模块化嵌入中，还是直接登录 Metabase），需要将Subscription and alerts（订阅与提醒）权限改为 "Yes"。

停用租户

入口：Admin settings > People > Tenants

停用一个租户会同时停用该租户的所有用户。

停用租户步骤：

进入Admin settings > People。
在左侧边栏选择Tenants（租户）。
点击租户旁边的三个点。
选择Deactivate tenant（停用租户）。

所有租户用户都会被停用，无法再登录。租户用户不会被永久删除（Metabase 不会删除用户，只会停用），因此即使租户用户已被停用，你也无法用相同的邮箱创建新用户。

这与前面提到的源码行为完全一致：停用操作会调用deactivate-tenant-users!，把is_active置为false并打上deactivated_with_tenant标记，同时归档租户根集合；重新激活时则反向恢复（见 enterprise/backend/src/metabase_enterprise/tenants/db.clj 与 enterprise/backend/src/metabase_enterprise/tenants/api.clj 的update-tenant!）。

切换租户策略

从单租户切换到多租户

启用多租户策略时，Metabase 中现有的所有用户都会被当作"内部"用户。如果你不希望其中任何用户变成租户用户，可以直接按全新实例的方式继续租户搭建（创建租户、创建集合、配置权限等）。

但如果想把某些既有用户分配为租户用户，需要：

用 API 调用将它们标记为租户用户：
```
PUT /api/user/:id {"tenant_id": 1}
```
如果使用 JWT 做 SSO，在 JWT 中加入@tenant声明。
配置租户组、数据权限和集合权限，因为你无法再用既有的内部组来配置租户权限。

从多租户切换到单租户

如果禁用多租户策略，所有租户用户都会被停用，所有（租户与共享）集合都会被删除（但如果你之后重新启用多租户策略，用户和集合都会恢复）。所以如果你只想停用租户功能而保留活跃用户，需要额外准备：

用普通用户组和普通集合复刻现有的租户配置（替代租户组和共享集合）。复习数据权限、集合权限和用户组的文档。务必用测试用户彻底验证你的配置——开发实例可能会派上用场。
如果使用了租户组，移除所有租户用户的租户组成员身份。
用 API 把租户用户改为内部用户：
```
PUT /api/user/:id {"tenant_id": null}
```
如果不做这一步，你的所有用户都会被停用。
最后，在所有内容验证无误后，再禁用该功能。

限制与注意事项

租户集合和个人集合无法禁用。
如果不希望租户用户创建和保存自己的图表，可以禁用 "Create queries"数据权限；嵌入场景下再配置嵌入式 UI 组件禁用保存功能。
租户用户不能更换租户。一旦外部用户被分配到某个租户，就不能切换到另一个租户。
如果禁用多租户策略，被停用的租户用户不会出现在 "Deactivated users（已停用用户）" 列表中，但 Metabase 仍会跟踪他们，并且不允许用相同邮箱创建新用户。
没有租户专属的用户组。租户组在所有租户之间共享。如果某个组只想适用于部分租户，可以创建该租户组，但不要加入不适用租户的任何成员。

企业官网建设流程全解析