strepsiades
134 lines
3.5 KiB
Markdown
134 lines
3.5 KiB
Markdown
# Preparation 领域重构指南
|
|
|
|
## 1. 范围
|
|
|
|
本文档对应 backend 的 `preparation` 里程碑节点表。
|
|
|
|
当前优先关注：
|
|
|
|
- `preparation.code`
|
|
- `preparation.approval_status`
|
|
- `preparation.is_exist`
|
|
|
|
## 2. 字段盘点
|
|
|
|
### 2.1 `code`
|
|
|
|
当前实现：
|
|
|
|
- 模型里是 `String`
|
|
- 没有本地 enum 类
|
|
- 项目初始化时，节点集合来自 `preparation_{project_type}` 字典数据
|
|
- 同步 schema `project_extensions/preparation.py` 里也是 `str`
|
|
|
|
项目侧取值范围：
|
|
|
|
- 当前无法从单一代码 enum 列出完整范围
|
|
- 已知典型值包括：`JSZB`、`HZBA`、`KYNS`、`TZJC`、`YDYS`、`LCPF`、`YDPF`、`JRPF`、`HPPF`、`SGXK`、`SBPF`
|
|
|
|
集团侧差异：
|
|
|
|
- 集团侧 `enum_config.Preparation.code` 已明确把该字段作为按项目类型变化的正式候选项
|
|
- 本地当前仍主要靠初始化字典/字符串承载
|
|
|
|
结论：
|
|
|
|
- 更适合迁到 `field_config`
|
|
- 不应继续只靠初始化字典和自由字符串
|
|
|
|
### 2.2 `approval_status`
|
|
|
|
当前实现：
|
|
|
|
- backend 依赖 `ApprovalMixin`
|
|
- 本地 `PreparationApproval` schema 仍使用 int
|
|
- 同步 schema `PreparationDetail` 里是 `Optional[str]`
|
|
|
|
项目侧取值范围：
|
|
|
|
- 当前本地未在 preparation 模块中沉成独立 enum
|
|
|
|
集团侧差异：
|
|
|
|
- 同步 schema 有字段，但没有正式 enum
|
|
|
|
结论：
|
|
|
|
- 应统一接入通用审批状态体系
|
|
|
|
### 2.3 `is_exist`
|
|
|
|
当前实现：
|
|
|
|
- 模型里是 `Boolean`
|
|
- backend 和 sync schema 均有该字段
|
|
|
|
项目侧取值范围：
|
|
|
|
- `true`
|
|
- `false`
|
|
|
|
集团侧差异：
|
|
|
|
- 当前没看到 enum_config 对这个字段给出候选项
|
|
|
|
结论：
|
|
|
|
- 保持布尔字段即可
|
|
|
|
## 3. 重点结论
|
|
|
|
- `preparation.code` 是标准的初始化候选项字段，最适合迁到 `field_config`。
|
|
- `approval_status` 不需要在本领域单独发明枚举，应直接接入通用审批体系。
|
|
- `is_exist` 是布尔存在性字段，不在本轮字段级配置重点内。
|
|
|
|
## 4. 待修改项清单
|
|
|
|
1. 将 `preparation.code` 正式迁到 `field_config`。
|
|
2. 区分“节点编码范围”与“审批状态/存在性”这两类字段，不要混在一个配置源里。
|
|
3. 将 `approval_status` 接入通用审批状态定义。
|
|
|
|
## 5. 按本轮要求的改造落点
|
|
|
|
preparation 属于本轮最适合先收口的一类：
|
|
|
|
- 初始化平铺
|
|
- code 字段明确
|
|
- 旧代码里已经出现多份硬编码映射
|
|
|
|
### 5.1 初始化
|
|
|
|
当前 preparation 初始化直接来自 `preparation_{project_type}` dict。
|
|
|
|
本轮目标是：
|
|
|
|
- 把 `preparation.code` 迁到 field config
|
|
- 初始化改成通过 config 工具读取候选项再批量创建
|
|
- 不再依赖 dict 作为初始化真源
|
|
|
|
### 5.2 Create 校验
|
|
|
|
当前 `PreparationCreate` / `PreparationService` 没有统一的 code 白名单校验入口。
|
|
|
|
本轮目标是：
|
|
|
|
- 在 create / update 对应的 service 入口开头，基于 config 校验 `preparation.code`
|
|
- 不再新增本地 code 白名单或名称反查表来兜底
|
|
|
|
### 5.3 下拉列表
|
|
|
|
preparation 当前没有单独的“节点编码下拉接口”，前端更多拿的是项目实例列表 `/preparation/list`。
|
|
|
|
这轮文档上的要求是：
|
|
|
|
- 如果后续需要独立 code 候选项下拉，应直接从 `preparation.code` field config 返回
|
|
|
|
## 6. 测试关注点
|
|
|
|
preparation 领域 service 层集成测试至少覆盖：
|
|
|
|
1. 初始化：项目初始化时生成的节点是否来自目标 field config。
|
|
2. Create / Update：合法 `code` 可以写入，非法 `code` 明确报错。
|
|
3. 列表：项目实例列表顺序是否来自配置顺序，而不是硬编码 `sort_code`。
|
|
|