Hide message text input bar if the user cannot send messages in a room

[aaravlu]

issue231

[aaravlu]

Screencast.from.2024-11-15.10-34-45.webm

I will never give up, please review:)

[alanpoon]

Untitled.video.-.Made.with.Clipchamp.mp4

Here are some issues I found:

• Currently this banner "you don't have permission" is applying to all rooms when the user is muted in a room.
• The error message not handled when the user sends out message when he is muted in a room after he joins the room

[alanpoon]

/

/
2. User Ban is timeline event: "m.room.power_levels" https://matrix-org.github.io/matrix-rust-sdk/matrix_sdk/ruma/events/enum.AnyStateEventContent.html#variant.RoomPowerLevels

My advice is to always check the behavior of the element.io for the correct api to use. Use two accounts, both in the same room. One mutes the other, you should already see the message text input bar hidden for the muted user. Hence there is no "can_user_send_message" checks in between.

[aaravlu]

My advice is to always check the behavior of the element.io for the correct api to use. Use two accounts, both in the same room. One mutes the other, you should already see the message text input bar hidden for the muted user. Hence there is no "can_user_send_message" checks in between.

Done.

[ZhangHanDong]

@CodiumAI-Agent /review

[CodiumAI-Agent]

PR Reviewer Guide 🔍

(Review updated until commit b700faa)

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis ✅ 231 - Fully compliant Fully compliant requirements: Hide the message input bar if the user does not have permission to send messages in a room. Display a notice informing the user that they cannot send messages if they lack permissions. Check permission status every time the user opens the room. Subscribe to room state changes to update permission status dynamically.

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Code Clarity The implementation of permission checks and UI updates could be refactored for better clarity and maintainability.

[alanpoon]

My advice is to always check the behavior of the element.io for the correct api to use. Use two accounts, both in the same room. One mutes the other, you should already see the message text input bar hidden for the muted user. Hence there is no "can_user_send_message" checks in between.

Done.

Nope, you need to also inspect the network using browser dev tool and understand matrix api.

1. Handle RoomPowerLevel change https://docs.rs/matrix-sdk-ui/0.7.0/matrix_sdk_ui/timeline/enum.AnyOtherFullStateEventContent.html here in sliding_sync.rs line 1632.
2. Remove the check_user_permission function from the process_timeline_updates function
3. Only call can_send_message async function when entering the room. Nothing to do with timeline.

[CodiumAI-Agent]

Persistent review updated to latest commit b700faa

[ZhangHanDong]

@Demolemon11

Core requirements:

• ✅ Correctly implemented the visibility logic for the message input control
• ✅ Implemented permission checks and controlled the UI based on the results
• ✅ Implemented clear prompts for when messages cannot be sent

Implementation details:

• ✅ Used Room:can_user_send_message() to check permissions
• ✅ Displays a prompt instead of the input box when permissions are insufficient

Suggestions for improvement:

• ❌ Lacks a subscription mechanism for permission changes
• ❌ Lacks unsubscribe logic when leaving the room
• ❌ Only checks permissions once when opening the room, without periodic checks

Code improvement suggestions:

• Using i64 type for permission values is not intuitive. Please refactor the permission status to a clearer enum type.
• Missing documentation comments for permission status, please add them.
• Permission check logic is scattered in multiple places, please centralize the management of permission-related logic.
• Lacks an event listening mechanism for permission changes.
• Please add complete error handling.
• Need to set a reasonable time interval for permission checks.
• Need to optimize the timing of state updates.

[kevinaboos]

Suggestions for improvement:

• ❌ Lacks a subscription mechanism for permission changes

this can be done in a future PR, too, if you want to keep this one simple/manageable. Multiple smaller PRs are preferred over one big PR.

• ❌ Lacks unsubscribe logic when leaving the room

Same comment as above.

• ❌ Only checks permissions once when opening the room, without periodic checks

I think this is the same thing as the first point. As I mentioned in one of my earlier comments, a subscription mechanism that asynchronously awaits updates to a user's power levels is much better than periodically checking it from the main UI thread, since updates to user power levels are very infrequent.

[alanpoon]

The Permission banner based subscription of the power level change works.

1. For the Power change message, add "from Default to Custom (-1)" Following Element.io

/

[kevinaboos]

your name choices for functions and variables are quite inconsistent. You have all of the following:

• CheckUserPostPermission
• check_user_post_permission
• CanUserPost
• can_user_post
• no_send_permission_notice
• NO_POST_PERMISSION_NOTICE
• "user send permission"

There are too many different names here for what is all the same thing. In this case, let's follow what the Matrix SDK does. Specifically, they use the phrase "can user send message", so let's use variants of that phrase everywhere else, instead of all the different names/phrases that I listed above from your current code.

[kevinaboos]

thanks for the naming fixes, things are much better now. Just a few more minor comments.