Design the CLI UX

[overanalytcl]

Description

This issue is dedicated to tracking the process of designing the command line user experience.

Tasks

• [ ] Authentication
  • [ ] Log in
  • [ ] Log out
  • [ ] Check auth status
  • [ ] Switch accounts
    • This means I need to have the ability to add and delete users which need their own subcommands.
  • [ ] Refresh stored auth credentials
    • This would probably mean logging out (if the user is logged in) and then create a new session and log in transparently.
  • [ ] See session ID (token)
    • Could be useful for scripting where you need to see the session ID. This isn't necessary (I believe), since one should use the CLI directly instead of calling the API (why would you choose that path?).
• [ ] Interacting with contests
  • [ ] Joining a contest
  • [ ] Seeing the leaderboard
    • I'd need to find a way to display said leaderboard (so I'll do research into available libraries for drawing tables), along with offering support for showing only certain fields or sort by one or more fields.
  • [ ] Creating contests
    • Is this something users can do?
  • [ ] Accept invitations (which would mean getting them, although this is more of an UI thing)
  • [ ] Getting the problems on a contest
  • [ ] I'll update things later here
• [ ] Interacting with problems
  • [ ] Get problems by name or ID
  • [ ] Display the statement
    • I am interested in Glamour for this task, since it is a native Go library and it's just so wonderful for the job.
    • I can't display $\LaTeX$, but that's expected.
  • [ ] Search for problems
  • [ ] Get statistics for a given problem
    • The research on the leaderboard display also applies here.
  • [ ] See the tags of a problem (this could be under a flag instead of a separate subcommand)
• [ ] Submissions
  • [ ] Create submission
  • [ ] Get submission (by ID)
  • [ ] Maybe delete your own submission?
  • [ ] Reevaluate a submission (self or admin)
• [ ] Admin-specific things
  • [ ] Set admins and proposers
  • [ ] Various maintenance tasks (TBD, probably not for 0.1.0)
  • [ ] Get all users
• [ ] Proposer- and editor-specific things
  • [ ] Create problems
  • [ ] Import problems from archive
    • Maybe make an interactive way of creating an archive if the directory is in a certain format?
  • [ ] View tests for a problem
    • [ ] Adding tests
    • [ ] Deleting tests
    • [ ] Updating test info
  • [ ] Add and update subtasks
  • [ ] Add attachments
  • [ ] Add editors and viewers (is this on the admin side?)
  • [ ] Delete a problem
  • [ ] Toggle visibility of problem
  • [ ] Create problem lists
• [ ] Problem lists
  • [ ] Filter them
  • [ ] Get by name
  • [ ] Get problem list
  • [ ] Updating and deleting
    • This feels like something that users shouldn't do
• [ ] Users
  • [ ] Get info about an user
    • [ ] Name
    • [ ] Solved problems
    • [ ] Bio
  • [ ] Deauth all sessions (either self or by an admin)
  • [ ] Find by name or ID
  • [ ] Set bio
  • [ ] Set preferred language or theme
    • This seems more useful for the UI than the CLI, but I'll consider localization later if Cobra lets me do it
  • [ ] Change email
  • [ ] Change password
  • [ ] Change name
    • Other things I didn't consider at this moment.

This issue will obviously change, it's mostly a discussion. Feedback welcome.

[rsdobre]

I think we can take some inspiration from the way git structures its commands. For example we could let users set a default email address kncli config user.email example@mail.com, so they don't need to input it for every auth. We'd store these in a .kncliconfig file. This would also apply for setting the default submission language, display language of problem statements, ect.

Regarding problem submissions, I'd imagine the command would look something like kncli problem submit solution.cpp --id 9999. That would get old pretty quick, so we should allow users to set a problem they are currently working on kncli problem --id 9999 and let them execute other commands without specifying the problem id (kncli submit solution.cpp, kncli statement).

In the future we could also look at auto running the example test cases locally, since most people don't like blindly submitting without at least checking the examples.

Auth and problem submissions are clearly the no. 1 priority, they will probably be the most used and as soon as we get those ready people can start using kncli