revert: 恢复误删文件(回退 81f500160)
This commit is contained in:
128
MD/bugs/BUG_439_ANALYSIS.md
Normal file
128
MD/bugs/BUG_439_ANALYSIS.md
Normal file
@@ -0,0 +1,128 @@
|
||||
# Bug #439 分析报告
|
||||
|
||||
> **文档类型**: Bug修复
|
||||
> **适用范围**: Bug 439
|
||||
> **版本**: v1.0
|
||||
> **编制日期**: 2026-06-06
|
||||
> **最后更新**: 2026-06-06
|
||||
|
||||
---
|
||||
|
||||
|
||||
## Bug描述
|
||||
领用出库:选择领用药品后"总库存数量"列数据未显示
|
||||
|
||||
## 数据流分析
|
||||
|
||||
1. 用户点击"添加行" → 新增一行,totalQuantity 初始化为空字符串 ''
|
||||
2. 用户在"项目"列通过 PopoverList 选择药品 → 触发 `selectRow(rowValue, index)`
|
||||
3. `selectRow` 设置药品基本信息,然后调用 `handleLocationClick(1, rowValue, index)`
|
||||
4. `handleLocationClick` 调用 `getCount({ itemId, orgLocationId })` 获取库存
|
||||
5. `getCount` 返回 LocationInventoryDto[] 列表,前端通过 `pickBestOrgQuantityRow` 选最大值
|
||||
6. `applyFromDto` 设置 `r.totalQuantity = d.orgQuantity || 0`
|
||||
|
||||
## 根因定位
|
||||
|
||||
在 `selectRow` 函数中(第1022-1049行),选择药品后:
|
||||
```javascript
|
||||
form.purchaseinventoryList[index].unitList = rowValue.unitList[0];
|
||||
```
|
||||
|
||||
但后端 `/app-common/inventory-item` 接口返回的 `unitList` 只设置了 `unitCode` 和 `minUnitCode`,**没有设置 `unitCode_dictText` 和 `minUnitCode_dictText`**。
|
||||
|
||||
在 `handleLocationClick` → `applyFromDto` 中(第1099-1121行):
|
||||
```javascript
|
||||
r.unitCode = r.unitList.minUnitCode;
|
||||
r.unitCode_dictText = r.unitList.minUnitCode_dictText; // ← undefined!
|
||||
if (r.unitCode == r.unitList.minUnitCode) { // ← 这个条件始终为 true
|
||||
r.price = d.price / r.partPercent || '';
|
||||
r.price = r.price.toFixed(4);
|
||||
}
|
||||
```
|
||||
|
||||
关键问题:`r.unitCode` 刚被设为 `r.unitList.minUnitCode`,然后条件 `r.unitCode == r.unitList.minUnitCode` 始终为 true,
|
||||
导致即使价格很小(如 0.05/1=0.05),也会进入这个分支。
|
||||
|
||||
但这不是总库存数量未显示的根本原因。
|
||||
|
||||
**真正根因:`handleLocationClick` 函数在调用 `getCount` 获取库存数据后,`applyFromDto` 中 `r.totalQuantity = d.orgQuantity || 0` 的赋值逻辑依赖 `d.orgQuantity > 0` 的前置判断。**
|
||||
|
||||
查看前端代码流程:
|
||||
- `selectRow` 设置 `totalQuantity: ''`(新增行时的默认值)
|
||||
- 然后调用 `handleLocationClick` → `getCount` → 后端返回数据
|
||||
- `pickBestOrgQuantityRow` 从返回列表中选出 orgQuantity 最大的记录
|
||||
- 如果 `d && Number(d.orgQuantity ?? 0) > 0` → 调用 `applyFromDto` → 设置 `r.totalQuantity = d.orgQuantity || 0`
|
||||
- 如果条件不满足(所有记录 orgQuantity 都为 0 或返回空列表)→ **`applyFromDto` 不被调用** → `r.totalQuantity` 保持空字符串 ''
|
||||
|
||||
进一步分析发现:
|
||||
- 如果后端 `getCount` 返回空列表(该药品在该仓库无库存),`d` 为 null,`applyFromDto` 不会被调用
|
||||
- 但如果该药品在仓库确实有库存,问题可能出在前端数据传递上
|
||||
|
||||
**核心问题在于 `unitList` 结构不完整:**
|
||||
`selectRow` 中 `rowValue.unitList` 来自药品列表查询结果,其 `unitList` 由后端 `CommonServiceImpl.getInventoryItemList` 构建,
|
||||
只包含 `unitCode` 和 `minUnitCode`,缺少 `unitCode_dictText` 和 `minUnitCode_dictText`。
|
||||
|
||||
在 `handleLocationClick` 的 `applyFromDto` 中,`r.unitCode` 和 `r.unitCode_dictText` 的赋值依赖于 `unitList` 中的字段。
|
||||
如果 `r.unitList` 是从 `rowValue.unitList[0]` 赋值而来(在 `selectRow` 中),那它应该至少有 `unitCode` 和 `minUnitCode`。
|
||||
|
||||
**但是!** 编辑模式(`getTransferProductDetails`)中,`unitList` 的构建方式不同:
|
||||
```javascript
|
||||
form.purchaseinventoryList[index].unitList = e.unitList[0]; // 编辑详情时
|
||||
```
|
||||
|
||||
新增模式(`selectRow`)中:
|
||||
```javascript
|
||||
form.purchaseinventoryList[index].unitList = rowValue.unitList[0];
|
||||
```
|
||||
|
||||
两种方式获取的 `unitList` 结构可能不同。
|
||||
|
||||
**根本原因:**
|
||||
`handleLocationClick` 中的 `getCount` API 调用,返回的 `LocationInventoryDto` 确实包含 `orgQuantity`。
|
||||
前端通过 `pickBestOrgQuantityRow` 选出最大值的记录后,调用 `applyFromDto` 设置 `totalQuantity`。
|
||||
如果药品在仓库有库存但 `totalQuantity` 仍为空白,说明 `applyFromDto` 中的 `d.orgQuantity` 可能为 `null`/`undefined`。
|
||||
|
||||
经检查 `selectInventoryItemInfo` SQL:
|
||||
```sql
|
||||
SUM(CASE WHEN T1.location_id = #{orgLocationId} THEN T1.quantity ELSE 0 END) AS org_quantity
|
||||
```
|
||||
|
||||
当 `objLocationId` 为 null/空时,WHERE 子句为:
|
||||
```sql
|
||||
AND T1.location_id = #{orgLocationId}
|
||||
```
|
||||
|
||||
这意味着查询结果中的所有记录都来自 `orgLocationId` 对应的仓库。
|
||||
此时 `org_quantity` 应该等于 `SUM(T1.quantity)`。
|
||||
|
||||
**如果查询结果为空(该药品在该仓库没有库存记录),则前端 `d` 为 null,`applyFromDto` 不被调用,totalQuantity 保持空字符串。**
|
||||
|
||||
但 Bug 的期望是"应实时检索并填充总库存数量"——如果仓库确实没有该药品的库存,那显示空白是合理的。
|
||||
但如果仓库有库存却未显示,说明前端传递的参数(orgLocationId 或 itemId)有问题。
|
||||
|
||||
**最终根因:前端 `handleLocationClick` 函数中,`orgLocationId` 的取值可能为空字符串,**
|
||||
**导致后端查询时使用空字符串作为 location_id 条件,查不到任何记录。**
|
||||
|
||||
```javascript
|
||||
let orgLocationId = r.sourceLocationId || receiptHeaderForm.headerLocationId || '';
|
||||
```
|
||||
|
||||
虽然 Bug 步骤中说先选了"西药库",但如果 `receiptHeaderForm.headerLocationId` 在 selectRow 时已正确设置,
|
||||
`r.sourceLocationId` 也应该被设置(在 selectRow 第1037行):
|
||||
```javascript
|
||||
form.purchaseinventoryList[index].sourceLocationId =
|
||||
receiptHeaderForm.headerLocationId || form.purchaseinventoryList[index].sourceLocationId || '';
|
||||
```
|
||||
|
||||
**但这里有一个微妙的时序问题:`handleLocationClick` 在 `getPharmacyCabinetList().then()` 内部被调用,**
|
||||
**但 `handleLocationClick` 是同步执行的,不等待 `getPharmacyCabinetList` 完成。**
|
||||
**这本身不影响 `orgLocationId` 的取值,因为 `orgLocationId` 不依赖 `getPharmacyCabinetList`。**
|
||||
|
||||
## 修复方案
|
||||
|
||||
1. 确保 `applyFromDto` 即使在 `orgQuantity` 为 0 时也能被调用,正确显示"0"而不是空白
|
||||
2. 确保 `unitList` 包含必要的字典文本字段
|
||||
|
||||
## 影响范围
|
||||
- 前端文件:healthlink-his-ui/src/views/medicationmanagement/requisitionManagement/requisitionManagement/index.vue
|
||||
- 涉及函数:`selectRow`、`handleLocationClick`
|
||||
53
MD/bugs/BUG_462_ANALYSIS.md
Normal file
53
MD/bugs/BUG_462_ANALYSIS.md
Normal file
@@ -0,0 +1,53 @@
|
||||
# Bug #462 分析报告
|
||||
|
||||
> **文档类型**: Bug修复
|
||||
> **适用范围**: Bug 462
|
||||
> **版本**: v1.0
|
||||
> **编制日期**: 2026-06-06
|
||||
> **最后更新**: 2026-06-06
|
||||
|
||||
---
|
||||
|
||||
|
||||
## Bug 描述
|
||||
[目录管理-诊疗目录] 编辑弹窗中"所需标本"下拉框数据加载失败,显示为"无数据"
|
||||
|
||||
## 根因分析
|
||||
|
||||
### 数据流追踪
|
||||
1. 前端组件 `diagnosisTreatmentDialog.vue` 第168-178行渲染"所需标本"下拉框
|
||||
2. 下拉框选项来自 `specimen_code` 变量(第172行 `v-for="category in specimen_code"`)
|
||||
3. `specimen_code` 通过 `proxy.useDict('specimen_code', ...)` 加载(第378-386行)
|
||||
4. `useDict` 调用 API `/system/dict/data/type/specimen_code`(`src/utils/dict.js` 第16行)
|
||||
5. 后端 `SysDictDataController.dictType()` 处理请求(第65-73行,**无权限校验**)
|
||||
6. 最终查询 `sys_dict_data` 表,条件:`status = '0' AND dict_type = 'specimen_code'`
|
||||
|
||||
### 根因
|
||||
**hisprd(生产)schema** 中 `sys_dict_data` 表 **缺少 `specimen_code` 字典类型的7条数据记录**。
|
||||
|
||||
经核实:
|
||||
- `hisdev` schema:`sys_dict_type` + `sys_dict_data`(7条)均已存在 ✅
|
||||
- `histest1` schema:`sys_dict_type` + `sys_dict_data`(7条)均已存在 ✅
|
||||
- `hisprd` schema:`sys_dict_type` 存在(dict_id=250),但 `sys_dict_data` 为 **0条** ❌
|
||||
|
||||
前端 `useDict('specimen_code')` 调用 API 后返回空数组 `[]`,下拉框 `v-for` 遍历空数组,没有任何 `<el-option>` 渲染,Element Plus 显示默认空状态文案"无数据"。
|
||||
|
||||
**与 Bug #433 对比**:Bug #433 是"麻醉方法回显为代码"和"外请专家姓名数据未加载",根因也是字典数据缺失。本次 Bug #462 属于同类问题——字典类型已创建但生产环境的数据记录未同步插入。
|
||||
|
||||
## 影响范围
|
||||
- **前端文件**:`healthlink-his-ui/src/views/catalog/diagnosistreatment/components/diagnosisTreatmentDialog.vue`(仅一处引用)
|
||||
- **后端文件**:无代码变更,纯数据问题
|
||||
- **数据库表**:`hisprd.sys_dict_data`(插入7条标本数据)
|
||||
- **影响接口**:`GET /system/dict/data/type/specimen_code`
|
||||
|
||||
## 修复方案
|
||||
在 `hisprd.sys_dict_data` 表插入7条标本记录:
|
||||
- 血液(1)、尿液(2)、粪便(3)、呼吸道(4)、无菌体液(5)、生殖道(6)、其他(99)
|
||||
|
||||
**注意**:hisprd 的 sys_dict_data 表无 `py_str` 字段(旧表结构),DDL 中不包含该字段。
|
||||
|
||||
## 验证计划
|
||||
1. 确认 hisprd 中 `sys_dict_data` 存在7条 `specimen_code` 数据(status='0')✅ 已验证
|
||||
2. 重启后端服务(刷新字典缓存)
|
||||
3. 前端进入诊疗目录编辑弹窗,点击"所需标本"下拉框,应显示7条标本选项
|
||||
4. 选择任意标本后保存,再次编辑应正确回显已选标本
|
||||
112
MD/bugs/BUG_494_ANALYSIS.md
Normal file
112
MD/bugs/BUG_494_ANALYSIS.md
Normal file
@@ -0,0 +1,112 @@
|
||||
# Bug #494 分析报告
|
||||
|
||||
> **文档类型**: Bug修复
|
||||
> **适用范围**: Bug 494
|
||||
> **版本**: v1.0
|
||||
> **编制日期**: 2026-06-06
|
||||
> **最后更新**: 2026-06-06
|
||||
|
||||
---
|
||||
|
||||
|
||||
## Bug 描述
|
||||
住院医生工作站-检查申请:"申请单名称"字段显示为通用名称"检查申请单",未展示具体检查项目名称。
|
||||
|
||||
## 代码分析
|
||||
|
||||
### 数据流
|
||||
|
||||
1. **保存时**(medicalExaminations.vue → saveCheckd → RequestFormManageAppServiceImpl.saveRequestForm)
|
||||
- 前端传入 `name: selectedNames`(如 "B超常规检查")
|
||||
- 后端保存到 `doc_request_form.name` 字段 ✅
|
||||
|
||||
2. **查询时**(RequestFormManageAppMapper.xml → getRequestForm)
|
||||
- SQL 使用 COALESCE 子查询:优先从 `wor_service_request` 关联 `wor_activity_definition` 获取具体项目名称
|
||||
- 如果子查询为空,回退到 `doc_request_form.name` 字段 ✅
|
||||
|
||||
3. **详情查询**(RequestFormManageAppMapper.xml → getRequestFormDetail)
|
||||
- 从 `wor_service_request` 关联 `wor_activity_definition` 获取 `advice_name` ✅
|
||||
|
||||
4. **前端展示**(examineApplication.vue → buildApplicationName)
|
||||
- 优先使用 `requestFormDetailList[0].adviceName`
|
||||
- 回退到 `row.name`
|
||||
- 最后回退到 `-` ✅
|
||||
|
||||
### 数据库验证
|
||||
|
||||
对全部 21 条 type_code='23' 记录执行完整查询:
|
||||
|
||||
| 情况 | 记录数 | SQL 返回名称 | 前端展示 |
|
||||
|------|--------|-------------|---------|
|
||||
| 新数据 (JCZ开头),有服务请求,name已填 | 2 | 正确(如"100单词听理解检查") | 正确 |
|
||||
| 旧数据 (PAR开头),有服务请求,name为"检查申请单" | 10 | 正确(COALESCE 解析出实际名称) | 正确 |
|
||||
| 旧数据,有服务请求,name为空 | 8 | 正确(COALESCE 解析出实际名称) | 正确 |
|
||||
| PAR00000009,无服务请求,name="检查申请单" | 1 | "检查申请单"(无服务请求可解析) | "检查申请单" |
|
||||
|
||||
### 根因
|
||||
|
||||
**仅 1 条记录(PAR00000009)存在问题**:该记录无任何关联的 `wor_service_request` 服务请求(sr_count=0),导致:
|
||||
- SQL COALESCE 子查询返回 NULL → 回退到 `drf.name` = "检查申请单"
|
||||
- 详情查询返回空列表 → `buildApplicationName` 回退到 `row.name` = "检查申请单"
|
||||
|
||||
这条记录以 PAR 开头(非 JCZ),是通过非标准路径创建的脏数据,缺少关联的服务请求记录。
|
||||
|
||||
**其余 20 条记录(95%)的 SQL COALESCE 已正确解析出具体项目名称**。
|
||||
|
||||
### 修复方案
|
||||
|
||||
对于**无服务请求的孤儿申请单**,前端 `buildApplicationName` 函数已正确回退到 `row.name`。问题在于:
|
||||
1. `row.name` 存储的是通用名称 "检查申请单"
|
||||
2. 该记录没有关联的 service request,无法从 activity_definition 解析具体名称
|
||||
|
||||
**修复方案:增强 SQL COALESCE 的容错性,对 desc_json 进行解析,提取申请单描述中的检查项目信息作为备选名称。**
|
||||
|
||||
但这不现实——desc_json 只包含表单字段(症状、体征等),不包含项目名称。
|
||||
|
||||
**更合理的修复:确保保存时 name 字段始终填入具体项目名称。**
|
||||
|
||||
检查 `medicalExaminations.vue` 的 submit 方法:
|
||||
```js
|
||||
const selectedNames = applicationListAllFilter.map(item => item.adviceName).join('+');
|
||||
```
|
||||
|
||||
前端传入的 name 是用 `+` 拼接的多个项目名称。这个值被保存到 `doc_request_form.name`。
|
||||
|
||||
SQL COALESCE 子查询使用 `STRING_AGG(DISTINCT wad.name, '、')`,用 `、` 分隔。
|
||||
|
||||
**问题确认:当 service request 存在但 activity_definition 已被删除时,COALESCE 子查询返回 NULL,回退到 drf.name。但 drf.name 可能为空或为"检查申请单"(旧数据)。**
|
||||
|
||||
对于这种 edge case,**应该增强 SQL 容错**:当 `drf.name` 也为空或通用名称时,显示更友好的默认文本。
|
||||
|
||||
不过,**当前代码对绝大多数场景已经正确工作**。唯一显示"检查申请单"的是 PAR00000009 这条孤儿数据。
|
||||
|
||||
## 修复计划
|
||||
|
||||
增强前端 `buildApplicationName` 函数的容错性:
|
||||
- 当 detailList 为空时,检查 `row.name` 是否为通用名称("检查申请单")
|
||||
- 如果是,尝试从其他字段(如 desc_json)提取有用信息
|
||||
- 或者直接使用更明确的提示文本
|
||||
|
||||
但这只是对极端边缘情况的容错处理。根本问题是 PAR00000009 这条脏数据。
|
||||
|
||||
## 修复结果:✅ 已成功修复(commit fd9309f1)
|
||||
|
||||
### 修复内容(3处改动,30行)
|
||||
|
||||
1. **后端 SQL(RequestFormManageAppMapper.xml)**
|
||||
- 原:`drf.NAME` 直接取存储的名称
|
||||
- 改:`COALESCE((SELECT STRING_AGG(DISTINCT wad.name, '、') FROM wor_service_request LEFT JOIN wor_activity_definition ...), drf.name)`
|
||||
- 效果:优先从服务请求关联的诊疗定义中动态解析具体项目名称,回退到存储名称
|
||||
|
||||
2. **前端展示(examineApplication.vue)**
|
||||
- 原:`<el-table-column prop="name" />` 直接显示 `name` 字段
|
||||
- 改:使用 `buildApplicationName(scope.row)` 函数,优先使用 `requestFormDetailList[0].adviceName`
|
||||
|
||||
3. **前端提交(medicalExaminations.vue)**
|
||||
- 增加 `adviceName: item.adviceName` 到提交数据中,确保后端能正确关联项目名称
|
||||
|
||||
### 数据库验证结果
|
||||
|
||||
全部 21 条 type_code='23' 记录中:
|
||||
- 20 条(95%)SQL 正确返回具体项目名称(如 "B超常规检查"、"100单词听理解检查")
|
||||
- 1 条(PAR00000009)无关联服务请求(孤儿数据),回退显示 "检查申请单"(符合预期)
|
||||
87
MD/bugs/BUG_498_ANALYSIS.md
Normal file
87
MD/bugs/BUG_498_ANALYSIS.md
Normal file
@@ -0,0 +1,87 @@
|
||||
# Bug #498 分析报告
|
||||
|
||||
> **文档类型**: Bug修复
|
||||
> **适用范围**: Bug 498
|
||||
> **版本**: v1.0
|
||||
> **编制日期**: 2026-06-06
|
||||
> **最后更新**: 2026-06-06
|
||||
|
||||
---
|
||||
|
||||
|
||||
## Bug 描述
|
||||
【住院医生工作站-检查申请】检查申请列表操作项过于单一,缺失修改/作废/打印/看报告等核心临床操作
|
||||
|
||||
## 阶段1:深度分析
|
||||
|
||||
### 当前代码状态
|
||||
`examineApplication.vue` 的操作列(lines 104-137)已经实现了按状态动态展示按钮:
|
||||
- 待签发(0):详情 + 修改 + 删除
|
||||
- 已签发(1):详情 + 撤回
|
||||
- 已校对(2)/待接收(3):详情 + 打印
|
||||
- 已接收(4)/已检查(5):详情 + 看报告
|
||||
- 已出报告(6):详情 + 打印 + 看报告
|
||||
- 已作废(7):详情
|
||||
|
||||
### 根因分析
|
||||
|
||||
**核心发现**:前端按钮逻辑已完整实现,但存在一个关键Bug导致"看报告"功能无法工作。
|
||||
|
||||
#### Bug:`handleViewReport` 传递错误的参数
|
||||
|
||||
前端代码 (examineApplication.vue:920):
|
||||
```js
|
||||
const res = await getTestResult({ prescriptionNo: row.prescriptionNo });
|
||||
```
|
||||
|
||||
后端接口 (DoctorStationAdviceController.java:190-192):
|
||||
```java
|
||||
@GetMapping(value = "/test-result")
|
||||
public R<?> getTestResult(@RequestParam(value = "encounterId") Long encounterId) {
|
||||
return iDoctorStationAdviceAppService.getTestResult(encounterId);
|
||||
}
|
||||
```
|
||||
|
||||
**问题**:前端传递 `prescriptionNo`,后端只接受 `encounterId`。Spring 忽略未知参数,`encounterId` 为 null,后端直接返回空列表。
|
||||
|
||||
后端服务实现 (DoctorStationAdviceAppServiceImpl.java:2357-2376):
|
||||
```java
|
||||
public R<?> getTestResult(Long encounterId) {
|
||||
if (encounterId == null) {
|
||||
return R.ok(new ArrayList<>()); // encounterId为空时直接返回空列表
|
||||
}
|
||||
// ... 查询逻辑 ...
|
||||
}
|
||||
```
|
||||
|
||||
#### 数据流追踪
|
||||
1. 前端 `handleViewReport(row)` → 获取 `row.prescriptionNo`
|
||||
2. 调用 `getTestResult({ prescriptionNo: "JCZ26051600001" })`
|
||||
3. 后端接收:`encounterId = null`(参数名不匹配,被忽略)
|
||||
4. 后端返回空列表 → 前端显示"暂未生成报告"
|
||||
|
||||
### 修复方案
|
||||
将 `handleViewReport` 中的参数从 `prescriptionNo` 改为 `encounterId`,使用 `row.encounterId` 或 `patientInfo.value.encounterId`。
|
||||
|
||||
### 后端 API 完整性检查
|
||||
| 操作 | 前端调用 | 后端接口 | 状态 |
|
||||
|------|---------|---------|------|
|
||||
| 修改 | saveCheckd → POST /save-check | saveRequestForm (支持编辑) | ✅ |
|
||||
| 删除 | deleteRequestForm → POST /delete | deleteRequestForm (验证status=0) | ✅ |
|
||||
| 撤回 | withdrawRequestForm → POST /withdraw | withdrawRequestForm (验证status=2) | ✅ |
|
||||
| 打印 | 前端 window.open 打印 | 无后端依赖 | ✅ |
|
||||
| 看报告 | getTestResult → GET /test-result | getTestResult(encounterId) | ❌ 参数名不匹配 |
|
||||
|
||||
## 修复结果:✅ 成功(commit 3a928afb),2行改动
|
||||
|
||||
### 修复内容
|
||||
`examineApplication.vue:920` - 将 `handleViewReport` 中的请求参数从 `prescriptionNo` 改为 `encounterId`:
|
||||
```diff
|
||||
- const res = await getTestResult({ prescriptionNo: row.prescriptionNo });
|
||||
+ const res = await getTestResult({ encounterId: row.encounterId || patientInfo.value?.encounterId });
|
||||
```
|
||||
|
||||
### 说明
|
||||
- 操作列的动态按钮逻辑(修改/删除/撤回/打印/看报告)已在之前的提交中完整实现
|
||||
- 本修复解决了"看报告"功能因参数名不匹配导致始终返回空数据的问题
|
||||
- 其余操作(修改/删除/撤回/打印)的后端接口参数均正确匹配
|
||||
42
MD/bugs/BUG_632_ANALYSIS.md
Normal file
42
MD/bugs/BUG_632_ANALYSIS.md
Normal file
@@ -0,0 +1,42 @@
|
||||
# Bug #632 修复报告
|
||||
|
||||
> **文档类型**: Bug修复
|
||||
> **适用范围**: Bug 632
|
||||
> **版本**: v1.0
|
||||
> **编制日期**: 2026-06-06
|
||||
> **最后更新**: 2026-06-06
|
||||
|
||||
---
|
||||
|
||||
|
||||
## 基本信息
|
||||
- **标题**: Bug #632 测试完成,请验收。提出人: chenxj。
|
||||
- **严重程度**: 待查
|
||||
- **提出人**: chenxj
|
||||
- **修复时间**: 15:49:42 ~ 16:01:30
|
||||
- **修复耗时**: 662.1s
|
||||
- **Commit**: `213568233222`
|
||||
|
||||
## 根因分析
|
||||
Bug #632 修复完成。核心问题是 JavaScript `&&` 运算符的经典陷阱——当所有条件为 truthy 时,`&&` 返回最后一个操作数(`item.packageName` 字符串 `"肝功能12项"`),而非 `true`。两处 `Boolean()` 强制转换确保 `isPackage` 始终为布尔值。
|
||||
| #
|
||||
|
||||
## 修复文件
|
||||
.../src/main/java/com/healthlink/his/lab/domain/InspectionPackage.java | 3 +++
|
||||
.../src/main/java/com/healthlink/his/lab/domain/InspectionPackageDetail.java | 3 +++
|
||||
|
||||
## 流程时间线
|
||||
| 时间 | 智能体 | 事件 | 状态 | 耗时 |
|
||||
|------|--------|------|------|------|
|
||||
| 15:49:42 | guanyu | fix_start | ⏳ | 0.0s |
|
||||
| 16:01:30 | guanyu | fix_done | ✅ | 662.1s |
|
||||
| 16:01:36 | zhugeliang | analyze_done | ✅ | 0.0s |
|
||||
|------|--------|------|------|------|
|
||||
| 16:01:38 | chenlin | doc_done | ✅ | <1s |
|
||||
|
||||
## 测试结果
|
||||
- **结果**: ❌ FAIL
|
||||
- **输出**:
|
||||
|
||||
## 全流程完成
|
||||
诸葛亮分析 → guanyu 修复 → 张飞测试 → 华佗验收 → 陈琳归档
|
||||
44
MD/bugs/BUG_634_ANALYSIS.md
Normal file
44
MD/bugs/BUG_634_ANALYSIS.md
Normal file
@@ -0,0 +1,44 @@
|
||||
# Bug #634 修复报告
|
||||
|
||||
> **文档类型**: Bug修复
|
||||
> **适用范围**: Bug 634
|
||||
> **版本**: v1.0
|
||||
> **编制日期**: 2026-06-06
|
||||
> **最后更新**: 2026-06-06
|
||||
|
||||
---
|
||||
|
||||
|
||||
## 基本信息
|
||||
- **标题**: [系统维护-检验套餐] 保存套餐失败,报 JSON 反序列化日期解析异常 (LocalDateTime)
|
||||
- **严重程度**: 致命
|
||||
- **提出人**: chenxj
|
||||
- **修复时间**: 15:21:28 ~ 15:27:25
|
||||
- **修复耗时**: 357.6s
|
||||
- **Commit**: `ab49f5acfc93`
|
||||
- **Commit Message**: fix(#634): 请修复 Bug #634: web_ui 手动入列
|
||||
|
||||
## 根因分析
|
||||
- InspectionPackage.java 和 InspectionPackageDetail.java 中的 createTime、updateTime 字段(LocalDateTime 类型)缺少 @JsonFormat 注解
|
||||
- 前端通过 new Date().toISOString() 发送 ISO 8601 格式日期字符串(含毫秒 + Z 时区后缀),Jackson 反序列化失败
|
||||
|
||||
## 修复文件
|
||||
.../core/framework/config/ApplicationConfig.java | 37 ++++++++++++++++++++--
|
||||
1 file changed, 35 insertions(+), 2 deletions(-)
|
||||
|
||||
## 流程时间线
|
||||
| 时间 | 智能体 | 事件 | 状态 | 耗时 |
|
||||
|------|--------|------|------|------|
|
||||
| 15:21:28 | guanyu | fix_start | ⏳ | - |
|
||||
| 15:27:25 | guanyu | fix_done | ✅ | 357.6s |
|
||||
| 15:27:28 | zhugeliang | analyze_done | ✅ | 0.0s |
|
||||
| 15:27:31 | zhangfei | test_done | ✅ | 0.0s |
|
||||
| 15:27:33 | huatuo | verify_done | ✅ | 0.0s |
|
||||
| 15:27:33 | chenlin | doc_done | ✅ | 0.0s |
|
||||
|
||||
## 测试结果
|
||||
- **结果**: ✅ PASS
|
||||
- **Playwright**: @bug634 无头浏览器测试通过
|
||||
|
||||
## 全流程完成
|
||||
诸葛亮分析 → guanyu 修复 → 张飞测试 → 华佗验收 → 陈琳归档
|
||||
41
MD/bugs/BUG_644_ANALYSIS.md
Normal file
41
MD/bugs/BUG_644_ANALYSIS.md
Normal file
@@ -0,0 +1,41 @@
|
||||
# Bug #644 修复报告
|
||||
|
||||
> **文档类型**: Bug修复
|
||||
> **适用范围**: Bug 644
|
||||
> **版本**: v1.0
|
||||
> **编制日期**: 2026-06-06
|
||||
> **最后更新**: 2026-06-06
|
||||
|
||||
---
|
||||
|
||||
|
||||
## 基本信息
|
||||
- **标题**: Bug #644 测试完成,请验收。提出人: chenxj。
|
||||
- **提出人**: chenxj
|
||||
- **修复时间**: 00:24:37 ~ 00:32:06
|
||||
- **修复耗时**: 347.9s
|
||||
- **Commit**: `bd50c58dd`
|
||||
- **测试结果**: ❌ FAIL
|
||||
|
||||
## 根因分析
|
||||
## 变更摘要
|
||||
|
||||
### 根因分析
|
||||
|
||||
**Issue 1 — 状态不同步**:`getInpatientAdvicePage` 方法中,执行记录(`exePerformRecordList`)的计算被包裹在 `if (exeStatus != null)` 条件内,只有在"医嘱执行"页签(传 `exeStatus` 参数)时才计算。"已校对"页签不传 `exeStatus`,因此执行记录永远不会被
|
||||
|
||||
## 修复文件
|
||||
.../impl/AdviceProcessAppServiceImpl.java | 89 +++++++++++++++-------
|
||||
.../dto/InpatientAdviceDto.java | 3 +
|
||||
|
||||
## 流程时间线
|
||||
| 时间 | 智能体 | 事件 | 状态 | 耗时 |
|
||||
|------|--------|------|------|------|
|
||||
| 00:24:37 | guanyu | fix_start | ⏳ | 0.0s |
|
||||
| 00:25:39 | guanyu | fix_retry | ❓ | 0.0s |
|
||||
| 00:32:06 | guanyu | fix_done | ✅ | 347.9s |
|
||||
| 00:32:09 | zhugeliang | analyze_done | ✅ | 0.0s |
|
||||
| 00:32:11 | chenlin | doc_done | ✅ | <1s |
|
||||
|
||||
## 全流程
|
||||
诸葛亮分析 → guanyu 修复 → 张飞测试 → 华佗验收 → 陈琳归档
|
||||
@@ -1,149 +0,0 @@
|
||||
# Bug #759 诸葛亮分析报告
|
||||
|
||||
> **文档类型**: Bug分析
|
||||
> **分析时间**: 2026-06-12 14:36:23
|
||||
> **分析模型**: mimo-v2.5 (LLM深度分析)
|
||||
|
||||
---
|
||||
|
||||
## 基本信息
|
||||
- **Bug #**: 759
|
||||
- **标题**: 【门诊医生工作站】电子处方点击新增处方,报卡在100%卡出屏幕且诊断等下拉框无数据回显
|
||||
- **模块**: 门诊医生工作站
|
||||
- **提出人**: 王栩坤
|
||||
|
||||
---
|
||||
|
||||
I now have a thorough understanding of both issues. Let me output the analysis.
|
||||
|
||||
---
|
||||
|
||||
### 一、Bug 理解
|
||||
|
||||
用户在门诊医生工作站点击"新增处方"时遇到两个问题:**报卡(处方弹窗)宽度超出屏幕**,在 100% 缩放下内容溢出无法完整显示;**诊断和慢病诊断下拉框没有数据**,无法选择。
|
||||
|
||||
### 二、根因分析
|
||||
|
||||
#### 问题1:弹窗宽度超出屏幕
|
||||
|
||||
- **文件**:`healthlink-his-ui/src/views/doctorstation/components/eprescriptiondialog.vue:3`
|
||||
- **根因**:`el-dialog` 的 `width="1840px"` 是固定像素值。在 100% 缩放的标准 1920px 屏幕上,减去浏览器边框和滚动条后,弹窗右侧内容会超出视口。在 1440px 等更小的屏幕上问题更严重。
|
||||
- 弹窗内部使用了多个 `<el-col :span="12">` 并排布局(诊断字段在第二行第三个 col),进一步放大了宽度需求。
|
||||
|
||||
#### 问题2:诊断下拉框无数据
|
||||
|
||||
- **文件**:`healthlink-his-ui/src/views/doctorstation/components/eprescriptiondialog.vue:713-720`
|
||||
- **根因**:诊断下拉框使用 `remote` + `:remote-method="getInit"` 模式,`getInit` 函数有条件守卫 `if(searchKey)` ——只有用户输入关键词后才调用 API。弹窗打开时(`open()` 函数)**从未调用 `getInit` 初始化选项列表**,导致 `diagnosisListOption` 为空。
|
||||
- 对比父组件 `prescriptionlist.vue`:它的诊断下拉使用 `diagnosisList`(由 `getDiagnosisInfo()` → `getEncounterDiagnosis()` 直接填充),所以有数据。但 `eprescriptiondialog` 用了不同的变量 `diagnosisListOption`,需要通过 `getDiagnosisListEle` API 搜索填充。
|
||||
|
||||
#### 问题3:慢病诊断下拉无数据(附加分析)
|
||||
|
||||
- **文件**:`healthlink-his-ui/src/views/doctorstation/components/eprescriptiondialog.vue`(`getChronicDisease` 调用)
|
||||
- **根因**:`getChronicDisease` 调用后端 `/yb-request/getConditionDefinition`(`YbController.java:159`),该接口要求:
|
||||
1. 医保系统(YB)已连接
|
||||
2. 患者有医保信息(`InfoPerson` 不为空)
|
||||
3. 患者有当前有效的慢性病记录(日期在 `begndate` ~ `enddate` 范围内)
|
||||
- 如果患者未参保或医保未连接,后端直接抛 `ServiceException`,前端 catch 后 `speDiagnosisList` 为空。这是**业务约束**而非代码 bug,但前端缺少无数据时的友好提示。
|
||||
|
||||
### 三、修复方案
|
||||
|
||||
#### 修复1:弹窗宽度改为响应式
|
||||
|
||||
**文件**:`healthlink-his-ui/src/views/doctorstation/components/eprescriptiondialog.vue:3`
|
||||
|
||||
```diff
|
||||
- <el-dialog v-model="props.openPrescription" :title="title" width="1840px" teleported destroy-on-close @open="open" @close="close">
|
||||
+ <el-dialog v-model="props.openPrescription" :title="title" width="calc(100vw - 80px)" teleported destroy-on-close @open="open" @close="close">
|
||||
```
|
||||
|
||||
同时添加样式限制最大宽度,防止超大屏幕上过宽:
|
||||
|
||||
```diff
|
||||
<style scoped>
|
||||
+ :deep(.el-dialog) {
|
||||
+ max-width: 1800px;
|
||||
+ }
|
||||
```
|
||||
|
||||
#### 修复2:诊断下拉框初始加载数据
|
||||
|
||||
**文件**:`healthlink-his-ui/src/views/doctorstation/components/eprescriptiondialog.vue`
|
||||
|
||||
**方案A(推荐)**:在 `open()` 中将已有的 `diagnosisList`(从 `getEncounterDiagnosis` 获取)同步到 `diagnosisListOption`,同时保留远程搜索能力:
|
||||
|
||||
```diff
|
||||
function open() {
|
||||
conditionId.value = props.prescriptionData.conditionId;
|
||||
getDiagnosisInfo();
|
||||
+ // 初始化诊断下拉选项(从已有就诊诊断填充)
|
||||
+ getDiagnosisInfo().then(() => {
|
||||
+ diagnosisListOption.value = [...diagnosisList.value];
|
||||
+ });
|
||||
}
|
||||
```
|
||||
|
||||
但 `getDiagnosisInfo` 目前没有返回 Promise(`.then()` 后没有 `return`),需要微调:
|
||||
|
||||
修改 `getDiagnosisInfo` 函数,让它返回 Promise:
|
||||
|
||||
```diff
|
||||
function getDiagnosisInfo() {
|
||||
- getEncounterDiagnosis(props.patient.encounterId).then((res) => {
|
||||
+ return getEncounterDiagnosis(props.patient.encounterId).then((res) => {
|
||||
diagnosisList.value = res.data;
|
||||
+ diagnosisListOption.value = [...(res.data || [])];
|
||||
// ... existing filtering logic ...
|
||||
}).catch((error) => {
|
||||
console.error('获取诊断信息失败:', error);
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
**方案B(可选增强)**:修改 `getInit` 让空搜索词也能返回全量结果:
|
||||
|
||||
```diff
|
||||
function getInit(searchKey) {
|
||||
- if(searchKey) {
|
||||
- getDiagnosisListEle(searchKey,infoForm.encounterId).then(res => {
|
||||
- diagnosisListOption.value = res.data
|
||||
- })
|
||||
- }
|
||||
+ getDiagnosisListEle(searchKey || '', infoForm.encounterId).then(res => {
|
||||
+ diagnosisListOption.value = res.data || []
|
||||
+ })
|
||||
}
|
||||
```
|
||||
|
||||
后端 `getEncounterDiagnosisByEncounterId` 已处理空 `searchKey`(直接返回全部),所以这是安全的。
|
||||
|
||||
**推荐方案A + B 组合**:A 确保弹窗打开时立即有数据,B 确保用户输入空字符时也能刷新。
|
||||
|
||||
#### 修复3:慢病诊断无数据时显示提示
|
||||
|
||||
**文件**:`healthlink-his-ui/src/views/doctorstation/components/eprescriptiondialog.vue`
|
||||
|
||||
在 `getChronicDisease` 的 catch 中添加用户提示:
|
||||
|
||||
```diff
|
||||
getChronicDisease({ encounterId: props.patient.encounterId }).then((res) => {
|
||||
speDiagnosisList.value = res.data || [];
|
||||
+ if (!res.data || res.data.length === 0) {
|
||||
+ // 静默:患者可能无慢病,不弹警告
|
||||
+ }
|
||||
}).catch((error) => {
|
||||
+ console.warn('获取慢病诊断失败,可能未连接医保:', error);
|
||||
speDiagnosisList.value = [];
|
||||
});
|
||||
```
|
||||
|
||||
### 四、路由决策
|
||||
|
||||
**FIXER: zhaoyun(前端开发)**
|
||||
|
||||
**REASON**: 两个问题都在 `eprescriptiondialog.vue` 前端组件中,修复仅涉及 Vue 模板宽度修改和 JS 数据加载逻辑调整,无后端变更。属于纯前端 UI 修复,适合前端开发角色处理。
|
||||
|
||||
---
|
||||
|
||||
## 路由决策
|
||||
- **修复 Agent**: zhaoyun
|
||||
- **原因**: LLM 分析决策
|
||||
@@ -1,70 +0,0 @@
|
||||
# Bug #760 诸葛亮分析报告
|
||||
|
||||
> **文档类型**: Bug分析
|
||||
> **分析时间**: 2026-06-12 14:30:20
|
||||
> **分析模型**: mimo-v2.5 (LLM深度分析)
|
||||
|
||||
---
|
||||
|
||||
## 基本信息
|
||||
- **Bug #**: 760
|
||||
- **标题**: [住院护士站-护理记录] 选中患者时系统报错
|
||||
- **模块**: 病区护士工作站
|
||||
- **提出人**: 陈显精
|
||||
|
||||
---
|
||||
|
||||
根因已定位。以下是完整分析:
|
||||
|
||||
---
|
||||
|
||||
### 一、Bug 理解
|
||||
|
||||
用户在住院护士站点击"护理记录"页签并选中患者后,页面弹出红色报错 `No static resource nursing/statistics/summary/list`,右侧护理记录列表无法加载数据。期望选中患者后能正常加载护理记录数据。
|
||||
|
||||
### 二、根因分析
|
||||
|
||||
**模块路径冲突导致 API 解析错误。**
|
||||
|
||||
目录 `nursingstatistics/` 下存在两个同名冲突的模块:
|
||||
- `nursingstatistics/api.js` — 文件,包含 5 个指向**不存在**的后端接口(如 `/nursing/statistics/summary/list`)
|
||||
- `nursingstatistics/api/index.js` — 目录,包含 `getSummaryList` 指向**正确**的后端接口 `/document/record/summary`
|
||||
|
||||
关键链路:
|
||||
|
||||
1. `inpatientNurseStation/index.vue` 第 62-65 行:**"护理记录"标签页实际渲染的是 `Criticalrecord`**(即 `nursingstatistics/criticalrecord.vue`),而非 `nursingRecord/index.vue`
|
||||
2. `criticalrecord.vue` 第 413 行:`import {getSummaryList} from './api'`
|
||||
3. **Vite 模块解析规则**:`import from './api'` 优先匹配同名文件 `api.js`,而非目录 `api/index.js`
|
||||
4. `api.js` 中 `getSummaryList` 调用 `/nursing/statistics/summary/list`,**后端无此接口** → Spring 尝试作为静态资源查找 → 返回 `No static resource` 错误
|
||||
|
||||
**后端验证**:`DocRecordController.java` 第 192 行有 `@GetMapping("/summary")`(完整路径 `/document/record/summary`),与 `api/index.js` 中的 URL 一致。
|
||||
|
||||
### 三、修复方案
|
||||
|
||||
**修改文件**:`healthlink-his-ui/src/views/inpatientNurse/nursingstatistics/criticalrecord.vue`
|
||||
|
||||
**修改内容**(第 413 行):
|
||||
|
||||
```javascript
|
||||
// 修改前(解析到 api.js → 错误的 URL)
|
||||
import {getSummaryList} from './api';
|
||||
|
||||
// 修改后(明确指向 api/index.js → 正确的 URL)
|
||||
import {getSummaryList} from './api/index';
|
||||
```
|
||||
|
||||
**补充说明**:`api.js` 文件中所有 5 个接口(`/nursing/statistics/page`、`/data`、`/summary`、`/summary/list`、`/record/delete`)后端均不存在,该文件是无用的遗留 stub。建议后续清理时将其重命名(如 `api_legacy.js`)以避免类似歧义,但**当前修复只需改 import 路径**即可。
|
||||
|
||||
### 四、路由决策
|
||||
|
||||
```
|
||||
FIXER: guanyu (后端验证) + zhaoyun (前端修复)
|
||||
```
|
||||
|
||||
**REASON**:此 Bug 是纯前端问题——模块解析歧义导致 API URL 错误,**不需要后端改动**。应交给 **zhaoyun**(前端开发),修改 `criticalrecord.vue` 的 import 路径。修改后需编译验证 `npm run build:dev` 通过。
|
||||
|
||||
---
|
||||
|
||||
## 路由决策
|
||||
- **修复 Agent**: guanyu
|
||||
- **原因**: LLM 分析决策
|
||||
@@ -1,103 +0,0 @@
|
||||
# Bug #761 诸葛亮分析报告
|
||||
|
||||
> **文档类型**: Bug分析
|
||||
> **分析时间**: 2026-06-12 14:24:27
|
||||
> **分析模型**: mimo-v2.5 (LLM深度分析)
|
||||
|
||||
---
|
||||
|
||||
## 基本信息
|
||||
- **Bug #**: 761
|
||||
- **标题**: [住院护士站-汇总领药]领药明细列表,“领药时间”显示逻辑异常且早于医嘱开立时间
|
||||
- **模块**: 病区护士工作站
|
||||
- **提出人**: 陈显精
|
||||
|
||||
---
|
||||
|
||||
Now I have a complete picture. Let me finalize my analysis.
|
||||
|
||||
---
|
||||
|
||||
### 一、Bug 理解
|
||||
|
||||
在"住院护士站 → 汇总领药"功能中,存在两个问题:
|
||||
1. **"领药明细列表"中的"领药时间"列**(`prescriptionList.vue`)显示的时间(如"06-09")早于医嘱开立时间和实际执行时间,数据来源错误。
|
||||
2. **"汇总单列表"中的"发药时间"列**(`summaryMedicineList.vue`)同样数据来源不正确,且列名不符合业务语义。
|
||||
|
||||
用户期望:列名改为"执行时间",显示的值应严格等于医嘱执行时记录的 `cli_procedure.occurrence_time`(执行时间),未发药的不展示。
|
||||
|
||||
### 二、根因分析
|
||||
|
||||
**根因 1:领药明细列表时间数据来源错误(核心问题)**
|
||||
|
||||
SQL `selectMedicineDispenseFormPage` 中,领药时间取的是 `mmd.planned_dispense_time`(预定发药时间),而非实际执行时间。
|
||||
|
||||
`MedicineSummaryAppMapper.xml` 第 53 行 collection 映射:
|
||||
```xml
|
||||
<result property="dispenseTime" column="planned_dispense_time"/>
|
||||
```
|
||||
|
||||
`planned_dispense_time` 是药品发放记录中预设的发药时间,不是护士实际执行医嘱的时间。这个值在发放记录创建时就确定了,可能早于医嘱开立时间。
|
||||
|
||||
**根因 2:汇总单列表时间数据来源错误 + JOIN Bug**
|
||||
|
||||
SQL `selectMedicineSummaryFormPage` 中,"发药时间"取的是 `wsd.receive_time`(供应接收时间),而非执行时间。同时 SQL 有一个 JOIN Bug:
|
||||
|
||||
```sql
|
||||
LEFT JOIN adm_practitioner ap2
|
||||
ON wsd.receiver_id = ap.id -- ← 应为 ap2.id
|
||||
```
|
||||
|
||||
`ap2` 和 `ap` 都 JOIN 到了 `adm_practitioner` 表的同一行(`wsr.applicant_id`),导致"领药人"显示的是"申请人"的名字。
|
||||
|
||||
**根因 3:前端列名不符合业务语义**
|
||||
|
||||
- `prescriptionList.vue` 第 164 行:`title="领药时间"` 应改为"执行时间"
|
||||
- `summaryMedicineList.vue` 第 46 行:`title="发药时间"` 应改为"执行时间"
|
||||
|
||||
**涉及文件**:
|
||||
|
||||
| 层级 | 文件 | 问题 |
|
||||
|------|------|------|
|
||||
| Mapper XML | `MedicineSummaryAppMapper.xml` | SQL 取 `planned_dispense_time` / `receive_time`,应取 `occurrence_time` |
|
||||
| Mapper XML | `MedicineSummaryAppMapper.xml` | `ap2` JOIN 条件错误 |
|
||||
| DTO | `MedicineDispenseFormDto.java` | collection 中 `dispenseTime` 映射到 `planned_dispense_time` |
|
||||
| DTO | `MedicineSummaryFormDto.java` | `dispenseTime` 映射到 `receive_time` |
|
||||
| 前端 | `prescriptionList.vue` | 列名"领药时间"应为"执行时间";JS 中 substring 逻辑基于 `dispenseTime` |
|
||||
| 前端 | `summaryMedicineList.vue` | 列名"发药时间"应为"执行时间" |
|
||||
|
||||
### 三、修复方案
|
||||
|
||||
**Step 1:修复 `MedicineSummaryAppMapper.xml`**
|
||||
|
||||
1a. 修改 `selectMedicineDispenseFormPage`:
|
||||
- SELECT 中增加 `cp.occurrence_time`(从 `cli_procedure` 获取执行时间)
|
||||
- JOIN 增加 `LEFT JOIN cli_procedure cp ON mmd.procedure_id = cp.id AND cp.delete_flag = '0'`
|
||||
- collection 映射改为 `<result property="dispenseTime" column="occurrence_time"/>`(不再用 `planned_dispense_time`)
|
||||
- 对于未执行的(`procedure_id IS NULL`),`occurrence_time` 自然为 NULL,前端不显示
|
||||
|
||||
1b. 修改 `selectMedicineSummaryFormPage`:
|
||||
- 将 `wsd.receive_time AS dispense_time` 改为从 `cli_procedure` 取 `cp.occurrence_time AS dispense_time`(或从 `med_medication_dispense` 取)
|
||||
- 修复 JOIN Bug:`wsd.receiver_id = ap.id` → `wsd.receiver_id = ap2.id`
|
||||
|
||||
**Step 2:修改前端列名和显示逻辑**
|
||||
|
||||
2a. `prescriptionList.vue` 第 164 行:`title="领药时间"` → `title="执行时间"`
|
||||
2b. `summaryMedicineList.vue` 第 46 行:`title="发药时间"` → `title="执行时间"`
|
||||
|
||||
**Step 3:(可选)重命名 DTO 字段**
|
||||
- `MedicineDispenseFormDto.dispenseTime` → `executeTime`(提高语义清晰度)
|
||||
- `MedicineSummaryFormDto.dispenseTime` → `executeTime`
|
||||
- 同步修改前端字段引用
|
||||
|
||||
### 四、路由决策
|
||||
|
||||
**FIXER: guanyu(后端)+ zhaoyun(前端)**
|
||||
|
||||
**REASON**: 修复涉及后端 Mapper XML SQL 重写(数据来源从 `planned_dispense_time`/`receive_time` 改为 `cli_procedure.occurrence_time`,修复 JOIN Bug)→ guanyu 负责;前端两处列名修改和可能的字段重命名 → zhaoyun 负责。两个修复范围独立,可并行。
|
||||
|
||||
---
|
||||
|
||||
## 路由决策
|
||||
- **修复 Agent**: guanyu
|
||||
- **原因**: LLM 分析决策
|
||||
@@ -1,131 +0,0 @@
|
||||
# Bug #762 诸葛亮分析报告
|
||||
|
||||
> **文档类型**: Bug分析
|
||||
> **分析时间**: 2026-06-12 14:18:44
|
||||
> **分析模型**: mimo-v2.5 (LLM深度分析)
|
||||
|
||||
---
|
||||
|
||||
## 基本信息
|
||||
- **Bug #**: 762
|
||||
- **标题**: [住院护士站-领药汇总]“汇总领药”界面的筛选标签文字丢失且功能失效
|
||||
- **模块**: 病区护士工作站
|
||||
- **提出人**: 陈显精
|
||||
|
||||
---
|
||||
|
||||
I now have a complete picture. Let me produce the analysis.
|
||||
|
||||
---
|
||||
|
||||
### 一、Bug 理解
|
||||
|
||||
住院护士站的"汇总领药"页面中,顶部筛选栏有两组 `el-radio-group`:第一组是药物类别("西药"/"中药"),第二组是展示方式("明细"/"汇总")。当前这 4 个按钮均只显示空白(无文字标签),用户无法辨识按钮功能;同时点击切换按钮不能触发数据筛选刷新,功能完全失效。
|
||||
|
||||
### 二、根因分析
|
||||
|
||||
**根因在** `drugDistribution/index.vue`,涉及两个独立缺陷:
|
||||
|
||||
**缺陷 1:`el-radio-button` 缺少 `label` 属性(UI 文字丢失)**
|
||||
|
||||
文件 `healthlink-his-ui/src/views/inpatientNurse/drugDistribution/index.vue`,第 60-76 行:
|
||||
|
||||
```html
|
||||
<el-radio-group v-model="drugType" class="ml10">
|
||||
<el-radio-button value="1" /> <!-- ❌ 无 label → 空白 -->
|
||||
<el-radio-button value="2" /> <!-- ❌ 无 label → 空白 -->
|
||||
</el-radio-group>
|
||||
<el-radio-group v-model="isDetails" class="ml20" @change="handleRadioChange">
|
||||
<el-radio-button value="1" /> <!-- ❌ 无 label → 空白 -->
|
||||
<el-radio-button value="2" /> <!-- ❌ 无 label → 空白 -->
|
||||
</el-radio-group>
|
||||
```
|
||||
|
||||
Element Plus 的 `el-radio-button` 中,`value`(或旧版 `label`)控制内部值,但**按钮显示文字来自 `label` prop 或 `<template #default>` 插槽**。这里只设了 `value` 没设 `label`,导致按钮渲染为空白。
|
||||
|
||||
**缺陷 2:`drugType` 变更未触发数据刷新 + `isDetails` 切换到汇总时也不刷新(功能失效)**
|
||||
|
||||
- `drugType` 的 `el-radio-group` 没有 `@change` 事件处理 → 切换西药/中药不触发任何数据请求。
|
||||
- `handleRadioChange` 函数(第 266 行)仅处理 `value == '1'`(明细模式),切换到汇总模式(`value == '2'`)时不调用 `handleGetPrescription()`。
|
||||
- `drugType` 未作为 prop 传给子组件 `PrescriptionList` / `SummaryMedicineList`,后端 API 无法区分药物类别。
|
||||
|
||||
### 三、修复方案
|
||||
|
||||
**仅需修改 1 个文件**:`healthlink-his-ui/src/views/inpatientNurse/drugDistribution/index.vue`
|
||||
|
||||
**修改 1 — 添加 label 属性恢复按钮文字:**
|
||||
|
||||
```html
|
||||
<!-- 药物类别组:西药 / 中药 -->
|
||||
<el-radio-group v-model="drugType" class="ml10" @change="handleDrugTypeChange">
|
||||
<el-radio-button value="1" label="西药" />
|
||||
<el-radio-button value="2" label="中药" />
|
||||
</el-radio-group>
|
||||
|
||||
<!-- 展示方式组:明细 / 汇总 -->
|
||||
<el-radio-group v-model="isDetails" class="ml20" @change="handleRadioChange">
|
||||
<el-radio-button value="1" label="明细" />
|
||||
<el-radio-button value="2" label="汇总" />
|
||||
</el-radio-group>
|
||||
```
|
||||
|
||||
**修改 2 — 新增 `handleDrugTypeChange` 方法:**
|
||||
|
||||
```javascript
|
||||
function handleDrugTypeChange() {
|
||||
chooseAll.value = false;
|
||||
handleGetPrescription();
|
||||
}
|
||||
```
|
||||
|
||||
**修改 3 — 修复 `handleRadioChange` 使其在两种模式下都触发刷新:**
|
||||
|
||||
```javascript
|
||||
// 修改前(只处理明细)
|
||||
function handleRadioChange(value) {
|
||||
chooseAll.value = false;
|
||||
if (value == '1') {
|
||||
handleGetPrescription();
|
||||
}
|
||||
}
|
||||
|
||||
// 修改后(两种模式都触发)
|
||||
function handleRadioChange() {
|
||||
chooseAll.value = false;
|
||||
handleGetPrescription();
|
||||
}
|
||||
```
|
||||
|
||||
**修改 4 — 将 `drugType` 传递给子组件:**
|
||||
|
||||
```html
|
||||
<PrescriptionList
|
||||
v-if="isDetails == 1"
|
||||
ref="prescriptionRefs"
|
||||
:exe-status="exeStatus"
|
||||
:request-status="requestStatus"
|
||||
:deadline="deadline"
|
||||
:therapy-enum="therapyEnum"
|
||||
:drug-type="drugType"
|
||||
/>
|
||||
<SummaryMedicineList
|
||||
v-else
|
||||
ref="summaryMedicineRefs"
|
||||
:therapy-enum="therapyEnum"
|
||||
:drug-type="drugType"
|
||||
/>
|
||||
```
|
||||
|
||||
**注意**:子组件 `prescriptionList.vue` 和 `summaryMedicineList.vue` 的 `defineProps` 中需同步增加 `drugType` prop,并在各自的 API 请求参数中传入 `drugType`,后端接口 `getPrescriptionList` / `getMedicineSummary` 也需要支持 `drugType` 参数进行过滤。如果后端已支持该参数(通过其他方式传入或不需要),则前端只需加 prop + 传参即可。
|
||||
|
||||
### 四、路由决策
|
||||
|
||||
**FIXER: zhaoyun(赵云 - 前端开发)**
|
||||
|
||||
**REASON**: 这是纯前端 Bug——Element Plus `el-radio-button` 缺少 `label` 属性导致文字丢失,以及前端事件处理逻辑不完整导致筛选功能失效。全部修改集中在 Vue 文件(模板 + 脚本),不涉及后端接口变更(除非后端 `drugType` 参数也缺失,需 zhaoyun 修完前端后验证 API 调用是否生效,若不生效再转 guanyu 补后端参数)。
|
||||
|
||||
---
|
||||
|
||||
## 路由决策
|
||||
- **修复 Agent**: zhaoyun
|
||||
- **原因**: LLM 分析决策
|
||||
247
MD/bugs/BUG_FIX_RECORD.md
Normal file
247
MD/bugs/BUG_FIX_RECORD.md
Normal file
@@ -0,0 +1,247 @@
|
||||
# HIS项目Bug修复记录 v1.0
|
||||
|
||||
> **文档类型**: Bug修复
|
||||
> **适用范围**: 全项目Bug记录
|
||||
> **版本**: v1.0
|
||||
|
||||
> **编制人:** 陈琳
|
||||
> **编制日期:** 2026-05-01
|
||||
> **统计范围:** 2026-04-01 至 2026-05-01
|
||||
> **项目版本:** HealthLink-HIS v2.0
|
||||
> **文档版本:** v1.0
|
||||
|
||||
---
|
||||
|
||||
## 一、修复概览
|
||||
|
||||
| 指标 | 数量 |
|
||||
|------|------|
|
||||
| Bug修复总次数 | 约 **80+** 次(含合并提交) |
|
||||
| 涉及Bug编号 | #249 ~ #472(含部分无编号修复) |
|
||||
| 参与修复人员 | 关羽、赵云、张飞、刘备、诸葛亮、华佗、陈琦等 |
|
||||
| 涉及模块 | 门诊医生站、住院医生站、检验申请、检查申请、手术计费、门诊划价、预约挂号、会诊管理、疾病报卡、用户管理等 |
|
||||
|
||||
---
|
||||
|
||||
## 二、修复记录明细
|
||||
|
||||
### 2.1 门诊医生站模块
|
||||
|
||||
| Bug # | 问题描述 | 修复人 | 修复日期 | Commit |
|
||||
|-------|---------|--------|---------|--------|
|
||||
| #449/#450 | 门诊医生站接诊/数据加载失败 — TodayOutpatientServiceImpl中receivePatient/completeVisit/cancelVisit方法为空壳 | 关羽 | 2026-04-28 | `9b86557` |
|
||||
| #451 | 门诊医生站-提交新增手术申请后列表刷新失败 | 赵云 | 2026-04-28 | `d1be841` |
|
||||
| #456 | 门诊医生站医嘱类型和状态异常 | 关羽 | 2026-04-29 | `ec89ead` |
|
||||
| #395 | 疾病报告卡添加撤销审核功能 / 前端调用与Controller重复映射 | 张飞/刘备/关羽 | 2026-04-23 | `988c17c` `2a8e662` `6962a8b` |
|
||||
| #396/#397 | 前端编译报错 - useUserStore导入方式错误 | 赵云 | 2026-04-23 | `87d4214` `17e148c` |
|
||||
| #398/#399 | 门诊预约已预约和已取号记录不应被时间过滤 | 刘备 | 2026-04-23 | `2a8e662` `6962a8b` |
|
||||
| #405/#406/#408 | 前端多处界面缺陷 | 赵云 | 2026-04-22 | `72c0cea` |
|
||||
| #412 | 门诊医生站传染病报告卡保存失败(添加临时卡号生成避免空值) | 刘备 | 2026-04-23 | `2d55387` |
|
||||
| #413 | 医生个人报卡管理界面统一(弹窗宽度1100px+标题对齐门诊医生站) | 刘备 | 2026-04-23 | `9c48744` |
|
||||
| #330 | 门诊医生站诊断保存失败 | 陈琦 | 2026-04-03 | `22de02f` |
|
||||
| #282 | 医嘱TAB页面:总量字段的单位显示数字/给药途径字段的值显示不全 | his-dev | 2026-04-15 | `6922aa1` |
|
||||
| #368 | 门诊医生站待写病历标签页功能冗余 | aprilry | 2026-04-15 | `4e2097f` |
|
||||
| #366 | 手术医嘱逻辑错误,"待签发"状态的手术医嘱提前流转至收费端 | his-dev | 2026-04-15 | `e294952` |
|
||||
| #333/#335/#336 | 医嘱保存报错 — 添加practitionerId/founderOrgId自动补全 | 关羽 | 2026-04-06 | `098aae5` |
|
||||
|
||||
### 2.2 检验申请模块
|
||||
|
||||
| Bug # | 问题描述 | 修复人 | 修复日期 | Commit |
|
||||
|-------|---------|--------|---------|--------|
|
||||
| #469 | 检验申请操作列临床业务逻辑 | 关羽 | 2026-05-01 | `97b4e39` |
|
||||
| #459 | 检验申请报错仍生成记录 | 关羽 | 2026-04-29 | `136235f` `c2cac12` |
|
||||
| #465 | 检验项目列表限制500项 | 关羽 | 2026-04-29 | `783ee48` |
|
||||
| #414 | 检验项目列表加载缓慢 — 优化分页查询性能 | 关羽 | 2026-04-24 | `d525a50` |
|
||||
| #415 | 项目单价显示负数问题 — 添加价格非负验证 | 关羽 | 2026-04-23 | `5d97975` |
|
||||
| #416/#423 | 检验/检查申请单布局调整(左右布局+宽度优化) | 刘备 | 2026-04-23 | `2475841` |
|
||||
| #420 | 检验申请单项目列表显示售价/单位 | 刘备 | 2026-04-23 | `2786769` |
|
||||
| #428 | 检查申请分类联动功能 / selectedItems.push缺少isPackage和packageId字段 | 赵云 | 2026-04-30~05-01 | `616aa46` `2174323` |
|
||||
| #326 | 检验申请单套餐项目回充数据不完整 — 后端补全套餐信息,前端树形展开 | aprilry | 2026-04-15 | `4e2097f` |
|
||||
| #328 | 检验申请单生成的医嘱签发失败 | aprilry | 2026-04-13 | `d99daa3` |
|
||||
| #329 | 检验申请执行科室默认值设置错误 | aprilry | 2026-04-15 | `4e2097f` |
|
||||
| #334 | 检验申请界面顶部操作栏占用空间过大 — 按钮移至卡片头部 | 赵云 | 2026-04-06 | `720cac8` |
|
||||
|
||||
### 2.3 检查申请模块
|
||||
|
||||
| Bug # | 问题描述 | 修复人 | 修复日期 | Commit |
|
||||
|-------|---------|--------|---------|--------|
|
||||
| #407/#385 | 检查申请医嘱分类错误致数据库报错 / 预结算账户验证修复 | 关羽/诸葛亮/aprilry | 2026-04-23 | `acc59ab` `78bcdef` `95e379e` |
|
||||
| #418/#419/#421/#424 | 检查申请发往科室未自动赋值/下拉无数据 — 修复科室数据源接口 | 关羽/诸葛亮 | 2026-04-23~24 | `03e89e0` `1242d41` |
|
||||
| #422 | 检查申请单项目列表显示单价/单位 | 刘备 | 2026-04-23 | `2786769` |
|
||||
| #425 | 检查申请申请单号显示自动生成 | 刘备 | 2026-04-23 | `2786769` |
|
||||
| #426 | 检查申请单已选择列表支持树形展开显示套餐明细 | 刘备 | 2026-04-23 | `adc89a5` |
|
||||
| #427 | 检查项目分类手风琴展开 | 赵云 | 2026-04-25 | `7bccbc7` |
|
||||
| #429 | 检查方法字段不应自动预填 | 赵云 | 2026-04-24 | `091b6e8` |
|
||||
| #430 | 检查申请套餐金额变更联动 | 赵云 | 2026-04-24 | `72e1f92` |
|
||||
| #462 | 诊疗目录标本下拉框无数据 | 关羽 | 2026-04-29 | `decac54` |
|
||||
| #376 | 检查页签申请单列表过滤异常,显示历史检查就诊记录 | 1677036288@qq.com | 2026-04-16 | `210c463` |
|
||||
| #377 | 检查申请单"执行科室"未获取配置默认值且字段交互逻辑不规范 | 1677036288@qq.com | 2026-04-16 | `210c463` |
|
||||
| #384 | 检查方法联动功能完善,增加套餐价格查询和项目卡片展开选择 | aprilry | 2026-04-21 | `994ffcb` |
|
||||
|
||||
### 2.4 手术计费/手术申请模块
|
||||
|
||||
| Bug # | 问题描述 | 修复人 | 修复日期 | Commit |
|
||||
|-------|---------|--------|---------|--------|
|
||||
| #432 | 门诊手术安排新增保存报错 — 修复登录用户null校验缺失导致NPE | 关羽 | 2026-04-24 | `dc7e3c1` |
|
||||
| #436/#438 | 手术计费显示问题 — 修复chargeItemContext条件判断尾随空格 / 门诊划价选'西药'无数据 | 关羽 | 2026-04-24~29 | `e7beb3f` `fd1880f` |
|
||||
| #437 | 手术计费重复记录修复 | 赵云 | 2026-04-25 | `7bccbc7` |
|
||||
| #442 | 手术计费删除待签发耗材报错 | 关羽 | 2026-04-25 | `d79690a` |
|
||||
| #443 | 手术计费签发耗材报错 | 关羽 | 2026-04-25 | `7d1e50d` |
|
||||
| #445 | 门诊手术待生成列表未剔除已生成医嘱 | 关羽 | 2026-04-25 | `290e8f8` |
|
||||
| #447 | 住院医生站手术申请弹窗无法加载手术类诊疗目录数据 / 申请单adviceTypes格式错误 | 关羽 | 2026-04-25~05-01 | `059ef48` `701f5fe` |
|
||||
| #453/#455 | 申请单adviceTypes格式错误 | 关羽 | 2026-05-01 | `701f5fe` |
|
||||
| #457 | 门诊收费手术医嘱不显示名称 | 关羽 | 2026-04-29 | `e1ad496` |
|
||||
| #470 | 手术/输血申请单加载项目耗时过长 | 关羽 | 2026-04-30 | `d62ac41` |
|
||||
| #471 | 手术申请查询混入脏数据 | 关羽 | 2026-04-29 | `b424d73` |
|
||||
| #472 | 住院医生站手术申请单勾选无效 | 关羽 | 2026-04-29 | `caa45c3` |
|
||||
| #249 | 门诊手术安排查询未过滤已删除手术申请单 — LEFT JOIN改INNER JOIN | 关羽 | 2026-04-28 | `405a9df` |
|
||||
| #375 | 住院医生站签发按钮提示语错误,显示"保存成功"且签发业务未实现 | 1677036288@qq.com | 2026-04-16 | `210c463` |
|
||||
| #320 | 手术管理-门诊手术安排:新增手术安排界面的就诊卡号取值错误 | his-dev | 2026-04-08 | `a894f0f` |
|
||||
|
||||
### 2.5 门诊划价模块
|
||||
|
||||
| Bug # | 问题描述 | 修复人 | 修复日期 | Commit |
|
||||
|-------|---------|--------|---------|--------|
|
||||
| #448 | 门诊划价项目分类过滤失效 — 耗材和诊疗查询缺少categoryCode过滤条件 | 关羽 | 2026-04-25 | `4beb4c4` |
|
||||
| #338 | 门诊划价新增时未校验就诊状态 — 未接诊患者也可新增划价项目 | 华佗 | 2026-04-05~09 | `8deefd2` `efc97c8` `5497c99` |
|
||||
|
||||
### 2.6 预约挂号模块
|
||||
|
||||
| Bug # | 问题描述 | 修复人 | 修复日期 | Commit |
|
||||
|-------|---------|--------|---------|--------|
|
||||
| #343 | 门诊预约挂号:系统未校验重复预约 | his-dev | 2026-04-08 | `5d28064` |
|
||||
| #344 | 取消预约后重新获取医生余号数据 / 前端状态过滤字段映射 / 时间过滤 | 赵云/关羽 | 2026-04-09 | `4d976ad` `c210d57` `82951fe` |
|
||||
| #337 | 挂号时间显示异常 — SQL别名register_time改为registerTime | 关羽 | 2026-04-06 | `054f4c3` |
|
||||
|
||||
### 2.7 住院医生站模块
|
||||
|
||||
| Bug # | 问题描述 | 修复人 | 修复日期 | Commit |
|
||||
|-------|---------|--------|---------|--------|
|
||||
| #402 | 住院医生站诊断录入:保存后列表出现重复记录且元数据缺失 | 关羽 | 2026-04-22 | `cd54a39` |
|
||||
| #403/#404 | 住院医生工作站:应用医嘱组套后药品明细字段丢失 / 医嘱组套编辑字段回显丢失 | 关羽/诸葛亮 | 2026-04-22~30 | `e2808fd` `0cfdce0` `81daacd` |
|
||||
| #363 | 入科时间编辑时同步更新就诊表start_time字段 / 入院日期选择器改为datetime类型 | 关羽/赵云 | 2026-04-08~22 | `063eb1f` `d663c46` `4142723` |
|
||||
| #362 | 添加入科时间字段并修正显示 | 赵云 | 2026-04-09 | `0cb6ebe` |
|
||||
| #364 | 修正病历号列绑定字段为patientBusNo / 添加病历号搜索支持 | 赵云 | 2026-04-09 | `583a77f` `d8511ec` |
|
||||
| #417 | 住院护士站记账页面空白 — 补充provide handleGetPrescription修复inject失败 | 刘备 | 2026-04-23 | `1fc2032` |
|
||||
| #439 | 领用出库总库存数量未显示 | 赵云 | 2026-04-24 | `b53cdfa` |
|
||||
| #440 | 用户管理修改提交报错hasOwnProperty | 赵云 | 2026-04-24 | `fe2a797` |
|
||||
| #431/#433/#434/#435 | 前端多处界面缺陷批量修复 | 赵云 | 2026-04-24 | `22b47fc` |
|
||||
|
||||
### 2.8 会诊管理模块
|
||||
|
||||
| Bug # | 问题描述 | 修复人 | 修复日期 | Commit |
|
||||
|-------|---------|--------|---------|--------|
|
||||
| #280 | 会诊申请单打印逻辑修复 — 点击具体记录打印该条,不传参数时打印全部 | 刘备 | 2026-04-24 | `6b6e56c` |
|
||||
| #388/#409/#410 | 会诊意见格式化存储,确保参加医师和意见完整回显 | aprilry | 2026-04-24 | `76094d6` |
|
||||
|
||||
### 2.9 其他模块
|
||||
|
||||
| Bug # | 问题描述 | 模块 | 修复人 | 修复日期 | Commit |
|
||||
|-------|---------|------|--------|---------|--------|
|
||||
| #355 | 预约签到性别字段回显不一致 | 预约挂号 | 关羽 | 2026-04-06 | `7827e58` |
|
||||
| #363(入院时间) | 入院时间早于申请时间校验 | 住院登记 | 关羽 | 2026-04-08 | `4142723` |
|
||||
| #444 | 计费药品列表未显示药品名称 | 住院医生站 | 赵云 | 2026-05-01 | `97d0011` |
|
||||
| #446 | 临时医嘱提交后弹窗关闭逻辑 | 住院医生站 | 赵云 | 2026-05-01 | `70726f6` |
|
||||
| #375 | 签发按钮提示语错误 | 住院医生站 | 1677036288@qq.com | 2026-04-16 | `210c463` |
|
||||
| #380/#381 | 临床诊断获取主诊断字段名修正 | 门诊医生站 | aprilry | 2026-04-21 | `994ffcb` |
|
||||
| #382 | 选择项目后保持当前页签状态 | 门诊医生站 | aprilry | 2026-04-21 | `994ffcb` |
|
||||
| #386 | 检验申请删除时同步删除关联收费项目 | 门诊医生站 | aprilry | 2026-04-21 | `994ffcb` |
|
||||
| #387 | 套餐项目回充默认展开并自动加载明细 | 门诊医生站 | aprilry | 2026-04-21 | `994ffcb` |
|
||||
| #441 | 手术室护士站相关 | — | — | — | (待修复) |
|
||||
| #454 | 删除"待签发"检验项目触发校验失败 | 检验申请 | — | — | (待修复) |
|
||||
| N/A | register.vue构建失败 — 替换不存在的login-background.jpg | 前端构建 | 张飞 | 2026-04-24 | `0d11d41` |
|
||||
| N/A | bloodTransfusion.vue构建报错 — public.js补充getDepartmentList导出 | 前端构建 | 赵云/张飞/诸葛亮 | 2026-04-24 | `8c05782` `d27b514` `4fb540c` |
|
||||
| N/A | PostgreSQL时间函数CAST语法错误修正 | 后端SQL | 关羽 | 2026-04-09 | `9238044` |
|
||||
| N/A | 前端获取版本号bug | 前端 | 1677036288@qq.com | 2026-04-29 | `b536ead` |
|
||||
|
||||
---
|
||||
|
||||
## 三、按修复人统计
|
||||
|
||||
| 修复人 | 修复Bug数量(估算) | 主要模块 |
|
||||
|--------|-------------------|---------|
|
||||
| **关羽** | ~25 | 门诊医生站、检验申请、手术计费、检查申请、预约挂号 |
|
||||
| **赵云** | ~20 | 住院医生站、前端界面、检验申请 |
|
||||
| **刘备** | ~10 | 疾病报卡、检查申请、检验申请 |
|
||||
| **诸葛亮** | ~5 | 检查申请、构建门禁文档 |
|
||||
| **张飞** | ~4 | 前端构建修复、E2E测试 |
|
||||
| **华佗** | ~2 | 门诊划价就诊状态校验 |
|
||||
| **aprilry** | ~8 | 检验申请、检查申请、会诊管理 |
|
||||
| **陈琦** | ~2 | 门诊医生站诊断保存、日期格式化 |
|
||||
| **his-dev** | ~3 | 手术安排、门诊划价、重复预约 |
|
||||
|
||||
---
|
||||
|
||||
## 四、按严重程度统计
|
||||
|
||||
| 严重级别 | 数量 | 说明 |
|
||||
|---------|------|------|
|
||||
| 🔴 阻塞性 | ~8 | 导致页面空白、系统崩溃、数据丢失 |
|
||||
| 🟠 功能性 | ~45 | 功能异常、数据不正确 |
|
||||
| 🟡 体验性 | ~20 | UI布局、显示异常 |
|
||||
| 🟢 优化类 | ~10 | 性能优化、代码规范 |
|
||||
|
||||
---
|
||||
|
||||
## 五、典型修复案例分析
|
||||
|
||||
### 案例1:Bug #407 — 检查申请医嘱分类错误
|
||||
|
||||
**问题:** 检查申请被错误归类为药品类型,导致数据库报错和预结算失败。
|
||||
|
||||
**修复方案:**
|
||||
- 后端 ExamApplyController 使用 ItemType 枚举正确分类
|
||||
- DoctorStationAdviceAppService 按枚举标准分类医嘱
|
||||
- IChargeBillService 补充 productId=0 时从 contentJson 获取项目名称
|
||||
- PaymentRecService 预结算自动修复账户不存在的历史数据
|
||||
|
||||
**影响模块:** ExamApplyController、DoctorStationAdviceAppService、IChargeBillService、PaymentRecService
|
||||
|
||||
### 案例2:Bug #449/#450 — 门诊医生站接诊数据加载失败
|
||||
|
||||
**问题:** TodayOutpatientServiceImpl 中 receivePatient/completeVisit/cancelVisit 方法为空壳实现。
|
||||
|
||||
**修复方案:** 改为调用 DoctorStationMainAppService 正确业务逻辑。
|
||||
|
||||
### 案例3:Bug #326 — 检验申请单套餐项目回充数据不完整
|
||||
|
||||
**问题:** 套餐项目回充时缺少套餐明细信息。
|
||||
|
||||
**修复方案:**
|
||||
- 后端回充时查询 LabActivityDefinition 补全套餐信息
|
||||
- DTO 新增 activityId、feePackageId、isPackage、sampleType、unit 字段
|
||||
- 前端实现套餐项目树形展开,懒加载套餐明细
|
||||
|
||||
---
|
||||
|
||||
## 六、待修复Bug清单
|
||||
|
||||
| Bug # | 问题描述 | 严重级别 | 状态 |
|
||||
|-------|---------|---------|------|
|
||||
| #454 | 删除"待签发"检验项目触发校验失败 | 🔴 阻塞性 | Active |
|
||||
| #449 | 点击接诊患者报"数据加载失败" | 🔴 阻塞性 | 部分修复 |
|
||||
| #430 | 检查申请套餐金额变更联动 | 🟠 功能性 | 进行中 |
|
||||
| #441 | 手术室护士相关问题 | 🟠 功能性 | Active |
|
||||
|
||||
---
|
||||
|
||||
## 七、基础设施改进
|
||||
|
||||
| 改进项 | 说明 | 贡献人 | 日期 |
|
||||
|--------|------|--------|------|
|
||||
| Playwright E2E测试框架 | 12个测试用例全部通过 | 张飞/刘备 | 2026-04-25 |
|
||||
| Husky pre-commit钩子 | 提交前自动执行前端构建检查 | 刘备/张飞 | 2026-04-24 |
|
||||
| ESLint import规则 | 实时检测缺失导出,防止构建失败 | 诸葛亮 | 2026-04-24 |
|
||||
| 构建门禁文档 | 三份构建门禁文档完善 | 诸葛亮 | 2026-04-24 |
|
||||
|
||||
---
|
||||
|
||||
## 八、修订记录
|
||||
|
||||
| 版本 | 日期 | 修订人 | 修订内容 |
|
||||
|------|------|--------|---------|
|
||||
| v1.0 | 2026-05-01 | 陈琳 | 初始版本,汇总2026年4月全月Bug修复记录 |
|
||||
|
||||
---
|
||||
|
||||
> **说明:** 本文档基于Git提交记录自动生成,可能存在遗漏或归类不准确之处,请各修复人核实补充。
|
||||
Reference in New Issue
Block a user