Husky/mute rewrite

[ghost]

ViBot

Changelog

closes #562
closes #563

mutes Table Restructured

CREATE TABLE `mutes` (
  `id` varchar(32) NOT NULL,
  `modid` varchar(32) NOT NULL,
  `guildid` varchar(32) NOT NULL,
  `reason` varchar(1024) NOT NULL,
  `appliedOn` int NOT NULL DEFAULT (unix_timestamp()),
  `duration` int NOT NULL,
  `removedOn` int DEFAULT NULL,
  `removedBy` varchar(32) DEFAULT NULL,
  `removeReason` varchar(1024) DEFAULT NULL
)

• A permanent mute is denoted by duration being 0
• An ended mute should have removedOn set
• Mutes with duration equaling -1 are mutes that ended before the DB restructure, mostly used to identify in ;punishments when we can't know when a mute was set or how long it was
  • Before, uTime only signified when the mute was supposed to end. It never got updated during an unmute to the time of the unmute, so it's only consistent for those who lasted the entire duration. For mutes it's quite often that's not the case and I'm not comfortable giving an 'ended' time that essentially means nothing.

Conversion Script
The below has been tested to work correctly copy-pasting into an ;eval

(async () => {
    const [rows] = await db.promise().query('SELECT * FROM mutes');
    const now = Date.now();
    const newRows = rows.map(({ id, guildid, reason, modid, uTime, muted, perma })=> {
        perma = perma || (isNaN(uTime) && muted);
        const duration = perma ? 0 : !muted ? -1 : Math.max(-1, (parseInt(uTime) / 1000)^0 - Date.unix());
        const removedOn = perma || duration > 0 ? null : Date.unix();
        const removedBy = removedOn && bot.user.id;
        const removeReason = removedOn && `Removed before ${(new Date()).toLocaleString('en-US')}`;
        return [ id, modid, guildid, reason, duration, removedOn, removedBy, removeReason ];
    });
    await db.promise().query('DROP TABLE IF EXISTS `temp_mutes`');
    await db.promise().query('CREATE TABLE `temp_mutes` ( \
        `id` varchar(32) NOT NULL, \
        `modid` varchar(32) NOT NULL, \
        `guildid` varchar(32) NOT NULL, \
        `reason` varchar(1024) NOT NULL, \
        `appliedOn` int NOT NULL DEFAULT (unix_timestamp()), \
        `duration` int NOT NULL, \
        `removedOn` int DEFAULT NULL, \
        `removedBy` varchar(32) DEFAULT NULL, \
        `overwritten` boolean NOT NULL DEFAULT false, \
        `removeReason` varchar(1024) DEFAULT NULL \
        )');
    await db.promise().query('INSERT INTO temp_mutes (id, modid, guildid, reason, duration, removedOn, removedBy, removeReason) VALUES ?', [newRows]);
    await db.promise().query('RENAME TABLE mutes TO mutes_backup');
    await db.promise().query('RENAME TABLE temp_mutes TO mutes');
})()

If an issue occurs, old mutes will either still be in tact or under mutes_backup. If for whatever reason we need to revert:

use halls;
drop table mutes;
rename table mutes_backup to mutes;

Rewrote mute and unmute commands

• Both are now usable as slash commands
• Overwriting a mute now attaching a reason & who removed it to the old mute
• Automatic unmutes and normal unmutes of temporary & permanent mutes all give the same embed as they now use the same unmute function
• Confirmations for if a mute is not managed by ViBot & if there's already active mutes have full info and are button confirmations now when trying to mute again.
• Unmute job will now reapply the muted role to anyone who had the role manually removed but has an active mute in the DB. This is to help avoid inconsistencies when they can be muted again and have multiple active mutes.
  • Disclaimer: I asked multiple upper staff & pinged Officer and got virtually no response so I'm assuming they at least read the message and are fine with it.
  • Automatic unmutes will properly log them being unmuted.
• Role ping automod now mutes using the same function as ;mute does
• Permanent mutes are now applied & removed the same as normal timed mutes

Bugs

• Stops DB from having invalid 'still muted' rows for people who were manually removed from the role
• Umute and mute, permanent/not, automatic/not all log the same way in #mod-logs channel
• Overwriting mutes now properly attaches reason/mod details to the old mute & logs properly
• Can now properly permanently mute
• Can actually attach a reason to unmutes in general

Examples

Ignore the footers here, I changed it to just be moderator displayName & displayAvatarURL() for consistency. Just don't feel like retaking all of them for a minor change

• normal 1 day mute
  
  
• overwriting a mute confirmation & perma
  
  
• confirmed overwrite
  
• Unmute
  
• What the raider sees for unmute
  
• Mute permanent slash command
  
• Unmute slash command
  
• Mute temporary slash command
  
• New punishments after db rework w/ an overwrite, active, and older mutes