Migrate temporary ban/mute

[Zabuzard]

Overview

Dyno supports temporary bans and mutes, so should we. This adds support for such a feature. Part of #63 and #64 .

Therefore, a duration option is added to the existing ban and mute commands, which allows selection from a menu, such as:

Details

The feature is implemented by using the existing ModerationActionsStore, which already supports a field expires_at.

A new class TemporaryModerationRoutine is scheduled every 5 minutes. The routine basically selects all actions from the store where expires_at is behind now (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 RevocableModerationAction is implemented and an implementation is added to a list in TemporaryModerationRoutine, 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 logger messages. 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 /audit command (ignore the timestamps, I didnt have the bot running for some time):

Checklist

TODO

• Wait for Migrate mute, unmute commands #252
• Add support for temp mutes
• Fix remaining issues in the code
• Javadoc, Linter

Testing

Base cases:

• Perm ban
• Perm mute
• Temp ban
• Temp unmute

Bot leaves guild

• Temp ban/mute, then remove bot from guild and wait until revoke kicks in (can be mocked easily by editing the DB guildId value)

User does not exist

• Temp ban/mute, then delete user account from Discord and wait until revoke kicks in (can be mocked easily by editing the DB userId value)

User is not a member

• Temp mute user, kick user, wait until revoke kicks in

Multiple overlapping actions

• Temp ban user, then unban, then temp ban again with different time (all within less than 5 minutes (the routine schedule))

Stale event

• Temp ban user, then unban, temp unban should not be executed anymore
• Temp mute user, then unmute, temp unmute should not be executed anymore

[Zabuzard]

Blocked by #252

[RealYusufIsmail]

Would it not be better waiting for the audit command?

[Zabuzard]

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.

[Zabuzard]

Blocked by #297

done

[Zabuzard]

Yikes, got no time to resolve the conflict before holiday anymore. Will do it afterwards 🤷

[Zabuzard]

Conflict resolved (no real code change)

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
2 Code Smells

0.0% Coverage
0.0% Duplication

[Zabuzard]

Merging since 2 weeks without actual code changes and everything looks fine.