Overview

To clean up the sub-folders under the api folder, we may want to consider to namespace the migrations and seeds folders to a separate db folder.

Here is a medium post that shows the syntax for setting the directory to use for the migrations and seeds files.

// knexfile.js
module.exports = {
  development: {
    client: ‘pg’,
    connection: ‘postgres://localhost/merch’,
    migrations: {
      directory: __dirname + ‘/db/migrations’
    },
    seeds: {
    directory: __dirname + ‘/db/seeds/development’
    }
  }
};

Overview

After much reading about Auth0 best practices, and the ways to configure scopes, and validating correct scopes are requested for each User Role, we are ready to fully implement the end solution. This ticket will cover the work related to the scopes, permissions, and related rules to correctly assign.

Requirements

NOTE: this took me reading through Auth0 docs a few times when reading about scopes, and authorization permissions.
scopes = permissions
Perhaps should have been obvious when docs saying permission name needs to match the scope name. Also, it is important that the scopes created are in the format verb:object. You can see this becomes important in the example rule created that automatically adds the correct permissions (scopes) to the User's id token.

• We will define the list of scopes that cover the basic operations that users will be able to perform on the site, as well as administrators
• Create scopes in Auth0, and corresponding permissions in authorization extension.
• Assign perms to Administrator and User Roles
• Ensure Validate Access Token Scopes Rule is production ready, and copy to github for source control

Optional

Define a script to use Auth0 API to create scopes and permissions to make management easier within multiple tenants.

Scopes List

I think to keep the list of scopes somewhat manageable that we can use a "create" scope to represent both the create and edit functions. We'll have two Roles

User Permissions

I don't think there is a need for a scope to allow the user to edit their own profile, I think that should be implied by the nature of having an access token. Once we create the concept of actual "tags" then we can add scopes in at that time.

• create:characters
• delete:characters
• create:games
• delete:games
• create:posts - this can cover both posting in lounge forums and actual games
• delete:posts
• view:gamelabels

Admin Permissions

I don't think we need scope for games_labels for now as those will be inserted via migrations for now.

• create:users
• delete:users

Task List

• Determine if we want to return User Role(s) as part of the id_token.
• Finalize Login providers and create test/prod apps (ie. Google, FB, twitch), etc
• Finalize list of scopes needed for MVP
• Create top-level auth0 folder in project with subfolder for rules, and README to explain
• Implement scopes and permissions for all Auth0 tenants

Overview

This ticket will cover the work to implement all objects related to the concept of game_labels.
We are specifically calling this object labels instead of tags to indicate that these are related to application and logic, and not more general user-created tags.

Requirements

After much discussion on the trello ticket and in chat, we have decided to implement a table structure similar to below. There will be a single label, then aliases that can be also be used as a lookup (ie. by user when searching) to return the canonical label.

These labels will connect together various objects within the application such as characters, games, and game engines. Game engines will enforce and allow the actions that GMs (and players) are able to perform in game in addition to normal posts.

|Tag ID          | Display Name | Short Name | Aliases (json array?) |
| ------------- |:-------------:| -----:|
|1|Dungeons & Drangons (5th Edition) | DnD5e | ['d&d5e', 'dndnext']|

Overview

Once #30 is complete where players can join a game, the Game Messages tab should prevent players from creating new messages unless they have a status of accepted or game-master.

Requirements

Any user (logged in our out) should be able to view the Game Messages tab and all its content.
The "Add Message" component should only be displayed to those users that are accepted to the Game, and the Game Creator.

For all other users, we'll display a friendly text message.

While games are viewable by everyone, only players are able to post game messages. Try posting a message in the Lounge, or searching for another open game.

Overview

One of the required features in order to allow users to play games is a dice roller. This will allow the user to create one or more rolls using commonly accepted dice syntax.

Examples

Here is the BGG dice roller guide. You can see it supports a lot of different formats. Some of the commons one are:

• 2d6+3 - roll 2 6 side and add 3
• 2d20l+3 - roll 2 twenty side and drop the lowest and then add 3
• 1custom3{Tom;Dick;Harry} - roll 1 custom 3 side, using the values Tom, Dick, Harry
• Exploding dice
• Fudge dice

Existing Packages

• chance - This is a mature package that focuses in trying to get close to real random. The rpg and dice rolls are only a really small part of the overall package. Probably not focused enough on just dice rolls.
• https://www.npmjs.com/package/d20
• https://www.npmjs.com/package/roll

Out of the above libs, I think the roll package is closest to what we are looking for.

Requirements

• A User should be able to add multiple dice rolls to a single message.
• The User should be able to add a descriptive label to each roll.
• Once a message is saved, the dice rolls should be able to be edited (ie. they are immutable).
  • A nice to have would be to not allow the user to remove any dice rolls once saved, though I don't know if this is required for MVP.
• Add a new column to game_messages table to store an array of dice rolls. Each dice roll object will be an object of: label, result, components of roll
• We do only need to implement some of the basic dice modifiers as this feature certainly follows the 80/20 rule. 20% of the dice features will be used 80% of the time.
  These features are:
• multiple dice, add/subtract constants
• drop high / drop low
• custom dice

Future Considerations

Once we have some basic character attributes we can use those values to automatically calculate certain rolls. These rolls will have to be based on the game label. For example for d&d5e, to roll Initiative is 1d20 plus the character Dexterity modifier. So the user could say: /roll Initiative

We will only be able to easily calculate certain rolls. We could also allow the user to create their own roll templates, or bookmarks. For example: /roll 2d20l+3 save advantage-attack
they could then later use: /roll advantage-attack

Overview

As a user, after searching and finding a potential Game to Join, I will want to view and Post in the Game Lounge. This will be discussion about the meta of the Game, ie. potential players asking questions, posting character ideas, etc. This discussion will not be part of the Game itself. It will not be part of the IC or OOC, what we currently have implemented as the game_messages table.

Requirements

The Post "widget" should be the same widget that is used to make game messages pots. We may just want to disable a few of the toolbar options such as IC, Singing, Etc.

The User must be logged in to create a Post in a Game Lounge.

The messages will be displayed in chronological order

Questions

Should this be implemented as a sibling table to game_messages? ie. game_lounge? How would we make use of a commentable pattern that you mentioned a while back? Is that overkill for this use case?

Overview

In testing a previous ticket I had to do a docker down, which totally reset my db so I had to bring everything up from scratch. This included creating new users.

While running master, just after #63 was merged, I am no longer able to sign up with a new email/password.

The user is created within Auth0
The user is redirected to the /login/callback page.
The various attributes are being written to the local storage correctly.
The page briefly says "Logging In" and then that text disappears.

There is an error in the console as follows. I think the user is never actually getting inserted into the users table, so on the callback page when it tries to reference me that query has failed as the new user has not been inserted into the db at this point. I can't figure out where the "correct" place is to do this insert (or where it used to happen before this refactor.

api_1     | 2018-02-17T03:24:34.866Z - info: select "users".* from "users" where "auth0UserId" = $1 - [auth0|5a8799bb5c679b17810f9c01] - 2.000 ms
api_1     | GraphQLError: User not found
api_1     |     at Object.__WEBPACK_IMPORTED_MODULE_2_models_user__.a.query.where.first.then.dbResult (/app/dist/webpack:/services/user.js:18:1)
api_1     |     at runCallback (timers.js:789:20)
api_1     |     at tryOnImmediate (timers.js:751:5)
api_1     |     at processImmediate [as _immediateCallback] (timers.js:722:5)
api_1     |     at QueryBuilder.then (/app/node_modules/objection/lib/queryBuilder/QueryBuilder.js:414:25)
api_1     |     at __WEBPACK_IMPORTED_MODULE_1_bluebird___default.a.try (/app/dist/webpack:/services/user.js:12:1)
api_1     |     at getUser (/app/dist/webpack:/services/user.js:11:1)
api_1     |     at runIfContextHasUser (/app/dist/webpack:/services/user.js:91:1)
api_1     |     at me (/app/dist/webpack:/schemas/user.js:40:1)
api_1     |     at resolveFieldValueOrError (/app/node_modules/graphql/execution/execute.js:498:12)
api_1     |     at resolveField (/app/node_modules/graphql/execution/execute.js:462:16)
api_1     |     at /app/node_modules/graphql/execution/execute.js:311:18
api_1     |     at Array.reduce (<anonymous>)
api_1     |     at executeFields (/app/node_modules/graphql/execution/execute.js:308:42)
api_1     |     at executeOperation (/app/node_modules/graphql/execution/execute.js:236:122)
api_1     |     at executeImpl (/app/node_modules/graphql/execution/execute.js:133:26)
api_1     |     at Object.execute (/app/node_modules/graphql/execution/execute.js:110:229)
api_1     |     at doRunQuery (/app/node_modules/apollo-server-core/src/runQuery.ts:155:16)
api_1     |     at /app/node_modules/apollo-server-core/src/runQuery.ts:69:39
api_1     |     at <anonymous>
api_1     | From previous event:
api_1     |     at runCallback (timers.js:789:20)
api_1     |     at tryOnImmediate (timers.js:751:5)
api_1     |     at processImmediate [as _immediateCallback] (timers.js:722:5)
api_1     | From previous event:
api_1     |     at completeValueWithLocatedError (/app/node_modules/graphql/execution/execute.js:546:22)
api_1     |     at completeValueCatchingError (/app/node_modules/graphql/execution/execute.js:518:21)
api_1     |     at resolveField (/app/node_modules/graphql/execution/execute.js:464:10)
api_1     |     at /app/node_modules/graphql/execution/execute.js:311:18
api_1     |     at Array.reduce (<anonymous>)
api_1     |     at executeFields (/app/node_modules/graphql/execution/execute.js:308:42)
api_1     |     at executeOperation (/app/node_modules/graphql/execution/execute.js:236:122)
api_1     |     at executeImpl (/app/node_modules/graphql/execution/execute.js:133:26)
api_1     |     at Object.execute (/app/node_modules/graphql/execution/execute.js:110:229)
api_1     |     at doRunQuery (/app/node_modules/apollo-server-core/src/runQuery.ts:155:16)
api_1     |     at /app/node_modules/apollo-server-core/src/runQuery.ts:69:39
api_1     |     at <anonymous>
api_1     | 2018-02-17T03:24:34.876Z - info: POST /graphql 200 - - 13.834 ms - {
api_1     |  "operationName": null,
api_1     |  "variables": {},
api_1     |  "query": "{\n  me {\n    ...userFields\n    __typename\n  }\n}\n\nfragment userFields on User {\n  id\n  name\n  username\n  profileImage {\n    url\n    publicId\n    __typename\n  }\n  completedAt\n  timezone\n  updated_at\n  __typename\n}\n"
api_1     | }
api_1     |

Overview

As a user, I should not be able to submit an empty game lounge message or game message
Currently there is no validation on the submit button, so pressing it will create a new message.

The button should have a check to be disabled if the textarea is in the default state (ie. no content).

Overview

As a User, after I complete the initial Sign up process, I should be redirected to a page to fill in a few additional required fields needed for the FA website.

Users will continue to be redirected to this special data collection page after each log in action until the required fields are submitted, which will trigger an a flag to indicate the process is complete and the page can be skipped in future log in actions.

Requirements

The URL for this page will be: /login/almost-finished
If the User visits this page and they are not logged in, they should be redirected to /login
If the User visits the page and they are logged in, but signupCompleted is true, they should be redirected to /games (eventually this may change once we have the proper account page created)
If the User visits the page and they are logged in, but signupCompleted is false is undefined, they they should stay on the page

Data Storage

Here are the fields that will be displayed on this additional sign up page:

• username (string) - required, globally unique
• name (string) - required
• profileImage (JSON) - optional
• timezone (String) - optional - will store the IANA timezone name ie. America/New_York

The storage for these fields will be in the users postgres table.

Logic

After the data has been saved to the users table, the function auth0.patchAuth0Metadata should be called to push the user and app metadata fields to Auth0.

NOTE - after thinking about this more I do not think that we need to store every profile attribute value in the Auth0 user_metadata field. There really isn't a point to this, we should only store values that might be needed by Auth0 functions, ie. sending emails, etc. I can think that only the username, name, and profileImage (url) will be required). This also makes it easier if we decide to add additional fields to our user profile in the future, we don't have to worry about pushing these fields to Auth0.

The user metadata should contain:

• username (string)
• name (string)
• profileImage (string) - will just be the "basic" https image url, not a json object with the publicId

The app metadata should contain:

• faUserId
• signupCompleted

Sign Up / Log in

After the initial sign up action, the user will be redirected to this page.
After a log in action, if the attribute signupCompleted is not set to true, then the user will be redirected to this page.

Once all required fields are submitted by the user, the field signupCompleted will be set to true in the users table. This field will be added to the app_metadata field.

Auth0 Data Sync

The existing Logic in Auth0 rules, and API Methods will need to be refactored to make the data sync process easier. Instead of the current process where data can sync two ways, it will be simplified to a one way data sync. All UI actions will POST to FA API methods. These methods will perform the necessary logic and update the postgres data as needed. They will then all call a single function to collate the data and POST to Auth0.

• Remove the rule update-user-profile-in-database.js
• Remove API method POST /api/users
• Remove function security/checkAuth0Secret and associated auth0.faClient.sharedSecret
• Refactor uploadUserPicture function to extract out logic that pushes data to Auth0

Questions

1. How do we want to store the profileImage data? This is because the field is optional, so we need to handle the state where we only have the default image from Auth0, or a user uploaded image that is hosted on Cloudinary?
2. Should we continue to maintain the faUserId in the app_metadata field in Auth0? I think so as its good to have the link in both data stores.

Overview

There are a few places in the api schema where we use the getOrCreateUserByAuth0Id function. Here and here are current examples.

These functions are breaking because for a logged out user, there is no user object on the context.req object.

These need to be refactored, perhaps with a general function so we don't have to keep repeating this pattern to check for the existence of the user object before calling this function.

Sample code snippet

const token = _.get(context.req, 'user.sub');

if (token) {
  return getOrCreateUserByAuth0Id(token)
    .then....
} else {
  // might or might not need this
  return [];
}

Overview

As a user, I want to be able to upload a different user profile image for my profile.
NOTE: this process will also be very similar and used to allow the User to upload a "profile image" for each Character.

Requirements

• The user will be able to select and upload a new profile image on their account profile page.
• The image will be uploaded to an express API. This API will then:
  • Upload file to S3
  • Upload file to Cloudinary
  • Make API call to Auth0 to set picture attribute in user_metadata.
• Web Client will make API call using auth0-js to Auth0 to refresh the local id_token which will now contain the new user profile image

For this ticket we will set up environment variables in the docker compose file to get api container access to S3. We will define a Role that will be used for dev as well as the higher environments. This Role will then be assigned to User objects.

A separate ticket will be responsible for setting up and managing the AWS Keys needed to call S3 from the api docker container.

Tasks

• Create Cloudinary Account
• Create S3 buckets for each environment (or with subfolders) for image storage
• Express API to POST profile image
• Create Auth0 Rule to normalize picture attribute in tokens

This ticket addresses tidying up the API database layer operations

• implement created_at and updated_at population for db operations. This should be flexible enough to handle tables rows that are only created and do not require an updated_at column
• implement deleted_at for soft deletes. This should be an optional mechanism as not all tables will require a soft delete mechanism Leaving this for now until it is needed for sake of expediency

Overview

As a user, I want the ability to be able to quote an already created Game Message.

Requirements

There should be an option the user can select to "Quote" a given message. It should be displayed in a similar UI fashion as the Edit functionality.
If quoted, then the editor should display the given message in a "Quoted" state. The user will then be able to add additional text before or after the quote block.

The UI for displaying a quote can be a "light blue" solid background. There should be a header for the section that says who (or which character) wrote the original quoted text.

There should also be a "Quote" menu bar button in the message editor. When clicked it should add the "Quote" block where the user can then add text inside the quote block.

Questions

1. What do we do about nested quoting? ie. quoting a quoted message?

Tasks

• refactor API JWT handling. Currently the graphql related middleware makes a call to checkJwt for each request, which adds a considerable amount of latency (between 200 and 800ms on my dev). This is either due to the library making a remote call or some other reason. In either case, the latency issue needs to be addressed via either correct use of the JWT auth0 library or via locally caching the JWT until it expires.

• refactor Auth so that it can be passed as a prop to any component irrespective of its position in the DOM tree.

• Incorporate the auth state into the router so that login redirects can be implemented outside of components and views.

Overview

This ticket covers the work to integrate the main "create post" text window. It will be implemented as a type of rich text editor (RTE). This will be one of the most common interactions the user will have with the site so the UX and how well it works will be critical.

Requirements

• The editor should easily allow the user to create the different types of "text", and actions within a single post.
• The initial set of text types are: Character Talking, Character Thinking, Character Signing, Regular Text.
• As discussed on a call, a game will primarily consist of a single game thread. This thread will be made of posts of different types. Everything will be displayed chronologically in a single feed so its easy to always have context around a post.
  • The initial post types will be: In Character (IC), Out of Character (OC)
  • TODO is how to handle additional types such as dice rolls, DM actions such as "call for initiative"
  • This will be handled in separate tickets, it's listed here just for context around this chat interface.
• The best UX for this interface is that the text markup renders correctly as the user is creating the post. If this proves too difficult, the next best option would be to give them a "preview" tab that they can easily switch between typing and previewing. Example UX would be the github issue/comment UI widget

Possible libraries

react-quill
draftjs
react-rte - based on draft js. Not sure if we need this or would write our own similar to this lib based on draft.
this reddit thread talks about history of draft. Lots of projects after it was released but a lot are stale now. Need to research them more. Draft is the building blocks to create own editor. Careful though as there are mobile issues and shims possibly needed for create react app.
marked

Overview

As a user, after reading the details of a Game, and possibly posting in the Game lounge, a user will want to Join a Game. As part of making a Post in the Lounge, a User will be able to apply to join the Game. The user will optionally be able to enter a message, but at the very least the act of applying will create a message such as: Michael has applied to join the Game!

This ticket will mainly cover the DB schema, methods and use cases for joining and the GM accepting players. A (basic) prototype UI can be added to the Game Details / Lounge Page.

Requirements

A user may apply to a Game, this will put the User in the initial state of: "pending".
The GM of the Game may then update the status of the User to: "accepted", or "rejected".
Though unlikely, a User may apply to the same game more than once.

A User must be logged in to create a Post in the Game Lounge and Join a Game. If the User is not logged in and clicks the Join button they should be redirected to the Login page.

Technical Details

For this ticket we will only handle the use case of a User applying to a game. A future enhancement to this ticket will allow for the User to optionally select a new or existing character to include when joining the game.

The db needs to support the use case of a user joining a game with a nullable (blank) character. The character can be filled in at a later point in time.

Database Tables

Here is a list of possible changes to support this feature.

game_players
id, userId, createdAt, status (pending, accepted, rejected, quit, kicked), updatedAt, deletedAt
Once we add the concept of characters, a nullable characterId will be added.

UI Implementation

In this ticket we will implement a basic UI to all for the following use cases:

• Joining a Game
• Viewing the status of Players in Game
• Allow GM of a Game to accept a Player

We will add a new tab on the View Game page between the existing two existing Tabs. The new tab name will be called: "Players"
The new tab will show a table of the players in the game that have a status of pending and accepted. Rejected and kicked status, etc players will not be displayed.
Above the table will display the number of min, max, and current accepted players.
The table will display the following information:
User Profile Image, Name (Timezone if set up already)
Status
In a future ticket we will add character information such as: Profile Image, Name, Level, Race, Class

Join Game

A new button will be added to the View Game "header" where the game title, scenario is displayed above the tab bar. The button should be right aligned. The label should be: Join Game
It should change to a disabled state of "Joined" if the user is currently accepted or the game-master.
It should be a disabled state with a label of "Pending" if the user is pending. All other states (ie. rejected, etc) should display the default Join Game.

After clicking the Join Game button, the user should go to a new page with the url: /games/:id/join
There should be a message textarea like on the game lounge tab.
The textarea should display by default, in italics: ":name has applied to join the game"
The should then be copy on the page to inform the user they can add to this message with any specifics about their character, or notes to the game master.
There should then be submit and cancel buttons at the end of the form. either option should take the user back to the View Game page.

Update the create game view to accept an image. Refactor the users API endpoint to accept both profile and game images.

Overview

POC for this project will be deployed to AWS. We will use ECS and associated services for deployment and management of services. For this POC we will create a basic set of CFN scripts to build the necessary components and create a test and production environment.

Requirements

We will be using AWS Fargate to make setting up the ECS infrastructure easy.

• CFN for parent test and production environments that will contain following sub templates
• CFN for ECS Cluster with Fargate, VPC
• CFN for Redis
• CFN for RDS
• Manually create ECR Repositories for client and api

Questions

1. We are going to run the React client in container or deploy to static location like S3 bucket?

Overview

As a user, I want the ability to be able to go back and edit a Game Message I already created. Obviously many use cases, to fix typos, forgot to add text, etc.

The UI should indicate though that a given Message was edited.

Requirements

For the v1 of this feature, we do not need to implement a full audit history, ie. keeping track of every change. We will simply keep track of the number of times a given Message was edited.

The UI for each Message should display either a settings, option, or directly an "Edit" link. When selected this will change the given Messge box into the regular editable form. The user will be able to make the edits as necessary and then save. The UI should then change back to the "display" version of the Message showing the new text.

Overview

As a user, I want to be able to insert an image into either a lounge or game message.

Requirements

For each editor, there should be a new icon added to the editor toolbar. It should use the semantic "image" icon. Clicking this should bring up the file browser for the user to select an image to upload.

The image should be inserted into the editor at the cursor location.
After the message is created or saved, the image should be displayed inline to the message.
A user viewing the message can click the image to open a larger version in an overlay.

Questions

Look at the plugin framework mentioned in #44 as possibly making this feature easier.

Overview

There are several features of the application that will need to support image uploads from the user. This ticket will cover:

1. the discussion and options to decide on the React (client) file upload library and server API
2. the file storage, CDN delivery, and responsive image generation

Discussion

Client & API Lib

• Unlike in DS, we can have our (web) client interact only with our server API, instead of interacting with any third party platforms, ie. S3, SaaS image service, etc. This also abstracts away the backend storage and logic from the client, thus making it easier to make a change.
• react-dropzone seems like a very functional and popular library. Only potential issue is that there is currently a call for new maintainers.

Storage, Delivery and Responsive lib

• We have a couple of different options for how we want to handle storing and generating responsive images.
  • One approach would be something similar to what we did in DS, we upload to an S3 bucket and have that trigger a lambda function to create a set of known dimensions. Pros are that it would be super easy to implement. Con is that its not as extensible if you need additional image sizes, etc.
  • Second option would be to use a responsive image service. These are SaaS platforms that handle everything for you, image storage, delivery, and real-time responsive image generation and manipulation. Pros are they are more extensible going forward, pretty easy to implement. Con is 3rd party dependency and potential higher cost.
    • Two options are: cloudinary and imgix

Approved Architecture

Client & API Lib

react-dropdown is as close to an "official" react file upload lib as exists. If drag and drop upload support is needed, then this should be the lib to use. Here is a quick tutorial showing it's usage.

Otherwise it can be regular javascript html5 file upload.

Storage, Delivery and Responsive lib

Cloudinary will be used as the platform to store and serve the responsive images. To provide flexibility going forward all file uploads will also be uploaded to S3 in addition. This way we already have all source images if we choose to move to a different platform or implement in-house in the future.

Responsive images and resizes are very easy to handle.

1. Games list
2. Game messages

Ideally the same infinite page scroll component should be used for the above and any subsequent views that require it.

Overview

To have separate environments in Auth0 for testing and production, we need to create separate tenants.

Requirements

The existing client, api and tenant will be used for the production env.
All new items should be created for a test environment (with appropriate names).

Instead of using textfield elements for the skill and posting frequency attributes, they should instead be select elements.

Options to use for Skill Level. The first option can be the default on initial load of the page

• Any/Newbie friendly,
• I’ve rolled dice before
• Expert/role play master and rules bookworm

Options to use for Posting Frequency. NOTE: also need to update label as it currently says Frequence.

• About 1 / day
• 2-3 times / week
• Hardcore - More than 1 / day

Let's also update the default (initial state) values for the min players to 2, and max players to 6.

Overview

Now that the table structure around the database games objects are solidifying we can add the concept of game labels. The table already exits, we just need to add the foreign key to the games table, update apollo types, and then update the Games UI elements.

Requirements

Add a foreign key from game_labels and games tables.
Update apollo types for games to include labelId and game_labels object.

• On /games page, add a Game Labels to search form. For v1 it can just be a regular dropdown, no need for auto-complete.
  ** When displaying game results, display the game label for each game
• On /games/:id page, display the game label for the game
• On /games/create add a new field for Game Label. For v1 it can be a basic dropdown

Lock v10 is now deprecated in favor of v11.
Here is the migration guide to upgrade to v11.

Auth0 recommendation is to move to centralized hosted page. We can make this change when custom domain support is out of beta.

Overview

After creating a new game on the /games/create page, as a user I am redirected back to the /games list page. The newly created game is displayed in the list twice. We have seen this bug present itself if this game was the first game ever created, or if there were already two games created.

@nazar believes the issue may be related to infinite load.

I have a feeling it is an issue with the infinite load - i.e the page view and the inf load both trigger at the same time

Overview

Allow a user to quit a game from the Players tab.
Allow a GM to "kick" a player that is accepted.
Implement the existing UI to allow a GM to accept or reject a "pending" player.

Overview

After a user goes through the initial sign up process, the claims in [this rule}(https://github.com/mikelax/forgingadventures/blob/master/auth0/rules/add-custom-authorization-claims.js) are being added to the ID Token that is returned in the callback response.

I have validated with console.log statements that the rule is actually running, so there must be something different with the order of operations for how the tokens are created internally after a sign up vs. log in.

Here is an Auth0 community question looking for answers.

Overview

We need to finalize the ways we will allow users to create accounts on FA. We can select up to two OAuth providers in addition to email/password auth.

Providers that probably make the most sense: Google, Facebook, Twitch, Discord

Auth tutorial on setting up Google client credentials

Overview

There is currently a bug on the UI as to how it handles expired JWT tokens. If the UI thinks the user is still logged in (ie. cookies exist) but the token in the cookie is expired then currently the game messages errors out. This is due to it making graphql calls with the expired token instead of redirecting to the login page.

Requirements

I have run into this use case leaving my browser open. In this case I think the system that renews the token by hitting the /silent page should handle this, but there might be a bug in that logic.

Also, we probably should also have the UI itself set up to handle receiving unauthorized HTTP responses and redirecting back to the login page.

Overview

After a game has been created, the GM (or game owner if we are using that status) should be able to update the game details.

Requirements

• Extract the create game form into a component which can then be re-used in both the create game and edit game views.
• For this ticket, we can create the new page and routes for the "edit game" page, but do not need to create any direct links to it yet. We will do that once we implement a "My Games" section under the user profile.
• See the attached page mock, we will implement a basic tab menu to allow the user to edit the game details, player status, all from a single location.
  • The existing Players tab should be refactored into a component so it also can be used in two places, the existing Games page, and this new edit game page.

Page mockup

Overview

This issues relates to work done in #80.
After a new user signup, the user is taken to the almost finished page. They go through and fill out this form, after submitting they are taken to the /games page.
The issue is that the dropdown menu that displays the username doesn't update until a full page refresh. This should update after the almost finish page is saved.

For this test I didn't upload a profile image, so it displayed the default Auth0 profile image, but this should also update.

Overview

We want to refactor the existing editor that is currently used on the game lounge messages tab into a re-usable component.

Requirements

This component should be built in such a way that it can be used in any generic use case. This even includes using it outside the scope of a game. An example of this would be if we want to allow for a "rich" user profile, or for the purpose of the user requesting to join a game.

The editor should be able be to be instantiated with a blank textarea, specific ghosttext, or an actual default message.

As part of this change the existing editor on the game lounge messages tab should be changed to use this new component. A separate ticket will cover the work to use the component on the join game page.

Overview

We want to bring in the react-helmet package to allow components to set specific HEAD attributes about given pages.

Requirements

Set up a standard convention for how components should use the package, and which attributes we want to be changes for each "page".

Update the client README with a section describing the usage and patterns.

Overview

Now that we have replaced the UI widget layer from bootstrap to semantic in #62 , we need to remove the final lib that is used on the almost finished page. This lib react-bootstrap-timezone-picker should be replaced with react-select.

Requirements

Remove the react-bootstrap-timezone-picker and sibling react-bootstrap libs from the client.
Obtain a JSON file structure that contains all the standard timezones, that will store the tz data in the same format as the previous lib.

Here is an example where you can use the select component as a multi-select with custom rendering for the selected items, to be able to instead display closer to a material design "chip".

Overview

Currently any logged in user is able to edit a lounge or game message. this should be refactored so only the user that created the message should be able to edit.

Overview

After the new RichEditor has been created in #59 it should replace the existing textarea on the Join Game page. The editor will have some default text loaded, but the user will be free to add additional text to the message.

Requirements

Replace the textarea with the new RichEditor. There is a todo in the /Join/index.js to address this issue.
The editor should have the default text of:
Name has applied to join the Game!

Refactor the _submit function to also call the createGameLoungeMessageMutation mutation to create the new lounge message after the createGamePlayer mutation.

Overview

I found this bug while testing changes for #30 when trying to create a new game that will add a new record for the game-master to the game_players table.

After the game is created, the user is redirected back to the /games page as they are supposed to. Everything on the UI looks correct, the new game is displayed. There is a JS error though in the console.

NOTE - this was the first game created (added) after running the migration that clears out the games table

NOTE 2 - I created a second game and still received this JS error, but in this case the newly created game did not display. After a page refresh the second game was displayed.

JS Error in browser

bundle.js:165308 Error: Can't find field games({}) on object (ROOT_QUERY) {
  "games({\"offset\":0})": []
}.
    at readStoreResolver (bundle.js:1272)
    at executeField (bundle.js:90607)
    at bundle.js:90564
    at Array.forEach (<anonymous>)
    at executeSelectionSet (bundle.js:90559)
    at graphql (bundle.js:90554)
    at diffQueryAgainstStore (bundle.js:1304)
    at readQueryFromStore (bundle.js:1247)
    at InMemoryCache../node_modules/apollo-cache-inmemory/lib/inMemoryCache.js.InMemoryCache.read (bundle.js:993)
    at InMemoryCache../node_modules/apollo-cache-inmemory/lib/inMemoryCache.js.InMemoryCache.readQuery (bundle.js:1083)
    at update (bundle.js:214005)
    at bundle.js:3591
    at tryFunctionOrLogError (bundle.js:5684)
    at bundle.js:3591
    at InMemoryCache../node_modules/apollo-cache-inmemory/lib/inMemoryCache.js.InMemoryCache.performTransaction (bundle.js:1053)
    at DataStore../node_modules/apollo-client/data/store.js.DataStore.markMutationResult (bundle.js:3590)
    at Object.next (bundle.js:2553)
    at SubscriptionObserver.next (bundle.js:212985)
    at SubscriptionObserver.next (bundle.js:212985)
    at bundle.js:4188
    at <anonymous>

See this guide to configure github to automatically deploy rules to Auth0 based on commit hooks.

NOTE: this requires the Auth0 code for db connections, rules, and hosted pages to be kept in a separate repo, otherwise the rules code will need to be in a top-level folder called rules.

Overview

As a user, I want to be able to easily browse for Games based on several different search criteria. I should then be able to see a table of results that show basic game details.

A separate ticket will cover the work to handle the user clicking on a Game to view even more details, see the lounge thread, and apply to join the Game.

Requirements

• This page should be accessible with the user logged in or out
• The user should be able to perform a search to find games as logged out user
• The URL for this page should be: /games
• The browser tab (page) title should be: Search For RPG Play by Post Games
• The (h1) page title should be: Find a Game, start your Adventure
• Below the page title should be a container that displays the search options with a "Search" button.
• The search options will be:
  • Game Label - auto complete dropdown
  • Posting Frequency - dropdown
  • Text - textfield
  • Status - dropdown. values of:
    • Player Recruitment
    • In Progress
    • Adding Additional Players
    • Closed (may not be needed for v1)
• After executing the Search, the matching Games should be displayed in a grid below the Filter option container. The results should page in additional games as the user scrolls to the end of the viewport
• When the page first loads, the most recently created games should be displayed with a status of: Player Recruitment

The grid of games should display the following for each Game:

• Game Title
• Game Label
• Min / Max Players
  • Eventually Current Players
• Skill Level
• Posting Frequency
• First X words/characters of Overview

Future Considerations

• We may eventually display the Game GM User Profile Image, name for each game
• Either the Game title or a new icon will be added to allow the user to see all game details and view the game lounge

Related to #43.

Tasks

1. Refactor the top level client login, callback and almost-finished routes into a single login view with the callback and almost-finished as sub-routes.

2. Refactor this block of code to only be called in the new login/callback component as currently the Promise in the block of code never fulfils as the lock.on events only trigger durring the auth0 callback. Instead attempt to use webAuth.checkSession to auto login the user if their auth0 session is still active.

Overview

After a user login replace the logout button with the user image and username with drop down menu to include entries:

• Profile
• Divider
• Logout

We will then be able to add additional options such as Account, Games, etc. once they are ready to be implemented.

Requirements

use semantic dropdown option combined with dropdown.menu to create the menu items.

Here are some examples:
https://github.com/Semantic-Org/Semantic-UI-React/blob/master/docs/app/Layouts/FixedMenuLayout.js
https://react.semantic-ui.com/modules/dropdown

• Add stylus with rapture for media query sugar
• determine app wide grid levels taking into account react-router 4 nesting
• create game grid
• list games grid
• view game grid

Overview

After doing some reading on various tutorials and posts, I think that we will need to implement a users table in the main postgres database. This table will store the Auth0 user_id column, along with a set of metadata needed by the website to function and provide all data to the UI for display (ie. user profile image).

We will implement a similar solution as the community answer above that creates a two-way link between the pg users table and Auth0 users table.

Development Tasks

• Migration for pg users table & foreign keys
• Auth0 rule for login
• (Rest) API to create user record in pg table. Params of Auth0 user_id, user and app metadata, response of pg user id
• Add users seed and refactor games seed
• Refactor games and messages insert to include user id

Questions:

1. Do we need to create a user id (pk) attribute in pg table, or can we use the Auth0 user_id field as the primary key in the pg users table? Yes, we will use internal pg userId. It will be added to Auth0 app_metadata

I created this question on the Auth0 community site to see if I can get any better answers that what I was able to find from random googling.

Overview

There is currently a bug in the editor when the last line of text uses one of the style icons. In this use case, if the cursor is after this style block (ie. the very end of the message) and you hit the return key, a newline is inserted before the style block instead of after it.

This happens on both the initial message create, and also if you go back and edit a message.

Here is a sample message that shows the error use case.

Here is the first line of text.
singingHere is a singing line of textsinging

This same issue also happens with the new Quote feature. It appears to be related to block level items.
This plugin appears like it might provide the fix we need. The plugin requires this plugin framework for draftjs. The framework might be a nice win anyway as there are some other plugins we may want to use such as emoji, image, linkify among others (these plugins will be in a separate Issue).

Overview

Now that we have ejected from CRA, we'll need to make some tweaks to the client webpack config. We will also need to make some updates to the api webpack config as well.

Requirements

Update configs, @nazar to provide more info if required.

Client

TODO

API

Update the start script to set the NODE_ENV environment variable. When running in dev mode it should be set to "development".

I think that we will be able to set environment variables such as this when you run a Task (container).

Overview

After implementing the basic quote message in #38, we want to enhance the rendering of the quoted message.

Requirements

Add a small header on the top of the quote section. The ideal would be to contain text like: Previous Message from :Name. To make it easier for the MVP we could omit the name and just have text say: Previous Message. The header would have a slightly darker background color as the quote section color.

Overview

After a user completes the sign up process, they must be automatically added to the correct Role within Auth0. The process should be automated for general users that sign up for the site. Granting users the administer Role can be a manual task done through the Auth0 Dashboard as it will be an infrequent change.

Requirements

Document in the Auth0 README the process for making a user an "admin". ie. granting the Auth0 Administers role with the authorization extension.