hl-api-changelog/changelogs-v2/2026-06/22_4237_房务管家订单详情抢单池_渲染缺口+抢单门控_房务前端.md
API Changelog Bot 56be7eedae docs(changelog-v2): 房务管家 #4237 补 H — 留言空态对齐定制师需求=1留言
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-22 17:05:50 +08:00

4.3 KiB

房务管家(订单详情 / 抢单池)渲染缺口 + 抢单门控(#4237,后端 PR #4239

变更类型:🐛 后端数据已齐全 → 前端渲染对齐 + 交互门控 端类型房务管家housekeeper前端订单详情弹窗 + 抢单池列表) 日期2026-06-22 工单:#4237 服务hl-order-service-v3数据已就绪


总览

wx 评审房务管家发现多处「前端渲染不全 / 交互缺门控」。后端数据基本都齐全×候选完整结构、productName、claim 信息),下列 1-3 项前端按完整结构渲染即可,可立即接。另有进度条 6 态 + 留言计数两项后端在改PR #4239,合并部署后出字段更新版

1. 抢单前隐藏「联系定制师 / 给定制师留言」(可立即接)

规则:抢单后才能和定制师聊天(聊天 = 留言)。订单还在抢单池(未被本房务抢单)时,不显示「联系定制师」「给定制师留言」入口(订单详情顶部两个按钮 + 内部留言区的「给定制师留言」)。

前端:按订单详情的 claim.isMine(未抢单为 false门控——未抢单 → 隐藏/禁用这些入口;抢单后 → 显示。

2. 抢单池列表补「产品名」(可立即接)

现状:列表只显挡位名(如"舒适·N晚"),无产品名。后端 pool VO 已含 productName(如"测试核心产品-单档-固定比例")。 前端:列表行补显 productName(产品名 + 挡位,别只显挡位名)。

3.「定制师需求」按完整段×候选结构渲染(可立即接)

现状:① 内部留言 tab 的「定制师需求」② 配房行程行 —— 都只显 第N晚 · X间 · 房型 · ¥价 · 备注 的简化视图,漏候选酒店 + 各候选备注 + 段备注DAY1 实有候选 呼伦贝尔香格里拉(备注777555) / 海拉尔嘉世豪(备注77777222),现只显一个备注、无酒店)。 后端已就绪requirement.current.days[].segments[] = {roomCategory, roomCount, budget, remark(段备注), candidates:[{hotelId, hotelName, remark(候选备注)}]}(房务侧 RequirementSnapshot,#4128 起完整;配房行程的 DayDetail 同样含 segments / hotels前端:按完整段×候选渲染——每段 房型 · X间 · ¥预算 · 候选(择一)酒店A(候选备注..) / 酒店B(候选备注..) · 段备注,对齐 admin 侧(#4220。内部留言「定制师需求」与配房行程行都补全。

4-5. 进度条 6 态 + 内部留言计数( PR #4239 已合并部署测试服 + API 实测验证,可接)

  • 进度条:原 4 步硬编码「接单/配房中/待最终确认/已最终确认」+ 待配房单误显「配房中」。后端已改由房务侧 6 态驱动,字段契约:
    • progress.steps[].label 校正为固定 4 步「待配房 / 配房中 / 待最终确认 / 已确认」,completed 按是否越过该步。
    • progress.currentStep:待配房=1 / 配房中(含询房中)=2 / 待最终确认=3 / 已确认=4。
    • 新增 progress.houseStatus6 态枚举 namePENDING_CLAIM/CLAIMING/IN_INQUIRY/PENDING_FINALIZE/CONFIRMED/EXCEPTION+ progress.houseStatusLabel(中文,含 4 步未单列的 询房中 / 异常)。前端进度条按这两个权威字段渲染,别再用旧硬标签
    • 实测(抢单池单 GET /admin/house/orders/{id}houseStatus=PENDING_CLAIM, houseStatusLabel=待配房, currentStep=1, steps[0].completed=false
  • 内部留言计数tabCounts.messageCount 由恒 0 改为计入定制师需求(=1。实测 messageCount=1
  • H 留言空态对齐(前端):既然口径是「定制师需求算 1 条留言」(messageCount=1),内部留言区别再显「该订单暂无内部留言」(与 count=1 自相矛盾,且该文案是前端写死,后端不返)。正确:把「定制师需求」当作第 1 条留言展示;真正空态只针对抢单后房务↔定制师聊天那部分——抢单前聊天关闭,可显「抢单后可与定制师沟通」之类引导而非笼统「暂无内部留言」。

说明(非 bug

  • 抢单池列表「呼伦贝尔市」= 后端按候选酒店 hotelId 解析中文城市去重回填(#3172,非已下线的手填城市字段。是否保留待产品定。