Adds ping-protection module.

[Kevinking500]

A full module dedicated to protecting specific users/roles for future pings!
Features:

• Sends a notice message with a GIF showing how to disable mention pings, about not being allowed to ping that user/role.
• User is able to configure the warnings message with embed functionality, while also being able to configure the protected roles, users, ignored roles and channels and to allow/don't allow reply pings
• User is able to configure if the bot will log ping history (default, yes and by default stored for 3 months.), if it logs moderation history (default no, as moderation capabilities is by default off. Stored for up to 12 months.) and if it keeps logs of leaved users (by default yes, by default up 1 day after leave, can be up to 7 days.)
• User is able to configure if the bot will mute or even kick the user after they reached xx amount of pings within a timeframe. By default it is 10 pings to trigger action within the configured timeframe of pings history logging. It also has an "advanced" configuration for that to allow for a custom timeframe in weeks. The mute duration can also be adjusted to liking.

Maybe even more features that I forgot to mention here lol
This module has been extensively tested by me and my testers over a 3 day period going over every feature, including after a full code polish. Changes may look longer/shorter in duration between them because I only commit changes once tested it works.

[CLAassistant]

All committers have signed the CLA.

[Kevinking500]

By the way to maybe answer some questions you may have:

• Why did I do select instead of integer in storage.json for database storage duration?

I did select with the specified minimum and maximum amount of storage time to prevent user-side configuration errors

• Why is this not an add-on to the moderation module or ghost-ping module?

This module is supposed to have many configuration fields, options and it wouldn't make sense to put it into a module, additionally I plan to add many other features in the future which would be inlogical to be inside a module

• Why did I not do a command warning for the panel command?

The bot already checks if the executor has administration permissions and the delete data button checks for it again, as the executor is supposed to make it not in a public channel, but sometimes they do and therefore the data deletion button checks it again

Just in case you were wondering any of the above, then you have the answers ^^
(If any of the above require a change let me know)

[SCDerox]

Thanks for your contribution. Without testing your code, I was able to identify multiple issues that need to be addressed - feel free to comment on them if you disagree.

Additionally:

• Pings still go through, meaning that users still recive the pings "protected" by this module. This means that this module does not prevent pings, instead it punishes them. Instead of doing this, the module should create and maintain an Auto Mod Rule and react to the autoModerationActionExecution event when the rule gets triggered to run punishments.

If you have any questions, concerns or disagree with any of my comments, please reply to them directly or let me know!

Happy holidays!

[Kevinking500]

Thanks for the requested changes! I will immediately work on resolving these, for ones that I have questions about I let them as a reply.

[Kevinking500]

Hey Simon, I have completed the changes requested. I think most (if not all) of your changes have been done, but it's been many hours so I can't remember if I did exactly all. Please let me know if everything has been solved now!

[SCDerox]

• Still not using automod APIs
• Please mark comments that you solved as "Resolved", otherwise I am unable to review the changes.

[Kevinking500]

Alright, I just reviewed all changes and I did everything except indeed the automod API which I forgot, I will be working on that now!
Though the purpose was mainly to protect the user from future pings by informing the user they are not allowed to ping. This is exactly the behaviour as other bots, and if the ping gets deleted we have to remember that there might be important context provided which we then need to enter into that message. I think it's best to be an option as I think that people also want it to let people ping in for example important situations

[SCDerox]

You could also add the automod feature as a configurable option, but I think to truly "protect" against pings, we need to actually be able to block them. This would make the module way more powerful 😄

[Kevinking500]

Hey, I have added that the bot will by default delete the original message with the ping, and adds the original content to the warning embed. Let me know if I need to adjust anything!
I didn't integrate Discord's native automod because it would overcomplicate it for a simple message deletion, though I might add it in the future if i want extra features from it.

[SCDerox]

I think the Discord Native Automod has a crucial feature that you cannot do, even with deleting the message: blocking the message from triggering a ping to the user, so I would find it crucial to be supported rather than simply deleting messages.

[Kevinking500]

Oh I actually didn't know that, that's a pretty neat feature!
I definitely think that's very useful. Though one thing is that this module is meant to be my starting point with scnx and allowing me to get the basics before getting into the api stuff like we discussed, and therefore I think that this would be a great starting point without the automod and adding it later on after getting the full basics. Now I am definitely not saying to wait months, just like get this published, see how it goes then apply api features. Though if you think this is essential then I can try adding it now, though it will definitely take some longer to figure that out aswell. Don't mean this harshly towards you at all though, just a little notice ^^

[SCDerox]

Thanks for explaining; however, I think it would be crucial to offer such a functionality at release, to ensure that we're delivering on user expectations. The automod API is built into discord.js (even at v13) and can be used easily (e.g. you just create a rule, update it every time the bot configuration changes, and listen to the event when it gets triggered), but I get if you are not interested in implementing such functionality at this point. If that's the case, please let me know, and I will look into alternatives.

[Kevinking500]

Ahhh okay if that's the case then I can definitely look into it a bit more for now. Thanks for providing that information as it's really useful, I think that if I do think that it's simple enough for now, that I will let you know tomorrow or atleast within the next 48 hours for a new commit with the automod integration ^^

[SCDerox]

No stress, happy to help if you have any questions or need guideance - here on GitHub or in the #oss-chat on Discord 😄

[Kevinking500]

So I looked over the automod docs completely with rules, and I couldn't find something that let's the user send the ping message but make the ping not go through as an actual ping. Which action type is it that's needed or do you mean actually blocking the message?
Also now that I realised it, deleting the message feels pretty useless when we contain the actual message content in the embed as it's basically the same and the ping just results in a ghost ping, so either simply blocking the message all together, or somehow getting that ping suppression is a better choice than deleting I think

[SCDerox]

So the easiest way to do this (the way we do it on our Discord as well), is to automatically sync the configured users as a keywword filter (trigger type: KEYWORD) with the following keywords for each user: <@ID> and <@!ID>.
This might look like this (with <@!ID> mentions missing):

When a message gets flagged by automod, Discord can block it automatically, by having an Action with Type BLOCK_MESSAGE configured (you can also set a configurable custom_message string).

[Kevinking500]

Ah yes thanks for the additional information!
I have taken a look actually on a very popular bot Sapphire who also does something similar like this and sends a message with the content without the actual ping so the message is still sent by the bot without the actual ping, which I think is smart and I will take inspiration from that aswell. As when the message is blocked, the warning message and moderation actions features will not work as the message is not sent.
I will edit it to this, but isn't it supposed to be <@&ID> for roles? Or is <@!ID> something else?

[SCDerox]

You can still trigger the warning message and moderation action manually, even without the message being sent by listing to the event and triggering relevant calls.
Older client versions might use <@!ID> to mention users with usernames.

[Kevinking500]

Yeah I am trying a workaround to log it into the history and moderate, I am planning a redesign of the module and logs when it is enabled, so it won't do something like showing a link to jump to the message when there is no such link etc.
I will let you know when it's ready ^^

[Kevinking500]

I am currently facing multiple issues with it, currently thr only thing I can manage to get it done correctly is blocking the message. Other things seem to not work and are likely only going to work correctly in Discord.js V14 but I might add the commit of the code that blocks the message but doesn't do other things it's supposed to so you can take a look at it

[SCDerox]

I am unsure what isn't working, your comment doesn't include any details. Since the API and event are fully supported on V13, simply upgrading discord.js won't likely address your issues.

[Kevinking500]

It's mainly an issue with the reposting the message content and the alert channel for AutoMod.
When you enter in the ChannelID in your configuration for the alert channel, Discord seems to simply refuse it, even when making the ID passing it over to Discord as (ID) instead of "(ID)".
Also the bot is also unable to fetch the channel ID from the alert causing it to not know where to send the reposted message. I am currently focussing on primarily just the blocking mechanic of AutoMod, then commit after testing.
Additionally the bot seems to not be able to log it in the history either because of these 2 issues.
Please let me know if you know fixes for this. (Sorry that I don't provide error logs, I am already currently testing the simple mechanics and almost ready to commit the simple blocking)

[SCDerox]

Please push your latest work, so I can take a look. I can't help without seeing your code.

[Kevinking500]

Here you go, there might be some verbose logging, you can ignore that as I basically just reverted to an old version and I usually log alot to diagnose issues as I noticed some issues fail silently.

[Kevinking500]

Damn that actually resolved a handful of issues.
After that the log channel did successfully get automatically set.
Though now we remain with the same issue of not able to find the channel ID of where the blocked message happened from the alert.
Also I accidentally forgot to complete the commit name and pressed commit :/
This is now the error in my terminal for the getting the channel ID for the reposting:
[WARN] [ping-protection] Repost Failed: Could not extract Channel ID

[Kevinking500]

After some consideration I am doing the following changes instead:
I will make the alert channel required so it always sends the alert
I will add a custom message to the message block to let the user know that this message content has been sent to a channel where the user could see it
I will remove the repost ability as essentially the protected user/people with the role is already able to see it anyway.

I will commit the following changes after I coded and tested it ^^

[SCDerox]

To get access to the channel, use [event].channelId (which needs to be fechted), to get access to the content, use [event].content

[Kevinking500]

Ahhh okay noted. Though I removed it not only because I didn't get it to work, also because the alert message already shows the content to the protected people/people with the protected role meaning doing both a repost and sending the alert is basically double double. I have sent the full code of the bot now that works as supposed to!

[Kevinking500]

Hi, i've found a quite critical bug when testing extensively today for Quality Assurance.
The allow reply pings configuration option did not work properly and the bot basically ignored it.
I have fixed this, tested it and confirmed it now works the following ways when it is set to allowed:

• The bot does not send a warning when a user replies to a protected user with mention enabled, UNLESS:

It pings a protected user/role in the actual message which is checked, then it does send a warning, logs it and punishes if necessary.

Please review the full code with soon if you haven't already ^^
(or if you are currently testing it, you can safely copy this code into messageCreate.js as it's the only file edited and only changes the logic for checking reply pings)