Storage Module Update + Action History (.json use / no dependencies)

[DukeOfCheese]

• References player storage system #262 from a couple years ago
• Tries to keep with EasyAdmin's pattern of using .json files instead of databases
• Stores moderation actions upon users (e.g warns, kicks, bans and offline bans)
• Provides name of moderator
• Attaches IDs to all the actions
• Provides copy discord button for the staff member / actioned user
• Delete action button on all actions in history
• Bans specifically have a designated button to unban from history
• Automatically clears punishment history after 30 days (convar to change how frequent this occurs)
• Convar to enable / disable this system
• Permissions to view actions / delete actions / attaches to ban.remove for the Unban Button
• Automatically attaches to existing EasyAdmin events for simplicity
• Currently attaches punishment history by Discord ID (see To-Do)
• Change how the storage module works
• Add in webhook logging
• Edit ban system
• Locales apart from English (want to ensure everything is complete before adding in locales)

Future Considerations:

• Add support for the Discord.js bot to view action history
• Potential to add the Rockstar licence of the user in thePlayer object which would allow this system to bind punishments to the licence instead of the Discord ID

[DukeOfCheese]

Very open to suggestions / additions, somewhat in early stages

[DukeOfCheese]

@Blumlaut Is this use of storage.lua more along the lines of what you were thinking?

[Blumlaut]

@Blumlaut Is this use of storage.lua more along the lines of what you were thinking?

i'll have to review the code in detail when i have more time but glancing over it thats about what i was thinking of, i'm just wondering how to best make this work with plugins, i wonder if we should just let them overwrite the Storage entity, or do something else...

Edit: Maybe instead of letting them overwrite the storage entity introduce something like with plugins and have a storage backend convar that people can set, this would also allow us to merge additional storage backends without having to overwrite the default

[DukeOfCheese]

Would it be worth removing the custom banlist convar in favour of this updated storage system or should the function still check for it for backwards compatibility

[Blumlaut]

Would it be worth removing the custom banlist convar in favour of this updated storage system or should the function still check for it for backwards compatibility

Good question, it hasn't been officially supported (or documented..) for years now, i'm not sure if it works any more even.

I'd probably drop it altogether and force people to migrate to the new system.

[DukeOfCheese]

Ban system completely overhauled with new system, commented at points throughout banlist.lua just to make my ideas clear. At the moment, no old code is deleted, rather commented out to ensure nothing is missed.

Small thing with this storage module, the performBanlistUpgrades() might not work as expected, I'll have to try it out once I get back to my PC

[DukeOfCheese]

Also, if anyone is a good discord.js developer, feel free to try and write some commands to view action history. Alternatively, I abandon discord.py for the week and learn djs to make it 😭

[Blumlaut]

Also, if anyone is a good discord.js developer, feel free to try and write some commands to view action history. Alternatively, I abandon discord.py for the week and learn djs to make it 😭

i can probably write some things for it whenever i have the time, i need to remove the configure command and document that change anyhow.

[DukeOfCheese]

Been a second since I've looked at this PR, I think I've cleared up most of the concerns, feel free to look it over and get back to me with any concerns

[DukeOfCheese]

FIXED

[Blumlaut]

just glanced over the code but it looks like there's still no mechanism to have storage backends perform migrations, what are you thinking here? should the storage backends take care of migrations upon being started or should EA "trigger" them when it deems them necessary?

Thinking about it, the first option may make more sense, although we should probably still include a function call for it purely so people dont go around trying to hook a different function or whatever to make it work instead of just doing a self-calling function.