5d65d2c241
后端 PR #4707 修 bug.docx「未最终确认却显示回配」：GET /admin/house/orders/{orderId} 的 data.actions 新增 canReopen（enabled 仅当 house_status=CONFIRMED 且本人持有）， 前端「回配」按钮改读 actions.canReopen.enabled，停用基于共享 PROCESSING/CLAIMING 列的 启发式。附带告知同批红点/待办后端修复(前端无需改)。已测试服 API 实测。
3.6 KiB
3.6 KiB
房务订单详情新增显式「回配」动作标志 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（与前两者同结构）：
"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：固定「回配」。
前端改法（关键）
- 「回配」按钮的显隐 / 可点改为只读
actions.canReopen.enabled，按钮文案用actions.canReopen.label，禁用态可展示disabledReason。 - 停用原先基于
house_status==CLAIMING/status==PROCESSING/room_control_status==PROCESSING的「回配」启发式判断——这是本次误显的根因（未最终确认的配房中订单会被误判成回配）。 - 点击「回配」仍调既有接口（未变）：
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 一并修了另外两项房务缺陷，前端无需改：
- 房务主动给定制师发起会话 → 定制师端「联系房务」红点现会点亮：原房务发起时消息落留言池、从不累加定制师未读，现已修（后端
open-house以订单定制师为锚判定开会话方）。前端红点仍读原有unreadMessageCount，自动生效。 - 已完成配房（CONFIRMED）的订单不再滞留房务待办列表：finalize 兜底 RESOLVE 相关待办 + 待办「定制师消息未读」派生项跳过已确认单。待办列表接口/字段不变。