E1868 remove reports from review mapping controller

Background

review_mapping_controller is the largest controller in Expertiza with 614 lines of code. The basic functionality of this controller is to assign reviewers to review artefacts or submissions by other participants or teams. But this controller includes a major chunk of code for generating and rendering several reports to the instructors. As part of the project E1837[1], the review_mapping_controller.rb file has been significantly modified to improve maintainability, code quality and code readability. To summarize, the review_mapping_controller was modified by separating the report generation functionality into a new helper named report_formatter_helper. This helper serves the logic for rendering different reports as per the instructor's request, thus segregating the controller specific code from the code for rendering the reports.

Refactoring from E1837 served as one of the primary design improvements to achieve scalability with different reports. But, this improvement contradicts with several Object-Oriented Design Principles. The aim of this project is to extrapolate the report_formatter_helper code into a reports_controller.

Goals

- Separation of concerns

- Generalize code to render reports

- Modify the UI to list report types

- Write tests for the newly introduced reports_controller

- Modify the existing tests for the refactored version of review_mapping_controller

Separation of Concerns

The reports and reviews are two different components which should not be clubbed. As part of this refactoring, the existing design of review_mapping_controller which handles two different functionalities namely

1. Manage various reviewers

2. Display and manage different reports

will be segregated into two controllers to handle the individual concerns exclusively. The new design will have

1. review_mapping_controller to manage the functionalities of reviewers.

2. reports_controller to handle the reports functionalities.

Generalize code to display reports

Every report boils down to one single idea i.e. loop through either participants or teams. This loop can be generalized so that the layout(includes headers, footers etc) can be consistent across reports while delivering the desired content.

Modify the UI to list the types of reports

In the current implementation, the reports are accessed by clicking on the “view review report” button in the buttons tray of an assignment, which leads into the review report page. This page contains a drop-down menu near the top which has the list of reports to navigate to.

This two-step navigation to view the reports can be converted into a single step by introducing a new ‘...’ icon in the buttons tray, which on hovering on it, would show the menu of various reports.

Write tests for the new controller

Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be modified and new tests must be added for the controller.

Modify the existing tests for the refactored version of review_mapping_controller

With the refactored version of review_mapping_controller handling the reviews functionality, it is necessary to discard the tests corresponding to reports from the tests for reviews.

Implementation specifics

In order adhere to the good design practices, the logic to differentiate reports will be implemented using a strategy pattern. Currently, there are seven different reports

1. Review report

2. Author feedback report

3. Teammate review report

4. Aggregated comments by rubric question

5. Comment summary by reviewee(team)

6. Potential collusion report

7. Answer tagging report

The new implementation will have ReportStrategy class with following subclasses

- ReviewReportStrategy

- AuthorFeedbackReportStrategy

- TeammateReviewReportStrategy

- RubricQuestionReportStrategy

- RevieweeCommentReportStrategy

- CollusionReportStrategy

- AnswerTagReportStrategy

Below is a simple UML diagram of these new classes