[SSF 195] - FM Required Actions Frontend#166
Conversation
| body: ConfirmDonationItemDetailsDto[], | ||
| @Body(new ParseArrayPipe({ items: UpdateDonationItemDetailsDto })) | ||
| body: UpdateDonationItemDetailsDto[], | ||
| ): Promise<Donation> { |
There was a problem hiding this comment.
we can make this return void!!!
There was a problem hiding this comment.
im fine with doing this. right now, however, a lot of our patches throughout our code have a mix of returning void, or the entity. i think we should standardize this to either, return void for all of them, or return the updated entity for all of them. we dont really do anything with the updated info, so im more in favor of doing void, but let me know your thoughts.
There was a problem hiding this comment.
super agree ive been suggesting returning void for these endpoints that i find since there is no need for the backend to expose those info to the frontend if it's not being used!
There was a problem hiding this comment.
ill update all of them. There are a few where we rely on the output though for the frontend (the ones used in Profile updating).
2 participants
ℹ️ 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
Screenshots of pages:
🏕️ (Optional) Future Work / Notes
N/A