[WIP] Implement Grading structure

[remo5000]

• This is WIP, based off assessments. This branch will be rebased and the base of the PR will be changed to master once assessments is merged.
• The swagger documentation can be added in Add API specs for Controllers #41

Features

• Add a grading schema
• Modify Submission to fit with the Grading specification

Structure

This one needs review, as I am not aware of all the usecases of Grading/Submission.

Grading (schema):

• SubmissionId (FK, Submission)
• GraderId (FK, User)
• [GradingInfo(s)] (embed, GradingInfo)

GradingInfo (struct):

• QuestionId (FK, Question)
• marks (field, int)
• comment (field, string)

The ID of the student and grader are declared only once. In addition, any combination of information (e.g to pass to frontend) can be retrieved using foreign keys.

---

Todos

• Add the schema
• Remove duplicate fields from Submission (from assessments)
• Add all the fields specified
• Add tests
• Add FK for questions [BLOCKED]

What's next (new issues/PRs)

• Implement the functions specified by the controller in Add API specs for Controllers #41

[coveralls]

Pull Request Test Coverage Report for Build 360

• 0 of 4 (0.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-1.4%) to 93.95%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
lib/cadet/assessments/grading/grading.ex	0	2	0.0%
lib/cadet/assessments/grading/grading_info.ex	0	2	0.0%

Totals
Change from base Build 341:	-1.4%
Covered Lines:	264
Relevant Lines:	281

---

💛 - Coveralls

[indocomsoft]

As discussed in #41, I think there is no need to create additional models and/or tables since the structure in the API are just for display-only.

The models are in the assessments branch that will be merged very soon. But for now, maybe we can just look at the API specs in isolation -- once it is agreed upon, the backend team can start writing the controllers for it.

[remo5000]

As discussed in #41