Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate status guards for Manual Tournaments #471

Open
AlphaKretin opened this issue Feb 1, 2023 · 3 comments
Open

Investigate status guards for Manual Tournaments #471

AlphaKretin opened this issue Feb 1, 2023 · 3 comments

Comments

@AlphaKretin
Copy link
Contributor

No description provided.

@AlphaKretin AlphaKretin changed the title Check tournament status for commands, e.g. only look at decks if opened, only finish if started? Investigate status guards for Manual Tournaments Feb 1, 2023
@AlphaKretin
Copy link
Contributor Author

AlphaKretin commented Feb 1, 2023

How necessary is this? The difference between a tournament being open for registration or not isn't actually a status, and that's the biggest factor I can think of.

@AlphaKretin
Copy link
Contributor Author

  • /channel: Doesn't have much reason to be used after the tournament is IPR, but no harm
  • /create: Irrelevant, doesn't act on an existing tournament
  • /csv: Only has a point after registration is open, but always useful past that
  • /deck: Ditto
  • /drop: Ditto
  • /finish: Can guard that the tournament is IPR before finishing, but it's also reasonable to allow shutting down a tournament prematurely without starting it for cancellations
  • /forcedrop: See /csv
  • /host: See /channel
  • /info: Always useful
  • /list: See /create
  • /open: This should actually be restricted to preparing only, I think
  • /queue: This could be preparing only, or would just return no results. Also no point prior to opening registration
  • /start: See /open
  • /timer: See /create
  • /update: Changing some settings after the tournament is in progress is a dodgy prospect, but no harm in updating the name or desc...

@AlphaKretin
Copy link
Contributor Author

In summary, the only commands that I think need status guards are:

  • maybe /finish
  • maybe /queue
  • /open
  • /start
  • /update on some functionality?

Additionally several commands such as /csv, /deck could benefit from a guard on a registerMessage existing, but that's not a status.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants