feat: add tenant-scoped rule and permission management
This commit is contained in:
wren
@@ -0,0 +1,501 @@
|
||||
# 租户主数据模型设计
|
||||
|
||||
> 适用范围：当前系统把 `area / region / 入口地区 / 省级公共范围` 混合当成业务隔离边界使用的场景
|
||||
> 文档定位：定义“地区正式升级为租户主数据”后的核心表结构、字段规则、接口边界和兼容策略，作为后续入口模块、RAG、合同模板、文档、公文、统计、RBAC 改造的底层依据。
|
||||
|
||||
---
|
||||
|
||||
## 1. 结论先行
|
||||
|
||||
当前系统真正缺的不是“再补几个地区下拉”，而是：
|
||||
|
||||
1. 缺少租户主数据表
|
||||
2. 缺少统一租户编码
|
||||
3. 缺少“公共租户 / 总部租户 / 普通租户”的类型语义
|
||||
4. 缺少租户启停、排序、展示名、别名、扩展字段
|
||||
5. 缺少业务表和租户主数据之间的稳定关联
|
||||
|
||||
因此建议正式引入：
|
||||
|
||||
1. `sys_tenants`
|
||||
2. `sys_tenant_aliases`
|
||||
3. `sys_tenant_feature_flags`
|
||||
4. 业务表中的 `tenant_code`
|
||||
|
||||
同时保留现有 `area / region / tenant_name` 一段时间作为兼容字段，但不再把它们当主键语义使用。
|
||||
|
||||
---
|
||||
|
||||
## 2. 当前模型为什么不够
|
||||
|
||||
当前系统涉及租户边界的核心字段分散如下：
|
||||
|
||||
1. `sso_users.area`
|
||||
2. `sso_users.tenant_name`
|
||||
3. `leaudit_documents.region`
|
||||
4. `contract_templates.region`
|
||||
5. `rag_dataset.area`
|
||||
6. `rag_chat_app.area`
|
||||
7. `leaudit_entry_modules.areas[].area`
|
||||
8. 前端若干页面里的固定地区常量
|
||||
|
||||
这些字段的问题不是“名字不同”这么简单，而是：
|
||||
|
||||
1. 没有统一编码
|
||||
2. 没有主数据约束
|
||||
3. 没有类型定义
|
||||
4. 没有别名映射
|
||||
5. 没有生命周期管理
|
||||
6. 没有租户能力开关
|
||||
|
||||
只要继续沿用字符串直写模式，新增一个租户就必须人工排查：
|
||||
|
||||
1. 登录态信息
|
||||
2. 首页入口
|
||||
3. RAG 数据集
|
||||
4. 合同模板
|
||||
5. 文档上传
|
||||
6. 交叉评查入口
|
||||
7. 统计维度
|
||||
8. RBAC 管理树
|
||||
|
||||
这已经不是可维护架构。
|
||||
|
||||
---
|
||||
|
||||
## 3. 目标模型
|
||||
|
||||
## 3.1 核心原则
|
||||
|
||||
后续统一按下面规则建模：
|
||||
|
||||
1. `tenant_code` 是唯一稳定编码，只用于程序匹配和外键引用
|
||||
2. `tenant_name` 是展示名称，可修改
|
||||
3. `area / region` 退化为兼容字段，不再承担主键语义
|
||||
4. “公共资源”不再用 `省级 / 省局 / default / 空串` 表示，而是用明确租户类型或独立作用域字段表达
|
||||
5. 所有租户候选值都必须来自主数据，不允许前后端各自发明字符串
|
||||
|
||||
## 3.2 推荐主表 `sys_tenants`
|
||||
|
||||
建议表结构：
|
||||
|
||||
```sql
|
||||
CREATE TABLE IF NOT EXISTS sys_tenants (
|
||||
id BIGSERIAL PRIMARY KEY,
|
||||
tenant_code VARCHAR(64) NOT NULL UNIQUE,
|
||||
tenant_name VARCHAR(128) NOT NULL,
|
||||
tenant_short_name VARCHAR(64) NULL,
|
||||
tenant_type VARCHAR(32) NOT NULL,
|
||||
parent_tenant_code VARCHAR(64) NULL,
|
||||
display_order INT NOT NULL DEFAULT 0,
|
||||
is_enabled BOOLEAN NOT NULL DEFAULT TRUE,
|
||||
is_builtin BOOLEAN NOT NULL DEFAULT FALSE,
|
||||
is_public BOOLEAN NOT NULL DEFAULT FALSE,
|
||||
can_host_entry_module BOOLEAN NOT NULL DEFAULT TRUE,
|
||||
can_host_documents BOOLEAN NOT NULL DEFAULT TRUE,
|
||||
can_host_rag BOOLEAN NOT NULL DEFAULT TRUE,
|
||||
can_host_templates BOOLEAN NOT NULL DEFAULT TRUE,
|
||||
ext JSONB NOT NULL DEFAULT '{}'::jsonb,
|
||||
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
|
||||
updated_at TIMESTAMP NOT NULL DEFAULT NOW(),
|
||||
deleted_at TIMESTAMP NULL
|
||||
);
|
||||
```
|
||||
|
||||
## 3.3 字段语义
|
||||
|
||||
重点字段建议如下：
|
||||
|
||||
1. `tenant_code`
|
||||
用于所有内部匹配，例如 `MZ`、`YF`、`JY`、`CZ`、`PROVINCIAL`、`PUBLIC`
|
||||
|
||||
2. `tenant_name`
|
||||
展示名，例如 `梅州`、`云浮`、`揭阳`、`潮州`、`省局公共`
|
||||
|
||||
3. `tenant_type`
|
||||
枚举建议：
|
||||
- `LOCAL`
|
||||
- `HEADQUARTER`
|
||||
- `PUBLIC`
|
||||
- `PILOT`
|
||||
- `INTERNAL`
|
||||
|
||||
4. `parent_tenant_code`
|
||||
用于表达层级，例如某试点租户挂在省级租户下
|
||||
|
||||
5. `is_public`
|
||||
表示该租户是否代表跨租户公共资源域，不再让业务侧自行解释 `省级 / default / 空串`
|
||||
|
||||
6. `is_builtin`
|
||||
标识是否系统内置。当前固定地区和公共租户可以先作为内置租户落地
|
||||
|
||||
7. `can_host_entry_module / can_host_documents / can_host_rag / can_host_templates`
|
||||
表示这个租户是否允许承载某类业务配置，避免把“公共租户”误用于不该投放的模块
|
||||
|
||||
8. `ext`
|
||||
用于保留显示标签、颜色、旧编码映射、第三方系统标识等扩展信息
|
||||
|
||||
---
|
||||
|
||||
## 4. 别名表设计
|
||||
|
||||
## 4.1 为什么必须有别名表
|
||||
|
||||
当前系统已存在以下同义值混用：
|
||||
|
||||
1. `省局`
|
||||
2. `省级`
|
||||
3. `default`
|
||||
4. `''`
|
||||
5. 未来可能出现的 `广东省局`
|
||||
|
||||
如果不显式建别名表，只靠 if/else 兼容，后续每个模块都会各写一遍归一逻辑。
|
||||
|
||||
## 4.2 推荐表 `sys_tenant_aliases`
|
||||
|
||||
```sql
|
||||
CREATE TABLE IF NOT EXISTS sys_tenant_aliases (
|
||||
id BIGSERIAL PRIMARY KEY,
|
||||
tenant_code VARCHAR(64) NOT NULL,
|
||||
alias_value VARCHAR(128) NOT NULL,
|
||||
alias_type VARCHAR(32) NOT NULL,
|
||||
is_enabled BOOLEAN NOT NULL DEFAULT TRUE,
|
||||
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
|
||||
updated_at TIMESTAMP NOT NULL DEFAULT NOW(),
|
||||
deleted_at TIMESTAMP NULL,
|
||||
UNIQUE (tenant_code, alias_value)
|
||||
);
|
||||
```
|
||||
|
||||
## 4.3 `alias_type` 建议
|
||||
|
||||
建议最少支持：
|
||||
|
||||
1. `LEGACY_AREA`
|
||||
2. `LEGACY_REGION`
|
||||
3. `DISPLAY`
|
||||
4. `IMPORT`
|
||||
5. `EXTERNAL_SYSTEM`
|
||||
|
||||
这样可以区分：
|
||||
|
||||
1. 历史库里的旧值
|
||||
2. 前端展示名
|
||||
3. 导入脚本映射值
|
||||
4. 第三方接口传入值
|
||||
|
||||
---
|
||||
|
||||
## 5. 租户能力开关表设计
|
||||
|
||||
## 5.1 为什么需要功能级能力开关
|
||||
|
||||
用户这次点出来的“入口模块无法给新租户分配”只是第一层问题。更深一层是：
|
||||
|
||||
新增租户后，不一定所有模块都同时开放。
|
||||
|
||||
例如某新租户可能只开：
|
||||
|
||||
1. 首页入口
|
||||
2. 文档上传
|
||||
|
||||
但暂时不开：
|
||||
|
||||
1. 合同模板
|
||||
2. RAG 知识库管理
|
||||
3. 交叉评查
|
||||
|
||||
所以需要功能级能力模型，而不是只维护一个名字列表。
|
||||
|
||||
## 5.2 推荐表 `sys_tenant_feature_flags`
|
||||
|
||||
```sql
|
||||
CREATE TABLE IF NOT EXISTS sys_tenant_feature_flags (
|
||||
id BIGSERIAL PRIMARY KEY,
|
||||
tenant_code VARCHAR(64) NOT NULL,
|
||||
feature_key VARCHAR(64) NOT NULL,
|
||||
is_enabled BOOLEAN NOT NULL DEFAULT TRUE,
|
||||
ext JSONB NOT NULL DEFAULT '{}'::jsonb,
|
||||
created_at TIMESTAMP NOT NULL DEFAULT NOW(),
|
||||
updated_at TIMESTAMP NOT NULL DEFAULT NOW(),
|
||||
deleted_at TIMESTAMP NULL,
|
||||
UNIQUE (tenant_code, feature_key)
|
||||
);
|
||||
```
|
||||
|
||||
## 5.3 `feature_key` 建议
|
||||
|
||||
建议按当前系统模块先固化：
|
||||
|
||||
1. `home.entry_module`
|
||||
2. `documents.upload`
|
||||
3. `documents.list`
|
||||
4. `govdoc.audit`
|
||||
5. `rag.dataset`
|
||||
6. `rag.chat`
|
||||
7. `contract.template`
|
||||
8. `cross.review`
|
||||
9. `usage.stats`
|
||||
|
||||
---
|
||||
|
||||
## 6. 业务表接入规范
|
||||
|
||||
## 6.1 用户表
|
||||
|
||||
当前：
|
||||
|
||||
1. `sso_users.area`
|
||||
2. `sso_users.tenant_name`
|
||||
|
||||
建议新增：
|
||||
|
||||
1. `sso_users.tenant_code`
|
||||
|
||||
规则：
|
||||
|
||||
1. `tenant_code` 为主归属租户
|
||||
2. `area` 先保留，作为历史兼容展示字段
|
||||
3. `tenant_name` 保留，但展示应优先来自 `sys_tenants.tenant_name`
|
||||
|
||||
## 6.2 文档表
|
||||
|
||||
当前：
|
||||
|
||||
1. `leaudit_documents.region`
|
||||
|
||||
建议新增：
|
||||
|
||||
1. `leaudit_documents.tenant_code`
|
||||
|
||||
兼容策略：
|
||||
|
||||
1. 老代码读取 `region` 时，通过别名表映射为 `tenant_code`
|
||||
2. 新代码写入时同时写 `tenant_code` 和兼容 `region`
|
||||
|
||||
## 6.3 合同模板
|
||||
|
||||
当前：
|
||||
|
||||
1. `contract_templates.region`
|
||||
|
||||
建议新增：
|
||||
|
||||
1. `contract_templates.tenant_code`
|
||||
2. 可选新增 `scope_type`
|
||||
|
||||
原因：
|
||||
|
||||
当前 `省级` 既像租户，又像公共范围，语义混乱。建议拆成：
|
||||
|
||||
1. `tenant_code`
|
||||
2. `scope_type = TENANT / PUBLIC`
|
||||
|
||||
## 6.4 RAG
|
||||
|
||||
当前：
|
||||
|
||||
1. `rag_dataset.area`
|
||||
2. `rag_chat_app.area`
|
||||
3. `is_public`
|
||||
4. `is_default`
|
||||
|
||||
建议新增：
|
||||
|
||||
1. `tenant_code`
|
||||
2. `scope_type`
|
||||
|
||||
说明：
|
||||
|
||||
`is_public` 可以保留，但应由 `scope_type` 和租户类型统一解释，避免 `省级 + is_public` 双重表达。
|
||||
|
||||
## 6.5 入口模块
|
||||
|
||||
当前：
|
||||
|
||||
1. `leaudit_entry_modules.areas JSONB`
|
||||
|
||||
建议：
|
||||
|
||||
1. 保留 `leaudit_entry_modules`
|
||||
2. 新增 `leaudit_entry_module_tenants`
|
||||
3. 由关系表表达模块与租户的分配关系
|
||||
|
||||
详见文档：
|
||||
|
||||
- [入口模块租户配置表迁移方案.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/入口模块租户配置表迁移方案.md)
|
||||
|
||||
---
|
||||
|
||||
## 7. 租户类型与公共范围语义
|
||||
|
||||
## 7.1 当前问题
|
||||
|
||||
现在公共范围至少存在 4 种写法：
|
||||
|
||||
1. `省局`
|
||||
2. `省级`
|
||||
3. `default`
|
||||
4. `''`
|
||||
|
||||
这 4 种值不能继续并存。
|
||||
|
||||
## 7.2 推荐统一语义
|
||||
|
||||
建议统一为两层：
|
||||
|
||||
1. 租户归属层
|
||||
2. 数据作用域层
|
||||
|
||||
推荐枚举：
|
||||
|
||||
1. `scope_type = TENANT`
|
||||
2. `scope_type = PUBLIC`
|
||||
3. `scope_type = CROSS_TENANT`
|
||||
|
||||
说明：
|
||||
|
||||
1. `tenant_code` 决定“归属”
|
||||
2. `scope_type` 决定“谁可以看”
|
||||
|
||||
例如：
|
||||
|
||||
1. 某模板属于 `PROVINCIAL_PUBLIC`，`scope_type=PUBLIC`
|
||||
2. 某知识库属于 `MZ`，`scope_type=TENANT`
|
||||
|
||||
这样比单纯写 `region='省级'` 清晰得多。
|
||||
|
||||
---
|
||||
|
||||
## 8. 后端接口建议
|
||||
|
||||
## 8.1 新增租户主数据接口
|
||||
|
||||
建议最少提供：
|
||||
|
||||
1. `GET /api/v3/tenants`
|
||||
返回启用中的租户列表
|
||||
|
||||
2. `GET /api/v3/tenants/{tenantCode}`
|
||||
返回租户详情
|
||||
|
||||
3. `POST /api/v3/tenants`
|
||||
创建租户
|
||||
|
||||
4. `PUT /api/v3/tenants/{tenantCode}`
|
||||
更新租户
|
||||
|
||||
5. `GET /api/v3/tenants/options`
|
||||
返回前端下拉所需精简结构
|
||||
|
||||
6. `GET /api/v3/tenants/features`
|
||||
查询租户能力矩阵
|
||||
|
||||
## 8.2 返回结构建议
|
||||
|
||||
建议前端统一使用：
|
||||
|
||||
```json
|
||||
{
|
||||
"tenant_code": "MZ",
|
||||
"tenant_name": "梅州",
|
||||
"tenant_type": "LOCAL",
|
||||
"is_public": false,
|
||||
"display_order": 10,
|
||||
"is_enabled": true,
|
||||
"features": [
|
||||
"home.entry_module",
|
||||
"documents.upload",
|
||||
"rag.chat"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 9. 前端接入规范
|
||||
|
||||
所有原来写死地区列表的页面，后续都不应该再维护常量数组，而应读取租户主数据接口。
|
||||
|
||||
重点包括：
|
||||
|
||||
1. 入口模块新建页
|
||||
2. 入口模块列表页筛选
|
||||
3. 交叉评查入口可见性计算
|
||||
4. RAG 地区配置页
|
||||
5. 合同模板地区筛选
|
||||
6. 使用统计地区维度筛选
|
||||
|
||||
前端要遵守两条规则：
|
||||
|
||||
1. 存储和提交用 `tenant_code`
|
||||
2. 展示才用 `tenant_name`
|
||||
|
||||
---
|
||||
|
||||
## 10. 不建议复用 `tenant_name` 当主键
|
||||
|
||||
虽然系统里已经有 `sso_users.tenant_name`，但不建议直接把它升级为租户主键，原因有 5 个：
|
||||
|
||||
1. 它本质更像组织展示字段
|
||||
2. 历史数据可能存在空值和重复值
|
||||
3. 它不一定稳定
|
||||
4. 它可能包含业务展示修饰词
|
||||
5. 它不能稳定承载外键关系
|
||||
|
||||
因此：
|
||||
|
||||
1. `tenant_name` 可保留
|
||||
2. 但必须引入新的 `tenant_code`
|
||||
|
||||
---
|
||||
|
||||
## 11. 与权限系统的关系
|
||||
|
||||
租户主数据模型不是替代 RBAC，而是给 RBAC 提供更稳定的数据边界基座。
|
||||
|
||||
关系应为：
|
||||
|
||||
1. RBAC 决定“你能做什么”
|
||||
2. 租户主数据决定“你的租户边界是什么”
|
||||
3. 数据范围执行器把两者合并成最终访问决策
|
||||
|
||||
也就是：
|
||||
|
||||
1. `permission_key`
|
||||
2. `data_scope`
|
||||
3. `tenant_code`
|
||||
|
||||
这三者必须同时成立。
|
||||
|
||||
---
|
||||
|
||||
## 12. 推荐实施顺序
|
||||
|
||||
建议顺序如下：
|
||||
|
||||
1. 建 `sys_tenants`、`sys_tenant_aliases`、`sys_tenant_feature_flags`
|
||||
2. 先把当前固定地区和公共范围落成主数据
|
||||
3. 给 `sso_users` 增加 `tenant_code`
|
||||
4. 先改入口模块为租户接口驱动
|
||||
5. 再改 RAG、合同模板、文档上传
|
||||
6. 最后将统一数据范围执行器接到 `tenant_code`
|
||||
|
||||
---
|
||||
|
||||
## 13. 本文档解决什么问题
|
||||
|
||||
本文档主要解决：
|
||||
|
||||
1. “地区”到底该怎么升级成“租户”
|
||||
2. 新租户为什么不能只改前端下拉
|
||||
3. 为什么必须引入 `tenant_code`
|
||||
4. 为什么必须有别名表和能力开关
|
||||
5. 业务表后续应该如何统一接租户主数据
|
||||
|
||||
下一步建议继续阅读：
|
||||
|
||||
1. [地区租户化与自定义租户扩展改造方案.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/地区租户化与自定义租户扩展改造方案.md)
|
||||
2. [地区到租户编码映射清洗清单.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/地区到租户编码映射清洗清单.md)
|
||||
3. [入口模块租户配置表迁移方案.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/入口模块租户配置表迁移方案.md)
|
||||
4. [自定义租户功能连带影响深度补充.md](/home/wren-dev/Porject/leaudit-platform/docs/权限与地区隔离/自定义租户功能连带影响深度补充.md)
|
||||
Reference in New Issue
Block a user