Mimingguang
87ed9d0a3f
changelog-filename-gate / validate (push) Failing after 2s
处置明细(mmg 2026-09-18): - 68 条机械核验通过批量翻 verified:frontend_ref 均可达且为 v2.1 祖先、 交付文件 HEAD 均在、关联 spec 批量 58 文件 891 例全绿。 - 11 条带演进史的例外逐条核后翻 verified:3 条交付自删文件(06_5610/ 07_5655/11_5810,删除即交付内容且终态保持);8 条被后续 changelog 预期 演进(10_5784→#5810、07_5664/08_5592→#5827、07_5665→去槽位化 U1、 01_5380/05_5356/06_5567/06_5581→settlement 族A扁平化与 mock 清理), status_note 均如实记录演进链。 - 05_5552 改判 not_required:frontend_ref 自述前端无需改动,grep 实证 vehicleFeeAmount.js 直接读后端 calendarPrice/calendarPriceMissing。 - 11_5827 frontend_ref 原空,经核交付即 753503c8(向导 4 步改 3 步提交 即派定),补登全哈希 753503c87cc635e5646b4368a8ed506746c79cf1。 另:保险域 2 条相邻条目(05_5530/06_5593)同标准复核翻 verified。 2026-07 历史月 45 条按规则不回扫,保持原状。
151 行
6.4 KiB
Markdown
151 行
6.4 KiB
Markdown
---
|
||
schema: "hl-changelog/v2"
|
||
ticket: "frontend"
|
||
title: "派单弹窗需求信息展示补全：Step1 缺结构化车型语句、Step2 缺特殊诉求与文字备注（后端字段已全部就绪）"
|
||
consumer: "admin"
|
||
change_type: "前端缺陷"
|
||
author: "wx(GIT)"
|
||
backend_status: "not_required"
|
||
gateway_status: "not_required"
|
||
frontend_status: "verified"
|
||
frontend_owner: "mmg"
|
||
frontend_ref: "a18e9db9"
|
||
target_release: ""
|
||
verified_at: "2026-09-18"
|
||
status_note: "前端已实现(2026-08-11,mmg,a18e9db9):三块同源当前生效需求原样渲染不自拼。Step1OrderDetail 用车备注块补 requirementFleetText 车型语句行(纳入 hasVehicleNotes 空态,null 不渲染该行);AssignModal Step2 底部当前需求块抽 RequirementFleetSummary.vue(车型语句+specialTags 中文标签直渲+requirementRemark 备注,空数组/falsy 各不渲染)。step1-order-detail.spec +2、新建 requirement-fleet-summary.spec 4 用例,checkpoint 精确文件集全过。[mmg 2026-09-18 批量复核翻 verified] ref a18e9db9 可达且为 v2.1 祖先;交付文件 HEAD 均在;关联 spec 批量 891 例全绿。"
|
||
updated_at: "2026-09-18"
|
||
base: "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）
|
||
|
||
```json
|
||
{
|
||
"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` 不刷新）
|