Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Unmute" behaves somewhat unexpectedly when speak permissions are non-zero #1475

Open
turt2live opened this issue Jul 17, 2017 · 2 comments
Open
Labels
O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Major Severely degrades major functionality or product features, with no satisfactory workaround Security T-Defect Z-WTF

Comments

@turt2live
Copy link
Member

Description

While setting up a new room, I set the PL required to speak to 50 (Moderator). After inviting alternate accounts and stepping through the process to promote them in the room, an Unmute option appeared. Out of interest, I clicked it and saw that the account was promoted to Moderator.

This was somewhat unexpected. The mute function should be independent of power level, in my opinion (although still affected by PL).

Steps to reproduce

  • Set room to have speak permissions at PL 50
  • Invite a user (and optionally have them join)
  • Click for member info on that user
  • Click Unmute
  • See PL 50 be granted

As stated above, this feels wrong. It'd be nice if I could unmute someone and not give them permission to the room settings (although this can be achieved by fiddling with power levels, annoyingly).

Log: not sent

Version information

  • Platform: web (in-browser)
  • Browser: Chrome 58
  • OS: Windows 10
  • URL: riot.im/develop
@lampholder
Copy link
Member

Also noticed:

  • when you've 'unmuted' the user, the button still reads 'unmute'. This fixes itself if you refresh the memberlist component
  • after refreshing the memberlist component, clicking 'mute' sets the powerlevel to custom: 49

I don't particularly like what we've done with 'mute' here. Some of that is a powerlevels issue (which I think is unweildy, but that's not a can of worms to open here).

Some of it is a conceptual issue. Muting in Twitter only stops you from seeing a user's messages; it doesn't remove that user's ability to tweet. Much like muting your television - it's only you that can't hear the broadcast.

Seeing as this will only be encountered in the course of power-user power level wrangling, this probably doesn't need to be addressed urgently (I can't immediately think of a scenario in which this could likely seriously trip somebody up, but if you can please shout up).

@lampholder lampholder added T-Defect S-Minor Impairs non-critical functionality or suitable workarounds exist P2 S-Major Severely degrades major functionality or product features, with no satisfactory workaround and removed S-Minor Impairs non-critical functionality or suitable workarounds exist S-Major Severely degrades major functionality or product features, with no satisfactory workaround labels Jul 18, 2017
@MadLittleMods MadLittleMods added O-Uncommon Most users are unlikely to come across this or unexpected workflow Z-WTF labels Mar 2, 2022
@dkasak
Copy link
Member

dkasak commented Mar 2, 2022

Ideally, granting an ability to speak would be a separate per-user permission instead of a power level. The user would then have the ability to speak in a room if either they had a sufficient power level or they were granted the discrete speaking permission. But this is complex to implement.

A more immediate solution could be to display a warning/confirmation modal when the unmute button is pressed, saying something like

Warning: Unmuting user will change their power level to 50 (Moderator). Do you still want to proceed?

@MadLittleMods MadLittleMods added Security S-Major Severely degrades major functionality or product features, with no satisfactory workaround and removed S-Minor Impairs non-critical functionality or suitable workarounds exist labels Mar 2, 2022
@SimonBrandner SimonBrandner removed the P2 label Mar 2, 2022
@t3chguy t3chguy transferred this issue from element-hq/element-web Apr 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
O-Uncommon Most users are unlikely to come across this or unexpected workflow S-Major Severely degrades major functionality or product features, with no satisfactory workaround Security T-Defect Z-WTF
Projects
None yet
Development

No branches or pull requests

5 participants