# Project Challenge: MongoDB and Express ## CoderManagement CoderManagement is a platform that helps individuals and teams manage their tasks. These are more than just simple to-do lists. Task management tools allow teams to collaborate digitally by organizing, prioritizing, and assigning tasks to each other. <details> <summary><strong>So what exactly does a task management software do?</strong></summary> As with most softwares, there is a range of complexity and technological advancement among different systems. With that being said, typical features include: 1. **Task scheduling** to set deadlines in advance. 2. **Task customization and editing** to update for specific situations. 3. **Task assignment**, which may include internal coworkers, external partners, or both. 4. **Notifications/Alerts** to remind users about upcoming tasks and responsibilities. 5. **Recurring tasks or templates** to standardize repetitive steps in your workflow. 6. **Sub-tasks or parent tasks** to create additional steps within a task. 7. **Time Tracking** to record the amount of time spent on tasks. 8. **Progress reporting** to track current positioning in regards to the overall goal. 9. **Task organization** using tags to prioritize the tasks. 10. **To-do lists** for easy task visualization. That’s a lot! The actual task management system is quite large for us at the moment. But we can utilize our knowledge to achieve a few features from it. To be specific, let’s implement features 1, 3, and 9 in our app. </details> ## Overview You’re the CEO of a small tech start-up company. After a while, you realize that you need a system that can keep track of the tasks and improve productivity. As this is just an internal mini-project of the company, your goal is also to keep the cost low. Remembering your amazing time at CoderSchool learning how to code, you roll up your sleeves and start up your Visual Studio Code. As a wise programmer, you started off planning for an MVP (Minimum Viable Product). For the **first phase** of this product: ### Entity relationship diagram You came up with this design ![ERD](https://i.imgur.com/5G9toaC.png) ### Features You have decided for this first phase of the application that: - You are the only manager who assign task - Your team members are employee - Your team members could sign up for an account with their name and become employee by default - You will create, assign and delete tasks to other users - **A user may have one, many, or no task he/she responsible for.** - **A task may have one or no one asign to it yet** - Right now you are the only user of this project, so no authentication needed ## Description Everyone who uses the app is a user. there are 2 roles for user: **employee** and **manager** You are the user that have higher authority in the company ( later could be other managers). This hierarchy of roles allows us to limit access to certain features in the application that only the `manager` has permission. However, at this stage, you just want to warm up your coding skills and make the most straightforward version as fast as possible. ### End points requirements For now, **your account** will be created through *Compass* with the role: `manager` Design your routes so that from a client app, you can: #### User 1. Create a new user with user’s **name**. Default **role** is `employee`. 2. Get all users with filters. You can decide yourself which queries you allow in the request based on the **User schema**. 3. Search for an employee by name 4. Get all tasks of 1 user *(Decide which one is better: by **name** or by **id**?)* #### Task 5. Create a task with the required information. 6. Browse your tasks with filter allowance (name, status, createdAt,…). The following attributes are required to help filtering tasks by `status`, and help sorting by `createdAt`, `updatedAt` - `status` - `createdAt`,`updatedAt` 7. Get a single task by id. 8. Assign a task to a user or unassign them 9. Update the status of a task. There's a **rule for updating task status**: when the status is set to `done`, it **can’t** be changed to other value except `archive` 10. Soft delete a task. *Remember how you did this in previous assignments?* 11. **Research and Apply**: In backend development, input validation is an important step. This time, you are required to research on express-validator and apply further API request input control: - Create user request must check `body` for : existence, including name , name’s value is a valid string. - Create task request must check `body` for : existence, and other requirements per task schema. - All routes that require `_id` , must be checked for its existence and whether it is a mongo object id. ## Schema hint In the real world, schema design is often the responsibility of senior devs. However, it is an important skill for a new developer to obtain and build gradually. Don’t worry. We will help you out a bit. As you already identified the problem above, the next step is to critically think about Schema - how and what data we want to record in our database. You will need 2 Schemas: **User** and **Task**. **User Schema**: - User is created by `name`, so there must be a `nam` field in **User schema**. This is mandatory (required) - User has two roles: `manager` and `employee` => a `role` field in `User` with String type and we need `enum` validator for its value. [more](https://masteringjs.io/tutorials/mongoose/enum) > The `enum` validator is an array that will check if the value given is an item in the array. If the value is not in the array, Mongoose will throw an error. **Task Schema**: - A task should contain the field `name` and `description` for the basic information. Can a task have no name and no description? For now, let’s make them mandatory. - The task `status` is tricky. Let’s say you have decided there are 5 types of values for the `status` field: `pending`, `working`, `review`, `done`, `archive`. - pending: work not started - working: is working on it - review: waiting for review result - done : review is finished with satisfaction - archive: package as references for future **Key note from requirements** - A user *may* have **one**, **many**, or **no** task he/she is responsible for. - A task *may* have **one** or **no one** asign to it yet ## Project planning tip ### Plan your routes Instead of jumping right into making routes, we ***should plan for it*** by writing pseudo code. It would be helpful to have the big picture at the beginning. As a reminder, we've done this in [previous lessons](https://learn.coderschool.vn/path-player?courseid=web-virgil-expressjs-with-mongodb&unit=62cc3ab2b641d804240f2fa4Unit). *Example in your `user.api.js`*: - Get all users ```js= /** * @route GET api/users * @description Get a list of users * @access private * @allowedQueries: name */ ``` - Get a single user by Id ```js= /** * @route GET api/users/:id * @description Get user by id * @access public */ ``` - Create a new user (manager's access) ```js= /** * @route POST api/users * @description Create a new user * @access private, manager * @requiredBody: name */ ``` Now it’s your turn to complete all the requirements! ## Marking Guide Everyone will start at a 100 score. | **Requirement** | **Grade** | | ---|---| |Missing any end points requirements| -10| |Missing the planning part a.k.a the pseudo-code for each route| -10| |Missing error handling | - 10| This assignment’s minimum pass score is 80/100 **Good luck have fun!**