Challenge Overview
Make several improvements to invite related endpoints:
- add one more field to a model
- add a new DELETE endpoint
- change the logic of one method
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. Previously these endpoints had very custom logic non-compatible with REST standards. In the previous challenge, we updated most of the invite endpoints to be closer to RESTful standards, and in this challenge, we would complete it.
Also, we’ve implemented masking email addresses in the invite objects to protect user privacy and we would make a couple of improvements for this functionality.
Technology Stack
-
Node.js
-
PostgreSQL
-
ElasticSearch
Code access
The work for this challenge has to be done in 2 repositories:
- Project Service repo https://github.com/topcoder-platform/tc-project-service branch `feature/restful-invites` commit 26f2b0af6a158457726d6e77090f897874505e6a or later.
- Project ES Processor repo https://github.com/topcoder-platform/project-processor-es branch `develop` commit 5fa17456bbf646039b8b6f64fc49bcd96e490afe or later.
- It’s important for working on this challenge to read the guide from the beginning to understand how the project works and regarding ES/DB read/write logic.
- For local setup, please follow steps 1-4 in the section “Steps to run locally”. Steps 5 and 6 in the guide are not necessary for this challenge.
- Config is provided on the forum.
Individual requirements
1) Add “hashEmail” field
Add a new filed “hashEmail” to ProjectMemberInvite model. It would be an optional field that would contain a hash of email.
- create a migration SQL script to in “/migrations” folder to update DB accordingly to model changes.
- update invite endpoints so when we create invite or update invite we should set “hashEmail” as “md5(email)”.
- make sure that all the endpoints that return invites also return "hashEmail" field.
- update “project-processor-es” Kafka message handlers to validate ProjectMemberInvite objects according to changes.
- update “project-processor-es” unit tests, so example data in unit tests have some data in all the “hashEmail” field and make sure that unit tests pass.
2) Add `DELETE /v5/projects/:projectId(\\d+)/invites/:inviteId(\\d+)` endpoint
Invites with “canceled” status are not returned by our GET endpoints, so basically “canceled” invite is equal to deleted ones. We don’t delete them for real in DB, though we delete “canceled” invites in ES.
At the moment we use the PATCH endpoint to change the status of invites to “canceled” which is equal to deleted in our system. We would like to move this functionality to a separate DELETE endpoint, so you could reuse a lot of logic, or implement a similar way to PATCH endpoint.
Here are the main points:
- DELETE endpoint should be accessed by any logged-in user, the same as PATCH endpoint, see code.
- DELETE endpoint should find an invite to delete the same way as PATCH endpoint, see code. So it finds invite by “:projectId”, “:inviteId” from URL that is in status PENDING or REQUESTED, otherwise it should return error 404 same like PATCH endpoint. Please, create a reusable method for ProjectMemberInvite model for finding an invite which can be used in both PATHC and DELETE endpoints.
- The same permissions logic should be implemented for DELETE endpoint, see code (please, adapt it for DELETE endpoint).
- Instead of deleting the invitation, this endpoint should change invitation status to `INVITE_STATUS.CANCELED` in the DB.
- Implement unit tests for this new endpoint a similar way as we have for other invite endpoints. We don’t request coverage level, but implement all the meaningful tests, including tests for checking permissions logic and other requirements of this challenge which could be covered by unit tests.
- DELETE endpoint should send event `project.actions.delete` to Kafka so the `project-processor-es` would listen to it and remove invite from ES. For this purpose implement a handler for this event in `project-processor-es`, as it would have the same logic as update invite handler, please reuse the logic there.
- As we created a DELETE endpoint, the PATCH endpoint should not be able to change the status to “canceled” anymore. Remove any logic regarding “canceled” status from the PATCH endpoint and if we try to change the status to “canceled” return the error with code “400” and error message `Cannot change invite status to “canceled”. Please, delete the invite instead.`.
3) Update email mask
In any place where we are returning invites to non-admin users, we are masking emails using method maskEmail. Please update its logic so it would mask email in the way the length of a masked email is always the same. Use the next logic: keep the first letter, add 3 stars “*”, keep the last letter for both email name and email domain. For one letter email/domain duplicate the letter as first and last. See examples:
a@z.com -> a***a@z***z.com
ab@zy.com -> a***b@z***y.com
abc@zyx.com -> a***c@z***x.com
abcdefgh@zyxwvuts.com -> a***h@z***s.com
- Update unit tests for this method but keep all the test cases.
General requirements
-
We don’t require coverage percentage for unit tests, but, please, create unit tests to cover requirements in this challenge where possible.
-
In general, please, reuse the common logic between PATCH and DELETE endpoints when possible.
-
Update the swagger file to reflect changes.
-
Update postman file with an example of DELETE endpoint.
-
All existent unit tests should pass.
-
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:
-
2 git patches with changes you’ve made to the code in our repositories
Additionally, the winner would be required to raise pull requests to the repositories after the challenge is completed.