[SSF-213] Create new donation fixes

[jiang-h-y]

ℹ️ Issue

Closes SSF-213

📝 Description

Backend:

• Auth gated POST /api/donations endpoint so only Food Manufacturers can access it
• Read in FM ID based on the logged in user instead of allowing FM ID to be passed in
• Removed FM ID from CreateDonationDTO and updated tests accordingly

Frontend:

• Extended alert hook to include a status field
• Refactored implementations of alert hook
• Ensured a success/error toast after logging a donation in apps/frontend/src/containers/foodManufacturerDonationManagement.tsx

✔️ Verification

• Tested logging a new donation
• Tested that non-FMs could not access the createDonation endpoint
• Tested that the success/error toast renders

Sucess:

Error:

🏕️ (Optional) Future Work / Notes

• One of the backend tests fails in workflows but not in terminal because of a small timing difference (not sure why)
  Edit: updated the backend test and now all tests pass
• Not super sure if manufacturerID is still necessary in apps/frontend/src/containers/donationManagement.tsx

[dburkhart07]

I'm noticing that the FloatingAlert component uses a status of info | error, whereas the AlertState interface uses success | error. We should standardize this (in my opinion, info | error everywhere). Can we change all the success alert messages to be info instead, create an enum in types to be reused in both the FloatingAlert and AlertState, make it so that all FloatingAlerts now just have status={alertState.status}?

[jxuistrying]

When I was smoke testing front end for FM users I noticed both dashboard and all pages are currently highlighted at the same time is that intended?

[jiang-h-y]

When I was smoke testing front end for FM users I noticed both dashboard and all pages are currently highlighted at the same time is that intended?

FM dashboard just hasn't been merged yet, but ideally "All Pages" and "Dashboard" should link to different pages after it's merged

[jiang-h-y]

To replace the [error, setError] useState pattern in foodManufacturerApplicationDetails.tsx and pantryApplicationDetails.tsx, I had to modify the alert hook. I separated this commit in case we want to make different design choices.

I also noticed during testing that you can edit pantry/FM applications so that the values for certain fields aren't the right type (e.g. setting "Zip/Postal Code" to a string). We might want to set some restrictions around that.

[dburkhart07]

lgtm pending decision on alert type

[dburkhart07]

Regarding the usage of this AlertType, why do we need this? I think we can just rely on the actual message to differentiate what the error is, and remove the typing altogether. Lmk if you have any other thoughts

[jiang-h-y]

Should I remove the alert type field altogether or just the enum?

[dburkhart07]

i think both, i dont really see a use case for this unless you do.

[jiang-h-y]

For switching between icons (e.g. line 221 for FM application details), should I case on the error message then?

I didn't really wanna do string matching though, so lmk if you have a better idea on how to switch between the icons.

[jxuistrying]

ok yea other than the frontend ui which is still waiting for FM to be merged otherwise everything else lgtm!

[jxuistrying]

waiting for fm dashboard to be merged so lgtm!