Fix some bugs around blocked admin users #45

Open
opened 2024-05-14 04:55:57 +00:00 by kirsle · 0 comments

A couple of bugs were found recently surrounding when an admin user from your main website is blocking a user, or vice versa.

What normally happens when two regular users block each other is: the blocklist is synced to BareRTC and both users are completely hidden from one another - they don't see each other on the Who List and don't see each other's messages in chat, as though the other one is not even online.

Admins, however, were initially designed not to be blockable as they should be able to get better visibility into messages. However, there are a few issues found.

What happens when an admin blocks a regular user (and vice versa)

Currently, in both directions:

  • They see each other in the Who's Online list, but the DMs button is red and crossed out ("muted" color), and when clicked returns an error saying you can't unmute them because of the block from the main website.
  • Both sides auto mute each other in chat and won't see each other's messages.
  • Both sides can't see each other's webcams. Usually the cam will be greyed out and unclickable, even if broadcasting. However, in case e.g. the admin was already logged in to chat when the block is put in place, he might see a blue clickable cam button (because his page isn't muting, until he refreshes and the blocklist syncs properly). But, the chat server will enforce that cameras won't open and return an error message.

However, this is unfortunate for a couple of reasons:

  • People who the admin has blocked, can know they are blocked because of the glaring red DMs button suddenly appearing on the Who List entry. And vice versa (the admin can know who blocked them for the same reason).
  • The glaring red DMs button is too eye catching.
  • The muting: if you have an admin chatbot and it is blockable, then people can block it and the chatbot no longer sees their messages in chat and so can't moderate the public channels effectively.

Fixes needed

  • For human admins: the Who List visibility aspect is OK, but the glaring red button should be dealt with.
    • Instead: when forced muting is on, the DM button should show as greyed out (as though the other side has closed their inbound DMs)
  • For the chatbot: a method to override the muting behavior should be necessary.
    • It must remain possible for regular users to mute the chatbot for public chat channels: they might find the bot annoying and want to silence it.
    • However: the chatbot must be able to see their public channel messages the other way, so it can moderate them.
    • And: the chatbot must retain the ability to send a DM to anybody (regardless of mute), so if it is triggered by a public channel message it can DM them and yell at them still.

Ideas for the admin chatbot override ability might include: a command it can send that overrides the mute behavior for itself.

A couple of bugs were found recently surrounding when an admin user from your main website is blocking a user, or vice versa. What _normally_ happens when two regular users block each other is: the blocklist is synced to BareRTC and both users are _completely hidden_ from one another - they don't see each other on the Who List and don't see each other's messages in chat, as though the other one is not even online. Admins, however, were initially designed not to be blockable as they should be able to get better visibility into messages. However, there are a few issues found. #### What happens when an admin blocks a regular user (and vice versa) Currently, in both directions: * They see each other in the Who's Online list, but the DMs button is red and crossed out ("muted" color), and when clicked returns an error saying you can't unmute them because of the block from the main website. * Both sides auto mute each other in chat and won't see each other's messages. * Both sides can't see each other's webcams. Usually the cam will be greyed out and unclickable, even if broadcasting. However, in case e.g. the admin was already logged in to chat when the block is put in place, he might see a blue clickable cam button (because his page isn't muting, until he refreshes and the blocklist syncs properly). But, the chat server will enforce that cameras won't open and return an error message. However, this is unfortunate for a couple of reasons: * People who the admin has blocked, can know they are blocked because of the glaring red DMs button suddenly appearing on the Who List entry. And vice versa (the admin can know who blocked them for the same reason). * The glaring red DMs button is too eye catching. * The muting: if you have an admin chatbot and it is blockable, then people can block it and the chatbot no longer sees their messages in chat and so can't moderate the public channels effectively. #### Fixes needed * For human admins: the Who List visibility aspect is OK, but the glaring red button should be dealt with. * Instead: when forced muting is on, the DM button should show as greyed out (as though the other side has closed their inbound DMs) * For the chatbot: a method to override the muting behavior should be necessary. * It must remain possible for regular users to mute the chatbot for **public** chat channels: they might find the bot annoying and want to silence it. * However: the chatbot must be able to see their public channel messages the other way, so it can moderate them. * And: the chatbot must retain the ability to send a DM to anybody (regardless of mute), so if it is triggered by a public channel message it can DM them and yell at them still. Ideas for the admin chatbot override ability might include: a command it can send that overrides the mute behavior for itself.
kirsle added the
bug
label 2024-05-14 04:55:57 +00:00
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: apps/BareRTC#45
There is no content yet.