nos78 / mrdata Goto Github PK

There needs to be a command to allow a user to download their guild's scores into a file that can be opened in a spreadsheet package, or text editor, or other human readable format

Currently feature development and test is performed on a seperate discord bot, called MrTest, who has his own API client key from the discord dev portal, and is a seperate entity from MrData within the discord program. To keep this level of separation, he has a seperate database (although since the config is a Json, this is easily changed).

However, MrTest does not have his own remote host, and simply runs on a the development PC. This is fine when there is only one person in the project team. I can develop, build and test locally, without requiring a remote host.

Once additional testers or developers join the team, unless we leave the development PC online 24/7, we will need to host MrTest remotely too.

Options can be explored, but since the port numbers are easily changed, we could use the same VM as MrData. This would increase the running costs, and the additonal processing cycles may increase the billing band we are occupying

When debugging MrData, the console is littered with warnings and failures - the database has reached its connection limit of 5.

Firstly: why is the bot needing more than 5? Since it uses asynchronous promises, it should be able to reuse the one it has, else close it.

Perhaps their are multiple forks and so each one needs a new connection.

Secondly: this connection limit is stupidly low, but it is a limit specified by our current database host, elephantsql.com - maybe we should migrate to a new host? The Bot Factory company websites have been using an Amazon AWS host for the last couple of months without hiccup - maybe we should be migrating over to here.

When running as a systemctl service, the new cmdExec.log functionality will cause the bot to fail to start if the permissions are incorrectly set (I needed to chmod 666 cmdExec.log). It runs fine if started manually with node bot.js.

If the file doesn't exist, then the service cannot create the file at all.

The commands are loaded from disk into the coomands collection when the bot starts.

This means that if new commands are created, the bot needs to be rebooted in order to load the new command. Given the modular design of the command system, it would make more sense to be able to reload the commands during runtime, via a command that it accessible by the bot owner.

The main help text is pretty disorganised - the command help pages are nice, the main help is a shambles.

MrData is a large enough project now to require external help during a development cycle.

It is no longer feasible to design develop build and test the product all by myself. MrData is running on 70+ discord servers, and it is no longer a project developed in the garage and being used by a few friends.

I do not have enough time to devote to testing new features and perform regression tests and expect MrData to run without any issues.

So, I need testers. This issue is created to assist in getting testers. To start, I will seek volunteers from Clam, and then the github community.

Testing will be done using MrTest - and new features will not be rolled over onto MrData until they are signed off.

It is not possible to enter a command in a private message, since the ability to add guild specific previxes.

We need a way of deleting user data from the database once a user leaves the server. Otherwise the leaderboards become full of entries saying "User 124567834 has left the building".

It might be nice to have their name in the leaderboard, but since the bot does not store these (names are queried automatically using the discord API). We don't want to change this behaviour, otherwise when a user changes their nickname we will be out of date.

A simple !removeuser command will suffice, with privileged permissions so only admins can delete users.

The recently added config.json flag, deleteCallingCommand operates on a server-wide basis, meaning that this changes the behaviour for every guild. This is as intended.

However, the related command, !deletecallingcommand (commands/deletecallingcommand.js) should allow individual guilds to modify this setting individually. If an administrator on server X performs the command, it changes the default behaviour of the bot for all servers!

This is currently not an issue, as MrData is operating on one server only. But this will prove problematic very soon, as v1.1.1 is intended to be rolled out to the discord community.

It would be nice to have version numbers for every command in the ~/commands module. These version numbers would be displayed when showing the command help.

The help for most of the commands has a hardcoded prefix and command name.

Using ${config.prefix} we can have the help return the correct prefix even when it changes, without having to modify the help. This will mean that the help text is still correct once the command prefix is user-defined.

This issue relates to the per-server settings project, and so this work is dependent upon that project. Although this issue is small, it is quite important and so Im raising it as an issue.

Currently, the !broadcast command will broadcast to every server that MrData has access to, if he can find a channel with the appropriate permissions. To avoid abuse, only the bot owner can use this command, but that does not eliminate all the issues.

This may upset some users, who may not want a bot posting unsolicited messages onto their discord server! Particularly when this is used to advertise new features or services, and at first glance may appear to be an unsolicited advertisement.

Can't invite the bot

It would be easier to read the help if the commands where split into groups, or topics.

IE: Utility, Scoring, Admin, etc...

So each group would have a title and a list of commands under it. Each group could be a seperate embed message, each command as a seperate field, and use inline text so that more than one command appears on the same line.

iOS users who use Safari cannot receive push notifications as the browser does not support service workers, not push notifications.

Therefore an alternative solution needs to be sought - such as developing a simple iOS app that can receive the notifications. A simple dummy app should suffice, as it only needs an app id and (hopefully) the OS push service will deal with the rest.

You should add !missionscompleted and !allianceshelpsent

It would be good if the bot could send push notifications, using a free mobile push service that integrates with Linux.

The data model needs to be reviewed.

From first look, it seems to be overcomplicated and probably even overnormalized.

The aim is to simplify the data model so that answering the questions derived from the use cases becomes as straight forward and easy as possible.

Someone was able to misappropriate MrData, and use it to send spam.

Initial investigation reveals that it was probably via the discord API bot token, which is used to verify the bot's identity. With this token, any malicious piece of code can log in as the bot and run its own code.

So I have changed the token. The token should not be stored in version control (and indeed, it isn't...) but there was a version of config-secret.json and the initial version of config.json that had the bot's token in it.

It is no coincidence that the spam started occuring on the same day and not five minutes after I made the repository public!

Check the code base to ensure there is nothing compromised, and additionally, add some logging for every command being executed.

Background

The main config.json contains the global settings that MrData requires to function - paths, colours for rich embed messages, the debug level, and so forth, the bot's command prefix.

In order to make MrData better, some of these configurations could be user-defined. That way, if a guild admin wants to have a different command prefix, he could do so.

Proposal

Configuration should be stored on a per-guild basis. These settings would override the main config.json, if they exist. If they do not exist, then the global setting will apply.

Variable assignment behaviour for JSONs, such as the settings, and other objects is to pass by reference. This means that, for example, creating a new setting from the template and then assigning fields actually changes the template too.

Change this to assign the variables by value, using Object.assign() or another method,

As per convention, user and developer instructions should be included into README.md.

Those are lacking at the moment.

It should include how to set up the environment for running the software properly (excluding the runtime, ofc) for both development and usage purposes.

Imagine you get back to the repo after 2 years - would you still know how to set up the environment?

Rather than have the exporting functionality in the commands/command.js file, the functionality for taking a query/table and putting it into a file should be added to the library functions.

With a modular design, one command could potentially facilitate any number of formats from CSV to JSON and beyond, simply by expanding the library to cope with another format. That way the command stays the same other than adding a parameter to specify what format is needed

A counter, ignoreMyself (and ignoreMaximum) was recently added to the client object, allowing the bot to programatically determine whether it should ignore X number of subsequent commands. However, this will prove problematic when the bot is running on more than one server.

The counter should be moved into a collection, indexed by guild key. This will allow a counter to be set for each individual server. The guild.id is easily obtained during the 'message' event, using message.guild.id

I noticed an upgrade subfolder in the sql folder? Is there a database migration tool in use?
If yes, which?

Exposed functions should have JSDoc comments.

Files should have meaningful headers (and replace the old ones which are not auto-updated by the VSCode extension whenever files are modified).

Background

There is some code in bot.js that should be extracted into new (or existing) libraries.

Modular command system

When the bot loads, the modular command system loads the commands from disk collates them into a collection. This is currently done within the main bot code, in bot.js. During development, if command files are modified, the bot has to be restarted.

Since the command system is supposed to be modular, one would be forgiven for thinking this means that commands are plug and play - you just drop a new file into the commands folder and a new command is accessible via discord. But that is not the case.

New functionality
However, if the command initialisation code where extracted into a library, a new command to reinitialise the bot could be created - meaning commands could be updated at runtime, and the bot would not have to be restarted every time there is a change to a command.

Alternatively, there are a range of events that could be hooked - one of these might be able to perform a similar task.

Pretty stack traces

There is some code that outputs a stack trace to the channel if an error is caught. This code should be extracted into a library function, so it can be used elsewhere.