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

[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]

I've also gone through all of Copilot's suggestions, some of it was beneficial, the unresolved ones are ones I'm not 100% sure about whether it would impact

[Blumlaut]

this is not quite what i meant.

I was more thinking of
https://docs.fivem.net/natives/?_0x964BAB1D

see:

EasyAdmin/shared/util_shared.lua

Lines 195 to 198 in b81a223

	function GetVersion()
	local resourceName = GetCurrentResourceName()
	local version = GetResourceMetadata(resourceName, 'version', 0)
	local is_master = GetResourceMetadata(resourceName, 'is_master', 0) == "yes" or false