From 3506d7980ccfb9386ad88bf6c4ea6d6f1d072649 Mon Sep 17 00:00:00 2001 From: API Changelog Bot Date: Tue, 30 Jun 2026 14:18:11 +0800 Subject: [PATCH] =?UTF-8?q?docs(changelog-v2):=20=E6=96=B0=E5=A2=9E57=5F?= =?UTF-8?q?=E7=AB=99=E5=86=85=E4=BF=A1=E4=B8=89tab=E7=BB=9F=E4=B8=80?= =?UTF-8?q?=E7=94=A8list=E5=8D=95=E6=8E=A5=E5=8F=A3+messageType=E5=8F=82?= =?UTF-8?q?=E6=95=B0=E5=8C=BA=E5=88=86(=E5=85=A8=E9=83=A8/ORDER/NORMAL),?= =?UTF-8?q?=E5=89=8D=E7=AB=AF=E5=8B=BF=E7=94=A8conversations=E6=8B=BC?= =?UTF-8?q?=E8=AE=A2=E5=8D=95tab?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...用list单接口_messageType参数区分_前端处理-管理后台.md | 50 +++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 changelogs-v2/2026-06/57_站内信全部订单普通三tab统一用list单接口_messageType参数区分_前端处理-管理后台.md diff --git a/changelogs-v2/2026-06/57_站内信全部订单普通三tab统一用list单接口_messageType参数区分_前端处理-管理后台.md b/changelogs-v2/2026-06/57_站内信全部订单普通三tab统一用list单接口_messageType参数区分_前端处理-管理后台.md new file mode 100644 index 0000000..fcf6f3d --- /dev/null +++ b/changelogs-v2/2026-06/57_站内信全部订单普通三tab统一用list单接口_messageType参数区分_前端处理-管理后台.md @@ -0,0 +1,50 @@ +# 站内信「全部 / 订单消息 / 普通消息」三 tab 统一用 `/admin/message/list` 一个接口 + `messageType` 参数区分 + +> 模块：管理后台 · 站内信/我的消息（顶部三 tab） +> 类型：**前端处理**（统一接口后端早已存在，无需改后端） +> 日期：2026-06-30 +> 反馈来源：前端反馈「2 个接口、没有"全部"的接口，想融合成一个接口用参数区分订单和普通消息」 +> 关联：56_（房务抢单后订单消息在「全部」tab 看不到——同一根因：前端用错了数据源） + +## 结论（先看这条） +**前端要的「一个接口 + 参数区分订单/普通」后端早就有了**，就是 **`GET /admin/message/list`**，用 **`messageType`** 参数三态切换。**三个 tab 全部走这一个接口**，传不同 `messageType` 即可，**不需要新增/合并任何后端接口，也不要再用 `conversations`（会话列表）去拼「订单消息」tab**。 + +## 统一契约：`GET /admin/message/list` +| tab | 请求 | 返回 | +|-----|------|------| +| **全部** | `GET /admin/message/list?pageNo=1&pageSize=20`（**不传 messageType**） | 系统通知 + 聊天消息**混排**，按时间倒序 | +| **订单消息** | `GET /admin/message/list?pageNo=1&pageSize=20&messageType=ORDER` | 仅订单消息（实时聊天 kind=CHAT） | +| **普通消息** | `GET /admin/message/list?pageNo=1&pageSize=20&messageType=NORMAL` | 仅普通消息（系统通知 kind=NOTIFY） | + +- `messageType` 取值：**留空=全部 / `ORDER`=订单消息 / `NORMAL`=普通消息**（仅这两个值，大写）。 +- 三个 tab 同接口、同分页（`pageNo`/`pageSize`），`total` 都准确（后端把 `messageType` 转成等价 `kind` 等值条件下推 SQL，不是查全部再内存过滤，所以翻页和「共 N 条」都对）。 +- 返回每条 `records[]` 自带 `messageType`（ORDER/NORMAL）+ `messageTypeLabel`（订单消息/普通消息），前端可直接按它渲染「类型」列，无需自己判断。 + +### 返回字段（已有，无变化） +```json +{ + "messageId": "雪花ID(String)", + "title": "标题(订单消息=团号·联系人, 普通消息=通知标题)", + "content": "正文", + "messageType": "ORDER | NORMAL", + "messageTypeLabel": "订单消息 | 普通消息", + "kind": "CHAT | NOTIFY", + "isRead": 0, + "createTime": 1782788699000, + "bizId": "订单id(订单消息有)", + "bizType": "HOUSE...", + "senderName": "发件人(订单消息有)", + "conversationKey": "HOUSE:订单id(订单消息有, 点开聊天用)", + "categoryCode": null, + "link": "跳转链接(普通消息可能有)" +} +``` + +## 【前端处理】 +1. **三个 tab 都改用 `GET /admin/message/list`**，仅靠 `messageType` 区分（空/ORDER/NORMAL）。**「全部」tab 不要在前端把"订单消息"和"普通消息"两次结果合并**——直接调不传 `messageType` 的 `list` 即可拿到混排全量。 +2. **「订单消息」tab 不要再接 `conversations`（会话列表）接口**。`conversations` 是**聊天面板的会话列表**（一会话一行、点开进会话线程），不是收件箱「订单消息」消息流；用它当 tab 数据源会导致 56_ 那个 bug（房务抢单后新到的订单消息在「全部」里看不到）。收件箱三个 tab 统一走 `list`。 + - 若需要「点订单消息 → 打开聊天会话」，用该条的 `conversationKey` 调聊天线程接口即可，不影响收件箱列表本身的数据源。 +3. 改完自检：房务抢单后，定制师抢单前发的消息应同时出现在「全部」和「订单消息」两个 tab（后端已确认该消息在 `list` 响应中，见 56_）。 + +## 备注（无后端改动） +本说明仅澄清既有接口契约，后端无任何代码改动。`unread-count`（顶部红点合并未读）、`{id}/read`（单条已读）、`read-all`（全部已读）等接口维持不变。