Tasks service - MathparLearningTeam/Documentation GitHub Wiki

General purpose

Tasks service is responsible for storing all the tasks available in Mathpar Learning system. Task is considered to be any text written in Mathpar language (so technically lectures are also considered to be tasks with no answer). Besides storing texts, conditions and solutions, service also persists task ownership (who is author, who can make changes etc). Tasks can also have a hierarchy - any teacher can create a copy of the task to modify it, but the copy will always have a parent field indicating to the source task so the credit is never gone.

Database

There are following entities presented in DB:

• AnswerTask - this entity is the representation of open-answer task. It has a condition which is shown to user on start and a solution which is compared to user's answer. Both fields are text written in Mathpar. Also it has fields to store the author's account (not profile) id and source id if required (copied)
• NoAnswerTask - this entity is the representation of material written in Mathpar language. The task requires user only to read the material, so it has no solution. The material (text) is stored as a string field. Also it has fields to store the author's account (not profile) id and source id if required (copied).

In order to manage all entities we are using JPA (spring-data implementation). DDL are defined explicitly and manageable via sql scripts stored in "resources/ddl/*.sql". If any alteration to DB is required, the new script with the current timestamp should be created to store all the SQL code to make the change. The "dummy_schema.sql" exists to provide some examples of complex SQL queries as well as to be a placeholder if there will be no SQL scripts for some reason (without a single DDL script spring boot will start throwing errors on the startup).

Services

Alongside the default services for CRUD entities operations we have:

• AccountService. This service is responsible for communicating with Account service for authentication purposes.

Controllers

There are 2 levels of controllers in the project - public and private. All the public endpoints are annotated with @PublicApi and are available to client. Private endpoints can't have this annotation and are available only for the internal usage within the project.

Currently we have following public controllers:

• AnswerTaskController
• NoAnswerTaskController

Private controllers:

• HealthController. This controller is responsible for monitoring (healthchecks) of the service, it should return the current status of service and its resources

Properties

In order to function properly service requires additional properties to be supplied, like DB url/username/password, account service url etc. Those properties are injected in runtime using the bean "MathparProperties" defined in "PropertiesConfiguration" class. During the bean creation, it calls the secrets manager service to retrieve properties from a specific namespace and maps it to its own fields. This bean isn't created during the unit test runs to avoid depending on external services and make the testing fully autonomous.

Authentication and authorization

Authentication

Task service uses AccountService as CAS (central authentication service) to authenticate users. Authentication is implemented as OAuth tokens. Every time user sends a request it is supplied with the token in headers. Before processing the request, school service uses the SpringSecurity filter chain to extract the token, check its validity and propagate it to other steps.

Authorization

Task service is responsible for its own authorization system. Authorization to alter the task has only account who owns the task, so it's enough to check that authentication token belongs to the account which owns the task.