Create Task endpoints

[KieranVieira]

NOTE: the following requires token/auth header

• [ ] Create POST endpoint at /api/tasks/ that creates a task with x body
• [ ] Create GET endpoint at /api/tasks/ that gets all tasks for a specific user (using decrypted token for user id) (takes in url params to filter for specific tasks, ie. get by label, in progress, done, etc)
• [ ] Create GET endpoint at /api/tasks/:taskId to get a specific task
• [ ] Create PUT endpoint at /api/tasks/:taskId to update a specific task
• [ ] Create DELETE endpoint at /api/tasks/:taskId to delete a specific task

[reevesabbas]

in our entity, it's many-to-one tasks to user, so each task has a user field in which the user is being saved in. Questions: What will the front-end of the app look like in terms of managing weekly tasks.

• i.e. can it manage recursive tasks by just displaying the task every week until isRecursive is set to false by the user? How are we going to track the completion of recursive tasks.
• if user checks off the task, we still want that task to display the next week. But if user sets isCompleted to true that day, how will we get it to repeat.
• Reset isCompleted field at 12am everyday for recursive tasks is possible solution.

task routes pseudocode: post:

• find User using userId passed in as param
• create a new Task and set fields from req body.
• handle cases for if task is recursive or not recurive
• not done yet

[reevesabbas]

GET route pseudo code:

labels will be passed in as query params/key value pairs store these labels in an object pass in this object into findAll method on user's task array return json body containing tasks

Filter options:

• Tags (School, Econ)
• Date (Anything before 9/14, Anything after 9/14, between 2 dates, on one date)
• Completed/In progress (status of tasks)
• recursive/non-recursive tasks (done by default)
• tag color?

[kaydengrant]

Filtering a task:

• tag name
• gte lte date
• completed/ip

[reevesabbas]

Issue: user.tasks returns without 'taskFinished' or 'tags' fields in the list of tasks. But they are included in the list of tasks being received for 'Should return status 200 with all user\'s tasks' test.

I tried to simply add the two fields in each taskExample, but this didn't work. I tried to delete testdb.sql and re-run tests but this didn't work. I'm pretty sure that the relations with task are being ignored. userRelations is only to task, so I think this may be why it's not including those fields. Going to do more research and try to find a way to include those relations or find a new way to get user.tasks. Or if there's a way to add these fields directly just for the sake of the test...

[reevesabbas]

https://stackoverflow.com/questions/59031198/typeorm-how-to-get-relations-of-relations it works but not accessing userRelations or taskRelations exported variables.

[KieranVieira]

True

[reevesabbas]

Documenting my thinking:

Currently working on POST route to create tasks with tags. First, checking if body.tags exists, then what I'm TRYNA do is: forEach element in the body.tags array, (since it's possible to add multiple tags, it has to be an array of objects with tagName and tagColor as the properties) create new tag set fields for that tag (now each object has tagName, tagColor, and tagId) save to task.tags array

reference this for saving: https://stackoverflow.com/questions/54885935/how-to-save-relation-in-manytomany-in-typeorm

But there are some itchues: I read that in order to save many-to-many relations, that the task entity has to already exist to save tags to it. SO I'm not sure we can do this in the same route, we might have to do what Kiri mentioned and create separate routes for tags.

Might still be possible to get this to work in one route, but I feel it'd be cleaner and easier to just create Tag routes.

Thoughts??? @kaydengrant

[kaydengrant]

ye i think that doing it in the same route makes sense except we would also have to have a section for checking if there is an existing tag. i think it would prolly be cleaner and easier if we did its own separate route too. either way we are going to need to change the current post route to allow users to add tags to their tasks when they first create them but the code for the latter decision will be far less complicated and should be more like the others currently (task.tags = body.tags or sum like that)

[kaydengrant]

Current status of ERGO: 2/4/2022

First things first, our tag endpoint pull request is failing to npm run test on GitHub. Not sure if we need to change the auto test file to 'devtest' or if there's some bug in our code not allowing it to run. This is kinda important bc if we can close this endpoint, we can merge the code into feature-tasks and get rid of a branch. Currently, all the code is being saved in feature-tags...

NEXT: filtering... Currently, all tasks are returned when there is no query for filtering. I'm not sure if any of the filtering components work at all as the error that I'm getting is that we cannot search for tags over a many-to-many relationship. I looked into it a bit, and people said that typeorm couldn't do this yet but it was also an old forum post so idk. We can converse and search about this many-to-many situation we have on Sunday!