MSPCA-2: get volunteer by id and update volunteer by id

[shreeyaadhikari]

ℹ️ Issue

Closes MSPCA-2

📝 Description

Adds the ability for foster coordinators to look up a single volunteer's full details by ID and update their info without overwriting the entire record.

Briefly list the changes made to the code:

1. Added GET /volunteers/:volunteerId which returns a single volunteer's full details, or a 404 if the ID doesn't exist.
2. Added PATCH /volunteers/:volunteerId which updates only the fields provided in the request body, leaving the rest of the record untouched.
3. Added UpdateVolunteerDto with address, city, zipcode, homebase, residentAnimals, notes, and fosterType as editable, optional fields, with @ IsEnum() validation on homebase and fosterType to restrict them to their real enum values.
4. Added assignedCoordinatorId handling in the update flow. The DTO accepts a coordinator ID rather than a full nested object
5. Added validateId checks in VolunteersController for both endpoints, returning a 400 for invalid IDs.
6. Added service and controller tests for both endpoints

✔️ Verification

Ran yarn test. All service and controller tests pass for VolunteersService and VolunteersController.

🏕️ (Optional) Future Work / Notes

Did you notice anything ugly during the course of this ticket? Any bugs, design challenges, or unexpected behavior? Write it down so we can clean it up in a future ticket!

[dburkhart07]

A lot of just small nits and general style guidelines that we will follow throughout development. Logic looks really great so far. Ty Shreeya!!!! 🐼

[dburkhart07]

all very small things, but looking really good! hopefully should be good to go after these changes!!

[dburkhart07]

could we also document all service functions using the following docstring format:

• Summary line describing the function
• Additional context about behavior or edge cases
• @PARAM tags for parameters
• @return tags for return value
• @throw tags for any exceptions they throw

[dburkhart07]

can you remove the columnName and relationName functions in the plural naming strategy? after that its good so ill approve

[Yurika-Kan]

some comments + tested endpoints with curl/postman!

yayyyy first mspca review <3333

[Yurika-Kan]

i see an existing findByIdOrFail(id) on main here @dburkhart07 should we use that method instead? it's the same method/impl with a diff name~

[dburkhart07]

yeah, in hindsight i didnt think that entire service method would get implemented by another ticket, but it did end up happening. now that we have it, it's a good helper to use, and should be used here as well. let's rather change findByIdOrFail to return it with the assignedCoordinator relation though, and update the tests

[Yurika-Kan]

heads up that my #7 is merged now & i already implemented the findByIdOrFail with loading relations: ['assignedCoordinator'] there.

mspca/apps/backend/src/volunteers/volunteers.service.ts

Lines 26 to 37 in 9c642fc

	async findByIdOrFail(id: number): Promise<FosterVolunteer> {
	const volunteer = await this.repo.findOne({
	where: { volunteerId: id },
	relations: ['assignedCoordinator'],
	});
	if (!volunteer) {
	throw new NotFoundException(`Volunteer with ID ${id} not found`);
	}
	return volunteer;
	}

so after pulling main's latest ver, u'd just need to replace the duplicate refs to findOneBy in getVolunteerById & updateVolunteerById to call findByIdOrFail instead.

[Yurika-Kan]

findOneBy loads no relations so assignedCoordinator comes back missing, should we pass it in as relations: ['assignedCoordinator']? @dburkhart07

[dburkhart07]

see above comment

[Yurika-Kan]

ticket says

Build PATCH /volunteers/:id endpoint. Address, city, zipcode, homebase, residentAnimals, notes, and fosterType should all be editable fields in the DTO.

but dto also exposes firstName, lastName, phone, secondaryPhone, email as editable fields - want to double check that's intended.. @dburkhart07

[dburkhart07]

still waiting on client communication for what fields we want to be editable. for right now, let's just say all the ones currently implemented here (there are a few noneditable fields that i already had removed), and we will limit scope later on as we get more information. good catch though, sorry about the inconsistency

[Yurika-Kan]

after addressing #2 (comment), everything will be aligned & it will lgtm <333