Notifications should be easy to implement in existing routes, and they should work with Forum and chat both.

https://docs.google.com/document/d/1SSU6l7l6tRl1G0PQrd_ixpj-1Sb4IBGMRCayBg-Jw60/edit?usp=sharing

• Remove answers from the forum schema and add two fields: isAnswer (Boolean) and parentId(object_id)
• This logic treats a question and answer as being objects from the same schema. The only difference between a question and answer are isAnswer which will be true for and answer and false otherwise.
• if isAnswer == true then set parentId as questions object_id
  else if isAnswer == false then set parentId as null
• Make a mongoose pre-hook implementing the aforementioned logic (throw validation_error if not question/answer object is in an invalid format)

• Currently if you put "name": "Manchester United" it gets converted into "manchesterunited". Slug should replace space with dash (-). Maybe install Lodash package and use _.kebabCase() function., it'll solve the issue.

• Slug should be unique.

The page should contain the following components:

1. Navbar and Search components
2. Main section including University details such as location, GRE,TOEFL,IELTS scores required,average fees, recent admits, etc.

Refer the design link for further reference.
Use reusable components for navbar/searchbar and wherever applicable.

Github: apiDoc

Documentation can include the following annotations:

• @api for method, route, and 1 line description
• @apiName for naming a route
• @apiDescription, if required, for special routes or special notes.
• @apiGroup for each resource (Forum)
• @apiParam for the fields which can be passed in body or filter.
• @apiPermission, first use @apiDefine in auth middleware to define the user permission model, then use that in authRequired routes.
• @apiSuccessto define the fields in response document.

Avoid @apiError and @apiHeader for now.

• Add roles for user: 'Admin' (if roles array is empty, it means he/she is a normal user)
• Add user role authorization middleware to be used in routes
• middleware should be of the format eg:
  hasRoles(listRoles) {
  return function(req, res, next) {...};
  }
• add this middleware in routes for eg:
  routes.get('/', loginRequired, hasRoles(['Admin']))
• Also add roles as a key in JWT having value as an array of roles for that particular user

• Add a route to get all chats of a user.
• User should have access only to his own chats.

The following Page should have

1. Search bar
2. Navbar
3. A component dealing with the questions
4. Filtering options like Trending, by University etc

Refer the Design template for further reference.

Use reusable components for navbar/searchbar and wherever applicable.

Github: apiDoc

Documentation can include the following annotations:

• @api for method, route, and 1 line description
• @apiName for naming a route
• @apiDescription, if required, for special routes or special notes.
• @apiGroup for each resource (User)
• @apiParam for the fields which can be passed in body or filter.
• @apiPermission, first use @apiDefine in auth middleware to define the user permission model, then use that in authRequired routes.
• @apiSuccessto define the fields in response document.

Avoid @apiError and @apiHeader for now.

The page should have the components:

1. Navbar and Search component
2. Header section including Profile Pic, Personal Details, Social links, etc.
3. The main section should have 3 options:
   a] Profile
   b] University Applications
   c] Questions
4. Hence, 3 different pages required.

Refer the design link for further reference.
Use reusable components for navbar/searchbar and wherever applicable.

Schema would be this for now (subject to change in the future)

• question
  • titile: String
  • text: String
  • poster: ObjectId>User
  • createdAt: Date
  • updatedAt: Date
  • upvoters: [ObjectId>User]
  • downvotes: [ObjectId>User]
• answers: [Array of the following schema]
  • text: String
  • poster: ObjectId>User
  • createdAt: Date
  • updatedAt: Date
  • upvoters: [ObjectId>User]
  • downvotes: [ObjectId>User]
  • pinned: Boolean (default: false)

You'll have to add support as well. This includes the "auth required" middleware which will be used by others.

Schema would be this for now (subject to change in the future)

• email: String
• password: String
• biography: String
• graduationYear: Number
• socialLinks: [Array of the following schema]
• currentSchool: [ObjectId>Tag]
• accepts: [ObjectId>Tag]
• rejects: [ObjectId>Tag]
• pinnedQuestions: [ObjectId>Forum]

To return the updated docs, we have to add this option:

const user = await User.findByIdAndUpdate(req.user._id,req.body,{
    new : true
});

Add this to PUT request of Tags and Forum as well.

• Should have roles 'admin' for POST, PUT, DELETE
• All other users would get 403

/:id/upvote -> Append request user to upvoters
/:id/downvote -> Append request user to downvoters
/:id/pin -> If owner, add to user's pinned posts

Model Changes

Many to many relationship:

• Add followers: [ObjectID->User] to Tag model
• Add tagFollows: [ObjectID->Tags] to User model

Route Changes

/:slug/follow -> Adds tag._id to user's tagFollows, and user._id to tag's followers.
/:slug/unfollow -> Removes tag._id from user's tagFollows, and user._id from tag's followers.

PUT /tags/:slug

Schema would be this for now (subject to change in the future)

• persons: [ObjectId>User]
• messages: [Array of the following schema]
  • text: String
  • timestamp: Date
  • sender: [ObjectId>User]

For now add the following:

• Winston for logging, we need a good logging framework and pipeline. All logs should go on terminal as well as a file.
• Dotenv for environment variables. Make two dotenv files: .env and .env.development for when NODE_ENV=development.
• A pipeline for deploying using one command. Basically, a script file build.sh which would build react, and start the backend server.
• Add COR to express, only allow localhost:3000 for react.

Github: apiDoc

• Add a package.json script docs which will generate the documentation into a folder, docs/
• Serve the docs in express at route /api/docs
• Document Tag route first, then we can decide how to document the whole project.

Documentation can include the following annotations:

• @api for method, route, and 1 line description
• @apiName for naming a route (GetTagList, GetTagBySlug)
• @apiDescription, if required, for special routes or special notes.
• @apiGroup for each resource (Tag)
• @apiParam for the fields which can be passed in body or filter.
• @apiPermission, first use @apiDefine in auth middleware to define the user permission model, then use that in authRequired routes.
• @apiSuccessto define the fields in response document.

Avoid @apiError and @apiHeader for now.

Instead of having random strings as "tags" we can have tags which are monitored. So if there's a University or a Domain that becomes a tag for a question or a user. This would make managing the website much more easier with a single model, plus you have good support for autocomplete if you have a fixed database of tags.

Schema would be this for now (subject to change in the future)

• name: String
• isSchool: Boolean (default: false)

Using Mocha and Chai, test

• All HTTP endpoints
• SocketIO

• We should be able to fuzz search through an endpoint.
  See: https://fusejs.io or any other library which may be better.

It should fuzzy search through all of post's question attributes, and tags. Answers you can skip.

• Add Tags to Forum model. Forum post can have an array of Tags as objectID refs.

• Add special handling of filtering by tags in GET / of posts. Discuss this with us before implementing.

• Make a route and corresponding controller for getting all public user profiles

Github: apiDoc

Documentation can include the following annotations:

• @api for method, route, and 1 line description
• @apiName for naming a route
• @apiDescription, if required, for special routes or special notes.
• @apiGroup for each resource (Chat)
• @apiParam for the fields which can be passed in body or filter.
• @apiPermission, first use @apiDefine in auth middleware to define the user permission model, then use that in authRequired routes.
• @apiSuccessto define the fields in response document.

Avoid @apiError and @apiHeader for now.

Since the token expires in 1day, client should refresh the expired token without having to re-send the username/ password.

Make a route for this in user controllers.