5.7 KiB
schema, ticket, title, consumer, change_type, author, backend_status, gateway_status, frontend_status, frontend_owner, frontend_ref, target_release, verified_at, status_note, updated_at, base
| schema | ticket | title | consumer | change_type | author | backend_status | gateway_status | frontend_status | frontend_owner | frontend_ref | target_release | verified_at | status_note | updated_at | base |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| hl-changelog/v2 | 5822 | 车辆槽位无条件可删除（删除即释放车/司机）+ 行程结束后端拦截 605047 + 逐日计划恒空两处修复 | admin | 修改接口 | wx(GIT) | deployed | not_required | implemented | mmg | 408ffc63 | 2026-08-11 | 前端已实现(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 文件全绿。 | 2026-08-11 | 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 核心修复均通过变异验证（退回旧逻辑后对应用例失败）。