For simplicity, I've been returning errors as Box so I didn't have to worry about casting and From<T> implementations. Returning proper error structs would be optimal for debugging and error reporting.

The proposal for having teams is as follows:

• When a lobby is opened for a team match, group members into teams.
• Each team is given a Team model, and each MatchmakingPlayerLobby model will point to that team.
• When a user joins a team, they are given access to a temporary role with the team's name.
  • The role will be placed under the specified Runback Admins for the guild.
  • If there are privileged roles placed under the Runback Admins, then there is an opportunity for guild members to edit roles that they previously did not have access to. Such a situation can be prevented by informing guild admins of such a risk and how to prevent it.
• Players report scores for each match using the standard /report-score method, but each player can report and verify the scores for their teams.
• When a team match finishes, report the scores to a TeamMatch structure and remove all temporary roles.

If there are any issues or enhancements that we can make to this structure, feel free to comment.

I've been trying to implement the /matchmaking report-score command, in the Interaction Handler I have something like this:

But I can't seem to figure out how to get the option values on the process_command function, I tried a lot.
@tristan-zander do you know if I can print the command options from Twilight to the terminal so I can see what it is that I'm getting?

We need to document which Scopes and Permissions the bot needs to function correctly.

Hey @tristan-zander, feel free to submit a PR to showcase your project!

• SeaQL/sea-orm#403

Description

The matchmaking family of application commands has a background loop that will close sessions after they time out. The logic is very rudimentary and won't allow the user to extend their time in the current session.

Acceptance Criteria for Issue Resolution

• Move background session loop into its own struct.
• Notify the users when their session is about to expire.
• Allow users to extend their session by 30 mins
• Store session information in the database, rather than in memory.

On the MatchmakingSettings model, adding a convenience function to get the Discord channel for the default matchmaking channel will let us know whether that channel exists or not. On the chance that the channel no longer exists, notify the Runback Admins that they need to set a new matchmaking channel.

Additionally, receive ChannelDelete events and check whether that channel corresponds to any MatchmakingSettings objects.

Hi, I'm having trouble setting up the environment, I read in the DockerFile that I need to manually mount a volume but I don't know how.

This is the error I'm getting right now:

[USER@fedora runback]$ sudo docker-compose -f docker-compose.development.yml up discord-bot
[sudo] password for USER:
runback_redis_1 is up-to-date
runback_zookeeper_1 is up-to-date
runback_db_1 is up-to-date
runback_kafka_1 is up-to-date
Recreating runback_discord-bot_1 ... done
Attaching to runback_discord-bot_1
discord-bot_1 | error: project root does not exist
runback_discord-bot_1 exited with code 1

Description

User's shouldn't have to interact with the application commands in order to interact with Runback. Standard operations with Discord should be supported.

When a user interacts with a matchmaking thread, they should be considered a part of that match.

Outstanding questions

• Should admins be added to a lobby? It would make sense not to have them act as players if they're just there for conflict resolution.

Acceptance Criteria for Issue Resolution

• When a user joins a public thread, add them to the lobby if it's a matchmaking thread.
• When a user joins a matchmaking thread, make sure any invitations for them are resolved.
• When a user leaves a matchmaking thread, remove them from the matchmaking session (matchmaking_player_lobby db model).