alpha-serpentis-developments / project-lynx Goto Github PK

!scanbots [PERMISSION_TYPE]

The command will return a list of bots with the corresponding permission in the server. Although this may not necessarily check if a bot may be malicious, it may assist server owners and administrators to decide what bots may be of high-risk or interest.

User Raid Protection (URP) is an automated feature that runs in the background. It'll take the moving average of the number of users joining and if it reaches a certain threshold (example, 15% higher than the moving average), it will designate them a "URP Detected" role and lock the user from reading/sending messages in the server.

They MUST be cleared manually using another command (perhaps !urp clear @[USER]) or remove the role manually.

It will not automatically kick/ban users as there's a possibility of false triggers.

There's a potential threat for overloading the writing to the files when Project Lynx will scale larger. This is especially true when using the !configure command which grabs the old JSONObject and will rewrite it as necessary, BUT when writing new data in, it requires the re-initialization of the cache of ALL THE GUILDS.

Disabled by default.

The feature would check in the background for a list of allowed URLs.

Subdomains are not checked.

As per @codic12 suggested.

• @ everyone permissions to roles/channels/categories
• Check if 2FA is enabled

When it comes to members they avoid bans just by leaving the guild and most bots doesnt have a feature where you can ban someone that's not in the guild

JDA to be updated from 4.1.1_101 to 4.2.x is extremely important due to the Discord API updates.

Have 2 new Commands

Mute Command - Gives the User the Mute Role for the guild
Set Mute Role Command Sets the Mute role for that guild

For Discord to kick or ban users with a reason, the reason must have 512 characters or less.

The bot does not currently have a way of determining the reason length.

The bot should log the full-length of the reason provided, but the reason submitted to JDA should be cut off.

If a new command is implemented, instead of having to handwrite it, it'll copy a "DEFAULT" key to the guildData to assign the new command key with that information, reducing the need to write the data manually into the JSON.

When a user attempts to execute a command, it'll be checked by a separate thread, comparing the UNIX time it was sent and the previous (if any).

It will NOT respond to the user. The limit will be set to 1 second/user.

(This number could be adjusted if deemed necessary)

>>ADMIN should be added to include administrators to the group of people able to use commands.

I was thinking, When it comes to warnings there should be a way where you can configure the bot so if you got x amount of warnings you'll get banned, kick, etc

An example I warned LostNuke 4 times for spamming, therefore, he's now banned from my guide

About

The configure command should be able to change each individual command for the specific command. This command can only be executed by an administrator or server owner.

The configure command will use a three-tier system:

Level 0

• The command is DISABLED
  • !configure CANNOT be disabled

Level 1

• ANYONE can use the command

Level 2

• Certain Roles can use the command

Usage Examples

(May Change Without Warning - Document the Change!)

!configure warnings 2 [ROLE_1, ROLE_2, ROLE_3, ...]
!configure warn 0
!configure about 1

Additional Planned Changes

• Modify the "DEFAULT" JSON key to set the tier levels for a few commands, if deemed appropriate.

• When the bot joins a new server, it will sort through the list of roles, and check their permissions to suggest the server owner/administrator on what Level 2 configuration could have.

Create an interface that would reduce the unnecessary amount of time to write particular sections repeatedly such as grabbing the reason, punished/executor users, etc.

Commit 76cbdea partially prepares this issue

The "resources" folder needs to be moved outside of the Java project for easier access to the JSON, the override file, and if needed, add/remove photos.

This will remove the need to recompile and/or recompile the code every time.

In addition, pull the "DEFAULT" JSON key outside from the data file and create a dedicated (mostly) static default.json so when new updates are needed to the data structure, it will not interfere with git pulls.

JSON is not great for scaling up in the future. Will need to consider other options.

Finish this method in Data.java to enable obtaining backups in the event of unreadable data or the need to rollback data.

Currently, to obtain the backup data, one would have to access the resources folder and grab the latest backup, whichever has the highest UNIX timestamp, copy the data and paste it into guildData.json

Numbers above 9 will begin to sort incorrectly. For example, from top to bottom, it'll become 11, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10

Currently, doing warn/kick/ban will send messages in both the channel where the action was executed and into their private messages.

An option to toggle the settings, or perhaps disable both of the messages to be sent.

Suggested by Discord user PTB Foxo#3787 <563854476021334047>

Anonymously warn someone, as a staff member we would need to warn someone for doing something but when it comes to warning the bot to say warned you for "Reason". But sometimes we want to remain anonymous for certain situation So I was thinking if you do -warn <user> "reason" --anon ( Add a --anon ) you can warn someone Anonymously and the bot will warn to the user as:

A Staff Member had warned you for XXXX

Convert moderator data into cache and JSON.

For cache, simply update the current cache with the added data.

For JSON, put it under the "moderation" key under the respective values/arrays.

So as you know when it comes to staff members maybe a higher-up wants to see if the staff member are doing their job so I was thinking when it comes to having reasons you should have like < Member who banned that user > : < Reason Go Here >

Example:

When the bot moderates a user, it DMs them. It gives the moderator username and then the reason.

However, it does not provide the server name. This can be an issue when the same bot is in several servers they are in.

A server name should be included in the DM message.