Conversation
dburkhart07
left a comment
There was a problem hiding this comment.
Few small changes. Additionally, can we use this PR to update the user entity? If you notice, all the other fieldsin our entity have a name, type, and sometimes a few other things. Can we apply that to firstName, lastName, and email?
| @Put(':id/info') | ||
| async updateInfo( | ||
| @Param('id', ParseIntPipe) id: number, | ||
| @Body() updateUserInfo: updateUserInfo, |
There was a problem hiding this comment.
Thoughts on making this change here:
We already have an update user role, and are now maing an update info endpoint. Would we rather have two separate updates, or just abstract this updateUserInfo DTO to include the role as well. We could then make it so the update function just takes the DTO instead of a Partial (this seems weird, we dont do this anywhere else), and adjust both functions' logic.
There was a problem hiding this comment.
If we needed both endpoints I would suggest keeping them separate for the sake of letting any user type call this endpoint, but limiting the update role endpoint to admins. But now that we have combined standard and lead volunteers, there is no longer any use case for updating a user's role, so we should just remove that endpoint.
| ): Promise<User> { | ||
| const { firstName, lastName, phone } = updateUserInfo; | ||
|
|
||
| const updateData: Partial<User> = {}; |
There was a problem hiding this comment.
Due to Sam's comment above, can we just make it so tha usersService.update now just takings in an updateUserInfo DTO, and do all the parsing/checking if valid values in there? While we are at it, let's use this as an opportunity to write unit tests for that service function. Use the format in orders.service.spec.ts as a reference for how we should go about it, as well as the dummy data in the testing db for what you should expect as results.
| describe('PUT /:id/role', () => { | ||
| it('should update user role with valid role', async () => { | ||
| const updatedUser = { ...mockUser1, role: Role.ADMIN }; | ||
| describe('PUT :id/info', () => { |
| mockUserRepository.save.mockResolvedValue(updatedUser as User); | ||
|
|
||
| const result = await service.update(1, dto); | ||
|
|
There was a problem hiding this comment.
we should check here that the updatedUser's firstName is now 'OnlyFirst'
| }); | ||
| }); | ||
|
|
||
| describe('update', () => { |
There was a problem hiding this comment.
- Please correct me if I'm wrong, but it looks like you added these new service tests this week? If so, can we write them according to the new style where we use the real testing database rather than mocking TypeORM? (You can use
order.service.spec.tsas an example, but also see the change Dalton made here) - Can we combine the
updatetests earlier in the file into these?
| @@ -0,0 +1,24 @@ | |||
| import { IsString, IsPhoneNumber, IsOptional, IsNotEmpty, MaxLength } from 'class-validator'; | |||
|
|
|||
| export class updateUserInfo { | |||
There was a problem hiding this comment.
Can we make this more consistent with our other DTOs by naming the file update-user-info.dto.ts and the class UpdateUserInfoDto?
|
|
||
| @Put('/:id/role') | ||
| async updateRole( | ||
| @Patch(':id/info') |
There was a problem hiding this comment.
We don't need the /info here since we are patching the user object itself
| const user = await this.findOne(id); | ||
| const { firstName, lastName, phone } = dto; | ||
|
|
||
| if (!user) { |
There was a problem hiding this comment.
Why was this check removed?
| BadRequestException, | ||
| ); | ||
| expect(mockUserService.update).not.toHaveBeenCalled(); | ||
| it('should update user info with defaults', async () => { |
There was a problem hiding this comment.
If we're adding a test where we try to call the controller method with an empty DTO, shouldn't the expected behavior be that we throw an exception?
| it('should update user info with defaults', async () => { | ||
| mockUserService.update.mockResolvedValue(mockUser1 as User); | ||
|
|
||
| const updateUserSchema: Partial<updateUserInfo> = {}; |
There was a problem hiding this comment.
We shouldn't need the Partial since all the DTO fields are optional anyway
ℹ️ Issue
Closes 102
📝 Description
Added an endpoint to update a user’s first name, last name, or phone number and tests for the controller to verify that it works.
✔️ Verification
Tested having no parameters, 2 parameters and 3 parameters and throwing the proper exceptions when having faulty data.
