103 行
5.4 KiB
Markdown
103 行
5.4 KiB
Markdown
---
|
||
schema: "hl-changelog/v2"
|
||
ticket: "5851"
|
||
title: "换版即作废定稿：定制师改需求/人数/天数/出发日期后车务卡片一律回到待派车；行程 day 增删两个 admin 端点下线"
|
||
consumer: "admin"
|
||
change_type: "修改接口"
|
||
author: "wx(GIT)"
|
||
backend_status: "deployed"
|
||
gateway_status: "not_required"
|
||
frontend_status: "not_required"
|
||
frontend_owner: "mmg"
|
||
frontend_ref: ""
|
||
target_release: ""
|
||
verified_at: "2026-08-11"
|
||
status_note: "PR #5856 / #5857 已合并 dev-v3 并部署测试服，26-7944（等量换版）与 26-0682（当代定稿回归）双向实测通过。前端实证 not_required(2026-08-11,mmg)——checklist 1 的 staleFinalizedPlan 卡片标记已由 #5824(aa9c087b)实现(BoardSlotSummary 挂「需求已换版 · 请核对车型与数量」warning 提示),本条仅后端放宽改判口径(去掉车数缺口前置,等量换版也改判),前端消费 assignmentProgress/assignmentStatus 的既有逻辑自动受益;checklist 2 canAssign=true 前端无按钮禁用零改动;checklist 3 下线的 /v3/admin/order/{id}/itinerary/days 端点 grep 实证前端零调用(增减天走 adjustment/submit 的 updates.itinerary.days,已存在),前端命中的 add-day/day/{editId}、product/item、hotel-requirements/assignments/days 均为不同端点不受影响。"
|
||
updated_at: "2026-08-11"
|
||
base: "dev-v3"
|
||
---
|
||
|
||
# 车务：换版即作废定稿 + 行程 day 端点下线（#5851 / #5852 / #5853）
|
||
|
||
> **服务**: hl-fleet-service、hl-order-service-v3
|
||
> **日期**: 2026-08-11
|
||
> **无 Flyway** · **无新增端点** · **无需改网关路由**
|
||
|
||
---
|
||
|
||
## 背景
|
||
|
||
#5824 上线后仍有一类场景没修好：需求换版但**车辆数不变**（如 `suv×1` → `商务车×1`、或只改人数/天数/出发日期）时，车务看板仍显示「已派车」，而订单侧已是「配车·待配」。
|
||
|
||
产品口径（wx 2026-08-11）：**只要定制师改需求 / 人数 / 天数 / 出发日期，车务就要重新配车流程**（行程节点级编辑不算，只有增减天数才算）。
|
||
|
||
---
|
||
|
||
## 变更接口
|
||
|
||
### `GET /admin/fleet/board/orders` —— 卡片改判口径放宽
|
||
|
||
**任何用车需求换版**（不再要求车辆数变多）都会让该订单卡片改判：
|
||
|
||
| 字段 | 变化 |
|
||
|---|---|
|
||
| `assignmentStatus` / `assignmentStatusLabel` | 陈旧定稿卡片由 `assigned`/`已派车` 改判为 `unassigned`/`待派车`（出团在即为 `unassigned_urgent`） |
|
||
| `assignmentProgress.finalizedByFleet` | 陈旧定稿时为 `false` |
|
||
| `assignmentProgress.staleFinalizedPlan` | 存在按上一版需求定稿的在途行时为 `true`（语义不变） |
|
||
| `canAssign` | 陈旧定稿时保持 `true`，改派动作仍在——**不会出现「显示待派车却点不动」** |
|
||
|
||
与 #5824 相比的差异：**去掉了「车辆数缺口」这个前置条件**。等量换版（只改车型/人数/日期）同样改判。
|
||
|
||
终态豁免不变：`canceled` / `completed` 行携带陈旧定稿不参与判定。
|
||
|
||
`statusCounts`、排序权重、分页 total 同源变化，tab 计数与列表条数保持一致。
|
||
|
||
### `GET /admin/fleet/board/summary` —— 计数随之变化
|
||
|
||
陈旧定稿卡片计入 `pendingArrangeVehicle` / 待派车分面，不再计入已派车。
|
||
|
||
### ⚠️ 端点下线（order-v3）
|
||
|
||
| 端点 | 处置 |
|
||
|---|---|
|
||
| `POST /v3/admin/order/{orderId}/itinerary/days` | **已删除** |
|
||
| `DELETE /v3/admin/order/{orderId}/itinerary/days/{dayId}` | **已删除** |
|
||
| `PUT` editDay | 保留（只改叙事，不动 dayNumber/dayDate） |
|
||
|
||
改天数请走 `POST /v3/admin/order/{orderId}/adjustment/submit` 的 `updates.itinerary.days`（数组长度表达增减天）。
|
||
|
||
**实测前端零调用**：`itinerary/days` 在 hl-ui 四个远端分支（master/v1/v2/v2.1）grep 全部 0 命中，连 api 包装函数都没写过；UI 上也没有「新增/删除一天」按钮。理论零影响，但仍属 admin 端点移除，故通知。
|
||
|
||
### 行为变化（无接口字段变化）
|
||
|
||
需求处于 `PENDING` / `PENDING_REVIEW` 时**仅修改出行人数**，此前会被幂等判定吞掉（不产新版本、`headcount` 永久停旧值），导致车务发最终方案被 `HEADCOUNT_BASELINE_MISMATCH` 永久拦死。现已修复：会正常产生 `PENDING_EDIT` 换版（version 号不增、requirementId 换新）并通知车务。
|
||
|
||
---
|
||
|
||
## 验证证据
|
||
|
||
测试服 2026-08-11 16:33 部署（hl-fleet-service）/ 16:31（hl-order-service-v3）。
|
||
|
||
| 单 | 场景 | 卡片状态 | finalizedByFleet | staleFinalizedPlan | canAssign | tab 计数 |
|
||
|---|---|---|---|---|---|---|
|
||
| 26-7944 | 等量换版 `suv×1` → `商务车×1` | **待派车** | false | true | true | 待派车 1 条 / 已派车 0 条 |
|
||
| 26-0682 | 当代定稿（回归） | **已派车** | true | false | true | 待派车 0 条 / 已派车 1 条 |
|
||
|
||
存量单靠定稿归属证据直接自愈，无需重新换版。
|
||
|
||
后端测试：fleet 受影响 5 类 664/664、`FleetRedLineArchTest` 13/13、spotless 通过；order-v3 253/253、`*ArchTest` 44/44。
|
||
|
||
---
|
||
|
||
## 已知取舍
|
||
|
||
纯人数变更且座位仍够时，订单侧 `vehicle_control_status` 仍可能到 DONE（与改动前一致、非回归）；**车务看板侧不受影响**，照常改判待派车。
|
||
|
||
---
|
||
|
||
## 前端 checklist
|
||
|
||
- [ ] 陈旧定稿卡片会从「已派车」tab 移到「待派车」tab，`staleFinalizedPlan=true` 建议在卡片上打「需重新核对」标记
|
||
- [ ] 该类卡片 `canAssign=true`，改派入口需保持可用
|
||
- [ ] 确认未使用已下线的 `itinerary/days` 两个端点（实测为零调用）
|