Conversation
|
See slack comment |
313c63d to
2577fbe
Compare
2577fbe to
265bad6
Compare
dburkhart07
left a comment
There was a problem hiding this comment.
Make these initial changes, also see message I sent you.
…com/Code-4-Community/ssf into sk/SSF-97-pantry-management-backend
…k/SSF-97-pantry-management-backend
…com/Code-4-Community/ssf into sk/SSF-97-pantry-management-backend
dburkhart07
left a comment
There was a problem hiding this comment.
Few initial things. Also, I do not see the second half of the ticket requirement to make a new endpoint for this: Add a new endpoint to overwrite the set of volunteers assigned to a pantry with a new set of volunteers for intended use case
| @@ -1,3 +1,35 @@ | |||
| export interface ApprovedPantryResponse { | |||
There was a problem hiding this comment.
I think we are going to need more info than this for our approved pantry response. For one, all these pantries are approved so we shouldnt need the status. Additionally, check out the Figma for the frontend: https://www.figma.com/design/brc5luMhizIFp893XIutYe/SP26---SSF-Designs?node-id=756-11085&t=3UiKr0MdYxCcdUUK-0
The modal that pops up with Pantry Details should tell you what information we need.
There was a problem hiding this comment.
Sorry, there may have been some confusion here. It's fine if we have to make another API call to get the full details about a pantry when the user navigates to the "pantry details" page - we just need the info for the main table (as well as the IDs necessary to be able to navigate to the other pages)
|
Final comments:
|
dburkhart07
left a comment
There was a problem hiding this comment.
LGTM! Thanks for responding to so much back-and-forth 🔴🐼
Yurika-Kan
left a comment
There was a problem hiding this comment.
first round of review!
found a field that was missing
done: jest tests ran
pending: testing via postman
litttt
Yurika-Kan
left a comment
There was a problem hiding this comment.
hefty second review! some small changes, adding auth gating, testing, and a bit more! thanks for the great work so far <3
(update) tested:
- postman calls
apps/backend/src/pantries/types.ts
Outdated
| name: string; | ||
| email: string; | ||
| phone: string; | ||
| role: string; |
There was a problem hiding this comment.
i don't think we need to save role of the volunteer here - they should always be volunteer - could you delete this everywhere in this implementation? @sam-schu lmk thoughts
There was a problem hiding this comment.
I'm fine either way - this type seems to only be used as part of the return of the endpoint to get info about the approved pantries, where I agree it's not strictly necessary that we return the role of every assigned volunteer but it also doesn't hurt anything
There was a problem hiding this comment.
Overall, for the endpoint to get info about approved pantries I would recommend either:
- return full pantry/volunteer details as you pretty much are now, but simplify by returning them as returned by typeorm, rather than
mapping all the individual fields- can define return types in terms of
PantryandUserrather than making new interfaces - just make sure to remove the users' cognito subs from the data being returned
- can define return types in terms of
- or limit returned info to what is necessary for the frontend, which will make the map and interfaces much more concise
| relations: ['volunteers', 'pantryUser'], | ||
| }); | ||
|
|
||
| return pantries.map((pantry) => ({ |
There was a problem hiding this comment.
Can you take a look at what the return from the above call to TypeORM looks like? That should likely have all the information we need, it doesn't look like this map is doing much other than copying all the fields from one object to another. If we do go with the current approach rather than just returning pantries (with volunteers' cognito subs removed), we should make things more concise by limiting to the fields that are actually needed by the admin pantry management page this endpoint is for
| newsletterSubscription: pantry.newsletterSubscription ?? false, | ||
| volunteers: (pantry.volunteers || []).map((volunteer) => ({ | ||
| userId: volunteer.id, | ||
| name: `${volunteer.firstName} ${volunteer.lastName}`, |
There was a problem hiding this comment.
We should not be combining the first and last names into one field here, this will make things more difficult for the frontend which needs to show the user's initials
| @@ -1,3 +1,40 @@ | |||
| export interface ApprovedPantryResponse { | |||
There was a problem hiding this comment.
Both of these interfaces look very similar to the Pantry and User entity types. Can we define the return types using those rather than re-listing out all their fields?
| @@ -1,3 +1,35 @@ | |||
| export interface ApprovedPantryResponse { | |||
There was a problem hiding this comment.
Sorry, there may have been some confusion here. It's fine if we have to make another API call to get the full details about a pantry when the user navigates to the "pantry details" page - we just need the info for the main table (as well as the IDs necessary to be able to navigate to the other pages)
apps/backend/src/pantries/types.ts
Outdated
| name: string; | ||
| email: string; | ||
| phone: string; | ||
| role: string; |
There was a problem hiding this comment.
I'm fine either way - this type seems to only be used as part of the return of the endpoint to get info about the approved pantries, where I agree it's not strictly necessary that we return the role of every assigned volunteer but it also doesn't hurt anything
ℹ️ Issue 97
Closes 97
📝 Description
Added a new endpoint (getApprovedPantries) to return all information necessary for the pantry management frontend about pantries with 'approved' status - includes assigned volunteers.
Added a second new endpoint (updatePantryVolunteers) to overwrite the set of volunteers assigned to a pantry with a new set of volunteers.
Added a type file for pantries and included ApprovedPantryResponse and AssignedVolunteer types.
Added a controller test for each endpoint.
✔️ Verification
Tested both endpoints using curl. Made sure GET endpoint retrieved all approved pantries with assigned volunteers, and that the PUT endpoint overwrites volunteer assignments successfully.