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

详情

docs(changelog): 派单弹窗需求信息两处各缺一半——后端字段已就绪转前端（原 #5848）

2026-08-11 18:22:26 +08:00

6.1 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	派单弹窗需求信息展示补全：Step1 缺结构化车型语句、Step2 缺特殊诉求与文字备注（后端字段已全部就绪）	admin	前端缺陷	wx(GIT)	not_required	not_required	pending	mmg				原 #5848 后端工单经调研判定为纯前端渲染缺口，已关单转本条。三块信息（结构化车型语句 / 通用特殊诉求 / 文字备注）后端在 GET /admin/fleet/board/orders/{orderId} 同一份响应里全部已返回，测试服 26-3698 实测有值，无需任何后端改动。	2026-08-11	dev-v3

派单弹窗需求信息展示补全（原 #5848 → 转前端）

页面：车务管理 → 派单看板 → 订单派车弹窗后端：零改动。三块信息早已在同一份详情响应里返回，只是前端两处各渲染了一半。

一、现状：两处各缺一半

位置	现在显示	缺什么
Step1「订单详情」→ 定制师/用车备注区块	只有文字备注（例：`用车备注杨子墨6人suv*2`）	缺结构化车型语句
Step2「排车」→ 底部「当前需求」区块	只有结构化语句（例：`当前需求：SUV7座×1 + 商务车7座×1`）	缺通用特殊诉求 + 文字备注

wx 的要求：两处都要同时展示「结构化车型语句 + 通用特殊诉求 + 文字备注」三块完整信息。车管在 Step2 排车时最需要看到「要儿童座椅」「要中文司机」这类诉求，现在只能看到车型数量。

二、数据来源：一个接口、一份响应、三个字段

两处同源——Step1 和 Step2 用的是同一个 order 对象，来自同一次请求：

GET /admin/fleet/board/orders/{orderId}
Authorization: Bearer <admin token>
（无请求体）

响应 data 里三个字段：

字段	类型	是否可空	说明
`requirementFleetText`	`String`	可为 null	后端拼好的结构化车型整句，如 `SUV7座×1 + 商务车7座×1`
`specialTags`	`List<String>`	恒为数组（无诉求时 `[]`）	通用特殊诉求，值本身就是中文标签
`requirementRemark`	`String`	可为 null	文字备注 / 其他诉求

requirements 是 requirementRemark 的兼容别名（同值），新代码请用 requirementRemark。

测试环境实测（2026-08-11，26-3698）

{
  "code": 200,
  "message": "成功",
  "data": {
    "requirementFleetText": "SUV7座×1 + 商务车7座×1",
    "specialTags": ["含高速油费"],
    "requirementRemark": "和法国飞行速度",
    "requirements": "和法国飞行速度",
    "plannerNote": null
  }
}

三、三个字段的使用口径（重要）

1. `requirementFleetText` —— 原样渲染，禁止自行拼装

整句由后端统一拼好，格式是 #5817 定的「车队组成写法」：座位内联 + 加号连接。

SUV7座×1 + 商务车7座×1

规则（后端已实现，前端不需要复刻）：

缺座位时省略座位：SUV×2 + 商务车7座×1
车型未知时回退原始值
需求为空或 fleet 为空 → 返回 null（整块不渲染）

⚠️ 禁止用 vehicleSlots[].requiredVehicleTypeLabel 或 requiredVehicles 自己聚合拼这句话——那些是派单行的历史快照，需求换版后是陈旧值（会显示成换版前的旧车型）。只有 requirementFleetText 是当前生效需求的权威值。

2. `specialTags` —— 直接渲染，不要查字典翻译

数组里的值本身就是中文标签（后端字典 vehicle_special_demand 的 dict_value 与 dict_label 有意保持一致），直接当 tag 渲染即可：

["儿童安全座椅", "大行李空间", "中文司机", "老司机(5年以上)", "含高速油费", "静音车型", "有WiFi"]

恒为数组，length === 0 时不渲染该块。

3. `requirementRemark` —— 自由文本

可能为 null，判 falsy 时不渲染。

四、前端要做的两件事

1. Step1「定制师/用车备注」区块 —— 补车型语句

在现有的 plannerNote / requirementRemark / specialTags 之外，增渲染 order.requirementFleetText（原样输出）。null 时不显示该行。

2. Step2 底部「当前需求」区块 —— 补诉求与备注

在现有的 requirementFleetText 之后，补上：

order.specialTags → tag 列表（空数组不渲染）
order.requirementRemark → 文本（null 不渲染）

五、版本一致性（验收项，后端已保证）

「两处展示的三块信息来自同一版当前生效需求，不串版本」这一条后端天然满足：

三个字段全部出自同一个当前生效需求对象（is_active=1 且 version 最大的那一版），一次取数、一起下发。前端只要都从这份响应取值，就不可能串版本。

反之，如果前端从 vehicleSlots 或 requiredVehicles 自己聚合，就会踩到派单行的陈旧快照——见上文第三节的警告。

六、空态汇总

场景	后端返回
无生效需求 / 需求不可达	`requirementFleetText: null`、`specialTags: []`、`requirementRemark: null`
`fleet` 为空数组或解析失败	`requirementFleetText: null`
无特殊诉求	`specialTags: []`（不是 null）
无备注	`requirementRemark: null`（不转空串）

整块判空规则：整句 null → 不渲染该行；tags length === 0 → 不渲染；备注 falsy → 不渲染。不要出现空白区块或字面量 null。

七、关联

原后端工单 #5848（已关单，判定为纯前端渲染缺口）
车型语句格式定义：#5817 / 11_5810b_需求车型语句改车队组成写法-修改接口-管理后台.md
陈旧快照坑的成因：#5871（换版后派单行 required_vehicle_type 不刷新）

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