Expertiza_Wiki - User contributions [en]

E1868 remove reports from review mapping controller

2019-01-03T03:11:51Z

Skeerth: /* Team */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_controller

=== Separation of Concerns ===
The reports and reviews are two different functionalities which should not be clubbed. As part of this refactoring, the existing design of review_mapping_controller handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This always forces the user to initially view the review report and only then choose the required report. We intend to modify this implementation such that the user is not forced to view the review report but can directly select the required report.

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are ten 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
:8. Calibration report
:9. Plagiarism checker report
:10. Self review report

The new implementation will have ReportFormatter module with following methods
:- ReviewReport
:- AuthorFeedbackReport
:- TeammateReviewReport
:- RubricQuestionReport
:- RevieweeCommentReport
:- CollusionReport
:- AnswerTagReport
:- CalibrationReport
:- PlagiarismCheckerReport
:- SelfReviewReport

UML representation of the new module is provided below

[[File:Complete Report strategy E1868.jpg|frame|center]]

=== Modified UI ===
In order to avoid the user to be redirected to review reports page every time the user wants to view a specific report, the following changes have been made to the implementation:

:1. The icon in view assignments page has been renamed from "view review report" to "view reports" to generalize.

[[File:assignment_view.jpg | frame | center]]

:2. On clicking the "view reports" icon, the user is directed to a new page that has the drop-down to select the required report.

[[File:reports_view.jpg | frame | center]]

= Test Plan =

The use case of reports gives a broad overview of the functionality. It also provides the preliminary tests to be written to ensure the proper working of the feature. Below use case diagram represents the intent of reports functionality.

[[File:Basic Use case for reports.jpg|frame|center]]

RSpec is the preferred testing framework in the project. The first set of test cases deal with the retrieval of different reports for assignments and validating the fields returned by the reports. The details are as follows(sample reports screenshot included)

:1. When the requested report type is "SummaryByRevieweeAndCriteria", we check that the corresponding data is rendered. This report should contain a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.

[[File:Reviewee summary report.jpg|frame|center]]

:2. When the requested report type is "SummaryByCriteria", we check that the corresponding data is rendered. This report should include a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.

[[File:Review summary report.jpg|frame|center]]

:3. When the requested report type is "ReviewResponseMap", we check the corresponding report data is rendered. This reports participants, average and range.

[[File:Review report.jpg|frame|center]]

:4A. When the requested report type is "FeedbackResponseMap" and assignment has varying rubrics by round feature, we check the corresponding participants' data related to feedback i.e. number of feedbacks done, last feedback status.
:4B. When the requested report type is "FeedbackResponseMap" and when the assignment does not have varying rubrics by round feature, we check the corresponding participants' data related to feedback i.e. number of feedbacks done, last feedback status.

[[File:Feedback report.jpg|frame|center]]

:5. When the requested report type is "TeammateReviewResponseMap", we check that there is a correct mapping between the participant and its response. The report must return participant information, the number of reviews completed, teammates reviewed, the last review status.

[[File:Teammate review report.jpg|frame|center]]

:6. When the requested report type is "Calibration" and participant is not empty we check if the correct report is rendered or not. The report must return the calibrated values of the participants' response to the given assignment.

[[File:Calibration report.jpg|frame|center]]

:7. When the requested report type is "AnswerTaggingReport", we check if the correct report page is rendered or not. The report must render the participants' details, the number of taggable answers, the number of answers tagged, the number of answers not tagged and the percentage of answers tagged.

[[File:Answer tagging report.jpg|frame|center]]

:8. When the requested report type is "PlagiarismCheckerReport", we check if the correct report page is rendered or not.
:9. When the requested report type is "CollusionReport", we check if the correct report page is rendered or not.
:10. When the requested report type is "SelfReviewReport", we check if the correct report page is rendered or not.

Since this refactoring project includes a new controller, the idea from the test perspective is to cover the basic scenarios of the feature. Complete feature coverage including corner case scenarios shall be committed based on the schedule for the project.

= Team =

[mailto:rvijaya4@ncsu.edu Ramya Vijayakumar]<br>
[mailto:skeerth@ncsu.edu Suhas Keerthiraju]<br>
[mailto:rdange@ncsu.edu Rajat Mahesh Dange]<br>
[mailto:ssaluja@ncsu.edu Sahej Saluja]<br>

E1868 remove reports from review mapping controller

2019-01-03T03:06:51Z

Skeerth:

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_controller

=== Separation of Concerns ===
The reports and reviews are two different functionalities which should not be clubbed. As part of this refactoring, the existing design of review_mapping_controller handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This always forces the user to initially view the review report and only then choose the required report. We intend to modify this implementation such that the user is not forced to view the review report but can directly select the required report.

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are ten 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
:8. Calibration report
:9. Plagiarism checker report
:10. Self review report

The new implementation will have ReportFormatter module with following methods
:- ReviewReport
:- AuthorFeedbackReport
:- TeammateReviewReport
:- RubricQuestionReport
:- RevieweeCommentReport
:- CollusionReport
:- AnswerTagReport
:- CalibrationReport
:- PlagiarismCheckerReport
:- SelfReviewReport

UML representation of the new module is provided below

[[File:Complete Report strategy E1868.jpg|frame|center]]

=== Modified UI ===
In order to avoid the user to be redirected to review reports page every time the user wants to view a specific report, the following changes have been made to the implementation:

:1. The icon in view assignments page has been renamed from "view review report" to "view reports" to generalize.

[[File:assignment_view.jpg | frame | center]]

:2. On clicking the "view reports" icon, the user is directed to a new page that has the drop-down to select the required report.

[[File:reports_view.jpg | frame | center]]

= Test Plan =

The use case of reports gives a broad overview of the functionality. It also provides the preliminary tests to be written to ensure the proper working of the feature. Below use case diagram represents the intent of reports functionality.

[[File:Basic Use case for reports.jpg|frame|center]]

RSpec is the preferred testing framework in the project. The first set of test cases deal with the retrieval of different reports for assignments and validating the fields returned by the reports. The details are as follows(sample reports screenshot included)

:1. When the requested report type is "SummaryByRevieweeAndCriteria", we check that the corresponding data is rendered. This report should contain a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.

[[File:Reviewee summary report.jpg|frame|center]]

:2. When the requested report type is "SummaryByCriteria", we check that the corresponding data is rendered. This report should include a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.

[[File:Review summary report.jpg|frame|center]]

:3. When the requested report type is "ReviewResponseMap", we check the corresponding report data is rendered. This reports participants, average and range.

[[File:Review report.jpg|frame|center]]

:4A. When the requested report type is "FeedbackResponseMap" and assignment has varying rubrics by round feature, we check the corresponding participants' data related to feedback i.e. number of feedbacks done, last feedback status.
:4B. When the requested report type is "FeedbackResponseMap" and when the assignment does not have varying rubrics by round feature, we check the corresponding participants' data related to feedback i.e. number of feedbacks done, last feedback status.

[[File:Feedback report.jpg|frame|center]]

:5. When the requested report type is "TeammateReviewResponseMap", we check that there is a correct mapping between the participant and its response. The report must return participant information, the number of reviews completed, teammates reviewed, the last review status.

[[File:Teammate review report.jpg|frame|center]]

:6. When the requested report type is "Calibration" and participant is not empty we check if the correct report is rendered or not. The report must return the calibrated values of the participants' response to the given assignment.

[[File:Calibration report.jpg|frame|center]]

:7. When the requested report type is "AnswerTaggingReport", we check if the correct report page is rendered or not. The report must render the participants' details, the number of taggable answers, the number of answers tagged, the number of answers not tagged and the percentage of answers tagged.

[[File:Answer tagging report.jpg|frame|center]]

:8. When the requested report type is "PlagiarismCheckerReport", we check if the correct report page is rendered or not.
:9. When the requested report type is "CollusionReport", we check if the correct report page is rendered or not.
:10. When the requested report type is "SelfReviewReport", we check if the correct report page is rendered or not.

Since this refactoring project includes a new controller, the idea from the test perspective is to cover the basic scenarios of the feature. Complete feature coverage including corner case scenarios shall be committed based on the schedule for the project.

= Team =

:1. Ramya Vijayakumar
:2. Suhas Keerthiraju
:3. Rajat Mahesh Dange
:4. Sahej Saluja

File:Complete Report strategy E1868.jpg

2018-12-07T22:30:58Z

Skeerth: Added complete list of reports

Added complete list of reports

E1868 remove reports from review mapping controller

2018-12-07T22:30:22Z

Skeerth: /* Refactored Design */

E1868 remove reports from review mapping controller

2018-12-07T21:04:54Z

Skeerth: /* Test Plan */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_controller

=== Separation of Concerns ===
The reports and reviews are two different functionalities which should not be clubbed. As part of this refactoring, the existing design of review_mapping_controller handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This always forces the user to initially view the review report and only then choose the required report. We intend to modify this implementation such that the user is not forced to view the review report but can directly select the required report.

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are ten 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
:8. Calibration report
:9. Plagiarism checker report
:10. Self review report

The new implementation will have ReportFormatter module with following methods
:- ReviewReport
:- AuthorFeedbackReport
:- TeammateReviewReport
:- RubricQuestionReport
:- RevieweeCommentReport
:- CollusionReport
:- AnswerTagReport
:- CalibrationReport
:- PlagiarismCheckerReport
:- SelfReviewReport

UML representation of the new module is provided below

[[File:Modified Report strategy E1868.jpg|frame|center]]

=== Modified UI ===
In order to avoid the user to be redirected to review reports page every time the user wants to view a specific report, the following changes have been made to the implementation:

:1. The icon in view assignments page has been renamed from "view review report" to "view reports" to generalize.

[[File:assignment_view.jpg | frame | center]]

:2. On clicking the "view reports" icon, the user is directed to a new page that has the drop-down to select the required report.

[[File:reports_view.jpg | frame | center]]

= Test Plan =

The use case of reports gives a broad overview of the functionality. It also provides the preliminary tests to be written to ensure the proper working of the feature. Below use case diagram represents the intent of reports functionality.

[[File:Basic Use case for reports.jpg|frame|center]]

RSpec is the preferred testing framework in the project. The first set of test cases deal with the retrieval of different reports for assignments and validating the fields returned by the reports. The details are as follows(sample reports screenshot included)

:1. When the requested report type is "SummaryByRevieweeAndCriteria", we check that the corresponding data is rendered. This report should contain a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.

[[File:Reviewee summary report.jpg|frame|center]]

:2. When the requested report type is "SummaryByCriteria", we check that the corresponding data is rendered. This report should include a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.

[[File:Review summary report.jpg|frame|center]]

:3. When the requested report type is "ReviewResponseMap", we check the corresponding report data is rendered. This reports participants, average and range.

[[File:Review report.jpg|frame|center]]

:4A. When the requested report type is "FeedbackResponseMap" and assignment has varying rubrics by round feature, we check the corresponding participants' data related to feedback i.e. number of feedbacks done, last feedback status.
:4B. When the requested report type is "FeedbackResponseMap" and when the assignment does not have varying rubrics by round feature, we check the corresponding participants' data related to feedback i.e. number of feedbacks done, last feedback status.

[[File:Feedback report.jpg|frame|center]]

:5. When the requested report type is "TeammateReviewResponseMap", we check that there is a correct mapping between the participant and its response. The report must return participant information, the number of reviews completed, teammates reviewed, the last review status.

[[File:Teammate review report.jpg|frame|center]]

:6. When the requested report type is "Calibration" and participant is not empty we check if the correct report is rendered or not. The report must return the calibrated values of the participants' response to the given assignment.

[[File:Calibration report.jpg|frame|center]]

:7. When the requested report type is "AnswerTaggingReport", we check if the correct report page is rendered or not. The report must render the participants' details, the number of taggable answers, the number of answers tagged, the number of answers not tagged and the percentage of answers tagged.

[[File:Answer tagging report.jpg|frame|center]]

:8. When the requested report type is "PlagiarismCheckerReport", we check if the correct report page is rendered or not.
:9. When the requested report type is "CollusionReport", we check if the correct report page is rendered or not.
:10. When the requested report type is "SelfReviewReport", we check if the correct report page is rendered or not.

Since this refactoring project includes a new controller, the idea from the test perspective is to cover the basic scenarios of the feature. Complete feature coverage including corner case scenarios shall be committed based on the schedule for the project.

E1868 remove reports from review mapping controller

2018-12-07T21:02:36Z

Skeerth: /* Test Plan */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_controller

=== Separation of Concerns ===
The reports and reviews are two different functionalities which should not be clubbed. As part of this refactoring, the existing design of review_mapping_controller handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This always forces the user to initially view the review report and only then choose the required report. We intend to modify this implementation such that the user is not forced to view the review report but can directly select the required report.

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are ten 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
:8. Calibration report
:9. Plagiarism checker report
:10. Self review report

The new implementation will have ReportFormatter module with following methods
:- ReviewReport
:- AuthorFeedbackReport
:- TeammateReviewReport
:- RubricQuestionReport
:- RevieweeCommentReport
:- CollusionReport
:- AnswerTagReport
:- CalibrationReport
:- PlagiarismCheckerReport
:- SelfReviewReport

UML representation of the new module is provided below

[[File:Modified Report strategy E1868.jpg|frame|center]]

=== Modified UI ===
In order to avoid the user to be redirected to review reports page every time the user wants to view a specific report, the following changes have been made to the implementation:

:1. The icon in view assignments page has been renamed from "view review report" to "view reports" to generalize.

[[File:assignment_view.jpg | frame | center]]

:2. On clicking the "view reports" icon, the user is directed to a new page that has the drop-down to select the required report.

[[File:reports_view.jpg | frame | center]]

= Test Plan =

The use case of reports gives a broad overview of the functionality. It also provides the preliminary tests to be written to ensure the proper working of the feature. Below use case diagram represents the intent of reports functionality.

[[File:Basic Use case for reports.jpg|frame|center]]

RSpec is the preferred testing framework in the project. The first set of test cases deal with the retrieval of different reports for assignments and validating the fields returned by the reports. The details are as follows(sample reports screenshot included)

:1. When the requested report type is "SummaryByRevieweeAndCriteria", we check that the corresponding data is rendered. This report should contain a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.

[[File:Reviewee summary report.jpg|frame|center]]

:2. When the requested report type is "SummaryByCriteria", we check that the corresponding data is rendered. This report should include a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.

[[File:Review summary report.jpg|frame|center]]

:3. When the requested report type is "ReviewResponseMap", we check the corresponding report data is rendered. This reports participants, average and range.

[[File:Review report.jpg|frame|center]]

:4A. When the requested report type is "FeedbackResponseMap" and assignment has varying rubrics by round feature, we check the corresponding participants' data related to feedback i.e. number of feedbacks done, last feedback status.
:4B. When the requested report type is "FeedbackResponseMap" and when the assignment does not have varying rubrics by round feature, we check the corresponding participants' data related to feedback i.e. number of feedbacks done, last feedback status.

[[File:Feedback report.jpg|frame|center]]

:5. When the requested report type is "TeammateReviewResponseMap", we check that there is a correct mapping between the participant and its response. The report must return participant information, the number of reviews completed, teammates reviewed, the last review status.

[[File:Teammate review report.jpg|frame|center]]

:6. When the requested report type is "Calibration" and participant is not empty we check if the correct report is rendered or not. The report must return the calibrated values of the participants' response to the given assignment.

[[File:Calibration report.jpg|frame|center]]

:7. When the requested report type is "PlagiarismCheckerReport", we check if the correct report page is rendered or not.

:8. When the requested report type is "AnswerTaggingReport", we check if the correct report page is rendered or not. The report must render the participants' details, the number of taggable answers, the number of answers tagged, the number of answers not tagged and the percentage of answers tagged.

[[File:Answer tagging report.jpg|frame|center]]

Since this refactoring project includes a new controller, the idea from the test perspective is to cover the basic scenarios of the feature. Complete feature coverage including corner case scenarios shall be committed based on the schedule for the project.

File:Answer tagging report.jpg

2018-12-07T20:58:11Z

Skeerth: Sample answer tagging report

Sample answer tagging report

E1868 remove reports from review mapping controller

2018-12-07T20:57:02Z

Skeerth: /* Test Plan */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_controller

=== Separation of Concerns ===
The reports and reviews are two different functionalities which should not be clubbed. As part of this refactoring, the existing design of review_mapping_controller handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This always forces the user to initially view the review report and only then choose the required report. We intend to modify this implementation such that the user is not forced to view the review report but can directly select the required report.

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are ten 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
:8. Calibration report
:9. Plagiarism checker report
:10. Self review report

The new implementation will have ReportFormatter module with following methods
:- ReviewReport
:- AuthorFeedbackReport
:- TeammateReviewReport
:- RubricQuestionReport
:- RevieweeCommentReport
:- CollusionReport
:- AnswerTagReport
:- CalibrationReport
:- PlagiarismCheckerReport
:- SelfReviewReport

UML representation of the new module is provided below

[[File:Modified Report strategy E1868.jpg|frame|center]]

=== Modified UI ===
In order to avoid the user to be redirected to review reports page every time the user wants to view a specific report, the following changes have been made to the implementation:

:1. The icon in view assignments page has been renamed from "view review report" to "view reports" to generalize.

[[File:assignment_view.jpg | frame | center]]

:2. On clicking the "view reports" icon, the user is directed to a new page that has the drop-down to select the required report.

[[File:reports_view.jpg | frame | center]]

= Test Plan =

The use case of reports gives a broad overview of the functionality. It also provides the preliminary tests to be written to ensure the proper working of the feature. Below use case diagram represents the intent of reports functionality.

[[File:Basic Use case for reports.jpg|frame|center]]

RSpec is the preferred testing framework in the project. The first set of test cases deal with the retrieval of different reports for assignments and validating the fields returned by the reports. The details are as follows(sample reports screenshot included)

:1. When the requested report type is "SummaryByRevieweeAndCriteria", we check that the corresponding data is rendered. This report should contain a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.

[[File:Reviewee summary report.jpg|frame|center]]

:2. When the requested report type is "SummaryByCriteria", we check that the corresponding data is rendered. This report should include a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.

[[File:Review summary report.jpg|frame|center]]

:3. When the requested report type is "ReviewResponseMap", we check the corresponding report data is rendered. This reports participants, average and range.

[[File:Review report.jpg|frame|center]]

:4A. When the requested report type is "FeedbackResponseMap" and assignment has varying rubrics by round feature, we check the corresponding participants' data related to feedback i.e. number of feedbacks done, last feedback status.
:4B. When the requested report type is "FeedbackResponseMap" and when the assignment does not have varying rubrics by round feature, we check the corresponding participants' data related to feedback i.e. number of feedbacks done, last feedback status.

[[File:Feedback report.jpg|frame|center]]

:5. When the requested report type is "TeammateReviewResponseMap", we check that there is a correct mapping between the participant and its response. The report must return participant information, the number of reviews completed, teammates reviewed, the last review status.

[[File:Teammate review report.jpg|frame|center]]

:6. When the requested report type is "Calibration" and participant is not empty we check if the correct report is rendered or not. The report must return the calibrated values of the participants' response to the given assignment.

[[File:Calibration report.jpg|frame|center]]

:7. When the requested report type is "PlagiarismCheckerReport", we check if the correct report page is rendered or not.

:8. When the requested report type is "AnswerTaggingReport", we check if the correct report page is rendered or not.

[[File:Answer tagging report.jpg|frame|center]]

Since this refactoring project includes a new controller, the idea from the test perspective is to cover the basic scenarios of the feature. Complete feature coverage including corner case scenarios shall be committed based on the schedule for the project.

File:Basic Use case for reports.jpg

2018-12-07T20:54:20Z

Skeerth: uploaded a new version of "File:Basic Use case for reports.jpg": Accommodated complete list of reports

New report types added

File:Basic Use case for reports.jpg

2018-12-07T20:40:29Z

Skeerth: New report types added

New report types added

E1868 remove reports from review mapping controller

2018-12-07T20:40:05Z

Skeerth: /* Test Plan */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_controller

=== Separation of Concerns ===
The reports and reviews are two different functionalities which should not be clubbed. As part of this refactoring, the existing design of review_mapping_controller handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This always forces the user to initially view the review report and only then choose the required report. We intend to modify this implementation such that the user is not forced to view the review report but can directly select the required report.

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are ten 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
:8. Calibration report
:9. Plagiarism checker report
:10. Self review report

The new implementation will have ReportFormatter module with following methods
:- ReviewReport
:- AuthorFeedbackReport
:- TeammateReviewReport
:- RubricQuestionReport
:- RevieweeCommentReport
:- CollusionReport
:- AnswerTagReport
:- CalibrationReport
:- PlagiarismCheckerReport
:- SelfReviewReport

UML representation of the new module is provided below

[[File:Modified Report strategy E1868.jpg|frame|center]]

=== Modified UI ===
In order to avoid the user to be redirected to review reports page every time the user wants to view a specific report, the following changes have been made to the implementation:

:1. The icon in view assignments page has been renamed from "view review report" to "view reports" to generalize.

[[File:assignment_view.jpg | frame | center]]

:2. On clicking the "view reports" icon, the user is directed to a new page that has the drop-down to select the required report.

[[File:reports_view.jpg | frame | center]]

= Test Plan =

The use case of reports gives a broad overview of the functionality. It also provides the preliminary tests to be written to ensure the proper working of the feature. Below use case diagram represents the intent of reports functionality.

[[File:Basic Use case for reports.jpg|frame|center]]

RSpec is the preferred testing framework in the project. The first set of test cases deal with the retrieval of different reports for assignments and validating the fields returned by the reports. The details are as follows(sample reports screenshot included)

:1. When the requested report type is "SummaryByRevieweeAndCriteria", we check that the corresponding data is rendered. This report should contain a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.

[[File:Reviewee summary report.jpg|frame|center]]

:2. When the requested report type is "SummaryByCriteria", we check that the corresponding data is rendered. This report should include a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.

[[File:Review summary report.jpg|frame|center]]

:3. When the requested report type is "ReviewResponseMap", we check the corresponding report data is rendered. This reports participants, average and range.

[[File:Review report.jpg|frame|center]]

:4A. When the requested report type is "FeedbackResponseMap" and assignment has varying rubrics by round feature, we check the corresponding participants' data related to feedback i.e. number of feedbacks done, last feedback status.
:4B. When the requested report type is "FeedbackResponseMap" and when the assignment does not have varying rubrics by round feature, we check the corresponding participants' data related to feedback i.e. number of feedbacks done, last feedback status.

[[File:Feedback report.jpg|frame|center]]

:5. When the requested report type is "TeammateReviewResponseMap", we check that there is a correct mapping between the participant and its response. The report must return participant information, the number of reviews completed, teammates reviewed, the last review status.

[[File:Teammate review report.jpg|frame|center]]

:6. When the requested report type is "Calibration" and participant is not empty we check if the correct report is rendered or not. The report must return the calibrated values of the participants' response to the given assignment.

[[File:Calibration report.jpg|frame|center]]

:7. When the requested report type is "PlagiarismCheckerReport", we check if the correct report page is rendered or not.

Since this refactoring project includes a new controller, the idea from the test perspective is to cover the basic scenarios of the feature. Complete feature coverage including corner case scenarios shall be committed based on the schedule for the project.

File:Use case for reports.jpg

2018-12-07T20:39:12Z

Skeerth: uploaded a new version of "File:Use case for reports.jpg": Added new reports

Updated use case representation for reports

E1868 remove reports from review mapping controller

2018-12-07T20:23:44Z

Skeerth: /* Refactored Design */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_controller

=== Separation of Concerns ===
The reports and reviews are two different functionalities which should not be clubbed. As part of this refactoring, the existing design of review_mapping_controller handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This always forces the user to initially view the review report and only then choose the required report. We intend to modify this implementation such that the user is not forced to view the review report but can directly select the required report.

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are ten 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
:8. Calibration report
:9. Plagiarism checker report
:10. Self review report

The new implementation will have ReportFormatter module with following methods
:- ReviewReport
:- AuthorFeedbackReport
:- TeammateReviewReport
:- RubricQuestionReport
:- RevieweeCommentReport
:- CollusionReport
:- AnswerTagReport
:- CalibrationReport
:- PlagiarismCheckerReport
:- SelfReviewReport

UML representation of the new module is provided below

[[File:Modified Report strategy E1868.jpg|frame|center]]

=== Modified UI ===
In order to avoid the user to be redirected to review reports page every time the user wants to view a specific report, the following changes have been made to the implementation:

:1. The icon in view assignments page has been renamed from "view review report" to "view reports" to generalize.

[[File:assignment_view.jpg | frame | center]]

:2. On clicking the "view reports" icon, the user is directed to a new page that has the drop-down to select the required report.

[[File:reports_view.jpg | frame | center]]

= Test Plan =

The use case of reports gives a broad overview of the functionality. It also provides the preliminary tests to be written to ensure the proper working of the feature. Below use case diagram represents the intent of reports functionality.

[[File:Use case for reports.jpg|frame|center]]

RSpec is the preferred testing framework in the project. The first set of test cases deal with the retrieval of different reports for assignments and validating the fields returned by the reports. The details are as follows(sample reports screenshot included)

:1. When the requested report type is "SummaryByRevieweeAndCriteria", we check that the corresponding data is rendered. This report should contain a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.

[[File:Reviewee summary report.jpg|frame|center]]

:2. When the requested report type is "SummaryByCriteria", we check that the corresponding data is rendered. This report should include a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.

[[File:Review summary report.jpg|frame|center]]

:3. When the requested report type is "ReviewResponseMap", we check the corresponding report data is rendered. This reports participants, average and range.

[[File:Review report.jpg|frame|center]]

:4A. When the requested report type is "FeedbackResponseMap" and assignment has varying rubrics by round feature, we check the corresponding participants' data related to feedback i.e. number of feedbacks done, last feedback status.
:4B. When the requested report type is "FeedbackResponseMap" and when the assignment does not have varying rubrics by round feature, we check the corresponding participants' data related to feedback i.e. number of feedbacks done, last feedback status.

[[File:Feedback report.jpg|frame|center]]

:5. When the requested report type is "TeammateReviewResponseMap", we check that there is a correct mapping between the participant and its response. The report must return participant information, the number of reviews completed, teammates reviewed, the last review status.

[[File:Teammate review report.jpg|frame|center]]

:6. When the requested report type is "Calibration" and participant is not empty we check if the correct report is rendered or not. The report must return the calibrated values of the participants' response to the given assignment.

[[File:Calibration report.jpg|frame|center]]

:7. When the requested report type is "PlagiarismCheckerReport", we check if the correct report page is rendered or not.

Since this refactoring project includes a new controller, the idea from the test perspective is to cover the basic scenarios of the feature. Complete feature coverage including corner case scenarios shall be committed based on the schedule for the project.

File:Use case for reports.jpg

2018-12-07T17:43:52Z

Skeerth: Updated use case representation for reports

Updated use case representation for reports

E1868 remove reports from review mapping controller

2018-12-07T17:42:38Z

Skeerth: /* Test Plan */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_controller

=== Separation of Concerns ===
The reports and reviews are two different functionalities which should not be clubbed. As part of this refactoring, the existing design of review_mapping_controller handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This always forces the user to initially view the review report and only then choose the required report. We intend to modify this implementation such that the user is not forced to view the review report but can directly select the required report.

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are eight 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
:8. Calibration report

The new implementation will have ReportFormatter module with following methods
:- ReviewReport
:- AuthorFeedbackReport
:- TeammateReviewReport
:- RubricQuestionReport
:- RevieweeCommentReport
:- CollusionReport
:- AnswerTagReport
:- CalibrationReport

UML representation of the new classes is provided below

[[File:Modified Report strategy E1868.jpg|frame|center]]

=== Modified UI ===
In order to avoid the user to be redirected to review reports page every time the user wants to view a specific report, the following changes have been made to the implementation:

:1. The icon in view assignments page has been renamed from "view review report" to "view reports" to generalize.

[[File:assignment_view.jpg | frame | center]]

:2. On clicking the "view reports" icon, the user is directed to a new page that has the drop-down to select the required report.

[[File:reports_view.jpg | frame | center]]

= Test Plan =

The use case of reports gives a broad overview of the functionality. It also provides the preliminary tests to be written to ensure the proper working of the feature. Below use case diagram represents the intent of reports functionality.

[[File:Use case for reports.jpg|frame|center]]

RSpec is the preferred testing framework in the project. The first set of test cases deal with the retrieval of different reports for assignments and validating the fields returned by the reports. The details are as follows(sample reports screenshot included)

:1. When the requested report type is "SummaryByRevieweeAndCriteria", we check that the corresponding data is rendered. This report should contain a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.

[[File:Reviewee summary report.jpg|frame|center]]

:2. When the requested report type is "SummaryByCriteria", we check that the corresponding data is rendered. This report should include a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.

[[File:Review summary report.jpg|frame|center]]

:3. When the requested report type is "ReviewResponseMap", we check the corresponding report data is rendered. This reports participants, average and range.

[[File:Review report.jpg|frame|center]]

:4A. When the requested report type is "FeedbackResponseMap" and assignment has varying rubrics by round feature, we check the corresponding participants' data related to feedback i.e. number of feedbacks done, last feedback status.
:4B. When the requested report type is "FeedbackResponseMap" and when the assignment does not have varying rubrics by round feature, we check the corresponding participants' data related to feedback i.e. number of feedbacks done, last feedback status.

[[File:Feedback report.jpg|frame|center]]

:5. When the requested report type is "TeammateReviewResponseMap", we check that there is a correct mapping between the participant and its response. The report must return participant information, the number of reviews completed, teammates reviewed, the last review status.

[[File:Teammate review report.jpg|frame|center]]

:6. When the requested report type is "Calibration" and participant is not empty we check if the correct report is rendered or not. The report must return the calibrated values of the participants' response to the given assignment.

[[File:Calibration report.jpg|frame|center]]

:7. When the requested report type is "PlagiarismCheckerReport", we check if the correct report page is rendered or not.

Since this refactoring project includes a new controller, the idea from the test perspective is to cover the basic scenarios of the feature. Complete feature coverage including corner case scenarios shall be committed based on the schedule for the project.

File:Report use case.jpg

2018-12-07T17:41:47Z

Skeerth: uploaded a new version of "File:Report use case.jpg": View privileges updated

use case for reports

E1868 remove reports from review mapping controller

2018-12-07T17:40:12Z

Skeerth: /* Modified UI */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_controller

=== Separation of Concerns ===
The reports and reviews are two different functionalities which should not be clubbed. As part of this refactoring, the existing design of review_mapping_controller handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This always forces the user to initially view the review report and only then choose the required report. We intend to modify this implementation such that the user is not forced to view the review report but can directly select the required report.

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are eight 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
:8. Calibration report

The new implementation will have ReportFormatter module with following methods
:- ReviewReport
:- AuthorFeedbackReport
:- TeammateReviewReport
:- RubricQuestionReport
:- RevieweeCommentReport
:- CollusionReport
:- AnswerTagReport
:- CalibrationReport

UML representation of the new classes is provided below

[[File:Modified Report strategy E1868.jpg|frame|center]]

=== Modified UI ===
In order to avoid the user to be redirected to review reports page every time the user wants to view a specific report, the following changes have been made to the implementation:

:1. The icon in view assignments page has been renamed from "view review report" to "view reports" to generalize.

[[File:assignment_view.jpg | frame | center]]

:2. On clicking the "view reports" icon, the user is directed to a new page that has the drop-down to select the required report.

[[File:reports_view.jpg | frame | center]]

= Test Plan =

The use case of reports gives a broad overview of the functionality. It also provides the preliminary tests to be written to ensure the proper working of the feature. Below use case diagram represents the intent of reports functionality.

[[File:Report use case.jpg|frame|center]]

RSpec is the preferred testing framework in the project. The first set of test cases deal with the retrieval of different reports for assignments and validating the fields returned by the reports. The details are as follows(sample reports screenshot included)

:1. When the requested report type is "SummaryByRevieweeAndCriteria", we check that the corresponding data is rendered. This report should contain a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.

[[File:Reviewee summary report.jpg|frame|center]]

:2. When the requested report type is "SummaryByCriteria", we check that the corresponding data is rendered. This report should include a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.

[[File:Review summary report.jpg|frame|center]]

:3. When the requested report type is "ReviewResponseMap", we check the corresponding report data is rendered. This reports participants, average and range.

[[File:Review report.jpg|frame|center]]

:4A. When the requested report type is "FeedbackResponseMap" and assignment has varying rubrics by round feature, we check the corresponding participants' data related to feedback i.e. number of feedbacks done, last feedback status.
:4B. When the requested report type is "FeedbackResponseMap" and when the assignment does not have varying rubrics by round feature, we check the corresponding participants' data related to feedback i.e. number of feedbacks done, last feedback status.

[[File:Feedback report.jpg|frame|center]]

:5. When the requested report type is "TeammateReviewResponseMap", we check that there is a correct mapping between the participant and its response. The report must return participant information, the number of reviews completed, teammates reviewed, the last review status.

[[File:Teammate review report.jpg|frame|center]]

:6. When the requested report type is "Calibration" and participant is not empty we check if the correct report is rendered or not. The report must return the calibrated values of the participants' response to the given assignment.

[[File:Calibration report.jpg|frame|center]]

:7. When the requested report type is "PlagiarismCheckerReport", we check if the correct report page is rendered or not.

Since this refactoring project includes a new controller, the idea from the test perspective is to cover the basic scenarios of the feature. Complete feature coverage including corner case scenarios shall be committed based on the schedule for the project.

E1868 remove reports from review mapping controller

2018-12-07T17:38:57Z

Skeerth: /* Test Plan */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_controller

=== Separation of Concerns ===
The reports and reviews are two different functionalities which should not be clubbed. As part of this refactoring, the existing design of review_mapping_controller handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This always forces the user to initially view the review report and only then choose the required report. We intend to modify this implementation such that the user is not forced to view the review report but can directly select the required report.

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are eight 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
:8. Calibration report

The new implementation will have ReportFormatter module with following methods
:- ReviewReport
:- AuthorFeedbackReport
:- TeammateReviewReport
:- RubricQuestionReport
:- RevieweeCommentReport
:- CollusionReport
:- AnswerTagReport
:- CalibrationReport

UML representation of the new classes is provided below

[[File:Modified Report strategy E1868.jpg|frame|center]]

=== Modified UI ===
In order to avoid the user to be redirected to review reports page every time the user wants to view a specific report, the following changes have been made to the implementation:

:1. The icon in view assignments page has been renamed from "view review report" to "view reports" to generalize.

[[File:assignment_view.jpg | frame | center]]

:2. On clicking the "view reports" icon, the user is directed to a new page that has the drop-down to select the required report.

[[File:reports_view.jpg | frame | center]]

= Test Plan =

The use case of reports gives a broad overview of the functionality. It also provides the preliminary tests to be written to ensure the proper working of the feature. Below use case diagram represents the intent of reports functionality.

[[File:Report use case.jpg|frame|center]]

RSpec is the preferred testing framework in the project. The first set of test cases deal with the retrieval of different reports for assignments and validating the fields returned by the reports. The details are as follows(sample reports screenshot included)

:1. When the requested report type is "SummaryByRevieweeAndCriteria", we check that the corresponding data is rendered. This report should contain a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.

[[File:Reviewee summary report.jpg|frame|center]]

:2. When the requested report type is "SummaryByCriteria", we check that the corresponding data is rendered. This report should include a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.

[[File:Review summary report.jpg|frame|center]]

:3. When the requested report type is "ReviewResponseMap", we check the corresponding report data is rendered. This reports participants, average and range.

[[File:Review report.jpg|frame|center]]

:4A. When the requested report type is "FeedbackResponseMap" and assignment has varying rubrics by round feature, we check the corresponding participants' data related to feedback i.e. number of feedbacks done, last feedback status.
:4B. When the requested report type is "FeedbackResponseMap" and when the assignment does not have varying rubrics by round feature, we check the corresponding participants' data related to feedback i.e. number of feedbacks done, last feedback status.

[[File:Feedback report.jpg|frame|center]]

:5. When the requested report type is "TeammateReviewResponseMap", we check that there is a correct mapping between the participant and its response. The report must return participant information, the number of reviews completed, teammates reviewed, the last review status.

[[File:Teammate review report.jpg|frame|center]]

:6. When the requested report type is "Calibration" and participant is not empty we check if the correct report is rendered or not. The report must return the calibrated values of the participants' response to the given assignment.

[[File:Calibration report.jpg|frame|center]]

:7. When the requested report type is "PlagiarismCheckerReport", we check if the correct report page is rendered or not.

Since this refactoring project includes a new controller, the idea from the test perspective is to cover the basic scenarios of the feature. Complete feature coverage including corner case scenarios shall be committed based on the schedule for the project.

File:Calibration report.jpg

2018-12-07T17:28:10Z

Skeerth: Sample "Calibration report"

Sample "Calibration report"

File:Teammate review report.jpg

2018-12-07T17:27:42Z

Skeerth: Sample "Teammate review report"

Sample "Teammate review report"

File:Feedback report.jpg

2018-12-07T17:27:13Z

Skeerth: Sample "Author feedback report"

Sample "Author feedback report"

File:Review report.jpg

2018-12-07T17:26:43Z

Skeerth: Sample "Review report"

Sample "Review report"

File:Review summary report.jpg

2018-12-07T17:26:21Z

Skeerth: Sample "Review summary report"

Sample "Review summary report"

File:Reviewee summary report.jpg

2018-12-07T17:25:32Z

Skeerth: Sample "Reviewee summary report"

Sample "Reviewee summary report"

File:Report use case.jpg

2018-12-07T17:23:59Z

Skeerth: uploaded a new version of "File:Report use case.jpg": Update on previleges

use case for reports

E1868 remove reports from review mapping controller

2018-12-07T17:23:04Z

Skeerth: /* Test Plan */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_controller

=== Separation of Concerns ===
The reports and reviews are two different functionalities which should not be clubbed. As part of this refactoring, the existing design of review_mapping_controller handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This always forces the user to initially view the review report and only then choose the required report. We intend to modify this implementation such that the user is not forced to view the review report but can directly select the required report.

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are eight 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
:8. Calibration report

The new implementation will have ReportFormatter module with following methods
:- ReviewReport
:- AuthorFeedbackReport
:- TeammateReviewReport
:- RubricQuestionReport
:- RevieweeCommentReport
:- CollusionReport
:- AnswerTagReport
:- CalibrationReport

UML representation of the new classes is provided below

[[File:Modified Report strategy E1868.jpg|frame|center]]

=== Modified UI ===
In order to avoid the user to be redirected to review reports page every time the user wants to view a specific report, the following changes have been made to the implementation:

:1. The icon in view assignments page has been renamed from "view review report" to "view reports" to generalize.

[[File:assignment_view.jpg | frame | center]]

:2. On clicking the "view reports" icon, the user is directed to a new page that has the drop-down to select the required report.

[[File:reports_view.jpg | frame | center]]

= Test Plan =

The use case of reports gives a broad overview of the functionality. It also provides the preliminary tests to be written to ensure the proper working of the feature. Below use case diagram represents the intent of reports functionality.

[[File:Report use case.jpg|frame|center]]

RSpec is the preferred testing framework in the project. The first set of test cases deal with the retrieval of different reports for assignments and validating the fields returned by the reports. The details are as follows(sample reports screenshot included)

:1. When the requested report type is "SummaryByRevieweeAndCriteria", we check that the corresponding data is rendered. This report should contain a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.

[[File:Reviewee summary report.jpg|frame|center]]

:2. When the requested report type is "SummaryByCriteria", we check that the corresponding data is rendered. This report should include a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.

[[File:Review summary report.jpg|frame|center]]

:3. When the requested report type is "ReviewResponseMap", we check the corresponding report data is rendered. This reports participants, average and range.

[[File:Review report.jpg|frame|center]]

:4A. When the requested report type is "FeedbackResponseMap" and assignment has varying rubrics by round feature, we check the corresponding participants' data is rendered.
:4B. When the requested report type is "FeedbackResponseMap" and when the assignment does not have varying rubrics by round feature, we check the corresponding participants' data is rendered.

[[File:Feedback report.jpg|frame|center]]

:5. When the requested report type is "TeammateReviewResponseMap", we check that there is a correct mapping between the participant and its response. We will return participant for the corresponding response.

[[File:Teammate review report.jpg|frame|center]]

:6. When the requested report type is "Calibration" and participant variable is not nil we check if the correct report is rendered or not.

[[File:Calibration report.jpg|frame|center]]

:7. When the requested report type is "PlagiarismCheckerReport", we check if the correct report page is rendered or not.

Since this refactoring project includes a new controller, the idea from the test perspective is to cover the basic scenarios of the feature. Complete feature coverage including corner case scenarios shall be committed based on the schedule for the project.

E1868 remove reports from review mapping controller

2018-12-07T16:23:45Z

Skeerth: /* Modified UI */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_controller

=== Separation of Concerns ===
The reports and reviews are two different functionalities which should not be clubbed. As part of this refactoring, the existing design of review_mapping_controller handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This always forces the user to initially view the review report and only then choose the required report. We intend to modify this implementation such that the user is not forced to view the review report but can directly select the required report.

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are eight 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
:8. Calibration report

The new implementation will have ReportFormatter module with following methods
:- ReviewReport
:- AuthorFeedbackReport
:- TeammateReviewReport
:- RubricQuestionReport
:- RevieweeCommentReport
:- CollusionReport
:- AnswerTagReport
:- CalibrationReport

UML representation of the new classes is provided below

[[File:Modified Report strategy E1868.jpg|frame|center]]

=== Modified UI ===
In order to avoid the user to be redirected to review reports page every time the user wants to view a specific report, the following changes have been made to the implementation:

:1. The icon in view assignments page has been renamed from "view review report" to "view reports" to generalize.

[[File:assignment_view.jpg | frame | center]]

:2. On clicking the "view reports" icon, the user is directed to a new page that has the drop-down to select the required report.

[[File:reports_view.jpg | frame | center]]

= Test Plan =

The use case of reports gives a broad overview of the functionality. It also provides the preliminary tests to be written to ensure the proper working of the feature. Below use case diagram represents the intent of reports functionality.

[[File:Report use case.jpg|frame|center]]

RSpec is the preferred testing framework in the project. The first set of test cases deal with the retrieval of different reports for assignments and validating the fields returned by the reports. The details are as follows

:1. When the requested report type is "SummaryByRevieweeAndCriteria", we check that the corresponding data is rendered. This report should contain a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:2. When the requested report type is "SummaryByCriteria", we check that the corresponding data is rendered. This report should include a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:3. When the requested report type is "ReviewResponseMap", we check the corresponding report data is rendered. This reports participants, average and range.
:4. When the requested report type is "FeedbackResponseMap" and assignment has varying rubrics by round feature, we check the corresponding participants' data is rendered.
:5. When the requested report type is "FeedbackResponseMap" and when the assignment does not have varying rubrics by round feature, we check the corresponding participants' data is rendered.
:6. When the requested report type is "TeammateReviewResponseMap", we check that there is a correct mapping between the participant and its response. We will return participant for the corresponding response.
:7. When the requested report type is "Calibration" and participant variable is not nil we check if the correct report is rendered or not.
:8. When the requested report type is "PlagiarismCheckerReport", we check if the correct report page is rendered or not.

Since this refactoring project includes a new controller, the idea from the test perspective is to cover the basic scenarios of the feature. Complete feature coverage including corner case scenarios shall be committed based on the schedule for the project.

File:Modified Report strategy E1868.jpg

2018-11-28T00:51:52Z

Skeerth: UML changes to represent module and method interactions

UML changes to represent module and method interactions

E1868 remove reports from review mapping controller

2018-11-28T00:50:41Z

Skeerth: /* Refactored Design */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_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 handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This two-step navigation to view the reports can be converted into a single step. There are two ways of doing so:
:1. Introduce a new ‘...’ icon in the buttons tray, which on hovering on it, would show the menu of various reports
:2. Rename the "view review report" button to reports with a drop down menu listing all the report types

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are eight 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
:8. Calibration report

The new implementation will have ReportFormatter module with following methods
:- ReviewReport
:- AuthorFeedbackReport
:- TeammateReviewReport
:- RubricQuestionReport
:- RevieweeCommentReport
:- CollusionReport
:- AnswerTagReport
:- CalibrationReport

UML representation of the new classes is provided below

[[File:Modified Report strategy E1868.jpg|frame|center]]

=== Modified UI ===
:1. One of the proposed changes to existing UI involves adding a new button to the buttons tray. For the assignment ‘Final Project (and Design Document)’ below, hovering over the ‘...’ icon (highlighted in the red box) should bring up the menu of additional reports. The image is only an illustration.

[[File: Reports icon.jpg|frame|centre]]

:2. Another proposed change is to modify "view review report" button to "view reports" drop-down menu listing all the available reports for the respective assignment.

The major drawback in the above proposed methods is that the user needs to return to the "view assignments" page each time a different report must be viewed. This repeats in a loop every time the user wants to view different reports for the same assignment.

'''***HENCE, THE ABOVE PROPOSED UI CHANGES ARE DEFERRED****'''

The icon in view assignments page has been renamed from "view review report" to "view reports" to generalize.

= Test Plan =

The use case of reports gives a broad overview of the functionality. It also provides the preliminary tests to be written to ensure the proper working of the feature. Below use case diagram represents the intent of reports functionality.

[[File:Report use case.jpg|frame|center]]

RSpec is the preferred testing framework in the project. The first set of test cases deal with the retrieval of different reports for assignments and validating the fields returned by the reports. The details are as follows

:1. When the requested report type is "SummaryByRevieweeAndCriteria", we check that the corresponding data is rendered. This report should contain a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:2. When the requested report type is "SummaryByCriteria", we check that the corresponding data is rendered. This report should include a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:3. When the requested report type is "ReviewResponseMap", we check the corresponding report data is rendered. This reports participants, average and range.
:4. When the requested report type is "FeedbackResponseMap" and assignment has varying rubrics by round feature, we check the corresponding participants' data is rendered.
:5. When the requested report type is "FeedbackResponseMap" and when the assignment does not have varying rubrics by round feature, we check the corresponding participants' data is rendered.
:6. When the requested report type is "TeammateReviewResponseMap", we check that there is a correct mapping between the participant and its response. We will return participant for the corresponding response.
:7. When the requested report type is "Calibration" and participant variable is not nil we check if the correct report is rendered or not.
:8. When the requested report type is "PlagiarismCheckerReport", we check if the correct report page is rendered or not.

Since this refactoring project includes a new controller, the idea from the test perspective is to cover the basic scenarios of the feature. Complete feature coverage including corner case scenarios shall be committed based on the schedule for the project.

File:Report strategy E1868.jpg

2018-11-28T00:48:35Z

Skeerth: uploaded a new version of "File:Report strategy E1868.jpg": New implementation

report strategy new

File:Report strategy E1868.jpg

2018-11-28T00:46:47Z

Skeerth: uploaded a new version of "File:Report strategy E1868.jpg": New implementation

report strategy new

E1868 remove reports from review mapping controller

2018-11-21T03:23:16Z

Skeerth: /* Test Plan */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_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 handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This two-step navigation to view the reports can be converted into a single step. There are two ways of doing so:
:1. Introduce a new ‘...’ icon in the buttons tray, which on hovering on it, would show the menu of various reports
:2. Rename the "view review report" button to reports with a drop down menu listing all the report types

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are eight 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
:8. Calibration report

The new implementation will have ReportStrategy class with following subclasses
:- ReviewReportStrategy
:- AuthorFeedbackReportStrategy
:- TeammateReviewReportStrategy
:- RubricQuestionReportStrategy
:- RevieweeCommentReportStrategy
:- CollusionReportStrategy
:- AnswerTagReportStrategy
:- CalibrationReportStrategy

UML representation of the new classes is provided below

[[File:Report strategy E1868.jpg|frame|center]]

=== Modified UI ===
:1. One of the proposed changes to existing UI involves adding a new button to the buttons tray. For the assignment ‘Final Project (and Design Document)’ below, hovering over the ‘...’ icon (highlighted in the red box) should bring up the menu of additional reports. The image is only an illustration.

[[File: Reports icon.jpg|frame|centre]]

:2. Another proposed change is to modify "view review report" button to "view reports" drop-down menu listing all the available reports for the respective assignment.

= Test Plan =

The use case of reports gives a broad overview of the functionality. It also provides the preliminary tests to be written to ensure the proper working of the feature. Below use case diagram represents the intent of reports functionality.

[[File:Report use case.jpg|frame|center]]

RSpec is the preferred testing framework in the project. The first set of test cases deal with the retrieval of different reports for assignments and validating the fields returned by the reports. The details are as follows

:1. When the requested report type is "SummaryByRevieweeAndCriteria", we check that the corresponding data is rendered. This report should contain a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:2. When the requested report type is "SummaryByCriteria", we check that the corresponding data is rendered. This report should include a summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:3. When the requested report type is "ReviewResponseMap", we check the corresponding report data is rendered. This reports participants, average and range.
:4. When the requested report type is "FeedbackResponseMap" and assignment has varying rubrics by round feature, we check the corresponding participants' data is rendered.
:5. When the requested report type is "FeedbackResponseMap" and when the assignment does not have varying rubrics by round feature, we check the corresponding participants' data is rendered.
:6. When the requested report type is "TeammateReviewResponseMap", we check that there is a correct mapping between the participant and its response. We will return participant for the corresponding response.
:7. When the requested report type is "Calibration" and participant variable is not nil we check if the correct report is rendered or not.
:8. When the requested report type is "PlagiarismCheckerReport", we check if the correct report page is rendered or not.

Since this refactoring project includes a new controller, the idea from the test perspective is to cover the basic scenarios of the feature. Complete feature coverage including corner case scenarios shall be committed based on the schedule for the project.

E1868 remove reports from review mapping controller

2018-11-21T03:17:00Z

Skeerth: /* Test Plan */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_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 handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This two-step navigation to view the reports can be converted into a single step. There are two ways of doing so:
:1. Introduce a new ‘...’ icon in the buttons tray, which on hovering on it, would show the menu of various reports
:2. Rename the "view review report" button to reports with a drop down menu listing all the report types

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are eight 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
:8. Calibration report

The new implementation will have ReportStrategy class with following subclasses
:- ReviewReportStrategy
:- AuthorFeedbackReportStrategy
:- TeammateReviewReportStrategy
:- RubricQuestionReportStrategy
:- RevieweeCommentReportStrategy
:- CollusionReportStrategy
:- AnswerTagReportStrategy
:- CalibrationReportStrategy

UML representation of the new classes is provided below

[[File:Report strategy E1868.jpg|frame|center]]

=== Modified UI ===
:1. One of the proposed changes to existing UI involves adding a new button to the buttons tray. For the assignment ‘Final Project (and Design Document)’ below, hovering over the ‘...’ icon (highlighted in the red box) should bring up the menu of additional reports. The image is only an illustration.

[[File: Reports icon.jpg|frame|centre]]

:2. Another proposed change is to modify "view review report" button to "view reports" drop-down menu listing all the available reports for the respective assignment.

= Test Plan =

The use case of reports gives a broad overview of the functionality. It also provides the preliminary tests to be written to ensure the proper working of the feature. Below use case diagram represents the intent of reports functionality.

[[File:Report use case.jpg|frame|center]]

RSpec is the preferred testing framework in the project. The first set of test cases deal with the retrieval of different reports for assignments and validating the fields returned by the reports. The details are as follows

:1. When the requested report type is "SummaryByRevieweeAndCriteria", we check that the corresponding data is rendered. This report should contain summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:2. When the requested report type is "SummaryByCriteria", we check that the corresponding data is rendered. This report should include summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:3. When the requested report type is "ReviewResponseMap", we check the corresponding report data is rendered. This reports participants, average and range.
:4. When the requested report type is "FeedbackResponseMap" and assignment has varying rubrics by round feature, we check the corresponding participants data is rendered.
:5. When the requested report type is "FeedbackResponseMap" and when assignment does not have varying rubrics by round feature, we check the corresponding participants data is rendered..
:6. When the requested report type is "TeammateReviewResponseMap", we check that there is a correct mapping between the participant and its response. We will return participant for the corresponding response.
:7. When the requested report type is "Calibration" and participant variable is not nil we check if the correct report is rendered or not.
:8. When the requested report type is "PlagiarismCheckerReport", we check if the correct report page is rendered or not.

E1868 remove reports from review mapping controller

2018-11-21T02:47:20Z

Skeerth: /* Test Plan */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_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 handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This two-step navigation to view the reports can be converted into a single step. There are two ways of doing so:
:1. Introduce a new ‘...’ icon in the buttons tray, which on hovering on it, would show the menu of various reports
:2. Rename the "view review report" button to reports with a drop down menu listing all the report types

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are eight 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
:8. Calibration report

The new implementation will have ReportStrategy class with following subclasses
:- ReviewReportStrategy
:- AuthorFeedbackReportStrategy
:- TeammateReviewReportStrategy
:- RubricQuestionReportStrategy
:- RevieweeCommentReportStrategy
:- CollusionReportStrategy
:- AnswerTagReportStrategy
:- CalibrationReportStrategy

UML representation of the new classes is provided below

[[File:Report strategy E1868.jpg|frame|center]]

=== Modified UI ===
:1. One of the proposed changes to existing UI involves adding a new button to the buttons tray. For the assignment ‘Final Project (and Design Document)’ below, hovering over the ‘...’ icon (highlighted in the red box) should bring up the menu of additional reports. The image is only an illustration.

[[File: Reports icon.jpg|frame|centre]]

:2. Another proposed change is to modify "view review report" button to "view reports" drop-down menu listing all the available reports for the respective assignment.

= Test Plan =

The use case of reports gives a broad overview of the functionality. It also provides the preliminary tests to be written to ensure the proper working of the feature. Below use case diagram represents the intent of reports functionality.

[[File:Report use case.jpg|frame|center]]

RSpec is the preferred testing framework for review mapping controller. The first set of test cases deal with the retrieval of different reports for assignments and validating the fields returned by the reports. The details are as follows
:1. When the type is SummaryByRevieweeAndCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:2. When the type is SummaryByCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:3. When the type is ReviewResponseMap we check the corresponding report data is rendered. This returns participants, average and range.
:4. When the type is FeedbackResponseMap and assignment has varying_rubrics_by_round feature we check the corresponding report data is rendered. It should return participants.
:5. When the type is FeedbackResponseMap and when assignment does not have varying_rubrics_by_round feature we check the corresponding page to report is rendered and participants are rendered.
:6. When the type is TeammateReviewResponseMap we check that there is a correct mapping between the participant and its response. We will return participant for the corresponding response.
:7. When the type is Calibration and participant variable is nil we check if the correct report is rendered or not.
:8. When the type is PlagiarismCheckerReport we check if the correct report page is rendered or not.

E1868 remove reports from review mapping controller

2018-11-21T02:45:32Z

Skeerth: /* Implementation specifics */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_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 handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This two-step navigation to view the reports can be converted into a single step. There are two ways of doing so:
:1. Introduce a new ‘...’ icon in the buttons tray, which on hovering on it, would show the menu of various reports
:2. Rename the "view review report" button to reports with a drop down menu listing all the report types

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are eight 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
:8. Calibration report

The new implementation will have ReportStrategy class with following subclasses
:- ReviewReportStrategy
:- AuthorFeedbackReportStrategy
:- TeammateReviewReportStrategy
:- RubricQuestionReportStrategy
:- RevieweeCommentReportStrategy
:- CollusionReportStrategy
:- AnswerTagReportStrategy
:- CalibrationReportStrategy

UML representation of the new classes is provided below

[[File:Report strategy E1868.jpg|frame|center]]

=== Modified UI ===
:1. One of the proposed changes to existing UI involves adding a new button to the buttons tray. For the assignment ‘Final Project (and Design Document)’ below, hovering over the ‘...’ icon (highlighted in the red box) should bring up the menu of additional reports. The image is only an illustration.

[[File: Reports icon.jpg|frame|centre]]

:2. Another proposed change is to modify "view review report" button to "view reports" drop-down menu listing all the available reports for the respective assignment.

= Test Plan =

The use case of reports gives a broad overview of the functionality. It also provides the preliminary tests to be written to ensure the proper working of the feature. Below use case diagram represents the intent of reports functionality.

[[File:Report use case.jpg|frame|center]]

RSpec is the preferred testing framework for review mapping controller. The first set of test cases deal with the retrieval of different reports for assignments and validating the fields returned by the reports. The details are as follows
:1 When the type is SummaryByRevieweeAndCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:2 When the type is SummaryByCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:3 When the type is ReviewResponseMap we check the corresponding report data is rendered. This returns participants, average and range.
:4 When the type is FeedbackResponseMap and assignment has varying_rubrics_by_round feature we check the corresponding report data is rendered. It should return participants.
:5 When the type is FeedbackResponseMap and when assignment does not have varying_rubrics_by_round feature we check the corresponding page to report is rendered and participants are rendered.
:6 When the type is TeammateReviewResponseMap we check that there is a correct mapping between the participant and its response. We will return participant for the corresponding response.
:7 When the type is Calibration and participant variable is nil we check if the correct report is rendered or not.
:8 When the type is PlagiarismCheckerReport we check if the correct report page is rendered or not.

E1868 remove reports from review mapping controller

2018-11-21T02:44:50Z

Skeerth: /* Refactored Design */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_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 handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This two-step navigation to view the reports can be converted into a single step. There are two ways of doing so:
:1. Introduce a new ‘...’ icon in the buttons tray, which on hovering on it, would show the menu of various reports
:2. Rename the "view review report" button to reports with a drop down menu listing all the report types

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are eight 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
:8. Calibration report

The new implementation will have ReportStrategy class with following subclasses
:- ReviewReportStrategy
:- AuthorFeedbackReportStrategy
:- TeammateReviewReportStrategy
:- RubricQuestionReportStrategy
:- RevieweeCommentReportStrategy
:- CollusionReportStrategy
:- AnswerTagReportStrategy
:- CalibrationReportStrategy

UML representation of the new classes is provided below

[[File:Report strategy E1868.jpg|frame|center]]

=== Modified UI ===
:1. One of the proposed changes to existing UI involves adding a new button to the buttons tray. For the assignment ‘Final Project (and Design Document)’ below, hovering over the ‘...’ icon (highlighted in the red box) should bring up the menu of additional reports. The image is only an illustration.

[[File: Reports icon.jpg|frame|centre]]

:2. Another proposed change is to modify "view review report" button to "view reports" drop-down menu listing all the available reports for the respective assignment.

= Test Plan =

The use case of reports gives a broad overview of the functionality. It also provides the preliminary tests to be written to ensure the proper working of the feature. Below use case diagram represents the intent of reports functionality.

[[File:Report use case.jpg|frame|center]]

RSpec is the preferred testing framework for review mapping controller. The first set of test cases deal with the retrieval of different reports for assignments and validating the fields returned by the reports. The details are as follows
:1 When the type is SummaryByRevieweeAndCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:2 When the type is SummaryByCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:3 When the type is ReviewResponseMap we check the corresponding report data is rendered. This returns participants, average and range.
:4 When the type is FeedbackResponseMap and assignment has varying_rubrics_by_round feature we check the corresponding report data is rendered. It should return participants.
:5 When the type is FeedbackResponseMap and when assignment does not have varying_rubrics_by_round feature we check the corresponding page to report is rendered and participants are rendered.
:6 When the type is TeammateReviewResponseMap we check that there is a correct mapping between the participant and its response. We will return participant for the corresponding response.
:7 When the type is Calibration and participant variable is nil we check if the correct report is rendered or not.
:8 When the type is PlagiarismCheckerReport we check if the correct report page is rendered or not.

E1868 remove reports from review mapping controller

2018-11-21T02:44:36Z

Skeerth: /* Refactored Design */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_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 handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This two-step navigation to view the reports can be converted into a single step. There are two ways of doing so:
:1. Introduce a new ‘...’ icon in the buttons tray, which on hovering on it, would show the menu of various reports
:2. Rename the "view review report" button to reports with a drop down menu listing all the report types

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are eight 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
:8. Calibration report

The new implementation will have ReportStrategy class with following subclasses
:- ReviewReportStrategy
:- AuthorFeedbackReportStrategy
:- TeammateReviewReportStrategy
:- RubricQuestionReportStrategy
:- RevieweeCommentReportStrategy
:- CollusionReportStrategy
:- AnswerTagReportStrategy
:- CalibrationReportStrategy

UML representation of the new classes is provided below

[[File:Report strategy E1868.jpg|frame|center]]

=== Modified UI ===
:1. One of the proposed changes to existing UI involves adding a new button to the buttons tray. For the assignment ‘Final Project (and Design Document)’ below, hovering over the ‘...’ icon (highlighted in the red box) should bring up the menu of additional reports. The image is only an illustration.

[[File: Reports icon.jpg|frame|centre]]

:2. Another proposed change is to modify "view review report" button to "view reports" drop-down menu listing all the available reports for the respective assignment.

= Test Plan =

The use case of reports gives a broad overview of the functionality. It also provides the preliminary tests to be written to ensure the proper working of the feature. Below use case diagram represents the intent of reports functionality.

[[File:Report use case.jpg|frame|center]]

RSpec is the preferred testing framework for review mapping controller. The first set of test cases deal with the retrieval of different reports for assignments and validating the fields returned by the reports. The details are as follows
:1 When the type is SummaryByRevieweeAndCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:2 When the type is SummaryByCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:3 When the type is ReviewResponseMap we check the corresponding report data is rendered. This returns participants, average and range.
:4 When the type is FeedbackResponseMap and assignment has varying_rubrics_by_round feature we check the corresponding report data is rendered. It should return participants.
:5 When the type is FeedbackResponseMap and when assignment does not have varying_rubrics_by_round feature we check the corresponding page to report is rendered and participants are rendered.
:6 When the type is TeammateReviewResponseMap we check that there is a correct mapping between the participant and its response. We will return participant for the corresponding response.
:7 When the type is Calibration and participant variable is nil we check if the correct report is rendered or not.
:8 When the type is PlagiarismCheckerReport we check if the correct report page is rendered or not.

E1868 remove reports from review mapping controller

2018-11-21T02:43:35Z

Skeerth: /* Test Plan */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_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 handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This two-step navigation to view the reports can be converted into a single step. There are two ways of doing so:
:1. Introduce a new ‘...’ icon in the buttons tray, which on hovering on it, would show the menu of various reports
:2. Rename the "view review report" button to reports with a drop down menu listing all the report types

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are eight 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
:8. Calibration report

The new implementation will have ReportStrategy class with following subclasses
:- ReviewReportStrategy
:- AuthorFeedbackReportStrategy
:- TeammateReviewReportStrategy
:- RubricQuestionReportStrategy
:- RevieweeCommentReportStrategy
:- CollusionReportStrategy
:- AnswerTagReportStrategy
:- CalibrationReportStrategy

Below is a simple UML diagram of these new classes

[[File:Report strategy E1868.jpg|frame|center]]

=== Modified UI ===
:1. One of the proposed changes to existing UI involves adding a new button to the buttons tray. For the assignment ‘Final Project (and Design Document)’ below, hovering over the ‘...’ icon (highlighted in the red box) should bring up the menu of additional reports. The image is only an illustration.

[[File: Reports icon.jpg|frame|centre]]

:2. Another proposed change is to modify "view review report" button to "view reports" drop-down menu listing all the available reports for the respective assignment.

= Test Plan =

The use case of reports gives a broad overview of the functionality. It also provides the preliminary tests to be written to ensure the proper working of the feature. Below use case diagram represents the intent of reports functionality.

[[File:Report use case.jpg|frame|center]]

RSpec is the preferred testing framework for review mapping controller. The first set of test cases deal with the retrieval of different reports for assignments and validating the fields returned by the reports. The details are as follows
:1 When the type is SummaryByRevieweeAndCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:2 When the type is SummaryByCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:3 When the type is ReviewResponseMap we check the corresponding report data is rendered. This returns participants, average and range.
:4 When the type is FeedbackResponseMap and assignment has varying_rubrics_by_round feature we check the corresponding report data is rendered. It should return participants.
:5 When the type is FeedbackResponseMap and when assignment does not have varying_rubrics_by_round feature we check the corresponding page to report is rendered and participants are rendered.
:6 When the type is TeammateReviewResponseMap we check that there is a correct mapping between the participant and its response. We will return participant for the corresponding response.
:7 When the type is Calibration and participant variable is nil we check if the correct report is rendered or not.
:8 When the type is PlagiarismCheckerReport we check if the correct report page is rendered or not.

E1868 remove reports from review mapping controller

2018-11-21T02:43:16Z

Skeerth: /* Test Plan */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_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 handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This two-step navigation to view the reports can be converted into a single step. There are two ways of doing so:
:1. Introduce a new ‘...’ icon in the buttons tray, which on hovering on it, would show the menu of various reports
:2. Rename the "view review report" button to reports with a drop down menu listing all the report types

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are eight 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
:8. Calibration report

The new implementation will have ReportStrategy class with following subclasses
:- ReviewReportStrategy
:- AuthorFeedbackReportStrategy
:- TeammateReviewReportStrategy
:- RubricQuestionReportStrategy
:- RevieweeCommentReportStrategy
:- CollusionReportStrategy
:- AnswerTagReportStrategy
:- CalibrationReportStrategy

Below is a simple UML diagram of these new classes

[[File:Report strategy E1868.jpg|frame|center]]

=== Modified UI ===
:1. One of the proposed changes to existing UI involves adding a new button to the buttons tray. For the assignment ‘Final Project (and Design Document)’ below, hovering over the ‘...’ icon (highlighted in the red box) should bring up the menu of additional reports. The image is only an illustration.

[[File: Reports icon.jpg|frame|centre]]

:2. Another proposed change is to modify "view review report" button to "view reports" drop-down menu listing all the available reports for the respective assignment.

= Test Plan =

The use case of reports gives a broad overview of the functionality. It also provides the preliminary tests to be written to ensure the proper working of the feature. Below use case diagram represents the intent of reports functionality.

[[File:Report use case.jpg|frame|center]]

RSpec is the preferred testing framework for review mapping controller. The first set of test cases deal with the retrieval of different reports for assignments and validating the fields returned by the reports. The details are as follows
:1 When the type is SummaryByRevieweeAndCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:2 When the type is SummaryByCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:3 When the type is ReviewResponseMap we check the corresponding report data is rendered. This returns participants, average and range.
:4 When the type is FeedbackResponseMap and assignment has varying_rubrics_by_round feature we check the corresponding report data is rendered. It should return participants.
:5 When the type is FeedbackResponseMap and when assignment does not have varying_rubrics_by_round feature we check the corresponding page to report is rendered and participants are rendered.
:6 When the type is TeammateReviewResponseMap we check that there is a correct mapping between the participant and its response. We will return participant for the corresponding response.
:7 When the type is Calibration and participant variable is nil we check if the correct report is rendered or not.
:8 When the type is PlagiarismCheckerReport we check if the correct report page is rendered or not.

E1868 remove reports from review mapping controller

2018-11-21T02:34:07Z

Skeerth: /* Refactored Design */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_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 handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This two-step navigation to view the reports can be converted into a single step. There are two ways of doing so:
:1. Introduce a new ‘...’ icon in the buttons tray, which on hovering on it, would show the menu of various reports
:2. Rename the "view review report" button to reports with a drop down menu listing all the report types

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are eight 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
:8. Calibration report

The new implementation will have ReportStrategy class with following subclasses
:- ReviewReportStrategy
:- AuthorFeedbackReportStrategy
:- TeammateReviewReportStrategy
:- RubricQuestionReportStrategy
:- RevieweeCommentReportStrategy
:- CollusionReportStrategy
:- AnswerTagReportStrategy
:- CalibrationReportStrategy

Below is a simple UML diagram of these new classes

[[File:Report strategy E1868.jpg|frame|center]]

=== Modified UI ===
:1. One of the proposed changes to existing UI involves adding a new button to the buttons tray. For the assignment ‘Final Project (and Design Document)’ below, hovering over the ‘...’ icon (highlighted in the red box) should bring up the menu of additional reports. The image is only an illustration.

[[File: Reports icon.jpg|frame|centre]]

:2. Another proposed change is to modify "view review report" button to "view reports" drop-down menu listing all the available reports for the respective assignment.

= Test Plan =

[[File:Report use case.jpg|frame|center]]

We are using RSpec testing framework to test our review mapping controller. We are planning to implement the following test cases:
:1 When the type is SummaryByRevieweeAndCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:2 When the type is SummaryByCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:3 When the type is ReviewResponseMap we check the corresponding report data is rendered. This returns participants, average and range.
:4 When the type is FeedbackResponseMap and assignment has varying_rubrics_by_round feature we check the corresponding report data is rendered. It should return participants.
:5 When the type is FeedbackResponseMap and when assignment does not have varying_rubrics_by_round feature we check the corresponding page to report is rendered and participants are rendered.
:6 When the type is TeammateReviewResponseMap we check that there is a correct mapping between the participant and its response. We will return participant for the corresponding response.
:7 When the type is Calibration and participant variable is nil we check if the correct report is rendered or not.
:8 When the type is PlagiarismCheckerReport we check if the correct report page is rendered or not.

E1868 remove reports from review mapping controller

2018-11-21T02:33:07Z

Skeerth: /* Refactored Design */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_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 handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This two-step navigation to view the reports can be converted into a single step. There are two ways of doing so:
:1. Introduce a new ‘...’ icon in the buttons tray, which on hovering on it, would show the menu of various reports
:2. Rename the "view review report" button to reports with a drop down menu listing all the report types

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are eight 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
:8. Calibration report

The new implementation will have ReportStrategy class with following subclasses
:- ReviewReportStrategy
:- AuthorFeedbackReportStrategy
:- TeammateReviewReportStrategy
:- RubricQuestionReportStrategy
:- RevieweeCommentReportStrategy
:- CollusionReportStrategy
:- AnswerTagReportStrategy
:- CalibrationReportStrategy

Below is a simple UML diagram of these new classes

[[File:Example.jpg|frame|center]]

=== Modified UI ===
:1. One of the proposed changes to existing UI involves adding a new button to the buttons tray. For the assignment ‘Final Project (and Design Document)’ below, hovering over the ‘...’ icon (highlighted in the red box) should bring up the menu of additional reports. The image is only an illustration.

[[File: Reports icon.jpg|frame|centre]]

:2. Another proposed change is to modify "view review report" button to "view reports" drop-down menu listing all the available reports for the respective assignment.

= Test Plan =

[[File:Report use case.jpg|frame|center]]

We are using RSpec testing framework to test our review mapping controller. We are planning to implement the following test cases:
:1 When the type is SummaryByRevieweeAndCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:2 When the type is SummaryByCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:3 When the type is ReviewResponseMap we check the corresponding report data is rendered. This returns participants, average and range.
:4 When the type is FeedbackResponseMap and assignment has varying_rubrics_by_round feature we check the corresponding report data is rendered. It should return participants.
:5 When the type is FeedbackResponseMap and when assignment does not have varying_rubrics_by_round feature we check the corresponding page to report is rendered and participants are rendered.
:6 When the type is TeammateReviewResponseMap we check that there is a correct mapping between the participant and its response. We will return participant for the corresponding response.
:7 When the type is Calibration and participant variable is nil we check if the correct report is rendered or not.
:8 When the type is PlagiarismCheckerReport we check if the correct report page is rendered or not.

File:Report strategy E1868.jpg

2018-11-21T02:32:23Z

Skeerth: report strategy new

report strategy new

File:Report strategy.jpg

2018-11-21T02:31:17Z

Skeerth: uploaded a new version of "File:Report strategy.jpg": report strategy

UML diagram for designing strategy gor reports

E1868 remove reports from review mapping controller

2018-11-21T02:29:35Z

Skeerth: /* Test Plan */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_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 handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This two-step navigation to view the reports can be converted into a single step. There are two ways of doing so:
:1. Introduce a new ‘...’ icon in the buttons tray, which on hovering on it, would show the menu of various reports
:2. Rename the "view review report" button to reports with a drop down menu listing all the report types

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are eight 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
:8. Calibration report

The new implementation will have ReportStrategy class with following subclasses
:- ReviewReportStrategy
:- AuthorFeedbackReportStrategy
:- TeammateReviewReportStrategy
:- RubricQuestionReportStrategy
:- RevieweeCommentReportStrategy
:- CollusionReportStrategy
:- AnswerTagReportStrategy
:- CalibrationReportStrategy

Below is a simple UML diagram of these new classes

[[File:Report strategy compressed 85 keerthi.jpg|frame|center]]

=== Modified UI ===
:1. One of the proposed changes to existing UI involves adding a new button to the buttons tray. For the assignment ‘Final Project (and Design Document)’ below, hovering over the ‘...’ icon (highlighted in the red box) should bring up the menu of additional reports. The image is only an illustration.

[[File: Reports icon.jpg|frame|centre]]

:2. Another proposed change is to modify "view review report" button to "view reports" drop-down menu listing all the available reports for the respective assignment.

= Test Plan =

[[File:Report use case.jpg|frame|center]]

We are using RSpec testing framework to test our review mapping controller. We are planning to implement the following test cases:
:1 When the type is SummaryByRevieweeAndCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:2 When the type is SummaryByCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:3 When the type is ReviewResponseMap we check the corresponding report data is rendered. This returns participants, average and range.
:4 When the type is FeedbackResponseMap and assignment has varying_rubrics_by_round feature we check the corresponding report data is rendered. It should return participants.
:5 When the type is FeedbackResponseMap and when assignment does not have varying_rubrics_by_round feature we check the corresponding page to report is rendered and participants are rendered.
:6 When the type is TeammateReviewResponseMap we check that there is a correct mapping between the participant and its response. We will return participant for the corresponding response.
:7 When the type is Calibration and participant variable is nil we check if the correct report is rendered or not.
:8 When the type is PlagiarismCheckerReport we check if the correct report page is rendered or not.

File:Report use case.jpg

2018-11-21T02:28:21Z

Skeerth: use case for reports

use case for reports

E1868 remove reports from review mapping controller

2018-11-21T02:26:02Z

Skeerth: /* Test Plan */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_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 handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This two-step navigation to view the reports can be converted into a single step. There are two ways of doing so:
:1. Introduce a new ‘...’ icon in the buttons tray, which on hovering on it, would show the menu of various reports
:2. Rename the "view review report" button to reports with a drop down menu listing all the report types

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are eight 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
:8. Calibration report

The new implementation will have ReportStrategy class with following subclasses
:- ReviewReportStrategy
:- AuthorFeedbackReportStrategy
:- TeammateReviewReportStrategy
:- RubricQuestionReportStrategy
:- RevieweeCommentReportStrategy
:- CollusionReportStrategy
:- AnswerTagReportStrategy
:- CalibrationReportStrategy

Below is a simple UML diagram of these new classes

[[File:Report strategy compressed 85 keerthi.jpg|frame|center]]

=== Modified UI ===
:1. One of the proposed changes to existing UI involves adding a new button to the buttons tray. For the assignment ‘Final Project (and Design Document)’ below, hovering over the ‘...’ icon (highlighted in the red box) should bring up the menu of additional reports. The image is only an illustration.

[[File: Reports icon.jpg|frame|centre]]

:2. Another proposed change is to modify "view review report" button to "view reports" drop-down menu listing all the available reports for the respective assignment.

= Test Plan =

[[File:Report use case 75 compressed E1868.jpg|frame|center]]

We are using RSpec testing framework to test our review mapping controller. We are planning to implement the following test cases:
:1 When the type is SummaryByRevieweeAndCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:2 When the type is SummaryByCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:3 When the type is ReviewResponseMap we check the corresponding report data is rendered. This returns participants, average and range.
:4 When the type is FeedbackResponseMap and assignment has varying_rubrics_by_round feature we check the corresponding report data is rendered. It should return participants.
:5 When the type is FeedbackResponseMap and when assignment does not have varying_rubrics_by_round feature we check the corresponding page to report is rendered and participants are rendered.
:6 When the type is TeammateReviewResponseMap we check that there is a correct mapping between the participant and its response. We will return participant for the corresponding response.
:7 When the type is Calibration and participant variable is nil we check if the correct report is rendered or not.
:8 When the type is PlagiarismCheckerReport we check if the correct report page is rendered or not.

E1868 remove reports from review mapping controller

2018-11-21T02:24:36Z

Skeerth: /* Test Plan */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_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 handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This two-step navigation to view the reports can be converted into a single step. There are two ways of doing so:
:1. Introduce a new ‘...’ icon in the buttons tray, which on hovering on it, would show the menu of various reports
:2. Rename the "view review report" button to reports with a drop down menu listing all the report types

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are eight 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
:8. Calibration report

The new implementation will have ReportStrategy class with following subclasses
:- ReviewReportStrategy
:- AuthorFeedbackReportStrategy
:- TeammateReviewReportStrategy
:- RubricQuestionReportStrategy
:- RevieweeCommentReportStrategy
:- CollusionReportStrategy
:- AnswerTagReportStrategy
:- CalibrationReportStrategy

Below is a simple UML diagram of these new classes

[[File:Report strategy compressed 85 keerthi.jpg|frame|center]]

=== Modified UI ===
:1. One of the proposed changes to existing UI involves adding a new button to the buttons tray. For the assignment ‘Final Project (and Design Document)’ below, hovering over the ‘...’ icon (highlighted in the red box) should bring up the menu of additional reports. The image is only an illustration.

[[File: Reports icon.jpg|frame|centre]]

:2. Another proposed change is to modify "view review report" button to "view reports" drop-down menu listing all the available reports for the respective assignment.

= Test Plan =

[[File:Report use case 75 compressed E1868.jpg|frame|center]]

We are using RSpec testing framework to test our review mapping controller. We are planning to implement the following test cases:
:1 When type is SummaryByRevieweeAndCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:2 When type is SummaryByCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:3 When type is ReviewResponseMap we check the corresponding report data is rendered. This returns participants , average and range.
:4 When type is FeedbackResponseMap and assignment has varying_rubrics_by_round feature we check the corresponding report data is rendered. It should return participants.
:5 When type is FeedbackResponseMap and when assignment does not have varying_rubrics_by_round feature we check the corresponding page to report is rendered and participants are rendered.
:6 When type is TeammateReviewResponseMap we check that there is correct mapping between the participant and its response. We will return participant for corresponding response.
:7 When type is Calibration and participant variable is nil we check if correct report is rendered or not.
:8 When type is PlagiarismCheckerReport we check if the correct report page is rendered or not.

E1868 remove reports from review mapping controller

2018-11-21T02:23:51Z

Skeerth: /* Test Plan */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_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 handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This two-step navigation to view the reports can be converted into a single step. There are two ways of doing so:
:1. Introduce a new ‘...’ icon in the buttons tray, which on hovering on it, would show the menu of various reports
:2. Rename the "view review report" button to reports with a drop down menu listing all the report types

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are eight 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
:8. Calibration report

The new implementation will have ReportStrategy class with following subclasses
:- ReviewReportStrategy
:- AuthorFeedbackReportStrategy
:- TeammateReviewReportStrategy
:- RubricQuestionReportStrategy
:- RevieweeCommentReportStrategy
:- CollusionReportStrategy
:- AnswerTagReportStrategy
:- CalibrationReportStrategy

Below is a simple UML diagram of these new classes

[[File:Report strategy compressed 85 keerthi.jpg|frame|center]]

=== Modified UI ===
:1. One of the proposed changes to existing UI involves adding a new button to the buttons tray. For the assignment ‘Final Project (and Design Document)’ below, hovering over the ‘...’ icon (highlighted in the red box) should bring up the menu of additional reports. The image is only an illustration.

[[File: Reports icon.jpg|frame|centre]]

:2. Another proposed change is to modify "view review report" button to "view reports" drop-down menu listing all the available reports for the respective assignment.

= Test Plan =

[[Report use case 75 compressed E1868.jpg|frame|center]]

We are using RSpec testing framework to test our review mapping controller. We are planning to implement the following test cases:
:1 When type is SummaryByRevieweeAndCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:2 When type is SummaryByCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:3 When type is ReviewResponseMap we check the corresponding report data is rendered. This returns participants , average and range.
:4 When type is FeedbackResponseMap and assignment has varying_rubrics_by_round feature we check the corresponding report data is rendered. It should return participants.
:5 When type is FeedbackResponseMap and when assignment does not have varying_rubrics_by_round feature we check the corresponding page to report is rendered and participants are rendered.
:6 When type is TeammateReviewResponseMap we check that there is correct mapping between the participant and its response. We will return participant for corresponding response.
:7 When type is Calibration and participant variable is nil we check if correct report is rendered or not.
:8 When type is PlagiarismCheckerReport we check if the correct report page is rendered or not.

E1868 remove reports from review mapping controller

2018-11-21T02:23:36Z

Skeerth: /* Test Plan */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_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 handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This two-step navigation to view the reports can be converted into a single step. There are two ways of doing so:
:1. Introduce a new ‘...’ icon in the buttons tray, which on hovering on it, would show the menu of various reports
:2. Rename the "view review report" button to reports with a drop down menu listing all the report types

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are eight 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
:8. Calibration report

The new implementation will have ReportStrategy class with following subclasses
:- ReviewReportStrategy
:- AuthorFeedbackReportStrategy
:- TeammateReviewReportStrategy
:- RubricQuestionReportStrategy
:- RevieweeCommentReportStrategy
:- CollusionReportStrategy
:- AnswerTagReportStrategy
:- CalibrationReportStrategy

Below is a simple UML diagram of these new classes

[[File:Report strategy compressed 85 keerthi.jpg|frame|center]]

=== Modified UI ===
:1. One of the proposed changes to existing UI involves adding a new button to the buttons tray. For the assignment ‘Final Project (and Design Document)’ below, hovering over the ‘...’ icon (highlighted in the red box) should bring up the menu of additional reports. The image is only an illustration.

[[File: Reports icon.jpg|frame|centre]]

:2. Another proposed change is to modify "view review report" button to "view reports" drop-down menu listing all the available reports for the respective assignment.

= Test Plan =

[[Report use case 75 compressed E1868|frame|center]]

We are using RSpec testing framework to test our review mapping controller. We are planning to implement the following test cases:
:1 When type is SummaryByRevieweeAndCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:2 When type is SummaryByCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:3 When type is ReviewResponseMap we check the corresponding report data is rendered. This returns participants , average and range.
:4 When type is FeedbackResponseMap and assignment has varying_rubrics_by_round feature we check the corresponding report data is rendered. It should return participants.
:5 When type is FeedbackResponseMap and when assignment does not have varying_rubrics_by_round feature we check the corresponding page to report is rendered and participants are rendered.
:6 When type is TeammateReviewResponseMap we check that there is correct mapping between the participant and its response. We will return participant for corresponding response.
:7 When type is Calibration and participant variable is nil we check if correct report is rendered or not.
:8 When type is PlagiarismCheckerReport we check if the correct report page is rendered or not.

E1868 remove reports from review mapping controller

2018-11-21T02:20:27Z

Skeerth: /* Test Plan */

= 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[http://wiki.expertiza.ncsu.edu/index.php/E1837_refactor_review_mapping_controller], 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 the single responsibility 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 reports
:- Testing the newly introduced reports_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 handles the following two different functionalities:
:1. Manage various reviewers
:2. Display and manage different reports

This violates the single responsibility principle[https://en.wikipedia.org/wiki/Single_responsibility_principle] by handling two different functionalities. This project aims to segregate these functionalities into the following two controllers:
:1. review_mapping_controller to manage the functionalities of reviewers
:2. reports_controller to handle the reports functionalities

=== Generalize code to display reports ===
The reports provide functionality such as presenting reviews for grading, showing author feedback (rejoinders), showing a table of all teammate reviews, showing a calibration report in an assignment where students rate the same work that has been previously rated by an instructor, and showing how many answers students have tagged.

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 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 listing various reports to navigate to.

This two-step navigation to view the reports can be converted into a single step. There are two ways of doing so:
:1. Introduce a new ‘...’ icon in the buttons tray, which on hovering on it, would show the menu of various reports
:2. Rename the "view review report" button to reports with a drop down menu listing all the report types

=== Testing the new controller ===
Since the logic for report generation has been abstracted into a new controller, existing tests for report generation must be verified for regression and also check for improving the code coverage statistics.

= Implementation specifics =

=== Refactored Design ===
In order to follow good design practices, the logic to differentiate reports will be implemented using Strategy Pattern[https://en.wikipedia.org/wiki/Strategy_pattern].

Currently, there are eight 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
:8. Calibration report

The new implementation will have ReportStrategy class with following subclasses
:- ReviewReportStrategy
:- AuthorFeedbackReportStrategy
:- TeammateReviewReportStrategy
:- RubricQuestionReportStrategy
:- RevieweeCommentReportStrategy
:- CollusionReportStrategy
:- AnswerTagReportStrategy
:- CalibrationReportStrategy

Below is a simple UML diagram of these new classes

[[File:Report strategy compressed 85 keerthi.jpg|frame|center]]

=== Modified UI ===
:1. One of the proposed changes to existing UI involves adding a new button to the buttons tray. For the assignment ‘Final Project (and Design Document)’ below, hovering over the ‘...’ icon (highlighted in the red box) should bring up the menu of additional reports. The image is only an illustration.

[[File: Reports icon.jpg|frame|centre]]

:2. Another proposed change is to modify "view review report" button to "view reports" drop-down menu listing all the available reports for the respective assignment.

= Test Plan =

[[File:Report use case 80 compressed E1868.jpg|frame|center]]

We are using RSpec testing framework to test our review mapping controller. We are planning to implement the following test cases:
:1 When type is SummaryByRevieweeAndCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:2 When type is SummaryByCriteria we check that the corresponding data is rendered. This method should return summary, reviewers, average scores by reviewee, average score by round and average score by criterion.
:3 When type is ReviewResponseMap we check the corresponding report data is rendered. This returns participants , average and range.
:4 When type is FeedbackResponseMap and assignment has varying_rubrics_by_round feature we check the corresponding report data is rendered. It should return participants.
:5 When type is FeedbackResponseMap and when assignment does not have varying_rubrics_by_round feature we check the corresponding page to report is rendered and participants are rendered.
:6 When type is TeammateReviewResponseMap we check that there is correct mapping between the participant and its response. We will return participant for corresponding response.
:7 When type is Calibration and participant variable is nil we check if correct report is rendered or not.
:8 When type is PlagiarismCheckerReport we check if the correct report page is rendered or not.