-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Allow mute commands to update duration of the mute #4992
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
base: V3/develop
Are you sure you want to change the base?
Conversation
|
Is it correct to allow the mute command to shorten the duration of the mute too? |
Good point, in my opinion it should not. However, in the original issue the author said to "update" which would be both shorten and lengthen. Let me know whether to only shorten! |
|
@bobloy Yes the mute command should allow shortening the duration of a mute as well as extending it, it is the moderators perogative to choose when to mute until and maybe they want to lessen the time to unmute. Something that wasn't really discussed but should be addressed for consistency is the mute function should also check if there is an existing server unmute task when a user is server muted and cancel the task the same way you did for channel mutes. |
I believe I did that with my if condition on line 1668. Let me know if that's not the correct way to do it |
|
You handled it for channel mutes but role-based server mutes still suffer from the same issue. |
I see, please check out my last commit for the solution to that :) |
Type
Description of the changes
Previously, when the author wanted to mute an already muted user, if muted user already inside muted list (if statement on line 1666), "That user is already muted in this channel." would be sent to the text channel and the user's current mute duration would not get updated.
Currently, when author mutes an already muted user, there will be an update to the mute duration. One case we accounted for is if the author changes the mute duration and happens to hit it after the mute task has been created. In this case, there may be an extra unmute task in the self.unmute_tasks cache, which will do nothing. We accounted for this by checking if an unmute task is in the unmute_tasks cache, and cancelling it if there is.
Closes #4834