96 行
5.0 KiB
Markdown
96 行
5.0 KiB
Markdown
---
|
||
schema: "hl-changelog/v2"
|
||
ticket: "5830"
|
||
title: "房务订单详情新增「订单详情」Tab：景点行程 tripItinerary + 出行人 travelers + 大交通 transport"
|
||
consumer: "admin"
|
||
change_type: "修改接口"
|
||
author: "wx(GIT)"
|
||
backend_status: "deployed"
|
||
gateway_status: "not_required"
|
||
frontend_status: "implemented"
|
||
frontend_owner: "mmg"
|
||
frontend_ref: "dbec5600"
|
||
target_release: ""
|
||
verified_at: "2026-08-11"
|
||
status_note: "前端已实现(dbec5600):OrderDetailModal 新增第 4 个「订单详情」Tab(徽标 tabCounts.tripItineraryCount 回退 tripItinerary.length),新建 OrderDetailPanel 渲染出行人表(脱敏 nameMasked 优先)/大交通表/每日安排(tripItinerary NSteps 节点),复用车务 fleet transport/display 纯函数同口径对齐 Step1;orderDetailReady=false 整块提示「订单信息加载失败,请稍后刷新」不误显「没有出行人」,ready=true 空数据显示「暂无」;orderDetailAdapter 透传 tripItinerary/travelers/transport/orderDetailReady + tripItineraryCount,既有 itinerary(配房住宿视角)一字未动。测试:OrderDetailPanel.spec 4 + orderDetailAdapter.spec 4(透传/降级/count 优先/transport 数组归 null),housekeeper 组件 84 全绿,checkpoint 5 文件含生产构建全过。"
|
||
updated_at: "2026-08-11"
|
||
base: "dev-v3"
|
||
---
|
||
|
||
# 房务订单详情新增「订单详情」Tab（#5830）
|
||
|
||
> **服务**: hl-order-service-v3
|
||
> **PR**: #5832（已合并 dev-v3 并部署测试服）
|
||
> **日期**: 2026-08-11
|
||
> **背景**: 房务订单详情此前只有 3 个 Tab（配房行程 / 定制师需求 / 操作日志），房务看不到出行人与大交通，行程也只有住宿视角。wx 要求对齐车务派单弹窗 Step1「订单详情」的三块内容。
|
||
|
||
---
|
||
|
||
## 变更接口
|
||
|
||
`GET /admin/house/orders/{orderId}` —— **根级新增 4 个字段**：
|
||
|
||
| 字段 | 类型 | 可空 | 说明 |
|
||
|---|---|---|---|
|
||
| `tripItinerary` | `List<ItineraryDayForFleetDTO>` | 否（降级时空数组） | **景点/餐食每日安排**（与车务 Step1 同源） |
|
||
| `travelers` | `List<OrderTravelerForFleetDTO>` | 否（降级时空数组） | 出行人，**脱敏版**（`nameMasked` 掩码、无证件/生日明文） |
|
||
| `transport` | `OrderTransportForFleetDTO` | 是 | 大交通（往返方向 / 交通方式 / 时间 / 路线 / 班次 / 关联出行人） |
|
||
| `orderDetailReady` | `Boolean` | 否 | 三块是否取数成功，见下方说明 |
|
||
|
||
### 🔴 不要和 `itinerary` 搞混
|
||
|
||
`itinerary` 字段**依旧是「配房行程」Tab 的住宿视角数据**（`ItineraryDay`：`stayDate` / `cityCode` / `arrange` 配房状态…），本次**一字未动**。新的景点行程叫 **`tripItinerary`**，两者结构完全不同，不要互换或复用。
|
||
|
||
### `tabCounts` 新增 key
|
||
|
||
```json
|
||
{
|
||
"itineraryCount": 2, // 配房行程 Tab（不变）
|
||
"messageCount": 1, // 留言（不变）
|
||
"unreadMessageCount": 0, // 留言未读红点（不变）
|
||
"operationLogCount": 4, // 操作日志（不变）
|
||
"tripItineraryCount": 3 // 【新增】订单详情 Tab 徽标 = 景点行程天数
|
||
}
|
||
```
|
||
|
||
### `orderDetailReady` 怎么用
|
||
|
||
三块数据是**软依赖**：订单核心侧取数异常时各自降级为空集合/null，房务详情接口**不会 500**（房务主职责是配房，不该被订单核心故障拖垮）。
|
||
|
||
但降级后的空数据与「客人确实没录出行人/没填大交通」**长得一模一样**。`orderDetailReady` 用来区分：
|
||
|
||
- `true` = 取数成功。此时字段为空就是**真的没有**，正常显示「暂无出行人 / 暂无大交通」
|
||
- `false` = 取数失败。前端应提示「订单信息加载失败，请稍后刷新」，**不要**显示成「该订单没有出行人」
|
||
|
||
实测印证：某订单 `transport` 各字段全 null（客人确实没录大交通），但 `orderDetailReady=true`，属于第一种情况。
|
||
|
||
---
|
||
|
||
## 前端要做
|
||
|
||
新增第 4 个 Tab「订单详情」，渲染三块，样式对齐车务派单弹窗 Step1：
|
||
|
||
1. **出行人信息**表：姓名（已脱敏）/ 所属地 / 人员类型 / 性别 / 年龄 / 国籍民族 / 关联班次
|
||
2. **大交通**表：方向（抵达接团 / 返程送站）/ 交通方式 / 时间 / 路线 / 班次 / 出行人
|
||
3. **每日安排**（`tripItinerary`）：按天展示景点、餐食等行程明细
|
||
|
||
Tab 徽标用 `tabCounts.tripItineraryCount`。只读入口下同样只展示、无操作。
|
||
|
||
---
|
||
|
||
## 验证证据
|
||
|
||
2026-08-11 测试服（网关 9443）实测真实房务订单：
|
||
|
||
```
|
||
tripItinerary = 3 天
|
||
travelers = 1 人（nameMasked = "娜***"，脱敏正确）
|
||
transport = 返回对象（该单客人未录大交通，各字段 null）
|
||
orderDetailReady = true
|
||
itinerary（配房行程）= 2 天 ← 无回归
|
||
tabCounts = {"itineraryCount":2, "messageCount":1, "unreadMessageCount":0,
|
||
"operationLogCount":4, "tripItineraryCount":3}
|
||
```
|
||
|
||
单测：`hl-order-service-v3` 全量 **6374 / Failures 0**（3 个 Errors 为 surefire 单 JVM 后期 OOM 的环境性问题，单独重跑绿）；`HouseDetailAggregatorTest` 80/80；专守循环依赖的 `OrderServiceCircularDependencyContextIT` 绿；ArchTest 绿。
|