3.0 KiB
3.0 KiB
去房务抢单上限(30单) + 改期/改天数后补「需求变更重配」待办
变更类型：🔧 行为变更（房务管家·抢单/待办） 端类型：管理后台（房务管家） 日期：2026-06-27 ｜ 工单：#4489 ｜ PR：#4490 ｜ 服务：hl-order-service-v3（双实例已部署测试服，API 实测通过）
一、去除房务抢单上限（不再限单数）
房务抢单/转单不再有「同时在跟 30 单」上限。
- 抢单
POST /v3/admin/order/hotel-requirements/{requirementId}/claim：不再返808003「你已达到同时在跟订单上限（30 单）」。 - 转单接收人：不再返
808015「接收人已达上限」。 - 错误码
808003/808015已删，前端可去掉相关上限提示/拦截逻辑。 - 转单候选选人页：所有房务恒可选（不再因「在跟 ≥30 单」灰掉）；卡片仍展示「在跟订单数 activeCount」供参考。
前端需：移除抢单/转单的「30 单上限」错误提示与前置拦截。
二、改期/改天数/改酒店后，待办列表新增「需求变更重配」（修复待办⑤永空）
此前定制师在调整订单改出发日期/行程天数/行程/酒店需求后，房务侧不产任何提醒（待办类型 REQUIREMENT_ADJUSTED 一直为空）。现已修复：
GET /v3/admin/order/todos 的 list[] 现会出现 todoType=REQUIREMENT_ADJUSTED「需求变更重配」 待办：
- 触发：定制师调整订单命中 出发日期 / 行程天数 / 行程 / 酒店需求 任一维度后，AFTER_COMMIT 自动产生。
- 归属：上个房务（被作废旧版的 claimer，
ownerUserId=上个房务）；解析不到时广播（任一房务可见）。 - 内容：
title「客户调整需求 · 原配房失效, 请重新配房」，urgency=DANGER，fromValue=上个房务名。 - 幂等：同一新需求版本只产 1 条（
dedupKey=REQADJ-{requirementId}）。 stats.REQUIREMENT_ADJUSTED计数同步生效。- 抢单池：该订单重版回池后标 返工单
isRework=true+ 显示「上个房务:X」（依赖此待办存在）。
前端需：待办列表渲染 REQUIREMENT_ADJUSTED（持久化、可处理类，与 REFUND 同款交互）；抢单池卡片读 isRework/上个房务名区分新单/返工单。
三、测试服实测
- 房务在跟 37 单时仍可抢单（去上限生效，原 808003 不再）。
- 改期 06-28→06-30 后：
REQUIREMENT_ADJUSTED待办正确产出，ownerUserId=上个房务、dedupKey=REQADJ-{新版需求ID}。
后端已完成并实测，前端按本单接入。
⚠️ 关联（订单侧/聊天侧另开工单交后端，前端先知会）：
- 改行程天数(减天) 目前订单侧不级联重置酒店配房 → 超范围晚库存暂未释放（#4491，订单侧修复中）。
- ④定制师未读消息 待办在「房务先抢单、定制师后联系房务」顺序下暂不触发（#4492，聊天会话子系统修复中）。