5d65d2c241
后端 PR #4707 修 bug.docx「未最终确认却显示回配」：GET /admin/house/orders/{orderId} 的 data.actions 新增 canReopen（enabled 仅当 house_status=CONFIRMED 且本人持有）， 前端「回配」按钮改读 actions.canReopen.enabled，停用基于共享 PROCESSING/CLAIMING 列的 启发式。附带告知同批红点/待办后端修复(前端无需改)。已测试服 API 实测。
45 行
3.6 KiB
Markdown
45 行
3.6 KiB
Markdown
# 房务订单详情新增显式「回配」动作标志 `canReopen`——前端停用启发式判断
|
||
|
||
> 模块：管理后台 · 房控台 · 房务订单详情
|
||
> 类型：**后端修改(已合并 dev-v3 + 部署测试服 + API 实测)** + 前端接入
|
||
> 日期：2026-07-01 · 关联 PR #4707 / 工单 #4706
|
||
> 背景：反馈「还没最终确认的订单为什么显示回配」。根因是后端原先**不产任何『已确认可回配』信号**，前端只能靠 `house_status=CLAIMING` / `status=PROCESSING` 等**共享状态列启发式**判断「回配」——而 reopen 把已确认单退回后与「首次配房中」逐列一致，故这些共享列对**未最终确认的普通配房中订单同样命中**，必然误显回配。现后端补显式标志，前端改读它。
|
||
|
||
## 【前端 · 房控台】需改动
|
||
|
||
### 房务订单详情 `actions` 新增 `canReopen`
|
||
`GET /admin/house/orders/{orderId}` → `data.actions` 现在除 `canTransfer` / `canFinalize` 外，**新增 `canReopen`**（与前两者同结构）：
|
||
|
||
```json
|
||
"actions": {
|
||
"canTransfer": { "enabled": ..., "code": "TRANSFER", "label": "转单", ... },
|
||
"canFinalize": { "enabled": ..., "code": "FINALIZE", "label": "最终确认", ... },
|
||
"canReopen": {
|
||
"enabled": true,
|
||
"code": "REOPEN",
|
||
"label": "回配",
|
||
"disabledReason": null,
|
||
"endpoint": "POST /admin/order/hotel-requirements/{requirementId}/reopen"
|
||
}
|
||
}
|
||
```
|
||
|
||
- **`enabled`**：`true` **当且仅当** `house_status=CONFIRMED`（已最终确认）**且**当前登录人是该单房务持有人（claimer）。与 reopen 接口服务端守卫同源。
|
||
- **`disabledReason`**：`enabled=false` 时给禁用文案——非已确认→「仅已最终确认的订单可回配」；已确认但非本人持有→「仅本人持有的订单可回配」。
|
||
- **`label`**：固定「回配」。
|
||
|
||
### 前端改法（关键）
|
||
1. 「回配」按钮的**显隐 / 可点**改为**只读 `actions.canReopen.enabled`**，按钮文案用 `actions.canReopen.label`，禁用态可展示 `disabledReason`。
|
||
2. **停用**原先基于 `house_status==CLAIMING` / `status==PROCESSING` / `room_control_status==PROCESSING` 的「回配」启发式判断——这是本次误显的根因（未最终确认的配房中订单会被误判成回配）。
|
||
3. 点击「回配」仍调既有接口（**未变**）：`POST /v3/admin/order/hotel-requirements/{requirementId}/reopen`（requirementId 取详情 `current.requirementId`，或直接用 `canReopen.endpoint` 提示的路径）。
|
||
|
||
## 已验证（测试服 API 实测）
|
||
- `GET /admin/house/orders/2071784830965620737`（house_status=CONFIRMED 且本人持有）→ `actions.canReopen = {enabled:true, code:"REOPEN", label:"回配", disabledReason:null, endpoint:".../reopen"}`。
|
||
- 未确认（配房中）/ 非本人持有 → `enabled=false` + 对应 `disabledReason`（单测覆盖）。
|
||
- 操作日志 opTypeLabel：`REOPEN` 现显示中文「回配」（原显示英文 REOPEN）。
|
||
|
||
## 同批后端修复（无需前端改动，告知即可）
|
||
本批 PR #4707 一并修了另外两项房务缺陷，**前端无需改**：
|
||
1. **房务主动给定制师发起会话 → 定制师端「联系房务」红点现会点亮**：原房务发起时消息落留言池、从不累加定制师未读，现已修（后端 `open-house` 以订单定制师为锚判定开会话方）。前端红点仍读原有 `unreadMessageCount`，**自动生效**。
|
||
2. **已完成配房（CONFIRMED）的订单不再滞留房务待办列表**：finalize 兜底 RESOLVE 相关待办 + 待办「定制师消息未读」派生项跳过已确认单。待办列表接口/字段**不变**。
|