Admins & Intro to MongoDB

[jeugarte]

Hello Sneha & Sophie! Here is this week's ticket, due on March 13th at 11:59 pm. 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

Please create a new branch called admin-modeling and push all your commits to this branch.

Modeling (without the runway)

This ticket is focused on bringing a new type of data we will store in our mongoDB: admins! This is different from Users. To think about it more intuitively, Users are general attendees of these private sessions. Admins are the ones setting up these meetings and using our application (based on my current knowledge). So we should represent the two different groups of people differently as they will have different privileges and metadata stored with them.

The schema/model (I use these terms differently, but I am talking about the general Class of an Admin 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:

• name
• uid
• email
• privilegeMode

Pretty similar to a User, right? We will still attach a uid to an admin because we can consider an Admin as inheriting from a User, so essentially an Admin is still a User. This will prove to be helpful later. Please call the interface "IAdmin".

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. Using the fields described above, please make a model for an admin. To avoid duplicating data, make sure you use the extends keyword and extend from the User interface.

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. 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. In order to make a collection for Admins, we will follow a similar process:

1. Add a model for Admins, right below the User model. Follow this documentation regarding the Prisma + MongoDB thangs. I HIGHLY recommend you read through it thoroughly, as it summarizes our tech stack really well and provides us insight into the connection between MongoDB and Prisma.
2. Make sure .env file is updated and confirgured correctly with the new connection (I will provide this)
3. Once implemented, run yarn prisma db push, which will enforce the models onto our DB. Once you run this and it succeeds, you should now see a new collection under the Test database, in the same tier as the User collection.

Admins are CRUD (without the U)

For this section, please create Create, Read, and Delete functions Unlike the current CRD 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 CRD function, please navigate to the corresponding folder and create a new folder & file /admin/route.ts. For example, when making the Create function, navigate to the /frontend/app/api/write/ folder, and add the folder & file to this folder. Make to import your interfaces you created in the /frontend/utils/ folder and to use them in the following ways:

1. For Retrieve, the Prisma Client will return dictionaries of documents of Admins. To assert that they are actually Admins of our type of interface IAdmin, cast the returned Admin to an IAdmin. Then return the IAdmin object. Make sure to use Try-Catch statements, just like in the current implementations. For this specific retrieve function, please retrieve the admin with the given email found in the request (passed in as a parameter).
2. For Create, assume that the parameter will be a request in the form of a json. When parsing the request body, please assert that the json conforms to an Admin object by casting it as an IAdmin. Take in this object and store it in the in the DB. Return the following, and a similar Response object for if there is an error with adding it to the DB (catch this error):

   return new Response(JSON.stringify(newAdmin), {
          status: 201,
          headers: {
              'Content-Type': 'application/json',
          },
      });

3. For delete, delete an Admin by email. Assume the request parameter will include a field for 'email'. Similar to create, return a Response object.

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.

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 POST = async (request) => {

};

export default POST

For when making the GET function, please replace 'POST' with 'GET'. 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.

Testing 🙀

Lastly, do not forget to test! Navigate to the /frontend/app/test/page.jsx to visualize all the current testing buttons. The file is getting a bit clutered, so lets make a new file called adminTests.ts. Use this file to add your 'handleClick' functions, which you will attach to each of the new buttons you create in page.jsx. Follow a similar structure as the other 'handleClick' functions in page.jsx. Please use your models/interfaces in these functions as needed. To complete your PR, screenshot your console after creating a new admin, getting that specific admin, and then deleting that same admin. Make sure these results are being printed to the console. Also, print errors and status responses to the console.

[jeugarte]

Completed in #9