Migrate temporary ban/mute #267
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Zabuzard
added
the
enhance command
Zabuzard
added
the
blocked
|
Blocked by #252 |
|
Would it not be better waiting for the audit command? |
Why? I could ask you the same. I do not see any actual blocking dependency between the two. Only inconvenience and extra work introduced for both of them. |
|
Blocked by #297 |
Zabuzard
removed
the
blocked
Merged
Heatmanofurioso
previously requested changes
Dec 10, 2021
...ion/src/main/java/org/togetherjava/tjbot/commands/moderation/TemporaryModerationRoutine.java
Outdated
Show resolved
Hide resolved
Zabuzard
force-pushed
the
feature/add_temp_ban_mute
branch
2 times, most recently
from
8d2d6ee to
69ab638
Compare
Zabuzard
requested review from
RealYusufIsmail,
java-coding-prodigy,
marko-radosavljevic,
Tais993 and
Heatmanofurioso
Closed
|
Yikes, got no time to resolve the conflict before holiday anymore. Will do it afterwards 🤷 |
* It was used quite a lot in the package but also outside, it made no sense anymore to keep it locked down in the utils class.
it will get more classes soon
* temporary moderation actions can now be added easily via interface instead of being all mushed into the main logic class
* database returns multiple results, forgot limit(1) * logic mistake of using last expired action instead of last temp action (implicitly given by last action that passes the "not permanent" check) * can use `fetchOptional` with database * added note regarding startup race condition issue
* cant Instant#plus weeks and months * also some improvements to the option order (UX) * added fixme for code duplication
* moved temporary data computation into util
* also, simplification of the queries in the rejoin listener
* added /warn action that was added in the meantime
Zabuzard
force-pushed
the
feature/add_temp_ban_mute
branch
from
f333deb to
d9ac5d9
Compare
|
Conflict resolved (no real code change) |
|
Kudos, SonarCloud Quality Gate passed! |
|
Merging since 2 weeks without actual code changes and everything looks fine. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Overview
Dyno supports temporary bans and mutes, so should we. This adds support for such a feature. Part of #63 and #64 .
Therefore, a
durationoption is added to the existingbanandmutecommands, which allows selection from a menu, such as:Details
The feature is implemented by using the existing
ModerationActionsStore, which already supports a fieldexpires_at.A new class
TemporaryModerationRoutineis scheduled every 5 minutes. The routine basically selects all actions from the store whereexpires_atis behindnow(minus edge cases, like already revoked, overwriten by another action, ...) and then revokes those actions by unbanning/unmuting the user.The system is designed modular enough to easily be expanded with new temporary moderation actions (i.e. other than temp ban and temp mute). Therefore, the slim interface
RevocableModerationActionis implemented and an implementation is added to a list inTemporaryModerationRoutine, the rest is automatic.The system also gracefully supports long downtimes. Hence, it is not a problem if the actual revocation date of an action is missed, the system will revoke it on the next execution when the bot is online again. This also holds true if the bot is temporarily removed from a guild or, more importantly if an user is temporarily not a member of the guild anymore (think about a temporary mute, then user leaves and wants to rejoin after the expiration date, mute should not be applied anymore).
Notes
Error handling, such as users who got deleted in the meantime, left the guild or the even the bot leaving the guild and similar, are handled solely by
loggermessages. There is no direct feedback in any guild channel (on purpose).Revocation is picked up by the existing mod-audit-log feature:
As well as by the
/auditcommand (ignore the timestamps, I didnt have the bot running for some time):Checklist
TODO
Testing
Base cases:
Bot leaves guild
User does not exist
User is not a member
Multiple overlapping actions
Stale event