wren
248 lines
7.2 KiB
Markdown
248 lines
7.2 KiB
Markdown
# 新平台评查点与评查组真实模型梳理
|
|
|
|
## 1. 先给结论
|
|
|
|
前面把“新平台评查点”理解成老库 `evaluation_points` 主表，这是错误的。
|
|
|
|
当前代码里实际上并存两套链路：
|
|
|
|
1. 新平台主链路
|
|
`入口模块 -> 一级业务大类分组 -> 二级业务子类型分组 -> 规则集 -> 规则版本(YAML) -> 文档评查结果`
|
|
|
|
2. 旧兼容链路
|
|
`/api/v3/evaluation-points` -> `docauditai.evaluation_points`
|
|
|
|
也就是说：
|
|
|
|
- 新平台“评查组/评查点分组”是真正的主配置骨架。
|
|
- 新平台运行时真正承载评查规则内容的，不是 `evaluation_points` 行数据，而是 `leaudit_rule_sets + leaudit_rule_versions` 中的 YAML 规则。
|
|
- 旧的“评查点管理”页面和 `/v3/evaluation-points` 目前仍然挂在老库兼容链路上，还没有完全切到新平台主模型。
|
|
|
|
## 2. 新平台真实对象关系
|
|
|
|
### 2.1 一级分组不是老地区分组
|
|
|
|
新平台一级分组已经不是“梅州/揭阳/省级”这种地区概念，而是业务大类根：
|
|
|
|
- 合同
|
|
- 行政卷宗
|
|
- 后续新增业务大类
|
|
|
|
对应证据：
|
|
|
|
- `scripts/创建sql/migrate_rule_groups_to_business_roots.sql`
|
|
- `fastapi_modules/fastapi_leaudit/services/impl/documentServiceImpl.py`
|
|
- `fastapi_modules/fastapi_leaudit/services/impl/evaluationPointGroupServiceImpl.py`
|
|
|
|
其中迁移脚本已经把目标写得很清楚：
|
|
|
|
- 一级分组 = 业务大类
|
|
- 二级分组 = 具体业务类型
|
|
- 规则集 = 挂在二级分组下
|
|
- 入口模块 = 绑定一级分组
|
|
|
|
### 2.2 二级分组才是运行时的“业务子类型”
|
|
|
|
二级分组必须绑定具体 `document_type_id`，用于表达：
|
|
|
|
- 建设工程合同
|
|
- 买卖合同
|
|
- 行政许可-新办
|
|
- 行政许可-延续
|
|
|
|
上传文档时，后端校验 `group_id` 是否属于当前 `document_type_id`，见：
|
|
|
|
- `documentServiceImpl.py` 中 `_resolveDocumentGroupId`
|
|
|
|
说明当前系统真实运行时，文档已经开始依赖：
|
|
|
|
- 文档类型
|
|
- 二级分组
|
|
- 一级根分组
|
|
|
|
而不是依赖老 `evaluation_points` 主表。
|
|
|
|
### 2.3 真正承载“评查点内容”的是规则集与规则版本
|
|
|
|
新平台分组页不是在维护老式点表，而是在维护：
|
|
|
|
- `leaudit_rule_group_bindings`
|
|
- `leaudit_rule_sets`
|
|
- `leaudit_rule_versions`
|
|
|
|
并且“新建规则集/YAML”动作会：
|
|
|
|
1. 根据二级分组推导 `rule_type`
|
|
2. 调用 `RuleService.CreateVersion(...)`
|
|
3. 生成规则版本 YAML
|
|
4. 反查对应 `rule_set_id`
|
|
5. 自动把规则集绑定到当前二级分组
|
|
|
|
对应代码：
|
|
|
|
- `evaluationPointGroupServiceImpl.py` 中 `CreateRuleDraft`
|
|
- `ruleServiceImpl.py` 中 `CreateVersion` / `ListSets` / `GetContent`
|
|
|
|
这说明新平台里的“评查点”更接近：
|
|
|
|
- 规则 YAML 中的一条条规则项
|
|
- 或某个规则集里的规则集合
|
|
|
|
而不是老系统那种独立的 `evaluation_points` 业务主表记录。
|
|
|
|
## 3. 前端页面语义已经分叉
|
|
|
|
### 3.1 `rule-groups` 页面是新平台主入口
|
|
|
|
前端 `RuleGroupsClient.tsx` 的语义已经非常明确：
|
|
|
|
- 展示一级业务大类
|
|
- 展示二级子类型
|
|
- 给二级子类型绑定规则集
|
|
- 直接创建规则 YAML 草稿
|
|
- 查看规则集可用版本和可用规则数
|
|
|
|
这页对应的是新平台主模型，不是老分组页换皮。
|
|
|
|
### 3.2 `rules/list`、`rules/new` 仍然是旧评查点页面
|
|
|
|
前端这两页仍在调用：
|
|
|
|
- `/api/v3/evaluation-points`
|
|
|
|
后端服务 `EvaluationPointServiceImpl` 明确连接：
|
|
|
|
- `LEGACY_RULE_DB_NAME`
|
|
- 默认库 `docauditai`
|
|
|
|
说明这两页还是旧兼容页面，并没有真正迁到新平台主链路。
|
|
|
|
## 4. 文档评查运行链路怎么命中分组
|
|
|
|
当前文档链路已经和新分组模型发生真实耦合：
|
|
|
|
1. 文档上传时可带 `group_id`
|
|
2. 后端校验该 `group_id` 必须是有效二级分组
|
|
3. 系统再反解一级根分组，用于归档和版本链路
|
|
4. 文档列表、详情、统计也会回查 `leaudit_evaluation_point_groups`
|
|
|
|
对应代码集中在：
|
|
|
|
- `documentServiceImpl.py`
|
|
|
|
这意味着：
|
|
|
|
- 分组模型已经进入实际业务运行面
|
|
- 它不是“还没启用的设计稿”
|
|
|
|
## 5. 为什么我前面会判断错
|
|
|
|
因为仓库里仍保留了“评查点管理”老接口与老页面：
|
|
|
|
- `EvaluationPointController`
|
|
- `EvaluationPointServiceImpl`
|
|
- `legal-platform-frontend/app/(audit)/rules/*`
|
|
|
|
它们让表面上看起来仍像“评查点主表驱动”。
|
|
|
|
但继续往下看新分组页、规则集页、文档上传与文档评查链路，就会发现当前新平台实际已经是：
|
|
|
|
- 分组承接业务结构
|
|
- 规则集承接规则内容
|
|
- 文档按分组与规则集运行
|
|
|
|
所以真正的问题不是“给老 `evaluation_points` 补 tenant_code 就完了”，而是：
|
|
|
|
- 哪些页面仍停留在旧兼容链路
|
|
- 哪些运行链路已经切到新分组模型
|
|
- 租户边界应该落在新分组/文档/规则集哪一层
|
|
|
|
## 6. 当前最重要的纠偏结论
|
|
|
|
### 6.1 不应再把旧 `evaluation_points` 当成新平台主模型
|
|
|
|
旧链路只能视为：
|
|
|
|
- 兼容管理页
|
|
- 过渡接口
|
|
- 待迁移遗留
|
|
|
|
不能再把它作为后续“租户化/权限化/评查模块改造”的主战场。
|
|
|
|
### 6.2 新平台真正要分析的核心表
|
|
|
|
后续围绕评查点/评查组，应优先分析这些对象：
|
|
|
|
- `leaudit_evaluation_point_groups`
|
|
- `leaudit_rule_group_bindings`
|
|
- `leaudit_rule_sets`
|
|
- `leaudit_rule_versions`
|
|
- `leaudit_documents.group_id`
|
|
- `leaudit_review_point_audits`
|
|
|
|
### 6.3 “评查点”一词在当前系统里有双重含义
|
|
|
|
当前仓库里“评查点”至少有两层语义：
|
|
|
|
1. 旧语义
|
|
老库 `evaluation_points` 里的单条配置记录
|
|
|
|
2. 新语义
|
|
规则集/YAML 里的具体规则项，以及文档评查结果里的单个 review point
|
|
|
|
后续文档和代码改造必须把这两个概念拆开命名，否则一定继续误判。
|
|
|
|
建议统一命名：
|
|
|
|
- 旧链路：`legacy_evaluation_point`
|
|
- 新链路配置骨架：`rule_group / subtype_group`
|
|
- 新链路规则内容：`rule_set / rule_version / yaml_rule`
|
|
- 运行结果：`review_point_result`
|
|
|
|
## 7. 对后续改造的直接影响
|
|
|
|
### 7.1 评查模块后续工作应拆成两条线
|
|
|
|
第一条：新平台主链路
|
|
|
|
- 分组
|
|
- 文档类型
|
|
- 入口模块
|
|
- 文档上传
|
|
- 规则集绑定
|
|
- 评查运行结果
|
|
|
|
第二条：旧兼容链路
|
|
|
|
- `/v3/evaluation-points`
|
|
- 旧评查点列表/新增/编辑页面
|
|
- 老库 `docauditai.evaluation_points`
|
|
|
|
### 7.2 现在优先级更高的不是“继续补旧点评租户字段”
|
|
|
|
而是先回答这几个问题：
|
|
|
|
1. 新平台二级分组是否需要直接租户化
|
|
2. 规则集绑定是否需要租户边界
|
|
3. 文档上传时的 `group_id` 选择是否需要按租户过滤
|
|
4. 文档评查结果是否需要按租户隔离回查
|
|
5. 旧 `rules/list` 与 `rules/new` 是否继续保留，还是迁入新规则集页
|
|
|
|
## 8. 下一步建议
|
|
|
|
建议后续按下面顺序继续：
|
|
|
|
1. 先梳理“新平台主链路的租户边界设计”
|
|
重点看：入口模块、文档类型、一级分组、二级分组、文档上传、文档列表、规则集绑定
|
|
|
|
2. 再单独梳理“旧评查点兼容链路去留方案”
|
|
明确：
|
|
- 继续兼容多久
|
|
- 是否只读
|
|
- 是否要做迁移映射
|
|
|
|
3. 最后才决定是否还要继续改 `/v3/evaluation-points`
|
|
|
|
否则会继续在“旧兼容页”和“新运行主链路”之间来回误伤。
|
|
|