父节点
d83a8175ba
当前提交
491e24904e
@ -0,0 +1,45 @@
|
|||||||
|
# 公司管理「删除」行为修复 — 真的删除了
|
||||||
|
|
||||||
|
> **服务**: hl-order-service-v2 (8094)
|
||||||
|
> **PR**: #1927
|
||||||
|
> **Issue**: #1926
|
||||||
|
> **日期**: 2026-05-09
|
||||||
|
> **影响范围**: admin「公司管理 / 旅行社管理」点删除按钮
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 一、用户可见变化
|
||||||
|
|
||||||
|
修复前: 点删除 → 提示"删除成功" → 列表刷新公司**还在**(用户多次重试问题持续)
|
||||||
|
修复后: 点删除 → 提示"删除成功" → 列表刷新公司**真消失**
|
||||||
|
|
||||||
|
## 二、前端不用改
|
||||||
|
|
||||||
|
接口契约 / 字段 / 路径 0 变化:
|
||||||
|
- `DELETE /admin/travel-agency/{id}` 入参/出参不变
|
||||||
|
- `GET /admin/travel-agency/page` 字段不变
|
||||||
|
- `GET /admin/travel-agency/enabled-by-platform` (本日新接口) 字段不变
|
||||||
|
|
||||||
|
如果之前有"强制刷新"或"轮询确认删除生效"之类的 workaround 代码,可以去掉了。
|
||||||
|
|
||||||
|
## 三、根因(简述)
|
||||||
|
|
||||||
|
后端原本用 `update set status='DISABLED'` 当作"删除"来避免外键悬空,但列表查询的 `selectPage` 在前端不传 status 时不过滤,DISABLED 公司仍然出现。修复改为走 BaseDO 的 `@TableLogic` 软删(set deleted_at = NOW()),让所有列表查询(MyBatis-Plus 自动加 deleted_at IS NULL 条件)统一过滤。
|
||||||
|
|
||||||
|
## 四、测试服验证 (2026-05-09 21:00)
|
||||||
|
|
||||||
|
| Case | 实测 |
|
||||||
|
|---|---|
|
||||||
|
| DELETE bohua-test (旧 BUG 留下的 status=DISABLED 数据) | 200, 列表 4 条不再出现 |
|
||||||
|
| DB 验证 bohua-test 行 deleted_at | 2026-05-09 21:00:10 已设 |
|
||||||
|
| DELETE kj (主体公司) | 业务码 594005 拒绝(主体禁删校验) |
|
||||||
|
| DELETE 不存在 ID | 业务码 AGENCY_NOT_FOUND |
|
||||||
|
|
||||||
|
## 五、不在本 PR 范围
|
||||||
|
|
||||||
|
- 跨服务引用校验(product/contract/order/team_report Feign 0 引用才允许删) — 留后续工单
|
||||||
|
- 旧 status='DISABLED' 历史数据治理(是否一次性 UPDATE 设 deleted_at) — 留后续讨论
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**联系人**: wx
|
||||||
正在加载...
x
在新工单中引用
屏蔽一个用户