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]

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

[kevinaboos]

You missed a few things from my last review; make sure you're reading each comment in detail, and using GitHub's commit/batch suggestion feature whenever you agree with my suggested code change.

Also, can you post a video proving that your code here actually does catch a changed permission? That is, I'd like to see a screen recording in which you:

• in Robrix with user account A, open a room that is owned/admin'd by user account B.
• in a different client with user account B, change the permissions of user account A for that room to be either "can post" or "cannot post"
• show that Robrix with user A has changed the view of the input bar on the bottom
• in the different client, change user A's permissions again back to what they originally were
• show that Robrix has changed its view of that room back to the original.

[aaravlu]

result:
Screencast from 2024-12-19 10-45-35.webm

bug:
Screencast from 2024-12-19 10-52-25.webm
Thanks for review.

It seems there is a bug: input_bar reshow after resizing to mobile layout.
I guess the reason is lack of permission inspection.
Should I fix it in this pr?

[kevinaboos]

result: Screencast from 2024-12-19 10-45-35.webm

Very nice, looks great!

bug: Screencast from 2024-12-19 10-52-25.webm Thanks for review.

It seems there is a bug: input_bar reshow after resizing to mobile layout. I guess the reason is lack of permission inspection. Should I fix it in this pr?

Yeah that's the same issue as the issue you had with the verification badge not persisting across mobile <--> desktop UI changes. The state of the widget gets reset.

You can fix it in a future PR or now, your choice.

[kevinaboos]

I'll approve this now. If you want to fix the issue mentioned above in this PR, just let me know, and I'll wait to merge it. If you want to fix it in a later PR, let me know and I can merge this one now.

[aaravlu]

I haved merged it when you read this comment.

I just found another bug, the hints should be collapsed just like the message input bar:

I'll fix the two bugs I mentioned in the future pr.

Thanks very much!

[kevinaboos]

Thanks, yeah those two should be easy enough to fix. The overflow of the permission message text can be fixed by setting its width: Fill and wrap: Word.