260629-ANDROID-Fix bug short profile#287
Conversation
| val userId = event.userId | ||
| val existing = findFriendByUserId(userId) | ||
| val friendToBlock = if (existing != null) { | ||
| existing.toBuilder().setState(FRIEND_STATE_BLOCKED).setSourceId(userId).build() |
There was a problem hiding this comment.
BlockFriend sets sourceId=userId; RN uses currentUserId when you block someone — verify event direction or isUserBlockedByMe breaks.
|
|
||
| publishAllFriendRelations() | ||
| notificationCenter.postNotificationOnMainThread(NotificationCenter.blockedUsersLoaded) | ||
| persistBlockedByUserId(userId) |
There was a problem hiding this comment.
persistBlockedByUserId runs on every BlockFriend socket; if that event also fires for self-initiated blocks, DataStore will mislabel them.
| super.show() | ||
| NotificationCenter.getInstance(0).addObserver(this, NotificationCenter.friendsLoaded) | ||
| NotificationCenter.getInstance(0).addObserver(this, NotificationCenter.blockedUsersLoaded) | ||
| friendController.loadFriendRelations(noCache = true) |
There was a problem hiding this comment.
loadFriendRelations(noCache=true) on every sheet open forces a full friends API fetch — throttle or use cached relations first.
| isOwnProfile = isOwnProfile, | ||
| isDM = clanId == 0L, | ||
| isWebhook = clanId != 0L && member == null, | ||
| isWebhook = clanId != 0L && msg.senderId == 0L, |
There was a problem hiding this comment.
isWebhook now keys off senderId==0 instead of member==null; users missing from member cache get full profile actions — confirm intended.
| val loadedMessages = args[1] as? ArrayList<MessageEntity> ?: return@observe | ||
| val rawMessages = args[1] as? ArrayList<MessageEntity> ?: return@observe | ||
| val loadedMessages = if (channelType != CHANNEL_TYPE_DM) { | ||
| ArrayList(rawMessages.filter { !it.isCallLogMessage() }) |
There was a problem hiding this comment.
Call-log filter only on NC ingest; call logs already in Room/local list for this channel stay visible until a full reload.
|
Review summary (6 inline comments posted):
Verdict: Request changes — verify BlockFriend event semantics before merge. |
…fix/short-profile # Conflicts: # app/src/main/java/com/mezon/mobile/home/friends/FriendController.kt
2 participants
issue: #234
root causes:
Bug 1: Một số entry point mở sheet không override onAddFriend → fallback về Toast hoặc navigate sang màn search thay vì gọi API sendFriendRequest trực tiếp
Solution
Ensure all instances of UserProfileBottomSheet have their onAddFriend listener implemented to directly call friendController.sendFriendRequest(userId, username) rather than navigating to the search fragment.
Test Cases
Tap the Add Friend button on User B's short profile and verify that a friend request is sent directly to User B.
Verify that the Add Friend button updates its state (e.g., changes to pending/hidden) immediately after tapping.
Bug 2: startProfileVoiceCall() không truyền DM channel ID vào call session → call-end message dùng context channel hiện tại thay vì DM
Solution
In ChatFragment.kt, filter call-related logs so they are excluded from the message list unless the current chat context (channelType) is a Direct Message (DM).
Test Cases
End a call initiated from a channel or thread and verify that no call-ended message is posted in that channel or thread.
End a call and verify that the call-ended log message is displayed only within the DM chat history.
Bug 3: Hầu hết entry point không override onSendMessage → default no-op → không làm gì cả; chỉ có VoiceRoomFragment có implement đúng
Solution
Add the Message button to UserProfileBottomSheet's action row, and implement the onSendMessage callback in all parent fragments to fetch/create a DM via dialogsController.getOrCreateDm(userId) and navigate to it.
Test Cases
Tap the Message button on User B's short profile and verify that it navigates to the DM screen with User B.
Tap the Message button on a user from inside a voice channel or text channel and verify that it successfully redirects to their DM conversation.
Bug 4: Button state render đồng bộ khi _allFriendRelations còn rỗng, API load async đến sau → flicker; riêng case bị block thì API không bao giờ trả về → button không tự fix được (đã fix bằng DataStore)
Persist locally-received block events (when someone else blocks you) inside DataStore since the backend API does not return them, and check this cached list to determine if the Add Friend button should be hidden.
Test Cases
Open User B's short profile after User B blocks you and verify that the Add Friend button is not visible.
Kill and restart the app, then open User B's short profile and verify that the Add Friend button remains hidden.