Challenge Overview
Challenge Objectives
Update invite related endpoints to follow RESTful style and other small adjustments.
Project Background
Topcoder Project Service is the main backend service of Topcode Connect – the client-facing application of Topcoder. We have a set endpoint to manage invitations to the projects. Our current implementation of these endpoints doesn't follow the RESTful style and has a very custom logic. Also, there are some minor peculiarities that block us from implementing new features. So in this challenge, we would like to update existing endpoints to be more RESTful and support some minor features we need.
Technology Stack
-
Node.js
-
PostgreSQL
-
ElasticSearch
Code access
The work for this challenge has to be done in one repository:
- Project Service repo https://github.com/topcoder-platform/tc-project-service branch develop commit 9c4f5acd23fa1bcc76f5012581d7b6e58486c52d or later.
- A quick local setup guide with config is provided on the forum.
Individual requirements
Project Service
1) All the invite related endpoints have to use the next URL route as a base: `/v5/projects/:projectId(\\d+)/invites` (currently we have a mix of slightly different routes like `/v5/projects/:projectId(\\d+)/members/invite(s)`).
2) POST /v5/projects/:projectId(\\d+)/invites
Currently, the endpoint for creating invitations supports the body with the list of `userIds` and `emails`. Instead of `userIds` we should support the list of `handles`.
When we send the list of `handles` to this endpoint it should retrieve `userIds` by `handles` from the Member Service. For this purpose implement a new method `getMemberDetailsByHandles` similar to getMemberDetailsByUserIds which would find user details including userId by `handles` instead of by `userIds` see how we do it in Connect App for reference.
- when we cannot invite a user with some `userId`, we return a `failed` array with objects like `{ userId: , message: }`. In all such cases, we should return an object with `handle` instead of `userId` like `{ handle: , message: }`
- the rest of the code should work as it is. Please, keep your changes in this endpoint as small as possible to avoid issues in existing functionality.
3) GET /v5/projects/:projectId(\\d+)/invites
Currently, only users who can "view" the project may call this endpoint. We should allow ALL logged-in the users to call this endpoint. But, we should filter the results:
- users who can "view" the project should get the full list of invites as they can do now
- users who cannot "view" the project but are logged-in should get only invitations for themself. So if the invitation has `userId` OR `email` of the currently authorized user, we return such invitations.
- non-logged-in users should get error 401
4) GET /v5/projects/:projectId(\\d+)/invites/:inviteId(\\d+)
Currently, this endpoint doesn't support `inviteId` and it gets the invite for the user who is calling this endpoint. Instead, it should return an invitation by id (`inviteId` in the URL).
- We should get data from ES first, and fallback to DB if the invitation with the requested id is not found in ES.
- users who can "view" the project should be allowed to get any invite by id
- users who cannot "view" the project but are logged-in should only get an invitation by id for themself. So if the invitation has `userId` OR `email` of the currently authorized user, we return such invitation, otherwise, return error 404.
- non-logged-in users should get error 401
5) PATCH /v5/projects/:projectId(\\d+)/invites/:inviteId(\\d+)
- Use PATCH instead of PUT
- This endpoint should find an invitation by `inviteId` from URL instead of `userId` or `email` from the body
- Update validation rule so only `status` field can be updated.
- The rest logic should be kept as it is, like: we should only be able to update invites with status `pending` or `requested` and so on.
6) Unit tests
-
Implement unit tests for the existent endpoint to list invites (`list.js`). Do it similarly to other unit tests.
-
Implement unit test cases to verify all the requirements above like various permission cases, filtering records, returned data (including checking properties). While we don’t require coverage in percentage, we expect tests to properly verify requirements in this challenge.
-
Existent unit tests should pass. Update them when necessary according to the changes.
General requirements
-
Update Swagger files according to the changes
-
Update Postman files according to the changes
-
Lint should pass (don’t disable eslint rules).
-
Git patch should be without errors or warnings.
If you have any questions or concerns, feel free to raise a question on the forum.
Final Submission Guidelines
Submit a zip file which would include:
-
git patch with changes you’ve made to the code in our repository.
Additionally, the winner would be required to raise a pull request to the repository after the challenge is completed.