Discord-Bot-V3.6

Transition to slash commands, with backwards compatibility for legacy prefix commands.

We also address the issue where ignoreme command was available to all (it is a premium command), added new ignoredusers and filtermodel command and spruced up commands with embeds, descriptions, fix ban command, etc

This helps with persistence so bot restarts will remember we messaged a guild owner about exceeding the plan limit.

As a Discord server has a lot of messages, or if a extension-used licence is tried against a Discord server, several functions go to the DB and execute painful request history logic. The extension highlighted the importance of fixing these painful queries (simulating a busy Discord server)

We replace painful SQL queries for profane word count with caching and incrementing via Redis

Notes:

Discord bot flow from Discord app directory allows users to add bots without website prompt.

This issue aims to notify that they must visit our site if they want to manage the filter service with a Discord Oauth login link for our dashboard.

Quick 5 minute refresh for rules. Improvements planned later on this issue.

• Simplify invite screen with clearer text on the steps to complete setup.
• Simplify and explain on the bot side what to do when the bot is directly invited (not via dashboard)
  • Strings in strings for easier maintainability
• Specially crafted login link that leads to the Discord server Home page (one-click setup)
• Use embeds to make the onboarding channel message tidier
• Update dashboard bot command to use the one-click login to server home dashboard

Improve synchronization between the filter service and the Discord bot for recording request history.

Previously, both the filter service and the Discord bot were independently creating request history entries, resulting in duplicate entries. Furthermore, the fields in these entries did not match, leading to inconsistencies in the displayed data in the request history views.

To address this issue, we have implemented a solution. The filter service now includes the request ID it generates, and the Discord bot reads this ID to update the corresponding record with additional information, rather than creating a new entry in the database.

This ensures better alignment between the filter service and the Discord bot in recording request history, eliminating duplicate entries and ensuring consistent data in the request history views.

Improved onboarding by creating a service licence on the spot, bypassing our background job which can take a few minutes - our analytics found users adding the bot, immediately sending content into their channel (presumably to test) and removing it when nothing happened (because licence setup in the background hadn't finished/ran yet.

V1.x API is EOL and will be dropped at the end of the year. Updating is necessary to make use of Threads/Forum type features as well.

This is necessary so that any disruption to a filter request is reprocessed if an error is returned from the service, or if we fail to process the message in a timely manner.

The on_message method in ProfanityBlocker.py checks if a message has been processed using the IsMessageProcessed method from the Database.py module. If the message has already been processed, it does nothing; otherwise, it continues processing the message.

The IsMessageProcessed method in Database.py checks if a message has been processed in the database by retrieving the request time for the message and checking if it has exceeded the max processing duration. If the message has not been processed or has exceeded the max processing duration, it returns False; otherwise, it returns True. If the message ID doesn't exist in the database, it inserts the message ID and request time.

Additionally, the MarkMessageAsProcessed method in Database.py marks a message as processed in the database by updating the processed flag and storing the request time for the message.

The logic in the reprocess_unprocessed_messages method respects the checks discussed earlier. When it fetches unprocessed messages and dispatches them using self.bot.dispatch('message', message), it effectively triggers the on_message method, which contains the checks for message processing. Therefore, the logic in reprocess_unprocessed_messages aligns with the message processing checks discussed previously.

Quick 5 minute refresh for rules can cause stalls if ProxySQL rejects the query because of long execution time.

Steps to Reproduce
1. Start the Discord bot with the Auto Moderation feature enabled.
2. Ensure the bot is part of a Discord server (guild) and has appropriate permissions.
3. Trigger the profanity detection feature by sending a message that violates defined profanity rules.
4. Observe the bot's attempt to process the message and apply the configured rule via the DoRule method.
 
Expected Result
The bot should correctly identify the profanity, delete the offending message (if configured to do so), and apply any additional configured actions (e.g., notify the user or server admin) without any errors.
 
Actual Result
 
The bot encounters a TypeError when attempting to call the DoRule method from the ProfanityBlocker module, specifically indicating a missing required positional argument: 'id'. This error prevents the bot from executing the configured actions for detected profanity.
 
Proposed Fix * Issue: The DoRule method was incorrectly called as a static method of the IFTTPB class without an instance context, leading to argument mismatch and a TypeError.

  * Resolution: Modify the call to DoRule in the ProfanityBlocker module to use self.IFTTPB.DoRule, ensuring it is called on an instance of the IFTTPB class. This change provides the necessary context for the method to access its instance variables and execute correctly.

 
 
 
Code Change:
  * Before: IFTTPB.DoRule(4, user=message.author, Message=message, Channel=message.channel)

  * After: self.IFTTPB.DoRule(id=4, user=message.author, Message=message, Channel=message.channel)

 
Additional Notes
 

Additional files needed updating to use the instance of the class.

This fix aligns with object-oriented programming principles, ensuring that instance methods are called on the correct object instances. It resolves the TypeError and allows the bot to handle profanity detection and rule enforcement as expected.

Fix issue where the bot is sending the wrong licence key for the guild the message was sent in...

Max_processing_duration was set incorrectly, leading to duplicate message reprocessing, especially with slower detailed word analysis.

Another side effect was that image processing would not be done in time for the incorrectly set limit causing reprocessing of the image several times.

105 error code will get us to refresh the global PBGuilds - there are better ways to do this - will optimise in another release

Fix it. We now check if the guild already exists

We now return a service errorcode if the licence does not exist.

The bot already had an error code for this - I also tweaked the message, used a different code.