修复禅道Bug清单中的前端问题:好友申请source校验、群解散二次验证缺失、
群解散事件未处理、错误码翻译缺失、恢复登录页误导性提示 - 好友申请首次必失败30000(P0):AddFriendModal把手机号搜索单独标记为 source:"phone"上报,但后端serveIMFriendRequestCreate的source校验只认 search/qr/group,命中default分支返回"invalid friend request source"。 改为手机号搜索也统一上报source:"search"(后端本就不区分具体搜索渠道), 用两个全新、此前无任何关系的测试账号验证首次申请200成功 - 解散群聊需要短信二次验证但完整流程从未实现(P0):新增 SecurityChallengeModal通用二次验证弹层(POST /security/challenges→ 验证码→verify→action_token)+ requestActionToken()(stores/ securityChallenge.ts,与requestConfirm同一模式),接入解散群聊和转让 群主(后者此前也因缺X-Action-Token必然404/400)。同时发现并修复 imDelete对无body请求不显式传空对象体,导致携带Content-Type: application/json但请求体真正为空时后端JSON解码失败返回400——实测确认 两个问题都解决后DELETE返回200 - 群聊被解散但当前正查看该群的用户界面不会跳转(P1):新增 topics.ts的subscribeTopicGone()监听SDK自身的onDeleteTopic回调, ConversationView据此在当前会话被解散时弹出提示并跳转回消息列表 - P2P会话发起方标题栏显示原始topic id、对方明明在线却显示离线:确认 为上一轮已修复的isCommType()根因问题的同一症状,本轮实测(新建从未 聊过天的账号对)已不再复现;群内消息发送者显示原始uid的关联描述同样 实测未复现 - 好友关系冲突(已是好友/申请正在处理中)报错英文原文透出:翻译表补充 FRIEND_REQUEST_CONFLICT - 深链/刷新页面时的"改为重新登录"链接此前在任何恢复登录过程中都会 立即显示(不管是否超时),造成短暂白屏时的误导性提示:改为仅在真正 超时后才显示该链接,与其上方的提示文案保持一致的显示条件
This commit is contained in:
+19
-11
@@ -130,9 +130,17 @@ export function leaveGroup(topic: string) {
|
||||
return imPost<{ topic: string; status: string }>(`/groups/${encodeURIComponent(topic)}/leave`, {});
|
||||
}
|
||||
|
||||
/** doc-flagged 待实现 (not yet implemented server-side) -- kept typed and ready for when it lands. */
|
||||
export function disbandGroup(topic: string) {
|
||||
return imDelete<{ topic: string; deleted: boolean }>(`/groups/${encodeURIComponent(topic)}`);
|
||||
/** Needs `X-Action-Token` (two-factor-guarded write, docs/IM-前后端对接文档.md §6.17) -- get one via
|
||||
* `requestActionToken({scene:'group_dissolve', ...})` (stores/securityChallenge.ts) first. Live,
|
||||
* fully implemented server-side (a stale comment here previously claimed otherwise) -- confirmed by
|
||||
* actually calling it. An explicit empty-object body is required: a bodiless DELETE still carries
|
||||
* this client's own `Content-Type: application/json` header, and the server's JSON decoder treats
|
||||
* a truly empty body under that header as malformed rather than "no optional fields provided". */
|
||||
export function disbandGroup(topic: string, actionToken: string) {
|
||||
return imDelete<{ topic: string; deleted: boolean }>(`/groups/${encodeURIComponent(topic)}`, {
|
||||
body: {},
|
||||
headers: { 'X-Action-Token': actionToken },
|
||||
});
|
||||
}
|
||||
|
||||
export type GroupRole = 'owner' | 'admin' | 'member';
|
||||
@@ -264,14 +272,14 @@ export function unmuteGroupMember(topic: string, userId: string) {
|
||||
return imDelete<{ user_id: string; muted: boolean }>(`/groups/${encodeURIComponent(topic)}/mutes/${encodeURIComponent(userId)}`);
|
||||
}
|
||||
|
||||
/** Needs `X-Action-Token` (two-factor-guarded write, docs/IM-前后端对接文档.md §6.26) -- not yet
|
||||
* wired since no risk-challenge flow is built anywhere in this app yet; calling this will 409 until
|
||||
* that's added. Kept typed so the group-management UI can be built ahead of that. */
|
||||
export function transferGroupOwner(topic: string, targetUserId: string, version: number) {
|
||||
return imPost<{ owner: string; previous_owner: string; version: number }>(`/groups/${encodeURIComponent(topic)}/owner-transfer`, {
|
||||
target_user_id: targetUserId,
|
||||
version,
|
||||
});
|
||||
/** Needs `X-Action-Token` (two-factor-guarded write, docs/IM-前后端对接文档.md §6.26) -- get one via
|
||||
* `requestActionToken({scene:'group_owner_transfer', ...})` (stores/securityChallenge.ts) first. */
|
||||
export function transferGroupOwner(topic: string, targetUserId: string, version: number, actionToken: string) {
|
||||
return imPost<{ owner: string; previous_owner: string; version: number }>(
|
||||
`/groups/${encodeURIComponent(topic)}/owner-transfer`,
|
||||
{ target_user_id: targetUserId, version },
|
||||
{ headers: { 'X-Action-Token': actionToken } },
|
||||
);
|
||||
}
|
||||
|
||||
export function getGroupGovernance(topic: string) {
|
||||
|
||||
Reference in New Issue
Block a user