ccoffey1 / agile-story-point-game Goto Github PK

Currently the application has no database to interface with in Azure. As a result, registering the DbContext is causing an exception, preventing the app from properly starting up.

Format of the initialization string does not conform to specification starting at index 0
(from the connection string in appsettings.json, since the connection string is currently tokenized with no transforms)

Since we need the DB anyway, a new DB should be created in Azure to satisfy this requirement and fix the error.

Description
To avoid every controller being filled with try/catches, a new way to handle exceptions should be found.

See https://www.youtube.com/watch?v=Ut6mRRFT2vM for ideas.

Two parts for this:

1. Any internal exceptions are caught and logged without try/catches all over the place.
2. Any validation exceptions return proper error messages back to the caller for use later when building out the UI.

Acceptance Criteria

• (spike) Find a good way to catch exceptions generally and log them. Attributes on controllers or a base class for controllers to derive from comes to mind.
• A new, custom exception type is made for validation/user validation errors. This exception should be caught by its type so we know when we have to pretty print a message back to the caller.

• Display a button "Return to Game" on the create/join game page
  • Button is displayed if a user has a JWT
  • Button is displayed if game exists for this user (add a new endpoint to check if game exists)

After a game is created, users should be able to join using the join code. Joining a game with an existing join code redirects the user to the game stage displaying the name of the game.

Out of scope: Error handling for scenarios where game doesn't exist and user already exists in game.

A UI landing page should be created when first visiting the site that should appear as follows:

(This will probably be prettied up later...)

Description
As a player I should be able to submit a story point vote. My voting options should be from 3 to 34, following a Fibonacci sequence.

Example:
3, 5, 8, 13, 21, 34

Acceptance Criteria

• A new endpoint that accepts a POST request
• Endpoint should take in points from 3 - 34, throwing exceptions out for any incorrect values.
• Endpoint should determine player and game from the JWT embedded in the request.
• Saving the point to the game should be stubbed for a future ticket.

When creating a game, it should redirect the user to the Game Stage, with the name they chose set, along with the join code.

• As a user I expect to see my homies in the game as separate cards.
• Any users who join a game session are revealed as cards on the main game stage.
  • This should refresh if any additional users join the game using sockets.

Description
The application should leverage a form of simple authentication when users create a new game and join a game in progress.

Acceptance Criteria

• JWT middleware added to the app startup.
• Route to acquire the JWT
• Test route using the JWT
• JWT integrated into Swagger UI

As a user I expect - after creating or joining a game - to be brought to the stage area where the game takes place.

The stage should be built out to display the following details (mocked for now):

• Team Name
• Join Code
• Point Selection Cards
• Consensus (with a ? as a placeholder for the points)
• Reasons Menu (see below - right side)

Out of scope:

• Cards in the middle
• Flip button

Submitting a request through the UI to create or join a game results in the following error:

Description
As a user/team lead I would like to be able to create a game session for team members to join.

Acceptance Criteria

• New endpoint api/game/create
• Endpoint takes in CreatorName, TeamName
• Calling this endpoint creates a game, associates a new User with FirstName = CreatorName with the game
• Returns a JWT for the new User

Link the UI to the API; should redirect to a placeholder page revealing the user's JWT and Team information.

Description
Currently, there exists one or more workflows where data is saved to one table, then to another, in separate transactions.

If something were to go wrong between these saves, this would leave the tables in a desynchronized state, potentially causing issues.

Acceptance Criteria
(Idea below is tentative based on options available)

• BeginTransaction() and CommitTransaction() methods are added to the base CosmosRepository class that all other repos inherit from.
• Using these methods should make saving across multiple tables atomic.

Description
As a user I would like to be able to join an already existing game session.

Acceptance Criteria

• New endpoint api/game/join
• Endpoint takes in ParticipantName and GameSessionId
• Calling this endpoint joins a game, associates a new User with FirstName = ParicipantName with the game
• Returns a JWT for the new User

SeriLog messages are currently using interpolated strings (ex: "Attempting to create a game {gameSessionName} requested by player {playerName}")

This is incorrect, and each variable should be passed as an argument to the function rather than interpolated into the message directly. Ex:

_logger.LogInformation("Attempting to create a game {GameSessionName} requested by player {PlayerName}", gameSessionName, playerName);

As a user I expect to see cards displayed for those participating in the game. Additionally, I should be able to click a 'Flip' button which will flip everyone's cards to display their chosen points.

Acceptance Criteria:

• All (mocked) players' cards are displayed in the center of the game stage.
• A 'Flip' button exists in an appropriate location.
• Clicking 'Flip' flips all of the cards to reveal their opposite side. This should be accompanied by a radical animation (staggered, if you're feeling crazy).

Notes:

• All data related to players and their points will be mocked. The mocked data should be easily replaced by an API call in the future.

Out of scope:

• Clicking 'Flip' hides the point selection cards from the screen.
  • This will be handled later using states for the game, such as 'voting' and 'done-voting'.
• Clicking 'Flip' hides the decision selection on the right side of the screen.
  • This will be handled later using states for the game, such as 'voting' and 'done-voting'.

Voting:

Flipped:

Description
Votes received from players should be saved to the game session itself.

Acceptance Criteria

• Submitted point votes should be saved to the Game Session object. Points should be saved in the form <player_object, vote>. (Or, if thought better, simply saving the player_id instead of player_object here to enforce some sense of a normalized DB.)
• Submitting more than one vote should cause a player's previous vote to update.

Github Action is skipping the Publish and Azure deploy steps erroneously when executed on the master branch.