Challenge Overview
General Requirements
1. Initial PG schema can be found at app/dbmigrations/01_initial.sql
2. Implement the Update Task API, see swagger API for detail description
Only the following fields are edittable by a user who has write access - title, details, prizes, taskEligibility, tags, maxAllowedRegistrants, and modifiedBy and modifiedAt should be auto-updated.
3. Implement the Register Task API, see the swagger API for detail description
3.1 The reigstration can only be allowed when there is no registration for this task or these is less registrations than maxAlloedRegistrants. Otherwise, return properly error code.
3.2 Please reference tasks_registrants table for understanding.
3.3 there are a few additional checks, described following.
a user can register only if their account is listed under task eligibility for that specific role. Following is an example that task eligibility can be defined on the task
taskEligibility: {
[
{
role: "submitter",
users: [123,23433],
groups: []
},
{
role: "copilot",
users: [123,23433],
groups: []
},
{
role: "reviewer",
users: [123,23433],
groups: []
}
]
}
if taskEligibility object is empty or no eligibility is defined for that role or user list is empty - anyone can register
also only admins can register on behalf of another user, return 400 bad request if user A is registering for user B and user A is not administrator
As far as task Registration response goes - we can ignore the queuing part. We may implement that in a future release
4. Please write tests for the new APIs, follow the same approach as app/tests/test.spec.js.
4.1 We have already added a dependency on mocha (http://mochajs.org/) for mocking.. we can use that to inject test dependencies
4.2 executing `npm test` runs all test files (**/*.spec.js)
4.3 All test files should live along with the source but named *.spec.js, for eg. routes/tasks.js test file should be routes/tasks.spec.js
5. Existing approach should be followed for consistency
5.1 JSON field validations: use express-validation which is already used in current implemented APIs
5.2 Connection pooling: service should initialize a connection pool (configurable params) during startup. Each request should request a connection from the pool to perform its database transaction
5.3 Support for transactions: we will need support for transactions
5.4 Using ORMs: stick to Sequelize
5.5 Promises: Use promises over callbacks. If library doesn’t provide promise support consider wrapping it using bluebird (http://bluebirdjs.com/docs/getting-started.html)
Codebase
please use the dev branch for development, source code attached in forum.
Testing
We use docker & docker compose for all local dependencies. Here’s the link to setup local dependencies (https://github.com/appirio-tech/tc-tasks-service/blob/dev/README.md)
Final Submission Guidelines
1. Code changes for implemented APIs.2. Tests for the implemented APIs.
3. Manually API invokation by using POSTMAN