changelog-filename-gate / validate (push) Successful in 1s

详情

changelog(frontend): 派单 Step2 统一选车弹窗空白+建议标签催办+需求展示区

2026-08-11 09:24:57 +08:00

6.7 KiB

原始文件 Blame 文件历史

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	frontend	派单 Step2：统一选车弹窗空白（后端有数据）+ 建议标签仍未删 + 需补用车需求展示区	admin	前端缺陷	wx(GIT)	not_required	not_required	pending	mmg					2026-08-11	dev-v3

派单弹窗 Step2「排车」三项前端待办（2026-08-11 wx 实操反馈）

页面：车务管理 → 派单看板 → 订单派车弹窗 → Step2 排车 实测订单：26-9313（orderId 2086270153414103041，孙晓东，08/22→08/24，成人10）后端：本条无后端改动，三项全部是前端渲染/布局问题。相关字段在测试环境均已可实测。

1. 🔴 缺陷：「统一选择车辆/司机」弹窗一片空白（后端数据正常）

现象

槽位卡点「统一选择车辆/司机」→ 弹窗打开后，只渲染出顶部提示条「确认后统一写入该槽位全部可编辑用车日期；每天仍可单独调整」和右上「应用到槽位全部日期」按钮，下方车辆列表 / 司机列表区域整片空白。Network 面板中 candidates 请求返回 200。

后端实测（2026-08-11 网关 9443，车务管理员 token）

用该槽位的真实上下文调 POST /admin/fleet/assignments/candidates：

{
  "orderId": 2086270153414103041,
  "requirementId": 2086700635972915201,
  "fleetItemIndex": 1,
  "startDate": "2026-08-22",
  "endDate": "2026-08-22",
  "headcount": 10,
  "excludeAssignmentId": 2086700639370301441
}

返回 code=200，数据是齐的：

字段	实测值
`vehicles.total` / 本页	21 / 20 条（蒙A-E2E01 丰田普拉多、蒙A-E2E99、蒙A-E5555 丰田埃尔法 …）
`drivers.total` / 本页	25 / 20 条（宝音德力格尔 15年、道尔吉 11年、巴雅尔 8年 …）
`vehicleTypeFacets`	4 类（SUV系列 9 / 商务车 9 / 大巴系列 2 / …）
`fleetTeamFacets`	4 组（北疆协作车队、合作车队A 4辆、合作车队B 2辆 …）
`canonicalSnapshot`	`planGeneration` / `snapshotVersion=6` / `retainedSlotIds` 均非空

结论与排查方向

接口有数据，是前端拿到响应后没有把列表渲染出来。 请重点看：

响应取数路径：车辆/司机是 data.vehicles.records / data.drivers.records（分页对象，不是裸数组），total 在 data.vehicles.total。是否误按裸数组解构导致渲染空列表？
该弹窗（「统一选择」入口）与单日「选择车辆/司机」入口是否复用同一个列表组件——单日入口此前是能出数据的，对比两条入口的 props/数据源差异。
弹窗内是否有基于槽位状态/日期区间的前置过滤（例如按 startDate===endDate 或「可编辑用车日期」集合过滤），把 20 条全过滤掉了。
Network 里 candidates 调了两次（截图可见），确认是否第二次请求的响应覆盖了第一次、而第二次带了更严格的筛选参数。

2. ⚠️ 催办：槽位头「建议 SUV」「建议车型未标注」标签仍未删除

changelogs-v2/2026-08/11_5810_换版槽位人工制-需求语句与派车日期门禁-修改接口-管理后台.md §3 已明确要求删除，当前线上（测试环境）仍在渲染，wx 2026-08-11 再次点名。

槽位头的「建议 {车型}」标签 → 全部去掉（含车型缺失时的「建议车型未标注」兜底文案）
字段层面 vehicleSlots[].requiredVehicleType / requiredVehicleTypeLabel / requiredSeats 后端仍返回真实值、契约保留（其它场景可能用），只是不要再渲染成槽位头的"建议 xx"标签
原因重申：槽位人工制下车务爱派什么车派什么车，后端不按车型校验（车型/数量/人数不符不拦截），"建议"标签会让车务误以为必须匹配。车型诉求统一由下面第 3 条的需求语句表达一次

3. 📐 新增布局：Step2 排车页需要一块「用车需求」展示区

位置（wx 截图指定）

派单弹窗 Step2「排车」页，槽位表格下方的空白区域（截图中红框位置：最后一个槽位的日期表格结束之后、弹窗底部之前）。当前这块是纯空白，浪费了整屏空间，而车务在这一步恰恰最需要对照需求。

展示内容

数据源：GET /admin/fleet/board/orders/{orderId} 根级 requirementFleetText（字段已存在，测试环境可实测）。

26-9313 实测当前值：商务车×1(7座)、SUV×1(5座)
⚠️ 后端正在把格式统一为 商务车7座×1 + SUV5座×1（座位数内联到车型后、多项用加号连接，wx 2026-08-11 定稿）。格式变更单独发 changelog，对前端接入方式无影响——
🔴 前端只管原样展示这个字符串，不要解析、不要自己按 vehicleSlots 或需求明细拼（拼法口径归后端一处收口，否则日后改口径要改两边）
null 时（需求不可达）整块不渲染，不要出现「当前需求：」空冒号或「当前需求：null」

建议形态

一行常驻文本即可，例如：

当前需求：商务车7座×1 + SUV5座×1

不做"变更态横幅"——常驻展示的好处是任何时候车务都能对照，不依赖任何"需求是否改过"的状态判断（requirementChangePendingCount 现已恒 0，不能再作为触发条件，见 #5810 §2）。

可一并放进这块区域的既有字段（同一接口根级，均已可实测，按需取用）：

字段	26-9313 实测值	说明
`requirementFleetText`	`商务车×1(7座)、SUV×1(5座)`（即将改为新格式）	必展示
`headcount`	`10`	乘车人数
`suggestedVehicleCount`	`2`	需求车辆数
`specialTags`	`["儿童安全座椅","大行李空间","中文司机","老司机(5年以上)"]`	特殊诉求，标签形态
`requirementRemark`	`孙晓东10人mpvx1 suv*1`	定制师需求备注

验证证据

第 1 条：2026-08-11 网关 https://api.test.1814.love:9443 车务管理员 token 实测 POST /admin/fleet/assignments/candidates，返回 code=200、vehicles.total=21、drivers.total=25、facets 非空（详见上表）。
第 2、3 条：同订单 GET /admin/fleet/board/orders/2086270153414103041 实测 requirementFleetText="商务车×1(7座)、SUV×1(5座)"、headcount=10、suggestedVehicleCount=2、specialTags 4 项、requirementRemark 非空；vehicleSlots 返回 3 个槽位且 superseded 全 false（#5810 后无旧数据行，符合预期）。

6.7 KiB 原始文件 Blame 文件历史 Unescape Escape