hl-api-changelog/changelogs-v2/2026-06/24_4354_订单详情brief补manualUrgent加急状态回显_管理后台.md

32 行
2.2 KiB
Markdown

此文件含有模棱两可的 Unicode 字符

此文件含有可能会与其他字符混淆的 Unicode 字符。 如果您是想特意这样的,可以安全地忽略该警告。 使用 Escape 按钮显示他们。

# 订单详情配房需求 brief 补 manualUrgent定制师侧加急状态回显,补 #4342,已上线测试服·可对接
> 变更类型:✅ 修改接口(新增字段,已部署测试服并 API round-trip 实证,可对接)
> 端类型:管理后台(定制师侧·订单详情「加急/取消加急」按钮)
> 日期2026-06-24 工单:#4354 PR#4355 服务hl-order-service-v3
> 关联:补 #4342——#4342 只给抢单池列表项HouseGrabPageItemRespVO加了 manualUrgent,订单详情 brief 漏透传,定制师侧加急按钮在详情读不到当前加急态。
---
## ⚠️ 关键说明
- **现象**#4342 定制师侧「加急 / 取消加急」按钮要切换,需读当前加急状态,但订单详情接口的配房需求 brief 没返回 `manualUrgent`。前端只能防御性恒显「加急」,已加急单进详情的「取消加急」态失真。
- **修复**itinerary 接口的配房需求 brief 补 `manualUrgent`(Boolean),与抢单池列表项口径一致。entity 早有此字段(Integer 0/1),纯透传补齐。
## 1. 新增字段
`GET /v3/admin/order/{id}/itinerary``data.hotelGroup.requirement``HotelRequirementBriefVO`)新增:
| 字段 | 类型 | 说明 |
|---|---|---|
| `manualUrgent` | Boolean | 定制师是否手动加急。`true`=已加急(按钮显「取消加急」),`false`=未加急(显「加急」)。**不返回 null**(后端 Integer 0/1/null → Boolean。 |
## 2. 测试服 round-trip 实证order 2069593503129636865
| 步骤 | 操作 | brief.manualUrgent |
|---|---|---|
| ① 初始 | — | `false` |
| ② 加急 | `POST /v3/admin/order/hotel-requirement/{reqId}/urgent` | → `true` |
| ③ 取消 | `POST /v3/admin/order/hotel-requirement/{reqId}/urgent/cancel` | → `false` |
加急 / 取消端点见 #4342 changelog权限该订单定制师本人 或 超管)。
## 3. 前端动作
- 订单详情「加急 / 取消加急」按钮的当前态,改读 `requirement.manualUrgent`(此前该接口无此字段)。你已做的防御处理(`req.manualUrgent` 有则显「取消加急」、无则显「加急」)可保留——补字段后「取消加急」态即保真,不再依赖字段缺省。