hackillinois / api-2018 Goto Github PK

See: #21 (diff)

ES6 Supplies their own Promise which has a naming conflict with the current imports (var Promise = require...). We should change this as a good practice.

We need a systematic way to handle events, for both the mobile apps and dashboard.

The specifics are highlighted here.

I've already checked with @kpchi and @redsn0w422 to see if they are ok with the restrictions I've set in place.

Since Vincent (no GitHub account) has to work under iOS limitations, there is some nuances about how to pick Event/Location names and descriptions. We need some training or some documentation highlighting limitations.

Limitations:

• Event Names should be under 25 characters. Overflow should end up in the description.
• Event Locations should be under 25 characters. Overflow should end up in the description.

Currently there is no endpoint to allow users to assign other users roles, we want to eliminate manual role assignment by creating an endpoint which:

• Allows any NON_PROFESSIONAL or above user to modify the roles of other users
• A user should only be able to assign or remove a role equivalent to their role or below
  -e.g. A VOLUNTEER should not be able to assign a SUPERUSER role to a user
• Users should not be allowed to modify the roles of users who have a role higher than their own
• Users should not be allowed to assign staff roles to attendees, or mentors
• Users cannot use this functionality if they are using the user impersonation utility
• Users can't modify their own roles

Reviewers will also need the ability to apply a decision to an applicant. This will most likely involve assigning the applicant an application state (pending, accepted, waitlisted, rejected), recording the reviewer, and assigning the applicant to a notification wave.

We will need to discuss exactly how much reviewer information we want to store. For example, should we only store who modified the decision last, or should we have who changed which portion of the decision?

This resource should only be available to properly-roled users. It will likely work in parallel with the socket microservice to keep clients alert about changes made to an applicant (without either system needing to know about the other directly).

A big thing that was left our of feature/basics was the functionality by which users will be able to reset their passwords. When users start registering, we'll really need to have this ready.

This feature should be added to the UserService and an endpoint should be added to the UserController as a POST/GET (the assignee should use his/her judgement). The endpoint should only be available to registered users who are trying to reset their own passwords, and a reset token will need to be created and sent to the user via email.

To avoid creating a ton of unnecessary reset tokens, there should be an expiration date for each token (configured via the global configuration) and a new token should be proceeded by the deletion of any old tokens. It is a good idea to add an enum Type to these tokens, which will give a reason for their existence. This one might be Auth.

Running npm run dev-migrations on a Machine running Ubuntu 16.04.1 LTS fails with this error:

$ ~/hackillinois/api-2017/$ npm run dev-migrations

> [email protected] dev-migrations /home/fa16-cs427/hackillinois/api-2017
> source resources/scripts/env.sh dev && ./database/flyway.sh migrate

sh: 1: source: not found

npm ERR! Linux 4.4.0-34-generic
npm ERR! argv "/usr/bin/nodejs" "/usr/bin/npm" "run" "dev-migrations"
npm ERR! node v4.2.6
npm ERR! npm  v3.5.2
npm ERR! file sh
npm ERR! code ELIFECYCLE
npm ERR! errno ENOENT
npm ERR! syscall spawn
npm ERR! [email protected] dev-migrations: `source resources/scripts/env.sh dev && ./database/flyway.sh migrate`
npm ERR! spawn ENOENT

In other words, source is not found when running sh rather than bash, although we ran the command from bash.

However, running source resources/scripts/env.sh dev && ./database/flyway.sh migrate manually in bash runs fine.

Potential fixes could be explicitly stating npm to use bash rather than sh.

Before the Hackathon's application opens, we need a system to collect emails so we can notify potential attendees when the event status changes (such as when applications open).

This would be a plain list of emails, and to query these emails you would need either the ADMIN's or the STAFF's permission.

We could also build this on top of the current User model, by creating default user passwords for everyone. However this would cause confusion when the user comes back to submit an application, as it would seem as if the user already created an account with the backend.

My recommendation would be creating a new interest model, where we curate the emails of people who are interested.

I think there is some sort of password requirement (length+needs numbers and letters etc.) ? But that is not stated anywhere. Either that or sometimes my request to reset my password just was not going through.

The admissions team will need to be able to add projects and attach mentors in order to make attendee registration work the way we want it to work. This issue will deal with how that is handled.

The implementation should proceed as follows:

• Create a Project model
  • id (INT, Required)
  • name (VARCHAR 100, Required)
  • description (VARCHAR 200, Required)
  • repo (VARCHAR 255, Required)
  • is_published (TINYINT 1, Default=0)
• Crete endpoints to allow for project creation/retrieval/update
  • POSTs should create a project (STAFF+)
  • GETs should retrieve the project (any authenticated user)
  • PUTs should update the project (STAFF+)
• Create a ProjectMentor model
  • id (INT, Required)
  • project_id (INT, FK Project.id, Required)
  • mentor_id (INT, FK Mentor.id, Required)
• Create endpoints to allow for mentor assignment/removal
  • POSTs should query for the project-mentor combination to make see if it already exists (like MailingList and UserRole does) and return any results. Otherwise, create the project mentor
  • DELETEs should remove a mentor from the project

Note that this does not handle the suggestion of projects by attendees. Please comment with any questions or suggestions.

There isn't any documentation on the different user roles and the endpoints that are available to them.

These are things that we want to clean up that are a little more complex and may need additional discussion before implementing

• No longer handle file uploads, and instead replace it with signed URIs or something similar
• Revisit attendee review endpoints
• Determine attendee model makeup from API configuration
• Move config-like utils into config

Right now, almost all of our API routes touch the database. As we continue building, I'd like to add a caching layer to cut down on the number of queries we need to make on frequently-accessed data. This will also give us the chance to add rate-limiting to the API as well.

The implementation I see is as follows:

• Create a CacheService to handle all caching operations
  • We should be able to at least create, fetch, update, and expire keys
  • We should support a local Redis cache for developers (i.e. those without an active AWS SDK), and use ElastiCache when available (i.e. in production)
• Add caching operations to existing API components
  • Assuming this is finished after registration, it would be nice to at least cache the responses of registration information
  • Feel free to use your judgement with this point

Overall, this should be a pretty straightforward feature, but it will come in handy very quickly.

Currently we don't properly utilize the active bit associated with a user's role

• We should begin using the active flags on user roles to permit actions based on their role(s)

The current API configuration assumes that HackIllinois is the only organization that will use it, the configs should be made to be more abstract so other Hackathon's can use the API

From a user experience standpoint the fact that we make all hackers create an account specifically for HackIllinois for 3 key interactions that are spread roughly 2 months apart from each other is kind of hard to justify. It will be a smoother interaction over the course of their time with us if they use their githubs to sign in.

1. it will be an account that people will remember
2. if the user does not have a github but wants to come to a hackathon let alone an open source hackathon they probably should have one.
3. login becomes 1 click (max 2 for first time)

If we implement this remember to add a way to change the default email, some people don't use the email associated with their github

Before we move on to actually creating the registration endpoint(s), we need the ability to add users to our mailing lists.

A big problem last year was having to query for and send emails to certain types of users. For example, if we wanted to send an email to all hackers accepted to the hackathon, we had to query for selected hackers and then send an email to each one. Instead, we'd like to be able to just send an email to one list and let our mail server handle the rest.

We will decide exactly what will be proving our mailing service during the development of this feature. For now, it suffices to build a service/client that will be able to add/remove a user to a certain list (where the client maintains a list of available lists). Some potential lists are:

• unregistered hackers
• registered hackers
• staff
• volunteers

Note that there will be an API key for whichever mailing service we choose. The service/client that is built should be sure to handle this by reading a key from the global configuration.

This feature will probably be fleshed out after a little more discussion

• The API should be able to ensure that external dependencies such as mailing lists already exist, and if not it should create them on startup

It might be a good idea to add this now before the API gets bigger. I have begun doing this in a separate branch (will prob keep it as a feature branch). My current thoughts are to use Chai and Mocha due to their easy HTTP request libraries, although I'm sure things like Jasmine would work fine as well. My current format is shown below:

├── test.js
├── auth
└── user
    ├── accredited.js
    └── index.js

Where test.js is the main test spec which pulls in tests from auth and user (which respectively test auth and user functionality, and accredited tests user functionality for accredited users). This is just the workflow I have set up right now and there is much room for change.

In general, reviewers will want to be able to access the applicants in a listing format. This will give them a limited amount of information for each applicant about which they can query, sort, and select. These resources should be reasonably compatible with some client-side table format. We will not design these resources off of a specific format, but it is a good thing to keep in mind the context of use.

It goes without saying that these resources should also be restricted to the proper roled users. We will need to discuss exactly which roles are allowed.

Do we want to enforce reviews via codeowners?

cc @nmagerko @YashoSharma

One of the recruiter utilities we want to provide is the functionality for recruiters to be able to scan someones qr code while talking to them and save their info so they can use it later.

• Endpoint to allow users with Recruiter permissions to be able to scan user QR code
• Recruiters can fetch the resumes of users they've scanned
• Recruiters from a company can fetch the resumes of all users their companies recruiters have scanned

The statistics we keep track of are currently generated on-demand and are then cached for a period of time. Ultimately, we should keep track of our statistics as they change, making it so that we'd (at worst) only ever have to compute our statistics once at the time of this enhancement's deployment.

Expectations for a good implementation might include:

• Rewriting the StatsService to write stats updates to the redis store and write-through to a stats database table
• Rewriting the StatsService to remove all joins and instead read from the redis store, pulling from the stats table only when necessary
• Deciding on new stats that we should be collecting

Note that we operate on multiple instances, so this implementation should be mindful of introducing race conditions into the stats aggregator.

Previously, all registration-related functionality was placed under issue #7. The evolution of the API has made it necessary to break up the registration milestone further into specific issues.

This issue will deal with applicant registration. This will need to come after the completion of #38 as one of the models associated with this feature uses the Project model. Regardless, the implementation should proceed as follows:

• Create an Attendee model
  • id (INT, Required)
  • user_id (INT, Required)
  • first_name (VARCHAR 255, Required)
  • last_name (VARCHAR 255, Required)
  • shirt_size (ENUM[S, M, L, XL], Required)
  • diet (ENUM[NONE, VEGETARIAN, VEGAN, GLUTEN_FREE], Required)
  • age (TINYINT, Unsigned, Required)
  • transportation (ENUM[NOT_NEEDED, BUS_REQUESTED, IN_STATE, OUT_OF_STATE, INTERNATIONAL], Required)
  • school (VARCHAR 255, Required)
  • major (VARCHAR 255, Required)
  • gender (ENUM[MALE, FEMALE, NON_BINARY, OTHER], Required)
  • is_novice (TINYINT 1, Default=0)
  • professional_interest (ENUM[INTERNSHIP, FULLTIME, BOTH], Required)
  • github (VARCHAR 50, Required)
  • interests (VARCHAR 255, Required)
  • status (ENUM[‘ACCEPTED’, ‘WAITLISTED’, ‘REJECTED’, ‘PENDING’], Required, Default=’PENDING’)
• Create an AttendeeRequestedCollaborator
  • id (INT, Required)
  • attendee_id (INT, Required)
  • collaborator (VARCHAR 255, Required)
• Create an AttendeeExtraInfo model
  • id (INT, Required)
  • attendee_id (INT, FK Attendee.id, Required)
  • info (VARCHAR 255, Required)
• Create an AttendeeProject model
  • id (INT, Required)
  • attendee_id (INT, FK Attendee.id, Required)
  • name (VARCHAR 100, Required)
  • description (VARCHAR 150, Required)
  • repo (VARCHAR 255)
  • is_suggestion (TINYINT 1, Required)
• Create an AttendeeProjectInterest model
  • id (INT, Required)
  • attendee_id (INT, FK Attendee.id, Required)
  • type (ENUM[‘CREATE’, ‘CONTRIBUTE’, ‘SUGGEST’], Required)
  • project_id (INT, FK Project.id)
  • attendee_project_id (INT, FK AttendeeProject.id)
• Create endpoints for create/retrieve/update of attendee registration
  • POSTs should create an attendee (max 1 per user) and add to role list (any authenticated user). The request should take attendee, collaborators, extras, projects, and interests keys, all required.
    • attendee should take all fields in the related model excluding sensitive fields (e.g. status)
    • collaborators should take a list of up to 8 attendee-requested-collabor models/fields (excluding the attendee key, which will be added upon attendee creation)
    • extras should take a list of up to 5 attendee-extra-info models/fields (excluding the attendee key again)
    • projects should take up to two attendee-project models/fields. One of which may have is_suggestion = 0 and the other of which may have = 1. There may never be two of the same type
    • interests should take up to (5 - projects) models/fields of attendee-project-interests. Require all fields except attendee_project_id -- all things listed in projects will need to be automatically linked/created as an interest as well
  • GETs should retrieve all information (joined in) with basically the exact same format as POST (Owner or SPONSOR, MENTOR, STAFF+). It should also include a resume field with the Upload object containing the user’s resume
  • PUTs should be the same as POSTs, but atomic for all sub-fields. attendee should be the only required sub-field, with the presence of any other sub-field requiring an atomic update (delete all present instances and re-instantiate)

Note that I'm still a bit unsure about how we'll be dealing with the status. I believe we might need to break acceptance/waitlisting off into another feature, as we will be handling that in a sort of RSVP-esque format where confirmation of a project is required from the applicant. I'll update this when I get more information.

Please comment with any questions or suggestions.

hackillinois-2017 makes sense for our naming conventions but makes things painful for the user to setup. Both flyway and mysql get mad about having the db named hackillinois-2017 and while I could get around the issues in mysql, flyway took more time than I wanted to spend so currently I am using a db named hackillinois.

Personally I think that there are 2 options here:

1. use a more complacent db name
2. add documentation on how to get around it.

If the answer is path 2, the flyway script needs to be updated to better handle the db name because I get an error right now

npm ERR! Darwin 15.5.0
npm ERR! argv "/usr/local/Cellar/node/6.2.2/bin/node" "/usr/local/bin/npm" "install"
npm ERR! node v6.2.2
npm ERR! npm  v3.9.5
npm ERR! code E404

npm ERR! 404 Registry returned 404 for GET on https://registry.npmjs.org/winnie
npm ERR! 404
npm ERR! 404  'winnie' is not in the npm registry.
npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
npm ERR! 404 It was specified as a dependency of 'hackillinois-api-2017'
npm ERR! 404
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/shotaro/ios/iphone-2017/api-2017/npm-debug.log

Seems like winnie isn't a default package on NPM, there must be some kind of instruction missing in the docs.

Another feature we'll need as we work our way towards registration is a storage integration. At a minimum, we use a storage service to keep things like resumes that are uploaded during registration.

We usually need to enforce a file size maximum (which can be set/read via the global configuration) and the files themselves have to correspond to a specific storage bucket. Depending on the provider we choose, we might have to make sure that filenames are unique, too.

There will need to be a service for adding/retrieving these files, as well as endpoints for uploading/downloading these files. Uploading should be available to any registered user, but downloading should only be available to content creators and administrators/staff. We might also permit access to certain sponsors later on, but that remains to be discussed.

The API uses module-level imports to initialize its components. For example, the database needs a logger instance and a configuration, and these objects are imported directly into the database module.

The problem with this is that some of these objects may have dependencies that can cause problems if everything isn't initialized in the correct order. For example, if the configuration isn't properly initialized/imported before the logger, then the database may find itself logging with an improperly prepared logger.

To solve this, we are currently importing everything in the correct order for the first time in api.js. I think it would be better if we instead had a bootstrap module that initializes an application context. The context would then be passed to all modules that require these components.

We need a way to log meaningfully in a production environment. Right now, we have a logging.js that simply exports the default CLI logger from the winston NPM package. Instead, we should export the appropriate logger for the environment.

Ultimately, we need someone to do a bit more research into how this should work, and then implement their findings. We will probably need to write our logs to a dedicated storage space as they will fill up quickly, and we will also want to add a bit more verbosity (tagging which lines of the log output belong to which request will be necessary, along with the route of the request itself).

Please comment below if you're interested in taking this issue.

Currently the documentation is only stored on the GitHub wiki, it would be ideal if the documentation was moved to an easily editable location, e.g. a docs folder

This will be the primary feature for interaction between hackers and organizers/mentors at the event.

At the very least, it will allow attendees to interact with mentors by allowing them to request help while also allowing mentors the ability to respond to these requests. However, we might consider generalizing this into a way for hackers to get help about anything. For example, hackers might be able to interact with operations staff as well -- perhaps something has gone wrong and an organizer needs to help out.

The involvement of non-mentors in this feature is up for discussion.

There are several things that are good things for beginners looking to get used to the codebase to undertake.

• Replace the find->then->ifNotNull->create Promise pattern when saving new data by using the database response to determine if a model exists
• Standardize endpoint names and conventions
  • GET /all for getting all, etc
• Refactor the events model
• Reduce stats inner queries to joins

We need a way to check which instances of our application are healthy. This endpoint should be very simple, just returning a 200 OK when requested. As such, the details are as follows:

• Create an endpoint at /health
  • GETs should return immediately with a 200 OK
  • All other requests should be ignored

This seems like a great issue for new contributors to tackle.

The two main security changes that we want to make are:

• Signing auth tokens with user specific keys to permit invalidation of existing tokens (this will need further discussion)

As part of how we handle help requests, we will probably want to allow those individuals requesting help to interact with mentors/organizational staff without necessarily having to go find someone in-person.

How exactly we want to implement this is up for discussion, although we have discussed just creating chat functionality via SocketIO. I am a bit wary about following through with this implementation, since creating a completely functional chat application seems a bit extreme. Perhaps we could make use of existing infrastructure instead (a mentor Slack, a Slack integration, pre-defined messages, etc).

It would be useful for admins to be able to enable/disable endpoints

• Endpoints to manage access to the controller
• DB table to store states of controllers (PK of controller name, and Bit for boolean)
• Cache the states on startup, and expire them when the state is changed
• If a state is not cached when accessed reread it from the db
• Middleware to process requests/handle invalid requests
• Use an EndpointNotAvailableError on failure

We are currently only able to create Attendees by email. We also need to be able to create Administrators, Staff, Volunteers, Mentors, and Sponsors (although these roles may change as event planning continues).

The role of the requester will need to be considered upon receiving the request. For example, a Hacker cannot make a request to the new endpoint to create an Administrator (that would be dangerous). Instead, it should be the case that Administrators can create any type of user and Staff can create any type of user except for Administrators (and perhaps other Staff).

In the wiki, the endpoint GET /v1/user/{:id} is allowed for ADMIN or STAFF roles, however, the current middleware permissions module only lets this endpoint be accessed by the user with the requested ID (i.e. if user with ID 2 goes to /v1/user/2). Is this the desired behavior or should it be in line with what is in the wiki?

Relevant files:

• middleware.permissions
• controllers.userController

We want to implement some form of rate limiting to the api, this should be a simple addition and ideal for new contributors to the codebase.

• Rate limit requests to the api

Accepted applicants will need to tell us whether or not they are coming to the event. In doing so, they will allow us to find out whether or not we need to admit more waitlisted applicants, expand our resources for the event, and so on.

The feature itself will be rather basic, providing the ability to select whether or not the applicant will be attending, how the applicants will be arriving (transportation), and updating any related statistics. Attendees should also be added to the appropriate mailing list(s).

When running our tests on Travis-CI the database pool is destroyed causing an error to be thrown

Knex:warning - Pool2 - Error: Pool was destroyed
Knex:Error Pool2 - Error: ER_ACCESS_DENIED_ERROR: Access denied for user ''@'localhost' (using password: NO)
Unhandled rejection Error: Pool was destroyed
    at Pool._destroyPool (/home/travis/build/HackIllinois/api-2017/node_modules/knex/node_modules/pool2/lib/pool.js:560:20)
    at Pool.<anonymous> (/home/travis/build/HackIllinois/api-2017/node_modules/knex/node_modules/pool2/lib/pool.js:474:18)
    at Pool.<anonymous> (/home/travis/build/HackIllinois/api-2017/node_modules/knex/node_modules/pool2/lib/pool.js:517:17)
    at tryCatcher (/home/travis/build/HackIllinois/api-2017/node_modules/bluebird/js/release/util.js:16:23)
    at Promise.errorAdapter [as _rejectionHandler0] (/home/travis/build/HackIllinois/api-2017/node_modules/bluebird/js/release/nodeify.js:35:34)
    at Promise._settlePromise (/home/travis/build/HackIllinois/api-2017/node_modules/bluebird/js/release/promise.js:564:21)
    at Promise._settlePromise0 (/home/travis/build/HackIllinois/api-2017/node_modules/bluebird/js/release/promise.js:612:10)
    at Promise._settlePromises (/home/travis/build/HackIllinois/api-2017/node_modules/bluebird/js/release/promise.js:687:18)
    at Async._drainQueue (/home/travis/build/HackIllinois/api-2017/node_modules/bluebird/js/release/async.js:138:16)
    at Async._drainQueues (/home/travis/build/HackIllinois/api-2017/node_modules/bluebird/js/release/async.js:148:10)
    at Immediate.Async.drainQueues [as _onImmediate] (/home/travis/build/HackIllinois/api-2017/node_modules/bluebird/js/release/async.js:17:14)
    at processImmediate [as _immediateCallback] (timers.js:383:17)
Unhandled rejection Error: Pool is destroyed
    at Pool.acquire (/home/travis/build/HackIllinois/api-2017/node_modules/knex/node_modules/pool2/lib/pool.js:162:12)
    at /home/travis/build/HackIllinois/api-2017/node_modules/knex/lib/client.js:268:29
    at Promise._execute (/home/travis/build/HackIllinois/api-2017/node_modules/bluebird/js/release/debuggability.js:299:9)
    at Promise._resolveFromExecutor (/home/travis/build/HackIllinois/api-2017/node_modules/bluebird/js/release/promise.js:481:18)
    at new Promise (/home/travis/build/HackIllinois/api-2017/node_modules/bluebird/js/release/promise.js:77:14)
    at Client.acquireConnection (/home/travis/build/HackIllinois/api-2017/node_modules/knex/lib/client.js:264:21)
    at /home/travis/build/HackIllinois/api-2017/node_modules/knex/lib/runner.js:188:47
    at Promise._execute (/home/travis/build/HackIllinois/api-2017/node_modules/bluebird/js/release/debuggability.js:299:9)
    at Promise._resolveFromExecutor (/home/travis/build/HackIllinois/api-2017/node_modules/bluebird/js/release/promise.js:481:18)
    at new Promise (/home/travis/build/HackIllinois/api-2017/node_modules/bluebird/js/release/promise.js:77:14)
    at /home/travis/build/HackIllinois/api-2017/node_modules/knex/lib/runner.js:187:35
    at tryCatcher (/home/travis/build/HackIllinois/api-2017/node_modules/bluebird/js/release/util.js:16:23)
    at Function.Promise.attempt.Promise.try (/home/travis/build/HackIllinois/api-2017/node_modules/bluebird/js/release/method.js:39:29)
    at Runner.ensureConnection (/home/travis/build/HackIllinois/api-2017/node_modules/knex/lib/runner.js:186:39)
    at Runner.run (/home/travis/build/HackIllinois/api-2017/node_modules/knex/lib/runner.js:41:44)
    at QueryBuilder.Target.then (/home/travis/build/HackIllinois/api-2017/node_modules/knex/lib/interface.js:32:43)
    at QueryBuilder.tryCatcher (/home/travis/build/HackIllinois/api-2017/node_modules/bookshelf/node_modules/bluebird/js/main/util.js:26:23)
    at doThenable (/home/travis/build/HackIllinois/api-2017/node_modules/bookshelf/node_modules/bluebird/js/main/thenables.js:52:38)
    at tryConvertToPromise (/home/travis/build/HackIllinois/api-2017/node_modules/bookshelf/node_modules/bluebird/js/main/thenables.js:30:20)
    at Promise._resolveCallback (/home/travis/build/HackIllinois/api-2017/node_modules/bookshelf/node_modules/bluebird/js/main/promise.js:445:24)
    at Promise._resolveFromSyncValue (/home/travis/build/HackIllinois/api-2017/node_modules/bookshelf/node_modules/bluebird/js/main/method.js:41:14)
    at Sync.insert (/home/travis/build/HackIllinois/api-2017/node_modules/bookshelf/node_modules/bluebird/js/main/method.js:17:13)
    at null.<anonymous> (/home/travis/build/HackIllinois/api-2017/node_modules/bookshelf/lib/model.js:1009:36)
    at tryCatcher (/home/travis/build/HackIllinois/api-2017/node_modules/bookshelf/node_modules/bluebird/js/main/util.js:26:23)
    at Promise._settlePromiseFromHandler (/home/travis/build/HackIllinois/api-2017/node_modules/bookshelf/node_modules/bluebird/js/main/promise.js:510:31)
    at Promise._settlePromiseAt (/home/travis/build/HackIllinois/api-2017/node_modules/bookshelf/node_modules/bluebird/js/main/promise.js:584:18)
    at Async._drainQueue (/home/travis/build/HackIllinois/api-2017/node_modules/bookshelf/node_modules/bluebird/js/main/async.js:128:12)
    at Async._drainQueues (/home/travis/build/HackIllinois/api-2017/node_modules/bookshelf/node_modules/bluebird/js/main/async.js:133:10)
    at Immediate.Async.drainQueues [as _onImmediate] (/home/travis/build/HackIllinois/api-2017/node_modules/bookshelf/node_modules/bluebird/js/main/async.js:15:14)
    at processImmediate [as _immediateCallback] (timers.js:383:17)
  23 passing (3s)
The command "npm test" exited with 0.

Maybe the db needs to be mocked in the tests?
@michaelcolomb @nmagerko

Currently our attendee model, and the associated service are quite monolithic cleaning this up requires us to:

• Break attendee information into multiple models
• Remove unnecessary models, e.g. extra info

Previously, all registration-related functionality was placed under issue #7. The evolution of the API has made it necessary to break up the registration milestone further into specific issues.

This will deal with mentor registration. The implementation should proceed as follows:

• Create Mentor model
  • id (INT, Required)
  • user_id (INT, FK user.id, Required)
  • first_name (VARCHAR 255, Required)
  • last_name (VARCHAR 255, Required)
  • shirt_size (ENUM[S, M, L, XL], Required)
  • github (VARCHAR 50)
  • location (VARCHAR 255, Required)
  • summary (VARCHAR 255, Required)
  • occupation (VARCHAR 100, Required)
  • status (ENUM[‘ACCEPTED’, ‘WAITLISTED’, ‘REJECTED’, ‘PENDING’], Required)
• Create MentorProjectIdea model
  • id (INT, Required)
  • mentor_id (INT, FK mentor.id, Required)
  • link (VARCHAR 255, Required)
  • contributions (VARCHAR 255, Required)
  • ideas (VARCHAR 255, Required)
• Create endpoints to allow for create/retrieve/update of mentor registration
  • POSTs should create a mentor (max 1 per user) and add to role list (any authenticated user). The request should take a mentor and ideas key (both required).
    • mentor should take all fields in the related model excluding sensitive fields (e.g. status)
    • ideas should take a list of project ideas (at least 1, max 5).
  • GETs should retrieve information with project ideas joined-in (Owner or STAFF+ only)
  • PUTs should update information (Owner can update anything but mentor.status and STAFF+ can update all).
    • ideas changes should be atomic, so if the ideas key is present (and only if it is present!) delete all existing ideas and create new ones with the given information.
    • Note this means that only the mentor key is required
• Update documentation
• Add tests (if testing framework is available by time of code review)

Additionally, note that when the mentor is accepted, they are to be added to the mentors' mailing list. If their status changes, they should be removed from that list. Please respond with any questions.

We ultimately need the functionality that lets users give us their registration information, or update existing registration.

All types of users can register. Hackers are the most complex registration type, as they have a lot of information to give us. Most other types of users will simply need to fill out some basic information such as their first and last names. We will decide on exactly what information will need to be given by which users when we get to this feature. The assignee should probably be a HackIllinois staff member so that we can discuss that aspect.

The structure of the registration is important. There should be separate tables for Administrators, Staff, Hackers, etc. These should have a foreign-key pointing back to the users table so that we can easily join data back onto the main user.

Don't forget to add/remove the user to the appropriate list(s) after registration. There should also be separate POST/PUT endpoints for registering and updating registration information, respectively.

Before we finish registration, we should address a potential security concern involving our authentication tokens.

The current authentication token holds a user's role. This is useful for the client, as it means that we do not have to make a request to get more information about a user's permissions in most cases. However, our authentication tokens cannot be expired at-will, which presents a problem.

Specifically, even if a user is demoted in role, he/she will continue to have the role that was previously signed into the authentication token until that token expires. Moreover, the server does not currently verify that the token it receives has a role that matches the persisted role, so it would be very easy to exploit this issue.

To fix this, we will remove the role from the authentication token and always query for the user presented in the token in the authentication middleware handler on the API. To ensure that we are not making more queries than we need, we will also modify the middleware to place the returned user onto the request object.

We want to enable admissions by team based review, the specifics of this feature will be discussed later.

In addition to the ability to view and applicant and make a decision, reviewers will also appreciate some help in getting the process done. It is expected that a portion of the review process will not be random, so certain API utilities will be necessary to be sure that we can help the reviewers out.

There has been some discussion already about the potential of providing resume summaries in addition to metrics related to how applicants compare to one another based on a variety of criteria. I would like to have that discussion here along with ideas for how we would implement these utilities and/or what existing libraries we could use to do so.

We need to figure out a name for the API (the current name isn't even valid anymore anyways). Let's start thinking of names and listing them here. I'll post some soon too.

Password Reset Form has incorrect text which is very confusing. It's also hard to tell if the request has gone through - some sort of confirmation message would be great.

The necessity to complete features for HackIllinois 2017 resulted in features without unit tests being merged into the codebase. In order to standardize the tests the following standards should be enforced:

• All service methods test appropriate inputs and edge cases
• Services that touch the datastore or cache should have tests that use the mocked resources rather than stubbing them (This issue is predominantly present in older tests)

As of now in order to get notifications mobile devices have to pull them from the api. It would be a lot more ideal if we used a push system for notifications instead.