Add moderation actions table

[Zabuzard]

Overview

Implements and closes #297. This is a crucial pre-requisite that blocks a whole list of features that are currently either being developed or in planning:

• Warn command Migrate /warn command #249 (to have a place to store the reason)
• Audit command Create an Audit Command #301 (to get a list of all actions for a user)
• Temporary bans Migrate temporary ban/mute #267 (to undo the action)
• Mute command Migrate mute, unmute commands #252 (to reapply the role after leaving)
• Actual author in log messages instead of bot Mod audit doens't log who issued moderation command #280 (to figure out the actual author behind the command)

This feature basically logs each moderation action (ban, kick, mute, ...) in a database table, with all necessary information such as target, author, timestamp, reason and more. This can then be used by other classes later to retrieve information (see list of blocked features).

Details

The implementation adds a new database table moderation_actions:

CREATE TABLE moderation_actions
(
    case_id           INTEGER   NOT NULL PRIMARY KEY AUTOINCREMENT,
    issued_at         TIMESTAMP NOT NULL,
    guild_id          BIGINT    NOT NULL,
    author_id         BIGINT    NOT NULL,
    target_id         BIGINT    NOT NULL,
    action_type       TEXT      NOT NULL,
    action_expires_at TIMESTAMP,
    reason            TEXT      NOT NULL
)

which is hidden behind a helper class ModerationActionsStore with retrieval methods such as:

• getActionsByTypeAscending
• getActionsByTargetAscending
• getActionsByAuthorAscending
• findActionByCaseId

(while those methods are not used right now, they will be used very soon by the mentioned features)

to add a new entry, one calls

• addAction

Additionally, the store has been integrated into all currently existing commands:

• BanCommand
• UnbanCommand
• KickCommand

so those commands will now also correctly add the entry to the database, when executed.

Notes

The point in time commands call the addAction method as of now is slightly off the actual point in time the action is executed.

Simplified speaking, we have

addAction(...);
guild.ban(...);

while the ban command is obviously a rest action that might be executed slightly deferred. That said, we could potentially use

guild.ban(...)
  .map(result -> {
    addAction(...);
    return result;
  });

in most cases instead (but maybe not all). However, the time will then still be slightly offset (even if its just some milliseconds).

(I wrote it like that to stay consistent with the point in time we have our actual log message being written. So if we should change this, the log also has to go into the map call)

tl;dr: It is not really possible to get the exact timestamp that the action is executed at. Hence, future methods that are added to ModerationActionsStore, such as timestamp-based retrieval (thinking about #280), must be implemented with a time variance in mind (action closest to timestamp ...).

Checklist

• Create the store
• Integrate the store
• Add a note to the class that timestamps might be slightly off
• Javadoc
• Fix Linter issues
• Testing

[RealYusufIsmail]

I have looked thorough it and all looks good.

fixed

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

0.0% Coverage
0.0% Duplication