digital-controllers / discord-bot Goto Github PK

To help students practise the techniques they have learnt and recall key information, we propose setting up a student and question database.

Databases

The student database should:

• Include the discord ID and username of every student, dynamically changing the username if their username changes;
• Split these students into two separate sections, an ATSA section and TCA section;
• For each student, record their ACAD and PRAC qualifications in two separate sections (e.g. ACAD-1 PASS ACAD-2 PASS ACAD-3 FAIL ACAD-4 PASS ACAD-5 UNKNOWN); and
• In the qualification section, include a flag for each ACAD module which will be set to 1 if the student fails every single question for that ACAD module in a quiz.

The question database should:

• Include questions differentiated by ACAD module;
• For each question, three answers with one correct answer;
• For each question, recommendations for further reading to pass the module (e.g. "Try looking at DCP101 Section 2 Chapter 2!)
• Include a flag indicating whether that question has been used for question of the day (henceforth QOTD), ideally queuing them so that the latest questions become a QOTD first and minimising repeats (questions which have not yet been QOTDs should ideally not be askable questions (defined later) but we can discuss this.).

Two separate interaction types will be needed for questions.

Student Interaction

Students should register in the database by either being added by an instructor or requesting their first quiz. If they do not already have an entry then the quiz should trigger their registration.
Students should be able to pick topics (Multiple choice) and have the bot create a small quiz for them depending on how many topics they picked (e.g. three questions per quiz), then allow the students to submit their answers as a multiple choice quiz. The bot should feedback the questions they incorrectly answered, and rather than give a direct answer for the question, should provide a further reading recommendation to promote self-teach. If the quiz was requested in the DC server, a "Ask An Instructor" button should be included that pings the applicable instructor roles (being created tonight) to request further assistance.

They should also be able to fetch a list of their qualifications, showing the ones they have passed and failed, possibly in image format (I can write this bit.) The bot can recommend further study as part of this query if certain modules are flagged for more review.

Instructor Interaction

Instructors should be able to perform lookups on every student, fetching all data on their qualifications, and should be able to easily and rapidly edit their qualifications (e.g. /qualification username:quantify acad:11 result:pass).

Instructors should also be able to add questions to the question database.

Automation

The bot needs to submit a QOTD daily at 1200UTC, preferably in a queue to ensure no repeats and that the latest questions begin their cycle as a QOTD to assess their effectiveness. The bot should post the answers at 2000UTC in spoiler tags, pinging all members who posted a reply in that forum post.

Nonsensical Ramblings

This is a pretty big addition so I've added a fair few people. I am fairly happy to take responsibility for the user interface but don't have very much experience with database management so would be amazing if @JustOneOther could take that.
This will be the initial phase of creating a fully integrated database system - in future our opt-in system can be adjusted to allow for flight plan submission from opted-in pilots with strips integration. For now this should give us the skills we need!

Also welcome to a new member of our org, @kerfuzzle, who will hopefully have some great advice and contributions in future.
Would prefer to keep discussion about this in this issue so I can look back at it since I have a very small brain. Now, where to start...

Currently, the DC Discord server is dependent on a 3rd-party bot for reaction role functionality.
This bot both paywalls features and has frequent outages.

We should implement similar functionality:

• Detect reactions being added and apply an appropriate role
• Set up reaction roles in DB
• List currently configured reaction roles
• Set up reaction roles using a command that takes a message ID (tbd?), an emote and a role as arguments
• Remove existing reaction roles via command

per title. The example given in the discord.py docs is this:

from discord.ext import tasks, commands

class MyCog(commands.Cog):
    def __init__(self, bot):
        self.index = 0
        self.bot = bot
        self.printer.start()

    def cog_unload(self):
        self.printer.cancel()

    @tasks.loop(seconds=5.0)
    async def printer(self):
        print(self.index)
        self.index += 1

    @printer.before_loop
    async def before_printer(self):
        print('waiting...')
        await self.bot.wait_until_ready()

This could easily be applied to update_server_embed, and I'll work on it if that's wanted. This would remove the requirement to run the /update_embed command when the bot is updated.

If this is something that is wanted, then I can work on it, but I'm not sure if there are reasons why we're not doing this yet.

Non-functional and may mess with other JetBrains IDEs

At the moment, our embed code is designed solely for use in the DC server. This works fine but it would be brilliant to make our bot publicly accessible.
This would probably involve a refactor of our current embed routines to ensure embeds update globally in a safe and efficient manner while storing their identifiers/guild identifiers in an SQL database and accounting for various edge cases such as a channel/embed being deleted, while also creating commands to allow external server administrators to create embeds in a simple manner.

This would also involve a rework of the bot's permissions and since we're using interactions to a great extent, we should be able to strip down the required perms significantly. The ultimate goal is to not require the reading of messages whatsoever, so an implementation should not have to search for messages in a channel and should rather immediately fetch and store the message id from the message object created.

I'm not quite sure where to start on this so please do give me your thoughts and ideas, and we'll see how to go about it.

Not everyone has the knowledge to read METAR reports by eye, and while copy/pasting a METAR report into a website is not difficult, it would enhance the user experience if this functionality were available through the bot.
I suggest a standalone /read-metar command, which will take a METAR report as an input and respond with the plain english representation of it, and a modification to the /metar command which includes the plain english representation after the METAR report.