leaudit-platform-backend/docs/权限与地区隔离/用户权限与权限点清单.md

# 用户权限初始化 SQL 与权限点清单

这份文档对应：`docs/权限与地区隔离/用户权限初始化SQL.sql`

用途只有两个：

- 帮你快速初始化当前新系统最小可用的用户权限体系
- 帮后续自己看代码、配角色、排查越权时不再忘记“每个权限点到底是干什么的”

当前这版严格按你确认过的业务收口：

- 只做 `RBAC + 单地区隔离`
- 用户地区只认 `sso_users.area`
- 角色只认 `provincial_admin`、`admin`、`common`
- `super_admin` 仅作为可选系统维护角色
- 数据范围只认 `ALL / DEPT / SELF`

---

## 1. 本次交付文件

- SQL：`docs/权限与地区隔离/用户权限初始化SQL.sql`
- 说明：`docs/权限与地区隔离/用户权限与权限点清单.md`

---

## 2. SQL 初始化了什么

这份 SQL 会初始化 5 类内容：

1. `roles` 角色基础数据
2. `sys_routes` 菜单 / 页面路由基础数据
3. `permissions` 权限点基础数据
4. `role_route` 角色可见菜单授权
5. `role_permissions` 角色权限点授权

它的定位不是“把所有未来功能一次性配满”，而是：

- 先把当前 `leaudit-platform` 已经稳定的核心能力配起来
- 后续有新接口，再继续增量追加权限点

---

## 3. 当前正式角色

## 3.1 `provincial_admin`

- 省级管理员
- 默认数据范围：`ALL`
- 能看全省文档、任务、评查结果、规则配置、用户与角色配置

## 3.2 `admin`

- 地区管理员
- 默认数据范围：`DEPT`
- 实际含义是“同地区”，不是组织部门
- 只能处理 `region = 当前用户.area` 的业务数据

## 3.3 `common`

- 普通用户
- 默认数据范围：`SELF`
- 通常只能看自己上传 / 自己触发 / 自己归属的数据
- 对部分只读接口，可以单独放宽到 `DEPT`

## 3.4 `super_admin`

- 可选系统超级管理员
- 默认数据范围：`ALL`
- 只建议用来做系统维护、初始化、排障
- 不建议参与日常业务权限设计

---

## 4. 数据范围解释

## 4.1 `ALL`

- 不做地区过滤
- 可看全部数据

## 4.2 `DEPT`

- 在本项目里，正式定义为“同地区”
- 一般等价于：`业务表.region = sso_users.area`

## 4.3 `SELF`

- 只能看自己的数据
- 一般等价于：
  - `created_by = 当前用户.id`
  - 或 `uploaded_by = 当前用户.id`
  - 或 `owner_id = 当前用户.id`

## 4.4 生效优先级

后端建议统一这样算：

1. 先看当前接口是否命中某条 `role_permissions`
2. 若该条有 `data_scope`，优先用它
3. 若该条没有 `data_scope`，回退到 `roles.data_scope`
4. 多角色命中时，取可见范围最大的那个：`ALL > DEPT > SELF`

---

## 5. 当前菜单建议

SQL 里初始化了以下核心菜单：

- `/documents`
- `/documents/list`
- `/rules`
- `/audit`
- `/audit/runs`
- `/system`
- `/system/users`
- `/system/roles`

这套菜单不是说前端必须完全一模一样，而是作为当前后台权限建模的“标准路径集合”。

---

## 6. 当前权限点清单

下面是当前已经纳入初始化 SQL 的权限点。

## 6.1 认证类

### `auth.me`

- 接口：`GET /api/auth/me`
- 用途：获取当前登录用户信息
- 建议角色：全部登录用户都可访问

---

## 6.2 文档类

### `documents.upload`

- 接口：`POST /api/upload`
- 用途：上传文档，可选自动触发评查
- `provincial_admin`：`ALL`
- `admin`：`DEPT`
- `common`：`SELF`

### `documents.list`

- 接口：`GET /api/documents/list`
- 用途：查看文档列表
- `provincial_admin`：全量文档
- `admin`：本地区文档
- `common`：自己的文档

### `documents.detail`

- 接口：`GET /api/documents/{documentId}`
- 用途：查看文档详情
- 数据范围逻辑应和 `documents.list` 保持一致

### `documents.history`

- 接口：`GET /api/documents/{documentId}/versions`
- 用途：查看同名文档历史版本
- 数据范围逻辑应和文档主记录一致

### `documents.delete`

- 接口：`DELETE /api/documents/{documentId}`
- 用途：删除文档
- 建议只开放给 `provincial_admin` 和 `admin`

---

## 6.3 评查类

### `audit.run`

- 接口：`POST /api/audit/run`
- 用途：手动触发评查
- `provincial_admin`：可发起任意地区 run
- `admin`：只能发起本地区 run
- `common`：只能发起自己可见文档的 run

### `audit.run.status`

- 接口：`GET /api/audit/run/{runId}`
- 用途：查看 run 当前执行状态

### `audit.result`

- 接口：`GET /api/audit/result/{runId}`
- 用途：查看评查结果

这两个接口都要跟随文档 / run 的归属范围过滤，不能因为知道 `runId` 就越权读取。

---

## 6.4 规则类

### `rules.list`

- 接口：`GET /api/rule-sets`
- 用途：查看规则集列表

### `rules.version.list`

- 接口：`GET /api/rule-sets/{ruleType}/versions`
- 用途：查看某规则集的版本列表

### `rules.content`

- 接口：`GET /api/rule-sets/versions/{versionId}/content`
- 用途：查看规则 YAML 正文

### `rules.validate`

- 接口：`POST /api/rule-sets/{ruleType}/validate`
- 用途：校验规则 YAML

### `rules.version.create`

- 接口：`POST /api/rule-sets/{ruleType}/versions`
- 用途：创建规则版本
- 建议开放给 `provincial_admin`
- 如确有地区自管需求，再按地区规则放给 `admin`

### `rules.publish`

- 接口：`POST /api/rule-sets/{ruleType}/publish`
- 用途：发布规则版本
- 建议只开放给 `provincial_admin`

### `rules.rollback`

- 接口：`POST /api/rule-sets/{ruleType}/rollback`
- 用途：规则回滚
- 建议只开放给 `provincial_admin`

### `rules.binding.list`

- 接口：`GET /api/rule-sets/bindings`
- 用途：查看规则绑定

### `rules.binding.create`

- 接口：`POST /api/rule-sets/{ruleType}/bindings`
- 用途：创建规则绑定

### `rules.binding.update`

- 接口：`PUT /api/rule-sets/bindings/{bindingId}`
- 用途：更新规则绑定

### `rules.binding.delete`

- 接口：`DELETE /api/rule-sets/bindings/{bindingId}`
- 用途：删除规则绑定

---

## 6.5 用户类

### `users.list`

- 接口：`GET /api/users/list`
- 用途：查看用户列表
- `provincial_admin`：全部用户
- `admin`：本地区用户
- `common`：通常不开放

### `users.create`

- 接口：`POST /api/users`
- 用途：创建用户
- 建议只开放给 `provincial_admin`

### `users.update`

- 接口：`PUT /api/users/{userId}`
- 用途：修改用户信息
- `admin` 仅能维护本地区用户

### `users.disable`

- 接口：`PUT /api/users/{userId}/disable`
- 用途：禁用 / 启用用户
- 建议只开放给 `provincial_admin`

### `users.roles.assign`

- 接口：`POST /api/users/{userId}/roles`
- 用途：为用户分配角色
- 建议只开放给 `provincial_admin`

---

## 6.6 RBAC 管理类

### `rbac.roles.list`

- 接口：`GET /api/rbac/roles`
- 用途：查看角色列表

### `rbac.roles.update`

- 接口：`PUT /api/rbac/roles/{roleId}`
- 用途：修改角色定义

### `rbac.permissions.list`

- 接口：`GET /api/rbac/permissions`
- 用途：查看权限点列表

### `rbac.role_permissions.assign`

- 接口：`POST /api/rbac/roles/{roleId}/permissions`
- 用途：给角色分配权限点

### `rbac.role_routes.assign`

- 接口：`PUT /api/rbac/roles/{roleId}/routes`
- 用途：给角色分配菜单

这些建议默认只给：

- `provincial_admin`
- `super_admin`

---

## 7. 角色默认授权概览

## 7.1 `provincial_admin`

建议拥有：

- 全部当前权限点
- 数据范围全部 `ALL`

## 7.2 `admin`

建议拥有：

- 文档上传、列表、详情、删除
- 评查触发、进度查看、结果查看
- 规则查看、校验、部分绑定维护
- 本地区用户列表与部分用户维护
- 数据范围多数为 `DEPT`

## 7.3 `common`

建议拥有：

- 当前用户信息
- 文档上传
- 自己文档列表 / 详情 / 历史版本
- 自己触发的评查任务与结果
- 部分规则只读查看
- 数据范围多数为 `SELF`

---

## 8. 后端接入要求

权限初始化 SQL 只是把“数据字典”配起来，真正生效还要靠后端统一遵守下面规则：

### 8.1 JWT 必须能拿到这些信息

至少要能拿到：

- `user_id`
- `area`
- `roles`
- `permissions`

### 8.2 接口先做功能权限，再做数据过滤

不要只做页面隐藏，必须后端实际校验：

1. 有没有权限点
2. 命中哪条 `data_scope`
3. 按 `ALL / DEPT / SELF` 注入查询条件

### 8.3 前端传入的地区不能覆盖后端数据权限

例如：

- `GET /api/documents/list?region=省局`

如果当前用户只是潮州 `admin`，后端仍然只能返回潮州数据，不能因为前端传了别的地区就放开。

---

## 9. 建议你怎么用这份 SQL

建议按这个顺序：

1. 先在测试库执行 `docs/权限与地区隔离/用户权限初始化SQL.sql`
2. 检查 `roles / permissions / role_permissions / role_route` 是否初始化成功
3. 给几个测试账号分别挂 `provincial_admin / admin / common`
4. 再用接口实际验证：
   - 文档列表是否按地区隔离
   - 当前用户信息是否正确返回 `area`
   - 上传 / 评查是否存在越权

---

## 10. 当前文档与总设计文档的关系

如果你后面忘了这套体系总原则，看这里：

- 总设计：`docs/权限与地区隔离/用户与地区权限完整设计方案.md`
- 导航说明：`docs/权限与地区隔离/权限与地区隔离文档导航.md`
- 本文：`docs/权限与地区隔离/用户权限与权限点清单.md`
- SQL：`docs/权限与地区隔离/用户权限初始化SQL.sql`

这四份组合起来，就是当前新系统用户权限方案的完整本地留档。