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

Greedy can mistake part of reason as a member in unmute #6236

Open
3c3digital opened this issue Aug 14, 2023 · 5 comments
Open

Greedy can mistake part of reason as a member in unmute #6236

3c3digital opened this issue Aug 14, 2023 · 5 comments
Labels
Category: Cogs - Mutes This is related to the Mutes cog. Status: Needs Discussion Needs more discussion. Type: Bug Unexpected behavior, result, or exception. In case of PRs, it is a fix for the foregoing.
Milestone

Comments

@3c3digital
Copy link

3c3digital commented Aug 14, 2023

What Red version are you using?

3.5.4

Cog name

Mutes

Command name

mute, unmute, and other commands using a Greedy Member converter

What did you expect to happen?

Only the intended member will be unmuted

What actually happened?

The intended member and another unrelated member gets unmuted

How can we reproduce this error?

  1. Ensure the mutes cog is loaded
  2. Ensure you have the privileges to mute and unmute members
  3. Mute a member
  4. Unmute the said member with a reason that partially resembles the name of another member who isn't intentionally being unmuted

Anything else?

This problem was discovered by the discord user codzombiestm. The original discussion in #support and extra context can be found here, note that their original usage of the unmute command with slashtags is not the root cause as confirmed by later examples of the command being used normally also manifesting this bug.

discord.ext.commands documentation states that greedy can be a footgun at times. Similar problems may be present elsewhere in the Mutes cog or the Red-Discordbot codebase.

@3c3digital 3c3digital added the Type: Bug Unexpected behavior, result, or exception. In case of PRs, it is a fix for the foregoing. label Aug 14, 2023
@github-actions github-actions bot added the Status: Needs Triage This has not been labeled or discussed for handling yet. label Aug 14, 2023
@Flame442
Copy link
Member

It is impossible to both allow multiple members to be muted/unmuted and to allow a reason to be set in the same command, without either requiring explicit quotes around the reason or having the chance for username collisions. I don't believe there is a good solution to this problem, but I will leave the issue open for discussion.

@Flame442 Flame442 added Status: Needs Discussion Needs more discussion. and removed Status: Needs Triage This has not been labeled or discussed for handling yet. labels Sep 27, 2023
@EternalllZM
Copy link

A solution might be to have a setting where you can disable multiple mute/unmutes (only allowing single). Then the reason doesn't require quotes to avoid unintentional matches in large servers.

@Flame442 Flame442 added the Category: Cogs - Mutes This is related to the Mutes cog. label Dec 2, 2023
@Flame442
Copy link
Member

Flame442 commented Dec 2, 2023

I'm not sure how feasible it is to have a setting like that, it would need to use a custom converter that hotswaps between two converters based on that setting. Not impossible, but definitely strange.

@Jackenmen
Copy link
Member

We could follow the existing strategy from the Mod cog - the ban command accepts a single member (that you can pass using anything that the Member converter accepts) and the massban command accepts multiple members that you can only pass using ID or a mention. In a similar fashion, we could split the mass-muting part of mute command to massmute.

@EternalllZM
Copy link

We could follow the existing strategy from the Mod cog - the ban command accepts a single member (that you can pass using anything that the Member converter accepts) and the massban command accepts multiple members that you can only pass using ID or a mention. In a similar fashion, we could split the mass-muting part of mute command to massmute.

I agree with this. Correct me if I'm wrong, but I do not see mass unmuting being something used more commonly than a single user. Knowing this, priority should be placed on the unmuting of a single user being as accurate as possible.

@Flame442 Flame442 added this to the 3.5.9 milestone Apr 5, 2024
@Jackenmen Jackenmen modified the milestones: 3.5.9, 3.5.10 Apr 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Category: Cogs - Mutes This is related to the Mutes cog. Status: Needs Discussion Needs more discussion. Type: Bug Unexpected behavior, result, or exception. In case of PRs, it is a fix for the foregoing.
Projects
None yet
Development

No branches or pull requests

4 participants