[SSF 195] - FM Required Actions Frontend

[dburkhart07]

ℹ️ Issue

Closes #195

📝 Description

Backend changes:
I realized during development that the single order updating was deprecated, as we needed a way to update the tracking link and shipping cost for all of the orders at once. Therefore, I added a new endpoint and service function (as well as tests) for this, and got rid of the old one. The backend now takes in ether the shipping cost or tracking link for each order from the donation, and updates the order to shipped when both are provided eventually. Additionally, I also realized now that we would need to make it so that we can edit fields for confirming a donation item, even after it gets confirmed. I modularized the old confirm donation item details endpoint to accept all fields as optional, and rather just serve as an update function that, in the even where all fields got values, we would make it so the details became confimred.

Frontend changes:
As this logic is somewhat confusing, I made the frontend page with a few changes to the design.

Order section:
We display all pending orders for the donation, with the option to add shipping cost (SC) and tracking link (TL). Since each order only becomes shipped when SC and TL are provided, while we allow users to only provide one, it will remain pending (and therefore in the modal) until both are provided. We bulk update all of the edited SC and TL fields at once through a single api call and DB transaction.

Donation item detail confirmation:
This modal is provided to the user to confirm details for all donation items that are being used in the pending orders from the previous modal. It displays all of them, whether they are confirmed or not (maybe some of the items were confirmed from a previous order). The user cannot submit the form until they have confirmed the details for all items from all the pending orders, regardless of which ones they provided a SC and TL for. After initial submission, should they still have pending orders to provide SC and TL for, each time, they have the option to update oz. per item, estimated value, or food rescue for each of the items. We also send all updates to all donation items to the backend in bulk, only updating the detail confirmation for items that end up having all 3 fields populated off of that API call.

Submission:
On submit, we do the donation item detail confirmation API call first. This is because we want to set the donation item details to confirmed before updating SC and TL, since after that we move the order to shipped, and can potentially the donation from matched to fulfilled if all its items are not shipped off.

✔️ Verification

• Tested new/endpoints in Postman
• Made sure all tests passed

Screenshots of pages:

🏕️ (Optional) Future Work / Notes

N/A

[Yurika-Kan]

round 1 comments!!!

[Yurika-Kan]

meep! lmk if this makes sense, need to talk more on the critical changes / effects of keeping modal mounted (like form state not resetting between donations). slack dms is the place to be!

[Yurika-Kan]

by conditionally mounting modal, it opens slower since it is a new component chakra initializes & the complete required actions link is unclickable after closing first time due to chakra being chakra (unmounting, parent component, messy etc)

can we always render the modal & decide visibility through isOpen instead? so chakra run its own open/close lifecycle and you can reclick the link second+ times?