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