Refactor Assignment Subscription System
Description / Overview
In order to fully support the correction of assignments during the semester, we should refactor the current subscription system in such a way that functionality is more general, allowing us to use core concepts to correct both exams and weekly exercises.
For weekly exercises during the semester, we want to put students and tutors in groups as well as bypass the verification phase where feedback is cross-checked. Tutors should still be able to correct submission from other group's participants e.g. when another tutor is unable to correct their group. As a default behavior, we want the submission component to only show submissions from students of the current tutor's group. However, tutors should have some kind of drop-down menu that allows them to select submissions of another group. We can reuse this concept for exams by having one or zero groups that cannot be changed.
Additionally, the current subscription model is not used as it was intended when it was first implemented. We want to directly create assignments without having to use the subscription model, thus we need to think about how to refactor the functionality to lock / track assignments, etc.
New assignment service design
Endpoints / Functionality
-
GET /api/assignment/
- Responds with list of active assignments
-
POST /api/assignment/
- Requires SubmissionType, Stage and ExerciseGroup (optional)
- Responds with an assignment to a submission
- Responds with error code if no assignment could be created for the given parameters
-
DELETE /api/assignment/{id}/
- Frees the requested assignment without submitting freedback (used for skipping)
-
POST /api/assignment/{id}/finish/
- Requires Feedback to finish the assignment with
- Frees the related submission so that it can be edited again
Experimental / Open for discussion
I think we should create assignments anytime where feedbacks are issued / edited. This includes the history / participants overview as well. Since we already shortpoll feedback, we could have something like a "request to edit" functionality. Say we have Tutor A and Tutor B. A submitted feedback and noticed that he made a mistake and he wants to edit his feedback in the history. In the meantime, B created an assignment on A's original feedback to validate it. A now issues a request to edit his original feedback to a special endpoint. B shortpolls this endpoint and notices that he's got a request from A. B can now decide to decline or accept the request. If accepted, B's changes are saved (either saved locally or sent to the server, depends on whether we want A to see B's changes or not?) and A gets access to the submission, allowing him to edit the feedback. If B accepts, he has to wait until A has finished.
For the participants overview, we should include something similar. If the reviewer clicks on a submission, he gets an assignment for it, meanig it is locked. The reviewer is visually aware about the assignments for the submissions and if he wants to get access to a reserved submission, the above method applies.
Workflow:
Tutor A wants to correct a submission in stage n of submissiontype x. He issues a post request to /api/assignment/ with the post body being
{
"stage": 1,
"submission_type": x
}The server picks a random submission matching the given criteria and if found, attatches this submission to a new assignment entry that is bound to the user. Every submission that is attached to an unfinished assignment is excluded in the picking phase, so that no other tutor will ever get an assignment to the same submission that is actively being worked on. If Tutor A wants to skip a submission, he can delete the assignment by issuing a DELETE request to /api/assignment/{id}/. If Tutor A finished working on an assignment, he makes a POST to /api/assignment/{id}/finish, with the post body having the information about the feedback he just created.
Feature checklist
- Resolve #183 (closed)
- Add dedicated Group model
- Implement groups / group switching in frontend
(Make sure these are completed before closing the issue, with a link to the relevant commit.)