Second Meeting Issue

[jeugarte]

Hello Srija & Sanya! Great job on the first ticket once again 🥳 We'll keep using the same technologies from last ticket (i.e. MongoDB, Prisma, models) into this week's ticket. But now, instead of Users, we'll be focusing on Meetings. Here is this week's ticket, due on March 29th. Please give yourselves enough time to work on the ticket + come to worksession this weekend to get a headstart (optional) + Slack me with any questions either through direct message or in the #cornell-recovery-dev-sp24 channel! 🫡

Branching

Before creating a new branch, please remember to pull from the master branch. To do so, you can run git pull origin after navigating to the master branch with git checkout master. Now you are ready to make the new branch. Create a new branch called meeting-modeling-2 and push all your commits to this branch. If you need a reminder of how to make a branch, please check the past ticket.

Modeling (without the runway)

As you saw from the designers' work, creating meetings is the main component of our product. So it is intuitive to keep a record of all the meetings that have been held, whether virtually or in-person. When our partners Scott and Matt create a meeting for a specific group (AA, Al-Anon, etc), we want to store these new meetings and their metadata in our database.

The schema/model (I use these terms differently, but I am talking about the general Class of Meetings and all the variables stored within them. If the terminology is confusing, please let me know) will constantly change as we learn more about our own product and the different information we need to store with each Admin, but for now, let's focus on the following:

• title
• mid
• description
• creator
• group
• date
• startTime
• fromTime
• zoomAccount

I created a /frontend/util/ folder that will include a file called models.ts. In this file, we will define our schema for each type of object/class we will store in our mongoDB. Think of interfaces as a quick way to make an object, just like in Java. These are just the properties the object must have if we make one. The interface IMeeting (already created by Mo), is implemented in models.ts. Take a few minutes to look over how it was created. Interfaces like IMeeting will prove useful to assert and formalize the types of information we are extracting from and sending to MongoDB.

The Prisma thangs (in question)

Inspect the schema.prisma file in /frontend/prisma/. So far, we have added a Prisma model (different from our model in /frontend/util/models.ts) for a User and Meetings (thanks to Mo once again). For the User schema, when I first created it and pushed the model to MongoDB, it created a Collection called User. Think about this as a table or a key. All user documents will be stored in this collection. Same thing happened for Meetings; you can check this by connecting to the MongoDB and inspecting the Meetings collection in the Test database. While you do not need to implement this, take a few minutes to look at the implementation. It would also be useful to know how the Prisma schema works and how to implement one for MongoDB, so I highly recommend checking out Mo's ticket (same section "The Prisma thangs (in question)") located in #4

Recovery-Unique-Driven Meetings (The URD in CRUD)

For this section, you will create Update, Read, and Delete functions. Unlike the current CRUD (create, read, update, and delete) functions located in folders distributed in /frontend/app/api/, we will use TYPESCRIPT over Javascript. Typescript is generally used for better practice purposes, so we'll start to change everything to Typescript slowly but surely.

For each individual retrieve, update, and delete function, please navigate to each corresponding folder and create a new folder & file /meeting/route.ts. For example, when making the Update function, navigate to the /frontend/app/api/update folder, and create a new folder meeting and add the file route.ts to this folder. Make to import your interfaces you created in the /frontend/utils/ folder and use them in the following ways:

1. For Retrieve, the Prisma Client will return dictionaries of documents of Meetings. To assert that they are actually Meetings of our type of interface IMeeting, cast the returned Meeting to an IMeeting. Then return the IMeeting objects. Make sure to use Try-Catch statements, just like in the current implementations. Have this specific retrieve function retrieve ALL meetings.

2. For Update, assume that the parameter will be a mid (meeting id) represented as a string as well as new times represented as a Date type. Take in these parameters and search for the meeting object in the database using the mid. If you find it, update its meeting times (both start and from). If the meeting is not found with the mid, throw an error. If it is found, please return the updated object:

3. For delete, delete a meeting by mid. Assume the request parameter will include a field for 'mid'. This time, return a Response object as noted below:

   return new Response(JSON.stringify({ message: "Resource deleted successfully" }), {
   status: 201,
   headers: {
   'Content-Type': 'application/json',
   },
   });

Reference the following documents to help you with CRD functions in the context of Prisma. https://www.prisma.io/docs/orm/prisma-client/queries/crud#update-a-single-record https://www.prisma.io/docs/orm/reference/prisma-client-reference - longer but more in depth explanation of each CRD function with input and return types.

In addition, check out Mo's implementation of creating Meetings in /frontend/app/api/write/meeting/route.ts. This should help setup up the imports, PrismaClient, and const function backbone. The actual function you will use within the const function will differ; that's when you should refer to the documentation listed above.

One last thing: make sure you export separately on the last line of the file. And do not use the function keyword, use const instead. And return the appropriate status codes in the Responses when required.

const createMeeting = async (newMeeting) => {

};

export default createMeeting

If you make any assumptions about the code, please list them in your PR or let me know about them. There is still some liberty for your own implementation. In a future ticket, you will work on implementing Update functionality to add and remove attendees (more complicated logic I feel was not necessary for this ticket).

Testing 🙀

Lastly, do not forget to test! Navigate to the /frontend/app/test/page.jsx to visualize all the current testing buttons. I created a new button for retriveing, updating, and deleting a meeting! All you need to do is fill in the parameters and bodies of information that will be sent over. Click the buttons to make the calls. Submit a screenshot of the new Meeting on MongoDB compass and the message in the console when printed.