Development: Refactor Course Dashboard Filtering

[chrisknedl]

Checklist

General

• I tested all changes and their related features with all corresponding user types on a test server.
• This is a small issue that I tested locally and was confirmed by another developer on a test server.
• Language: I followed the guidelines for inclusive, diversity-sensitive, and appreciative language.
• I chose a title conforming to the naming conventions for pull requests.

Server

• Important: I implemented the changes with a very good performance and prevented too many (unnecessary) and too complex database calls.
• I strictly followed the server coding and design guidelines.
• I added multiple integration tests (Spring) related to the features (with a high test coverage).
• I documented the Java code using JavaDoc style.

Motivation and Context

There is a bug related to the data that is shown on the course dashboard (#9086). The related pieces of code were so convoluted that a fix without refactoring would have been very difficult to understand for reviewers, and would have further decreased the code's readability and maintainability.

Fixes #9086.

Description

Most importantly, the code assumed that for a singular student, multiple participations are possible for the same exercise, which is not true. Therefore, the ordering based on the initialization state has been removed, and the corresponding logic has been reduced to the relevant parts. Since only rated exercises are relevant for the course dashboard, practice programming exercise submissions are not considered any more.

The logic for submission filtering should not be included in the exercise entities, so it has been moved from the Exercise Entities to a new SubmissionFilterService, where instead of polymorphism, a case distinction is used to determine the relevant filter logic for the type of exercise.
The relevant result for the course dashboard now always comes with the connected submission. Previously, it was theoretically possible to return a result as part of a submission to which it previously did not belong.

Steps for Testing

Prerequisites:

• 1 Instructor
• Best to have a course with different types of exercises and submissions/results.

For the linked issue

1. Create a Programming exercise with online code editor and manual assessment. Set the due date one day in the future, and the assessment due date 2 days in the future.
2. Create an assignment repository, submit once.
3. Make some changes so that some of the tests pass, e.g. by creating and implementing the SortStrategy interface. Submit again.
4. Change the exercise due date to two minutes in the future and wait for it to pass.
5. Start assessing the submission. Add some feedback that slightly changes the score.

General

View the scores and statistics section in the course dashboard. The values should be the same on this branch as they are on develop. The statistics page should also show the same statistics.

Testserver States

You can manage test servers using Helios. Check environment statuses in the environment list. To deploy to a test server, go to the CI/CD page, find your PR or branch, and trigger the deployment.

Review Progress

Performance Review

• I (as a reviewer) confirm that the client changes (in particular related to REST calls and UI responsiveness) are implemented with a very good performance even for very large courses with more than 2000 students.
• I (as a reviewer) confirm that the server changes (in particular related to database calls) are implemented with a very good performance even for very large courses with more than 2000 students.

Code Review

• Code Review 1
• Code Review 2

Manual Tests

• Test 1
• Test 2

Performance Tests

• Test 1
• Test 2

Test Coverage

Screenshots