91 行
5.7 KiB
Markdown
91 行
5.7 KiB
Markdown
---
|
||
schema: "hl-changelog/v2"
|
||
ticket: "5822"
|
||
title: "车辆槽位无条件可删除（删除即释放车/司机）+ 行程结束后端拦截 605047 + 逐日计划恒空两处修复"
|
||
consumer: "admin"
|
||
change_type: "修改接口"
|
||
author: "wx(GIT)"
|
||
backend_status: "deployed"
|
||
gateway_status: "not_required"
|
||
frontend_status: "implemented"
|
||
frontend_owner: "mmg"
|
||
frontend_ref: "408ffc63"
|
||
target_release: ""
|
||
verified_at: "2026-08-11"
|
||
status_note: "前端已实现(408ffc63):AssignModal 删除失败 catch 删 605007/605027 硬编码文案分支改统一透传后端 message(605047 含引导语),一键清空 clearAllSlotsErrorMessage 同步去 605007/605027(保留 605012 引导);删除按钮门禁本就「未完结即可删」(#5572/#5788 已放开),注释口径更新为「任意状态可删,唯一门禁 605047」。逐日计划恒空(dailyVehiclePlan/actualVehicleCount/vehicleFeeSummaries)为后端纯 bug 修复无契约变化,前端零改动。测试:assign-modal-title.spec 三处用例改 605047 透传断言+新增「行程已出发仍可删」正向用例,fleet/board 35 spec 428 全过,checkpoint 2 文件全绿。"
|
||
updated_at: "2026-08-11"
|
||
base: "dev-v3"
|
||
---
|
||
|
||
# 车务派单：槽位删除放开 + 逐日计划恒空修复（#5822 / #5821 / #5829 / #5831）
|
||
|
||
> **服务**: hl-fleet-service
|
||
> **PR**: #5825（#5822+#5821）、#5834（#5829+#5831）—— 均已合并 dev-v3 并部署测试服
|
||
> **日期**: 2026-08-11
|
||
> **含 Flyway**: `20260811.001`（删除意图表唯一键改按稳定槽位 ID）
|
||
|
||
---
|
||
|
||
## 变更接口
|
||
|
||
### 1. `DELETE /admin/fleet/assignments/slots/{slotId}` —— 删除门禁全部撤销
|
||
|
||
**旧行为**：以下三种情况拒绝删除
|
||
- `605007` 槽位已完成派车或已最终确认（含 completed 行、已最终确认的取消行）
|
||
- `605027` 行程已出发
|
||
|
||
**新行为**：**任意派车状态均可删除**（已派车 / 待确认 / 已完成 / 已最终确认后取消 / 行程已出发，全部放行）。删除时：
|
||
- 仍占用车辆/司机的行（holding/assigned）联动取消 → **车辆与司机的档期占用被释放，回到空闲可再次被候选查询选中**
|
||
- `canceled` / `completed` 历史行保留不物理删（对账、保险退款关联不丢）
|
||
|
||
**唯一保留的门禁**：`605047` 行程已结束，派车信息只读，不能修改或改派。
|
||
|
||
| 错误码 | 状态 |
|
||
|---|---|
|
||
| `605007` | **已下线**，不再由本接口返回（常量已删除） |
|
||
| `605027` | 本接口不再返回（该码在「整组取消派单」路径仍在用，定义保留） |
|
||
| `605047` | **新增于本接口**：行程已结束（今天 **严格大于** 服务结束日）时拒绝；**结束日当天仍可删除** |
|
||
|
||
**前端要做**：删除按钮的禁用条件只剩「行程已结束」一种；原本针对 605007/605027 的错误提示分支可以删掉，改为透传 605047 的 message。
|
||
|
||
### 2. `GET /admin/fleet/board/orders/{orderId}` —— `vehicleSlots` 三项变化
|
||
|
||
| 字段 | 变化 |
|
||
|---|---|
|
||
| `canDelete` | 不再受派车状态影响（已派车/已确认/已完成一律 `true`）；**唯一为 `false` 的情况是行程已结束/已关账**，与接口 605047 同口径 |
|
||
| `deleteBlockReason` | `canDelete=true` 时恒 `null`；为 `false` 时是只读原因文案（如「行程已结束」） |
|
||
| 槽位列表本身 | **已被删除的槽位不再返回**。此前因看板由现存派车行聚合、而历史行永不物理删，删除后槽位仍会显示；现已按删除意图过滤 |
|
||
|
||
**前端要做**：不要再依赖「`canDelete=false` 就是因为已派车」的旧假设；直接用 `deleteBlockReason` 展示原因即可。
|
||
|
||
### 3. `dailyVehiclePlan` / `actualVehicleCount` / `vehicleFeeSummaries` 恒空修复
|
||
|
||
**这是无契约变化的纯 bug 修复，但前端表现差异很大**，两个场景此前会让整单逐日计划、实派车数、车费汇总全部为空：
|
||
|
||
- **场景 A（#5821）**：方案最终确认过后，那笔派单又被取消 —— 已取消的行仍占住「当前方案」锚点，把活跃行全挡在门外
|
||
- **场景 B（#5831）**：车务点「添加车辆槽位」后方案重新解冻 —— 此时一条已确认的行都没有，代码却仍按「历史代际」逻辑只保留已完成行程的行
|
||
|
||
场景 B 影响面尤其大：**任何点过「添加车辆槽位」的订单都会立刻中招**，车务看不到逐日计划就无法核对、更无法提交最终方案。
|
||
|
||
修复后两种场景均正常返回。实测订单 `2086637109266862081`：修复前 `dailyVehiclePlan=[]`、`actualVehicleCount=0`，修复后 **12 条（2 车 × 6 天）、实派 2、车费汇总 2 条**。
|
||
|
||
**前端要做**：无需改动，接口数据恢复后原有渲染即正常。若前端曾为规避空数据加过兜底/隐藏逻辑，可以撤掉。
|
||
|
||
---
|
||
|
||
## 验证证据
|
||
|
||
2026-08-11 测试服（网关 `https://api.test.1814.love:9443`，车务管理员 token）实测：
|
||
|
||
| 用例 | 结果 |
|
||
|---|---|
|
||
| 原报 605007 的槽位删除 | `code=200` ✅ |
|
||
| 删除后槽位从详情消失 | ✅（非仅接口成功） |
|
||
| **删除即释放占用** | 蒙A-E2E01 `available=false, 冲突1条` → `available=true, 冲突0条`，联动取消 1 行 ✅ |
|
||
| 已派车槽位 `canDelete` | 全部 `true` ✅ |
|
||
| 行程已结束（2026-07-29）订单删槽位 | `605047 行程已结束，派车信息只读，不能修改或改派` ✅ |
|
||
| 订单 2086637109266862081 逐日计划 | 12 条 / 实派 2 / 车费汇总 2 条 ✅ |
|
||
| 4 个含「已确认+已取消」行的订单 | `dailyVehiclePlan` 均非空 ✅ |
|
||
|
||
Flyway `20260811.001` 已落库（`success=1`，唯一键已改为 `(requirement_id, assignment_slot_id)`）。单测：fleet 全量 3390 / Failures 0（Errors 均为 Testcontainers 等环境依赖类）；#5831 与 #5822 核心修复均通过**变异验证**（退回旧逻辑后对应用例失败）。
|