Challenge Overview
For this challenge, we'd like to add support of filtering on group ids for challenge listing page, mainly GET /challenges and GET /members/{handle}/challenges API.
1. Assuming there is a groupIds field in challenges type in elasticsearch. the filltering should be applied to this when querying the elasticsearch to get the list of challenges.
Notes, this field is not populated yet, it holds an array of integers, which represents the the list of group ids the challenge belong to. If the groupIds is missing or empty, it means the challenge is Public.
You can directly update the elasticsearch of that field for testing purpose.
2. If the API is accessed anonymously, the API will query only public challenges (with groupIds field empty or missing)
3. If the API is accessed with auth info, it will first call the Query Groups service to get a list of groups that user belong to, then query ES for challenges that is public or belong to the group list
4. The user groups service is not implemented. we'd like to create mock service for this. following are the description.
Query groups
GET /v3/groups?memberId={memberId}&membershipType={membershipType}
Request
Parameters
memberId (number, optional*) - ID of the member which belongs to groups to be searched.
membershipType (number, optional*) - Membership type of the member specified in memberId.
* both memberId and membershipType should be specified if one of them is specified.
Response (200)
OK
{
"id": "-6b6bcc07:15bae231ad8:-5d65",
"result": {
"success": true,
"status": 200,
"metadata": null,
"content": [
{
"id": "3",
"name": "ExampleGroup1",
"description": "This is an example group1.",
"modifiedBy": 12345678,
"modifiedAt": "2015-09-25T03:56:16.000Z",
"createdBy": 12345678,
"createdAt": "2015-09-25T03:56:16.000Z"
},
{
"id": "4",
"name": "ExampleGroup2",
"description": "This is an example group2.",
"modifiedBy": 12345678,
"modifiedAt": "2016-05-29T12:12:52.000Z",
"createdBy": 12345678,
"createdAt": "2015-09-25T03:56:16.000Z"
}
],
"version": "v3"
}
Response (401)
Missing Bearer or JWT is expired.
We can follow https://github.com/appirio-tech/tc-common-tutorials/tree/master/submission-system/docker/s3_mock_api to create the mock service, or you can create your own.
5. There should be a configuration for the Query Groups Service, so we can easily switch to the real one, when the service is implemented.
6. Support a groupIds in filter parameter, it should check the user groups first, and doing union operation before querying against ES. If groupIds is specified in filter parameter, public challenges should be filtered, that is saying we'd like a way to return a list of challenges that belong to a specific group the current user have access to.
7. Please create/update the postman scripts for testing.
8. swagger.yaml should be updated to describe the new usage properly.
About Local Setup
Please follow the guide in source code for reference.
- Mock Service for Query groups service
- Verification Steps
1. Assuming there is a groupIds field in challenges type in elasticsearch. the filltering should be applied to this when querying the elasticsearch to get the list of challenges.
Notes, this field is not populated yet, it holds an array of integers, which represents the the list of group ids the challenge belong to. If the groupIds is missing or empty, it means the challenge is Public.
You can directly update the elasticsearch of that field for testing purpose.
2. If the API is accessed anonymously, the API will query only public challenges (with groupIds field empty or missing)
3. If the API is accessed with auth info, it will first call the Query Groups service to get a list of groups that user belong to, then query ES for challenges that is public or belong to the group list
4. The user groups service is not implemented. we'd like to create mock service for this. following are the description.
Query groups
GET /v3/groups?memberId={memberId}&membershipType={membershipType}
Request
Parameters
memberId (number, optional*) - ID of the member which belongs to groups to be searched.
membershipType (number, optional*) - Membership type of the member specified in memberId.
* both memberId and membershipType should be specified if one of them is specified.
Response (200)
OK
{
"id": "-6b6bcc07:15bae231ad8:-5d65",
"result": {
"success": true,
"status": 200,
"metadata": null,
"content": [
{
"id": "3",
"name": "ExampleGroup1",
"description": "This is an example group1.",
"modifiedBy": 12345678,
"modifiedAt": "2015-09-25T03:56:16.000Z",
"createdBy": 12345678,
"createdAt": "2015-09-25T03:56:16.000Z"
},
{
"id": "4",
"name": "ExampleGroup2",
"description": "This is an example group2.",
"modifiedBy": 12345678,
"modifiedAt": "2016-05-29T12:12:52.000Z",
"createdBy": 12345678,
"createdAt": "2015-09-25T03:56:16.000Z"
}
],
"version": "v3"
}
Response (401)
Missing Bearer or JWT is expired.
We can follow https://github.com/appirio-tech/tc-common-tutorials/tree/master/submission-system/docker/s3_mock_api to create the mock service, or you can create your own.
5. There should be a configuration for the Query Groups Service, so we can easily switch to the real one, when the service is implemented.
6. Support a groupIds in filter parameter, it should check the user groups first, and doing union operation before querying against ES. If groupIds is specified in filter parameter, public challenges should be filtered, that is saying we'd like a way to return a list of challenges that belong to a specific group the current user have access to.
7. Please create/update the postman scripts for testing.
8. swagger.yaml should be updated to describe the new usage properly.
About Local Setup
Please follow the guide in source code for reference.
Final Submission Guidelines
- Code changes for supporting groupIds filtering- Mock Service for Query groups service
- Verification Steps