4.2 KiB
4.2 KiB
房务待处理已完成未读订单缺少“有未读消息”标签
模块：管理后台 · 房务管家
/housekeeper/todos类型：前端待处理（后端无接口变更） 日期：2026-07-03 工单：#4739 说明：后端已返回未读数，前端需补充列表行原因标签展示。
问题现象
测试页面：
- 页面：
http://192.168.100.160:9527/housekeeper/todos - 订单：
HL20260702232101505 - 客户：赵骐
- 当前订单状态：已完成
- 当前未读数：
2
当前结果：
- 该订单已进入“我的未完成/待处理”列表。
- 列表行显示红色数字气泡
2。 - 但列表行没有明确展示“有未读消息”标签。
用户期望：
- 已完成订单因为定制师新消息回到待处理时，需要有明确原因标签“有未读消息”。
- 否则用户只能看到“已完成”状态和数字气泡，不清楚该订单为什么仍在待处理中。
后端当前口径
后端接口已返回未读数字段，不需要新增接口或字段。
GET /v3/admin/order/grab-pool/my-claims/hotel?status=todo&page=1&pageSize=20
测试服复验结果：
| 订单号 | 状态 | unreadMessageCount | 说明 |
|---|---|---|---|
HL20260702232101505 |
已完成 | 2 |
应展示“有未读消息”标签 |
HL20260702232103376 |
配房中 | 0 |
不展示“有未读消息”标签 |
【前端 · 管理后台】处理要求
1. 待处理列表行展示未读原因标签
在 /housekeeper/todos 列表中，按行判断：
const showUnreadMessageTag = Number(row.unreadMessageCount || 0) > 0
展示规则：
unreadMessageCount > 0：展示标签“有未读消息”，并保留未读数字气泡。unreadMessageCount === 0：不展示该标签。
2. 待处理原因标签是多标签并列，不是互斥状态
待处理列表行的原因标签应支持多个独立标签同时展示。
示例：
| 场景 | 期望展示 |
|---|---|
| 只有未读消息 | 有未读消息 |
| 只有改需求 | 改需求 |
| 只有酒店超时 | 酒店超时 或现有超时文案 |
| 同时有未读消息 + 改需求 + 酒店超时 | 同一行展示 3 个独立标签：有未读消息、改需求、酒店超时 |
前端不要把“有未读消息”做成覆盖其他原因的单一状态，也不要因为订单已有“已完成 / 配房中”等状态标签就隐藏原因标签。
建议实现口径：
- 订单状态标签：表达当前房务状态，例如
已完成、配房中。 - 待处理原因标签：表达为什么出现在待处理列表，例如
有未读消息、改需求、酒店超时。 - 多个待处理原因同时存在时，按独立标签数组渲染，互不覆盖。
3. 标签用于解释已完成订单仍在待处理中的原因
已完成订单进入待处理列表时，列表行必须让用户看到触发原因。
建议展示位置：
- 与订单状态标签“已完成”同一组标签区域；或
- 与未读数字气泡相邻，保证一眼能识别原因。
4. 读完消息后的刷新
用户点击处理/联系定制师并读完消息后，前端需要刷新列表数据：
- 未读数字消失。
- “有未读消息”标签消失。
- 如果该订单仍有其他待处理原因，例如改需求或酒店超时，应保留对应原因标签。
- 如果该订单没有其他待处理原因，应从待处理列表移除。
验收标准
| 场景 | 期望 |
|---|---|
HL20260702232101505 未读数为 2 |
列表行显示“有未读消息”标签，并显示未读数量 2 |
HL20260702232103376 未读数为 0 |
不显示“有未读消息”标签 |
| 同一订单同时存在未读消息、改需求、酒店超时 | 同一行展示 3 个独立原因标签，不互相覆盖 |
| 已完成订单因未读消息进入待处理 | 用户能通过标签理解进入待处理的原因 |
| 读完消息并刷新 | “有未读消息”标签和数字同步消失；其他原因标签保留；无其他待处理原因时订单退出待处理列表 |
影响范围
| 页面/能力 | 说明 |
|---|---|
/housekeeper/todos |
房务管家待处理列表 |
unreadMessageCount |
复用现有后端字段，无接口新增 |