33 行
3.3 KiB
Markdown
33 行
3.3 KiB
Markdown
# 站内信：订单消息按「会话」归并成一条 + 跳转去配房详情(非 order-v2) + 详情页红点接 unreadMessageCount
|
||
|
||
> 模块：管理后台 · 站内信「订单消息」+ 房务订单详情红点
|
||
> 类型：**前端处理**（后端数据已具备，无后端改动）
|
||
> 日期：2026-06-30 · 反馈来源：wx 手动测试
|
||
> 说明：**本文 D1 部分修正 57_「订单消息 tab 用 list?messageType=ORDER」** —— 订单消息改为按会话归并（一个订单一条）。
|
||
|
||
## D1：一个订单的聊天要归并成一条（不要一条消息一行）
|
||
现象：「订单消息」tab 把同一个订单的多条聊天消息（如 4444112、77721）显示成**多行**。要求：**一个订单的会话只显示一条**（最新一条 + 未读数），像聊天 App 的会话列表。
|
||
|
||
【前端处理】**「订单消息」tab 改用会话列表接口** `GET /admin/message/chat/conversations?pageNo=1&pageSize=20`（一行=一个会话/订单，自带 `lastMessagePreview`/`lastMessageAt`/`unreadCount`/`orderNo`/`customerName`），**不要**再用 `list?messageType=ORDER`（那是一条消息一行）。
|
||
- 「普通消息」tab 仍用 `list?messageType=NORMAL`（系统通知，一条一行，正确）。
|
||
- 「全部」tab：系统通知（NOTIFY）一条一行 + 订单聊天按会话归并一行（CHAT 会话），二者混排。
|
||
|
||
## D2：订单消息「跳转」目标错（房务进了 order-v2 订单详情，应进配房详情）
|
||
现象：房务（admin/房务管理员）点订单消息的「跳转」，进了 `order-v2/detail/{orderId}`（定制师侧订单详情页），**应进「配房详情」**（房务自己的工作页）。
|
||
|
||
【前端处理】订单消息（CHAT 会话）的点击/跳转**按角色去对应工作页**：
|
||
- **房务** → 打开**配房详情**弹窗（房务订单详情，接口 `GET /admin/house/orders/{orderId}`，orderId 取会话的 bizId / conversationKey `HOUSE:{orderId}` 解析），**不要**跳 `order-v2/detail`；
|
||
- 或点击订单消息直接**打开该会话的聊天面板**（changelog 59 的 `open-house`）也可，按产品取一种；总之房务侧不应落到 order-v2 定制师订单详情页。
|
||
|
||
> ⚠️ 关联后端待核（已记录）：房务能打开 `order-v2/detail` 且未报越权——order-v2（一期）订单详情接口对房务角色是否应拦，需产品确认（房务是否禁看定制师订单详情）。本条前端先把跳转目标改对，越权另行核。
|
||
|
||
## C：定制师发消息后，房务订单详情「联系定制师」没红点
|
||
现象：定制师给房务发消息，房务订单详情页「联系定制师」按钮**没红点**。后端已查实数据正确（截图当时该消息确为未读）。
|
||
|
||
后端已提供：`GET /admin/house/orders/{orderId}` → `data.tabCounts.unreadMessageCount`（该订单聊天未读数，经 Feign 取当前登录房务在该会话的未读，纯读不误清）。
|
||
|
||
【前端处理】
|
||
1. 房务订单详情渲染时，`tabCounts.unreadMessageCount > 0` 即在「联系定制师」按钮上显示红点（数字角标可选）。
|
||
2. 实时：房务停留在详情页时若定制师发来消息（CHAT SSE，conversationKey=`HOUSE:{orderId}`），前端据 SSE 点亮该红点（或重拉 unreadMessageCount），不必等重开页面。
|
||
3. 房务打开聊天会话（open-house 标记已读）后，红点随 unreadMessageCount 归 0。
|