siggame / colisee-lib Goto Github PK

Error handling middleware should:

• Accept any base error and turn it into a 500 and return it
• Accept any http-error and return it
• Log any non 5XX messages as debug or similar level
• Log any 5XX messages as critical or similar level

The logging middleware should:

• Log the following information as debug or similar level:
  • Requesting IP
  • Requesting Method
  • Requesting Path (including query params)
  • Request body size

Update .travis.yml to use travis-ci support for auto deploying github pages. Also include .nojekyll to force rendering of files with _ as a prefix.

We need to add three more columns to the teams table in the database. They shouldn't affect any other tables.

• a "salt" column that contains a string
• a "hash_iterations" (or similar name) column that contains a number
• a "role" column that can have the values ["user", "admin"]
• a "contact_name" column that contains a string

Please let me know if there is anything else you need to know

https://palantir.github.io/tslint/2016/03/31/sharable-configurations-rules.html

Survey common helper functions used in colisee services along with other common functionality used and add them to this library. Reduces number of places that need to be touched when an api changes and reduces the chances for helpers and other ad hoc functionality from being implemented incorrectly between services.

The website is going to need some new tables and shift around the team table a bit to support new features that we want to have before MegaMiner. These changes should integrate a user + team system, instead of the teams just being synonymous with users, as well as adding a submissions metadata table that may have more added on later

From looking at previous commits I think I should hopefully be able to tackle this myself and put up a PR, but I still would appreciate some input on it, especially some of the data types

Worth noting, I don't think these changes should/could be pushed to chess.siggame.io. We could argue that the submissions_metadata could be put there (and maybe it should?) but I have a feeling that it will cause some unforeseen problems trying to set up the new table on the already existing database.

Existing tables

teams

• Where team_captain is a foreign key to the users table.
• The teams table no longer needs any of the user specific information, and we decided that whoever creates the team will become team captain and will be the one who can send out invites to the team.
• I am not sure what the best type would be for the profile_pic column, any input?

New Tables:

users

• This is the new users table, the only new entry really is the form_response field, which we figured is where we would put the responses to the form that asks shirt size and pizza preferences, that way we don't need to make database changes if the questions change.
• Edit: I also added an 'active' field for email verification so they have to click on their email to activate their account

teams_users

• Where team_id and user_id are foreign keys to their respective tables. This is to reference which user is on which team

invites

• These are where the invites will go, whenever someone invites another person onto their team it is stored in here, the is_completed field is to show whether or not the invitation has been accepted or rejected.

submissions_metadata

• Where submission_id is a foreign key to the submissions table
• This table will be for meta data that users add on to their submissions. For now the only thing we have to add is a label and a color for the label, but there is room for expanding this later on.
• Is there a more appropriate type for the label_color ? It will likely just be a hex code, but after some research I didn't find a standard way to store that.

A nice feature for when doing something like

const game: db.Game;
`${game}`

since it gets called implicitly.