The pygamecommunitybot from pygame-community

Implement a generic interface for supporting multiple database backends using DB-API 2.0 compliant database engine libraries

Using the DB-API 2.0 Specification, we could use the API uniformity across popular database engine libraries that adhere to it to implement a generic interface for database support in this project. SQLAlchemy provides a great API surface for implementing that.

Configuration example:

botconfig = {
    "authentication": {
        "client_id": 1234567891011121314,
        "token": "...",
        "...": ...
    },
    "databases": [
        {
            "name": "a_database",
            "url": "sqlite+aiosqlite:///path/to/a_database.db",
            "connect_args": {},  # arguments to pass to aiosqlite.connect() from sqlalchemy
        },
        {"...": ...} # other databases
    ],
    "intents": 0b1100011111111011111101 # https://discord.com/developers/docs/topics/gateway#list-of-intents
}

This example shows how databases are to be specified. Each database has a dictionary of details relevant to establishing a connection with it.

At runtime, the database info shown here would parsed to automatically establish a database connection, via an AsyncEngine object that could be requested. bot.databases["pgbot"] would also contain the database's "uri" and the optional "library" parameter (to be read when multiple libraries supporting the same engine are implemented).~~

Bot extensions that need access to a database can check if a discord.ext.commands.Bot object passed to their setup() function defines the .get_database(s)(...) methods. For some bot-specific built-in extensions, the database to use can be hardcoded.

Upon seeing the available database connection and the database engine, as well as the library it was provided by, bot extensions can then choose to reject them if they don't implement support for their library/database engine, by raising an exception.

All in all, this workflow would allow us to finally support databases, starting with SQLite via SQLAlchemy and aiosqlite. With extra work, we can expand support to any library that adheres to the DB-API 2.0 specification.

Create `helpforums_pre` and `docs_pre` extension as precursors for `helpforums` and `docs`, add `showcase_pre` and `polls_pre`

#21
#16
#17
#20

Create `polls` extension for the creation of server polls, with support for scheduled opening and closing

Overview

The polls extension should allow for the versatile creation of polls, by allowing members to vote using reaction emojis. Rich embeds would serve as the basis for presenting polls to the public. Polls should support precise scheduling of opening and closing dates.

Synopsis

TBA

Technical Information

In order to maximally utilize Discord's message reaction limits (20 unique reactions), these poll embed character limits must apply:

author.name: 100
title: 256
description: 2000
fields.x.name: 64
fields.x.value: 100

These allow for poll options (embed field names) to always reach 20 while adhering to embed character limits (6000 characters in total).

All commands can be contained in a cog called Polls, which would store poll related state and would manage database interactions.

New Bot Commands

#19
- poll/poll create: Create a simple poll with a description as well as up to 20 emoji options and their text.
- richpoll/richpoll create: Create a poll with a description, color, up to 20 emoji options and their text, custom title, description, start and stop date, as well as images and thumbnails specified as URLs. Anything going beyond the functionality of poll create should be optional.
- poll edit: Edit a poll message's attributes (description, up to 20 emoji options and their text) without losing vote counts when possible.
- richpoll edit: Edit a poll message's attributes (title, description, color, thumbnail, image, up to 20 emoji options and their text) without losing vote counts when possible. Anytime the start date of a poll is moved into the future, all existing votes should be removed.
- poll close: Close a poll regardless of any scheduled opening/closing dates.

Create `helpforums` extension for a richer help forums experience in community servers

Create `docs` extension for the flexible retrieval of software library documentation, based on the evaluation of strings representing qualified names of library modules & components

Migrate all functionality meant for "Pygame Community Discord" into separate extension called `pcbheart`

Moving those into a separate repository whilst keeping guild-agnostic functionality would allow for PygameBot to be hosted and used by other individuals with ease.

Create `messaging` extension for the rich manipulation of messages, embeds and attachments

Overview

The messaging extension should allow for the easy but versatile manipulation of bot messages and their parts, ranging from things like message/ embed creation, editing & cloning to target locations, as well as mass message link/ID fetching and deletion (which can also include non-bot messages).

Synopsis

TBA

Technical Details

TBA

New Bot Commands

All commands can be contained in a cog called Messaging.

The message root command can also have a msg alias for convenience.

EDIT:
Due to the large amount of commands and their complexity, this feature implementation will be split into 2 parts.

Create `text_command_manager` extension for managing guild text commands

The text_command_manager extension would enable per-guild state & permission control for guild text commands, in the same fashion as Discord's Slash Command Permissions to ensure familiarity, whilst removing some limitations specific to slash commands (no configuration limit to only parent commands) and even adding the option of temporarily applying mock roles for permission testing. Initial management should be primarily achieved using text commands.

The core principle around this feature is to use preemptive command checks via discord.py's discord.ext.commands.Bot.add_check(..) method to enforce restrictions based on persistently stored text command state.

The structure of the text command state data is as follows:

class GuildTextCommandState(TypedDict):
    guild_id: int
    "The ID of the target guild for which this state has been created."
    tcmd_uuid: str
    "A UUID string representing the command's ID."
    parent_tcmd_uuid: str
    "A UUID string representing the parent command's ID."
    qualified_name: str
    "The qualified name of the text command."
    enabled: int
    "A 2 bit integer where ( 1 << 0 ) enables a command and ( 1 << 1 ) enables its "
    "subcommands. If set to 0b01, all subcommands of a command will be recursively "
    "disabled."
    channels: NotRequired[dict[int, bool]]
    """A dictionary of channel IDs to booleans that marks
    in which channels a text command should be enabled in, or explicitly disabled
    (if e.g. enabled by a parent command). If not missing, this will override or add "
    "to a parent's setting, depending on whether the "All Channels" sentinel "
    "(guild ID - 1)  is specified or not.
    command's settings
    """
    roles: NotRequired[dict[int, bool]]
    """A dictionary of role IDs to booleans that marks
    which roles enable the usage of a text command, or explicitly disables it
    (if e.g. enabled by a parent command). If not missing, this will override or add "
    "to a parent's setting, depending on whether the "@everyone" role (guild ID) "
    "is specified or not.
    """

Commands

All text command management commands would be contained under a root text command called tcm, defined in a central cog called TextCommandManager, which does all the management work at runtime All commands would be guild-only. tcm and its subcommands are also subject to text_command_manager's management.

tcm: Outputs a very short description of what its subcommands are for.
tcm mockroles: Show the currently applied mockroles apply one or more ephemeral specified mock roles to yourself, to be used for testing command permissions.
tcm view: Shows the settings of all configured text commands or those specified by full name.
tcm set: Add or replace settings for specified text commands.
tcm setglobal: Add or replace global settings that may be used or overridden by text commands.

tcm clear: Clears the settings configured for the specified text commands.
tcm clearall Clears the settings of all configured text commands, including any global settings.
tcm clearoverrides: Clears any channel and/or role overrides for the specified text commands.
tcm clearglobaloverrides: Clears any global channel and/or role overrides that may be used or overridden by text commands.
tcm clearmockroles: Clear any mock roles that were previously set by an invoker.

pygame-community / pygamecommunitybot Goto Github PK

pygamecommunitybot's People

Contributors

Stargazers

Watchers

pygamecommunitybot's Issues

Overview

Synopsis

Technical Information

New Bot Commands

Overview

Synopsis

Technical Details

New Bot Commands

Commands

Recommend Projects

Recommend Topics

Recommend Org