Add the ability for staff and admin users to reset their own password from the login page.

Frontend

• Add the "Reset Password" view (Figma link), and take the user to this view when they click the "Forgot Password?" text (no need for a separate URL, you can just use an internal React state to determine which UI to show)
• When the user enters their email address and then clicks "Send Link", use the Firebase API to send the user a link to reset their password (Firebase will email the link when you call this API)
• Develop the UI for the page that users will go to when they create a new password. This is the page users will get a link to in their email. See Figma link for this page. When the user enters their new password into this page, call the Firebase API to set their password

Add the ability for an admin to delete any other user from the accounts page on the staff portal.

Figma link

Backend

Create a new API route, DELETE /api/user/{uid}, to delete a user by their UID (firebase ID, which is also a field in our MongoDB database of users). This route should require the requesting user to be admin (use the requireAdmin middleware). This route should call firebaseAuth.deleteUser(uid) to delete the user with the provided UID. It should then delete the user with the given UID from our MongoDB database. If a user with the provided UID is not found, it should throw a 404 not found error.

Frontend

Implement the following user flow to delete a user:

1. From the accounts page, an admin can click the gear next to any user.
2. A small popup will appear with several options; for now, the only option in the list should be "Remove user".
3. When the admin clicks "Remove user" from this popup, they will see a full-page popup asking them to confirm that they want to delete the selected user.
4. If they click "Cancel Selection", the popup should close and nothing should happen.
5. If they click "Yes, Remove User", then the frontend should call your backend route to delete the user, then close the popup and display a success or error message based on whether the request succeeds/fails.

Proof-of-Concept for reading from and writing to PDF files, for eventual use in exporting a VSR form to a PDF. We will have a template PDF file with blank fields for the data specific to each form (e.g. date-of-birth, military status, etc.) that our backend code will fill in. The required capabilities for this task are to read an existing PDF file (use any PDF with text fields), write to it by filling in text fields, and save the result. Then, open the result file and verify it is valid and has been filled in correctly. I'd recommend the PDF-Lib NPM package.

Resources:

• PDF-Lib NPM package
• PDF-Lib Documentation

Proof-of-Concept for writing data to an Excel (.xlsx) file, for use in exporting VSR data to Excel from our backend code. Use the ExcelJS NPM package. Play around with it and ensure that you can write data to a sheet, save it, and view it in Excel. Then, create a function to write a given 2D array of data to an Excel sheet, given the file name and data.

Resources:

• ExcelJS documentation

Implement searching, sorting, and filtering on the VSR table view.

Figma link

1. Search

The user should be able to type a search term into the search bar on the VSR table page, and then the VSR list should update to show only VSRs that match the search term.

Backend

Add a search query parameter to the GET /api/vsr API route (the getAllVSRS method) with a string to search for. If this search term is provided and is not the empty string, then this route should only return VSRs where any of the fields (except _id, which is a random string) match the search term. For example, if the user makes a request to GET /api/vsr?search=Ben, then you should filter the VSRs to those with a match for "Ben". See the MongoDB documentation and this StackOverflow answer for examples of how to search.

Frontend

Add a listener to the search text input field to detect when the user types a search term. You should use the MaterialUI debounce function (see this StackOverflow answer) with a time of 500 ms to only fire changes at most every 500 ms (so that we don't detect changes to every character as the user types). When an input change is detected, send a new request to the backend to get the VSRs, using the search term that the user entered.

2. Sort

By default, the VSRs in the table should be sorted by the following criteria:

1. By status, in the following order: Received, Approved, Appointment Scheduled, Complete, No-show / Incomplete, Archived
2. By date received, from newest to oldest. The ordering by status takes priority, so VSRs should only be sorted by date received if they have the same status. So we should first show all VSRs with a status of "Received", from newest to oldest, then all VSRs with a status of "Approved", from newest to oldest, etc.

You can look at the GET /api/furnitureItems API route code for an example of sorting model fields by multiple criteria.

Backend

Change the GET /api/vsr API route's query to implement the given sorting. It should do this no matter what (i.e. regardless of any parameters the frontend provides).

Frontend

No changes necessary, since all the sorting will be done on the backend.

3. Filter

Add the ability for users to filter by the following fields:

• Status
• Income level
• Zip Code (multiple can be entered, separated by commas)

Backend

For each field that can be filtered by, have the GET /api/vsr API route take a query parameter for that field (e.g. GET /api/vsr?status=Received). If the query parameter is provided and is not set to the empty string, then the list of returned VSRs should be filtered to those matching the given query parameter(s) (e.g. in the previous example, we would filter to only VSRs with a status of "Received").

Frontend

The status filter should be implemented by enabling the user to select a status from the status dropdown above the VSRs table; when they select a status, the frontend should use that status as the status query parameter sent to the backend, in order to filter by that status.

The income level and zip code filters should be implemented as on the Figma designs. There is a popup that is opened/closed when the user clicks the "Filter" button. On that popup, the user can select an income level and/or zip code(s) to filter by. For these fields, only apply the filter (i.e. send the filter request to the backend) when the user clicks the "Apply filter" button.

Proof-of-Concept of using Firebase APIs for authentication. This is the first stage of the authentication feature, and involves ensuring that our Firebase credentials are valid and we know how to use the Firebase APIs.

• Call the Firebase API to sign in using the PAP dev email account (credentials in .env file) and receive an auth token (JWT)
• Verify the auth token and determine the identity of the user who signed in

Resources:

• Firebase sign-in documentation
• Firebase verify token documentation

Add the ability for staff to update a VSR's status. The possible statuses are:

• Received: The VSR has been received but not yet processed.
• Approved: The VSR has been approved by a staff member.
• Appointment Scheduled: The VSR has been approved, AND the veteran has scheduled an appointment to pick up the requested items.
• Completed: The VSR came to their appointment and picked up the requested items.
• Resubmit: The staff has requested that the veteran edit their form.
• Archived: The VSR has been archived, so that it is not deleted, but can be filtered out (like archived emails).
• No-show/Incomplete: The veteran scheduled an appointment, but did not show up for it.

The status flow works like this:

• Once the VSR is submitted, the status is set to "Received" by default.
• The staff can then approve the request, setting the status to "Approved" (but cannot set the status to anything else).
• After the request has been approved (i.e. is in any status other than "Received"), the staff can freely change its status to any other status.

Backend

Create an API route to edit the status of a VSR. I'd recommend something like PATCH /api/vsr/{id}/status, where the PATCH method means to partially update an existing resource (VSR, in this case). The request body can contain the requested new status, and backend must update the corresponding VSR in the database to that status, then return a response with the new status (or the entire contents of that VSR, if you feel that would be necessary).

Frontend

On the VSR individual page, we need some UI for the staff to edit a VSR's status. Specifically:

1. If the status is currently "Received", then display the "Approve VSR" button at the bottom of the page; when the user clicks it, use the backend API route described above to update the VSR's status, then indicate whether the request succeeded/failed
2. If the status is not currently "Received", then display the status select menu at the top of the page, allowing the staff to edit the VSR's status (send a request to our edit status API route whenever they select a new status)

Create the VSR table view page for staff to see a list of VSRs. Focus on the frontend at first, because the backend route for this task depends on the backend routes and DB models for other tasks being completed.

Frontend

• Implement the table view page. See Figma design.
• Put this page on the /staff/vsr URL
• I'd recommend using the Material UI Table component for the table itself
• For now, focus on the UI of the page. That is, rendering the title, search bars, refresh & export buttons, and table view itself. Use some hard-coded dummy data in the table for now, and the buttons don't have to do anything yet.

Backend

• Once our authentication backend routes and VSR database models are done, then we will need an API route to GET /api/vsr/ that will return a list of all submitted VSRs. This route should require the user to be authenticated and have the staff or admin role. The frontend will then use this data to populate the VSRs table.
• The "Refresh" button should make the frontend make a new request to the backend to get the VSRs, and then update the table with the new data.
• Searching by keywords and filtering by status will eventually need to be implemented in this route

Implement the second page of the VSR form. The Figma design can be found here. The first page has already been developed, so you'll essentially be expanding on the form by adding a second page. The task writeup for the VSR form first page describes what work is involved at each layer of the tech stack, but here's a quick summary for this page specifically:

• MongoDB Database: Add the necessary fields to our VSR data model to include all fields on the 2nd page of the form
• Backend: Add validators for each new field, and update the controller (i.e. route handler) to accept these new fields in the request body, and pass them into the database
• Frontend: Build the UI for the 2nd page of the form, and connect it with the backend. Use the field components developed for the 1st page of the form so you don't have to build from scratch. Also, implement the transitioning between pages of the form by clicking the "Back" and "Next" buttons - I'd recommend just having a useState for the current page, and showing a different component for the correct page UI based on the current page value.

Proof-of-Concept for sending email notifications from our backend. Use the nodemailer NPM package to send an email from our backend, from [email protected]. Write an async function that takes a destination email address, subject, and body (all strings) and resolves on success, or rejects on error. Test it by sending an email to your own email address.

Resources:

• Nodemailer documentation

Add the ability for staff/admin users to export all VSR data to a spreadsheet.

Backend

• Create a new API route like GET /api/vsr/bulk_export that exports all VSRs. The route should return an Excel (.xlsx) file with the VSRs in it
• See #6 for a list of possible libraries to use for writing to Excel
• For now, you can just export every field of the VSR in the most human-readable/useful format possible (use your judgment), we might take some fields out later

Frontend

• Connect the "Export" button the VSR table view to your new backend route, so it will call the route and then download the Excel file to the user's device

Add the ability for admins to delete VSRs. Note that only users with the admin role should be able to do this, not just any staff.

Frontend

• Figma link for Delete VSR feature
• On the table view of VSRs, there should be a "Delete VSR" button that shows up when the user selects one or more rows in the table (selecting them via checkboxes)
• When the user clicks the "Delete VSR" button, the website should display a popup confirming they want to delete the VSR(s)
• If the user confirms they want to delete the VSR(s), the frontend should send a request to the backend to delete each VSR, then exit the popup and display some type of success message.
• Note that since only admins have permission to delete VSRs, this feature should only be displayed on the UI if the logged-in user is an admin.

Backend

• Add an API route, DELETE /api/vsr/{id}, to delete a single VSR by its ID. This route should check that the user is an admin (by using the Firebase JWT token to look up the user in our users database) before doing the deletion. The frontend can call this route once for each VSR that the user wants to delete.

Implement the profile home page (need to figure out latest version of the design on Figma)

Backend

• Create a route to get the list of all users: GET /api/user. This route should be admin only (see the backend middleware for requiring a certain role)

Frontend

• Implement the profile home page, which for now should just retrieve the current user's data using GET /api/user/whoami and the data about all users using the new route you created, and displays this data on the page
• Figma link
• This page should go on /staff/profile

Implement the third page (furniture items) of the VSR form. The Figma design is here. Please read the descriptions of the following tasks for information about the overall system and how to implement a new page of the VSR:

1. #9
2. #19
3. #15

This task is essentially to add the third page of the VSR, which will entail the same actions described in the write-up for #19. Additionally, fetching the list of available furniture items from the backend and submitting the requested items will be done based on the description in the writeup for #15.

Implement the mobile version of the staff login page, Figma is here. This should only require a couple very minor changes (I think):

1. Cutting off the sides of the U.S. flag background image when the screen is much taller than it is wide
2. Making the white, rounded-corner form component (the one above the background) shrink to take up most of the width of the screen, with small margins on the left and right, when the screen is small enough that the desktop version won't fit

Add the ability for staff to edit an existing VSR. The Figma design can be found here.

• When the user clicks "Edit Form" on the VSR individual page (the view page, not edit), then they should see the UI for editing the VSR.
• On the edit VSR page, when the user clicks "Discard Changes", they should see the popup confirming whether they want to discard their changes; if they click "Discard Changes", then they should be taken back to the VSR view page
• On the edit VSR page, when the user clicks "Save Changes", then their changes should be saved, and they should be taken back to the VSR view page

Backend

Create a new API route to edit a VSR. I'd recommend PUT /api/vsr/{id}, since the PUT HTTP method means to completely update an existing resource (a VSR in this case). This route will be very similar to the route for creating a new VSR, except that it will overwrite the fields in an existing VSR in the database instead of creating a new VSR in the database.

Frontend

Implement the UI for the edit VSR page and the functionality to switch between the view and edit pages as described. When the user saves their changes, the frontend should call the API route to edit a VSR, sending the new inputs to the VSR form fields.

Implement the new Navbar for admin, staff, and veterans.

Admin

Figma link
For admins, the Navbar should show the US flag on the left (which is already implemented) and a profile picture on the right. When the user clicks on the profile picture, it should display a dropdown of links to the various pages (the Figma has the list). For now, these links can be dead or broken since not all pages are implemented yet.

Staff

Figma link
For staff, the Navbar should be very similar to the admin Navbar, but should only have links to the dashboard, profile page, and logout, since staff are not authorized to edit the furniture items or email template. You can check if a user is staff or admin using the papUser.role property on the result of useContext(UserContext) (there are many examples in the code).

Veterans

Figma link
For veterans, the Navbar should show a "Contact Us" button on the right. When the user clicks it, it should open a pop-up (see the Figma). When the user clicks "Email now", it should be a link (NextJS Link component) to email them (href="mailto:[email protected]")

End-to-end feature: Staff can sign into the web application using an email and password (no need for sign in with Google account for now), and our backend can retrieve their corresponding user account and role in our MongoDB database.

Frontend

• Render the login page on /login (see Figma design)
• When the user enters an email and password into the login page and clicks the Login button, the frontend should sign them in using Firebase (see #4 for Firebase API documentation)
• After the user is signed into Firebase, the Firebase API will give them an auth token (JWT). The frontend will then send that auth token on future requests to our backend as a header, so our backend knows who they are.
• Right after signing into Firebase, the frontend should make a request to our backend on a /api/whoami route that will return details about the current user (their role, username, email, etc.).

Backend

• We need a users model in our database to represent the users of our application. For now, the only fields we need are:

1. role, a string that should be either be staff or admin.
2. uid, a string that should be the user's unique ID in Firebase. This allows us to associate a Firebase token/user with a user in our DB.
   We can get other information, like email and full name, from the Firebase API

• In your local MongoDB database, create a user for testing using the PAP dev email account (credentials in .env file)
• Create an API route /api/whoami that should ensure the user is authenticated and should return information about their corresponding record in our DB. Use the Firebase API to validate the Firebase JWT token in the request header, and use that token to retrieve the user UID from firebase. Then, find the user in our DB with that UID, and send that user's UID, role, and ID in the response. If that UID is not found in our DB, return an error message saying the user does not exist.

Resources

See #4.

Add the ability for staff/admin users to edit the list of furniture items available for veterans to select on page 3 of the VSR.

Backend

• Create three new API routes:

1. POST /api/furnitureItems to create a new furniture item
2. PUT /api/furnitureItems/{id} to edit a new furniture item (replacing all fields with the values specified in the request body)
3. DELETE /api/furnitureItems/{id} to delete a furniture item

Frontend

• Figma link
• Put this page on a new URL: /staff/furnitureItems
• Implement the user flows on Figma for adding/editing/deleting existing furniture items, using the 3 backend routes you wrote

Implement the first page (Personal Information) of the VSR design on Figma. We'll eventually add the other 2 pages on, with "Next" and "Back" buttons to navigate between them. But for now, just put the "Submit" button on the first page, and have that button submit the form to our backend, so we can test the first page end-to-end.

Backend

• DO THIS FIRST Create a MongoDB database model for a VSR. Look at the Figma design, and/or the VSR PDF if you need it (attached to this issue) to see what fields there are and what data types they should have. For now, only include the fields on the first page of the VSR in the Figma design. The reason this part should be done first is that other tasks (staff table and individual view of VSRs) require this DB model to be created in order for their backend routes to be written
• Create an API route to POST /api/vsr to submit a VSR. This route should NOT require the user to be authenticated (authentication is only for staff). On this route, verify that all required fields are present in the request body and meet validation rules (see the Frontend section for examples of validation). I'd recommend using Express Validator to validate the request. This is the library used in the TSE Onboarding repo, so feel free to reference that repo as an example of validating request data. If all validation checks pass, create an entry in the VSR database using the data in the request body.

Frontend

• Put the VSR form on the /vsr URL (this might change later)
• Render the layout of the first page, matching the Figma design. Create some reusable components for form fields (e.g. text field, multiple choice). I know that not all fields of the same type will look the same, but just do your best to use reusable components
• The text fields can just be input elements, but the multiple-choice fields will need code to listen to when the user clicks on one of the options, and update the UI to show that option as selected (I assume the selected option would have a dark background and white text, but we can clarify with the designers).
• To manage the form fields, validation, submission, etc., I'd recommend using a 3rd-party library. I like React-hook-form, another option is Formik or any other library you want to find yourself. Use whatever you prefer.
• When the user clicks the "Submit" button, this should first validate the form data. Ensure that all fields are filled in and meet some reasonable validation rules (e.g. age should be an integer, not "K#MD83nm2", use your best judgment to what validation should be run on each field). If one or more fields fail validation, display an error message on that field indicating what is wrong (e.g. "Age is required", "Age must be an integer").
• If all validation checks succeed, submit the form data to our backend via a POST request to /api/vsr.

Add the ability for an admin to create a new user from the accounts page.

Figma design

Backend

Create an API route, POST /api/user, to create a new user. This route should require the requesting user to be an admin (use the requireAdmin middleware). This route should take name, email, and password fields in the request body. It should then do the following:

1. Validate that all required fields are provided in the request body (using validators, just like we have for the VSR create and edit routes).
2. Call the Firebase API to create a new user using the provided data (see https://firebase.google.com/docs/auth/admin/manage-users#create_a_user).
3. Create a new user in our MongoDB database of users, using the UID returned by the Firebase API call, and the role of "staff" (we don't need a way to create a new admin user).
4. Return the data for the new MongoDB user in JSON format, just like the data returned from /api/user/whoami.

Frontend

Implement the following user flow:

1. From the accounts page, an admin can click the "Add Account" button.
2. After clicking this button, the admin will see a popup where they can enter the name, email, and password for the new user.
3. After entering the information and clicking the submit button, the frontend will make a request to your new backend API route to create the new user. When the request returns, the admin will see a confirmation popup (or an error notification if adding the new user failed.

When a VSR is submitted, we want a notification email to be sent to staff telling them a new VSR was submitted. This email should include the name and email address of the request. The purpose of this feature is so that staff can later search their email to find VSR submissions by name or email.

• First, follow the instructions in #5 to get email notifications working at all
• Then, create a function to send an email to staff saying that a new VSR was submitted. The email subject can be "New VSR Submitted" and body can be "A new VSR was submitted by [name] from [email]" or something like that. Use constants for the subject and body so we can change them later. This function should take the name and email as parameters, and send an email to staff. I'd recommend making it an async function that resolves upon successful submission and rejects upon error
• Make a new environment variable in our backend to indicate what email address these notifications should be sent to. Call it something like EMAIL_NOTIFICATIONS_RECIPIENT. This way, we can have these emails be sent to ourselves or our TSE pap dev email address for now, and have them be send to the actual Patriots & Paws email address in production. Your code should use this environment variable as the address to send emails to

We need a way to store the available furniture items, and the items that a specific veteran has requested. On the third page of the VSR form (Figma link), it should show all the available furniture items and allow the veteran to select which items they want, as well as quantities.

For this task, focus on the database and backend first, since there is a lot of work involved just on the backend. We will also need separate tasks to update the create & retrieve VSR API routes, and the frontend for the VSR form and VSR individual view.

Backend

Furniture item database model

Create a DB model for a furniture item. It should have the following fields (all of which are required):

1. category: String. Determines which section on the VSR form the item should show up on. E.g. "bedroom", "bathroom".
2. name: String. The name for the furniture item. E.g. "Matching Box Spring(s)", "Blankets"
3. isGasElectric: Boolean. Represents whether this item has gas and electric options available. Currently, only the stove and dryer should have this property set to true; all other items should have it set to false.
4. allowMultiple: Boolean. Represents whether we should allow veterans to ask for more than 1 of this item. For the items with the plus and minus buttons to select a quantity on the Figma, this property should be true, and for the items where you just select/deselect it but don't choose a quantity, it should be false.
5. categoryIndex: Number. Index of the item within its category. Should be an integer. Will be used to put items in a specific order within each category. For example, within "Bedroom", the "Matching Box Spring(s)" furniture item's category index is 1, "Matching Bed Frame(s)" should be 2, etc.

Data population script

We need a way of loading the current furniture items into the database. Creating the furniture item DB model will define what an item should look list, but we need to also define which items exist. Rather than manually entering them one at a time through MongoSH or something, we should create a script that will load the furniture items into the MongoDB database. By "script" I mean a JS/TS file that will run code to create all the items that exist. You can create a JSON file for the data itself, and the script will just read the items from that JSON file and insert them into the database. Creating a script for this will allow each developer to insert the data into their own local database, and will allow us to insert the data into the production database, in an automated way.

Furniture item & VSR association

Now that we've defined what furniture items are available, we need a way to store which items each veteran has requested. We can do this by adding a field to the VSR model called requestedItems. This field should be required, and is an array of objects, where each object has the following fields:

1. itemId: Required. The ID (_id field) of the item that was requested. I think there's an ObjectID type or something in Mongoose.
2. quantity: Number, required. The quantity of the item that the veteran requested. Should be 1 for items where you can't choose a quantity (allowMultiple field).
3. isGas: Optional, boolean. Use this field only if the item has isGasElectric set to true. Set this field to true if the veteran chose gas, and false if they chose electric.

Additionally, we'll need an otherItems field to the VSR model, an optional field for anything the veteran enters into the "Identify other necessary items" box.

Implement a 4th page of the VSR form for veterans to review their VSR before submitting. The purpose of this feature is to help veterans catch mistakes on their form so they are more likely to submit accurate information and not need to re-submit or email PAP about errors on their form.

Figma design

The user flow should be as follows:

1. A veteran fills out the first 3 pages of the VSR, just like we currently have implemented.
2. After filling out page 3, the veteran clicks the "Review" button and are taken to the review page (currently, there is a "Submit" button on page 3 that immediately submits the VSR when they click it).
3. On the review page, the veteran can view the information they entered. If they notice any mistakes and want to change it, they can click the "Edit Fom" button for that section.
4. After clicking "Edit Form", the veteran is taken back to the corresponding page (out of the 3 pages) for the section they clicked "Edit Form" for. They can then edit their entered information and proceed from step 2.
5. The veteran can also click the "Back to Edit" (I think we should rename this to "Back to Editing") button on the review page to be taken back to page 3 of the form.
6. On the review page, once everything looks good, the veteran can click the "Submit" button to submit their VSR. The flow after this is the same as currently have implemented (they will see a confirmation popup if it was submitted successfully, or an error notification if there was an error).

Note that this task is entirely frontend, it doesn't require any backend changes.

For the review page, I would recommend re-using the components on the VSR individual page that display details for each field.

Implement the VSR individual view page for staff. This should show one VSR in detail. Focus on the frontend first, because we need the VSR DB model to be completed in order to build the backend route for this task.

Frontend

• Implement the VSR individual view, following the Figma Design
• Put this page on the /staff/vsr/[id] URL (see the NextJS dynamic routes documentation)
• Use the Material UI Accordion component for the accordion sections
• You can use hard-coded dummy data for now, to test the view and ensure it matches the design
• Once the backend for this task is complete, the frontend should call the backend route to get the data for the individual VSR.

Backend

• Once our VSR MongoDB database model is done, add an API route to GET /api/vsr/[id] to get data on a specific VSR. The id in the URL path should be the ID of the VSR (MongoDB assigns each DB entry a unique ID). This route should verify that the user is authenticated (using a Firebase token in the header) and has the staff or admin role. If these checks pass, retrieve the corresponding VSR and return its data in the response