Topcoder Project Service - Filter Organization Configs

Update the endpoint to support filtering.

Project Background

Topcoder Project Service is the main backend service of Topcode Connect – the client-facing application of Topcoder. We have an endpoint that lists organization configs - “orgConfigs”. As per Topcoder “v5” API standard it works the next way:
- first, it tries to get data from the Elastic Seach index (as it’s the fastest way) using method “util.fetchFromES”
- but in case it didn’t get any data from the Elastic Search index, it fallbacks to the DB and gets data from there using the method “findAll”

This endpoint supports the filtering of ”orgConfigs” objects by “orgId” and “configName”, but currently, this support have a few issues which we are going to fix in this challenge.

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 v5-upgrade commit 203892f8685e32acc9796150447f1c541a384731 or later.

- Config for local setup is provided on the forum.

Individual requirements

1. Support filtering by multiple “orgId”

• Currently, endpoint  “/v5/projects/metadata/orgConfig” supports filtering by only single “orgId” like this:
  “/v5/projects/metadata/orgConfig?orgId=1234567”.

• Add support to filter by multiple “orgId”, so we can add them comma-separated, like this: “/v5/projects/metadata/orgConfig?orgId=123456,456789,987654”.

2. Filter data from ES (ElasticSearch index)

• At the moment when we request data from ES index, we don’t filter. We should fix it and apply filters by “orgId” and “configName” when we query data from ES. Note, that method “fetchFromES” supports the second param with “query”. Don’t filter data just by JS, query already filtered data from ES.

• As we have to use the filter for the ES query, move up the code to validate filter params, before the call to ES.

3. Unit tests

Note, that the current unit tests only check the case where data comes from DB.

Create at least 3 new unit tests:
1. “should return 200 for admin with filter (ES)” This unit test should work the same as the one we have now “should return 200 for admin with filter”. But the current unit test checks the case when data comes from “DB” and this new unit test should check the same case but when data comes from “ES”.
2. “should return 200 for admin and filter by multiple ‘orgId’ (DB)” - check that filtering by multiple “orgId” works properly when the data comes from DB.

3. “should return 200 for admin and filter by multiple ‘orgId’ (ES)” - check that filtering by multiple “orgId” works properly when the data comes from ES.

General requirements

• Existent unit tests should pass. Note, that some unit tests fail randomly when running altogether, so you may run only the unit tests for the files you have changed.

• Lint should pass.

• Git patch should be without errors or warnings.

Final Submission Guidelines

• Git patch.

• The winner would be required to raise a PR to the repository.