Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-24T17:41:52Z

Tsattle: /* Database Schema */

__TOC__
== '''Abstract''' ==
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

== '''Problem Statement''' ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. It is important that functionality be added so Expertiza can track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

The overall amount of time directly spent on the review is most important. One can track the amount of time spent on the review by tracking the amount of time from when the page is opened untill when the review is saved/submitted. Therefore, being able to track the time from once a resource is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

The following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and resources should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

== '''Previous Implementations''' ==
Thus far, Expertiza does not have the completed aforementioned feature. Previous attempts to implement this functionality have been made but the work was not merged into Expertiza code base for various reason. These previous projects are summarized below:

#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://github.com/expertiza/expertiza/pull/1662/commits E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== '''Proposed Solution''' ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1662/commits E1989] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages and the reason it was not integrated into expertiza was due to the amount of white space in commits and unsatisfactory commit messages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both. Tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.
*There are a few solutions one could implement to fix such an issue, such as marking both the start time and end time for when an external link or application was accessed by a user. Another solution which we will attempt in our first iteration of development is to track the time that an external link was clicked, and use the submission time of the review as our estimated end time for the external link. We thought of this design choice because once the report is submitted, the access time to external links should be stopped since the review is complete.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints about the use of a tabular method that was implemented in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791], stating that the review report table becomes too cluttered, we intend to create a pop-up window that will display the results in a table or graph of some sort. The proposed pop up will display all necessary information in a neat and simple self contained form. The exact display is undetermined, however proposed solutions include another tabular design, bar graphs, pie charts, etc.

== '''User Stories''' ==
The following section outlines the predicted user interactions with our software. Two potential users have been identified; users and instructors.

====Student====
Students will be interacting with the implementation when filling out a review. A similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1989._Track_the_time_students_look_at_other_submissions E1989] is used, however small edits were made to provide clean code and a trackable commit history. Initially, the user will click on the review they want to complete. Once the link is clicked the time will start to be logged. Upon the clicking of an external link another another timer will begin tracking it. This process repeats until the submission is saved/submitted or the page is exited out of. In the case where a review was previously saved, the timer will pick up from the last tracked time. The diagram below displays the flow of interactions visually.
[[File:User_Story.png| center |Image: 50 pixels]]

====Instructor====
Instructors will be interacting with the implementation when the are observing student reviews. Once again, a similar story from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1989._Track_the_time_students_look_at_other_submissions E1989] will be used for the instructor with minor changes. Firstly, the instructor will navigate to a page that displays all current and previously reviews. They will then be able to select a review from the given list and look at statistics about resources accessed and time spent on each resource. Saved reviews and already submitted reviews will be tagged differently. The diagram below displays the flow of interactions visually.

[[File:Instructor_Story.png | center |Image: 50 pixels]]

== '''Database Schema''' ==
Our datatable is named '''submission_viewing_events'''. The attributes and their descriptions are provided in the spreadsheet below. We use '''map_id''' to join '''response_maps''' table for storing the primary information. '''Round''' contains an int variable associated with the specific round review, '''link''' contains a character string storing the external link the reviewer clicked on, '''start_at''' contains the starting time the external link was pressed, while '''end_at''' contains the time when the link was closed.

[[File:Db_FINAL.PNG | center]]

 

Below shows the database relationship with other tables. '''submission_viewing_events''' will be touching '''response_maps'''. The highlight demonstrate which field correspond to response_maps key.

[[File:Db_schema_FINAL.png | center]]

== '''Code Changes''' ==
Our implementation builds off of the work done in E1989. This previous project has a substantial amount of the functionality already completed for tracking and viewing external pages and certain types of files. The primary error in this implementation is that when multiple files are open, the times at which they record reviews are overlapped creating inaccurate review reports. The displayed review report will also need to be edited to present review reports in a visually appealing manner. The following changes were made:

=== '''Files Created''' ===
<hr/>

==== '''controllers/submission_viewing_events_controller.rb''' ====

Creates a controller for handling events of submission viewing reviews. Created using rails 'generate controller' function. Includes three methods

# record_start_time : function starts the time for links that have been visited by the user.
# record_end_time : records the end time for links that have been visited by the user.
# mark_end_time : records the end time for links that have no end times.

==== '''db/migrate/20200420201807_create_submission_viewing_events.rb''' ====

Migration file to create data table for handling log start and end time for each link/file in the review. Created using rails 'generate model' function. More info regarding schema is included in the Database section.

==== '''app/views/submission_viewing_events/index.html.haml''' ====

Created a simple index page for viewing of submission events.

==== '''app/views/submission_viewing_events/edit.html.haml''' ====

Created file to allow for editing capabilities of submission viewing events.

==== '''app/views/submission_viewing_events/_form.html.haml''' ====

Created partial form that was used to fill in edit.html.haml file, as well as a few others.

==== '''spec/controllers/submission_viewing_events_controller_spec.rb''' ====

Implemented test cases for created SubmissionViewingEventsController using Rspec as per expertiza standard.

=== '''Files Edited''' ===
<hr/>

==== '''db/schema.rb''' ====

Updated to include the SubmissionViewingEvents model migration, as executed via a 'rake db:migrate"

==== '''app/views/reports/_review_submissions_time_spent.html.erb'''====

will be edited to accurately log viewing times for multiple links open at the same time. This will include creating methods such as calculateTime to help with parsing review times of different links, and a function drawChart to display review times in a visually appealing manner.

==== '''app/views/reports/_review_report.html.erb'''====

will be edited to reflect chart made in _review_submissions_time_spent.html.erb

==== '''app/views/submission_viewing_events/new.html.haml'''====

Created new.html.haml for submission_viewing_events for assisting in setting up the views.

==== '''app/views/submission_viewing_events/show.html.haml'''====

Created show.html.haml for submission_viewing_events for assisting in setting up the views.

==== '''app/helpers/submitted_content_helper.rb'''====

Updated line 32 to incorporate file link for the return variable, ret.

===='''app/views/popup/view_review_scores_popup.html.erb'''====

Break up query in line 55 into two queries.

==== '''app/views/reports/_review_submissions_time_spent.html.erb'''====

Created a view for reports controller.

==== '''app/views/reports/_review_report.html.erb'''====

Made changes to _review_report to reflect changes in reports_controller

==== '''app/views/response/_submitted_files.html.erb''' ====

Added JavaScript to this file which allows tracking of start and end times of accessing a hyperlink. Most functionality is on-click for tracking these times.

==== '''config/routes.rb''' ====

Added collection for start and end times when hyperlink is accessed. Includes post and get calls for recording start and end times as necessary (see lines 420-428)

==== '''app/controllers/response_controller.rb''' ====

Added field @current_round to file for tracking the current round of reviews for a student. See lines 83 and 267 for variable instantiation.

==== '''app/views/response/view.html.erb''' ====

Edited to set submission check variable to false.

==== '''app/views/response/response.html.erb''' ====

Edited to contain two functions to track start and end time or review. Added hidden field tags to form to track timeouts, as well as a submission check to ensure reviewer is still working on review.

==== '''app/views/submitted_content/_main.html.erb''' ====

Added checks for local assignment submissions, where if true a partial specifically for hyperlinks and submitted files are loaded. See lines 10-20 for specific changes.

==== '''app/views/submitted_content/_hyperlink.html.erb''' ====

Adds functionality to ensure that user must click on a hyperlink instead of copying and pasting the link. From line 41-end there is more JavaScript that marks start and end times for accessing these hyperlinks.

== '''Testing Plan''' ==
===Rspec===
Automatic testing will be achieved using Rspec. The primary controller for testing will be controllers/submission_viewing_events_controller.rb, as edits will be made to mark_end_time and record_end_time methods to ensure that recorded review times for resources are not overlapping.

Proposed Rspec Tests:
* When a new review is started probe the Expertiza timer and ensure it returns the start value (0)
* When a saved review is started again probe the Expertiza timer and ensure it returns the time value stored in the database
* When an external link is clicked on a new review probe the timer link for that link and ensure it returns the start value (0)
* When an external link is clicked on a previously saved review probe the timer link for that link and ensure it returns and ensure it returns the time value stored in the database
* When a review is saved/submitted ensure that the time sent to the database matches time stored in database after execution
* When a review is clicked on by the instructor the data returned from date base should match test data.

===Manual Testing===
# Log in as instructor
# Assign a review to a student
# Log in as student
# Complete the dummy review in 5 minutes
# Log in as instructor
# Navigate to review report tab
# Verify that the review was completed ~5 minutes.

== '''References''' ==

=== Useful Links ===

[https://github.com/expertiza/expertiza Expertiza Repo] 
[https://github.com/rohanpillai20/expertiza E1791 Repo] 
[https://github.com/rohanpillai20/expertiza/tree/E1989_Merge_Fixes E1989 Repo]

=== Our Implementation ===

[https://github.com/jamcdon3/expertiza/tree/E2015 Github Repo:] 
[https://github.com/rohanpillai20/expertiza/pull/51 Pull Request:] 
[https://github.com/expertiza/expertiza/pull/1728/commits Pull commits]

=== Team Information ===
'''Mentor:''' 
Abhirav Kariya

'''Students:''' 
Hartley Leroy 
John McDonald 
Christian Morris 
Tyler Sattler

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-24T17:41:23Z

Tsattle: /* Our Implementation */

__TOC__
== '''Abstract''' ==
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

== '''Problem Statement''' ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. It is important that functionality be added so Expertiza can track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

The overall amount of time directly spent on the review is most important. One can track the amount of time spent on the review by tracking the amount of time from when the page is opened untill when the review is saved/submitted. Therefore, being able to track the time from once a resource is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

The following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and resources should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

== '''Previous Implementations''' ==
Thus far, Expertiza does not have the completed aforementioned feature. Previous attempts to implement this functionality have been made but the work was not merged into Expertiza code base for various reason. These previous projects are summarized below:

#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://github.com/expertiza/expertiza/pull/1662/commits E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== '''Proposed Solution''' ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1662/commits E1989] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages and the reason it was not integrated into expertiza was due to the amount of white space in commits and unsatisfactory commit messages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both. Tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.
*There are a few solutions one could implement to fix such an issue, such as marking both the start time and end time for when an external link or application was accessed by a user. Another solution which we will attempt in our first iteration of development is to track the time that an external link was clicked, and use the submission time of the review as our estimated end time for the external link. We thought of this design choice because once the report is submitted, the access time to external links should be stopped since the review is complete.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints about the use of a tabular method that was implemented in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791], stating that the review report table becomes too cluttered, we intend to create a pop-up window that will display the results in a table or graph of some sort. The proposed pop up will display all necessary information in a neat and simple self contained form. The exact display is undetermined, however proposed solutions include another tabular design, bar graphs, pie charts, etc.

== '''User Stories''' ==
The following section outlines the predicted user interactions with our software. Two potential users have been identified; users and instructors.

====Student====
Students will be interacting with the implementation when filling out a review. A similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1989._Track_the_time_students_look_at_other_submissions E1989] is used, however small edits were made to provide clean code and a trackable commit history. Initially, the user will click on the review they want to complete. Once the link is clicked the time will start to be logged. Upon the clicking of an external link another another timer will begin tracking it. This process repeats until the submission is saved/submitted or the page is exited out of. In the case where a review was previously saved, the timer will pick up from the last tracked time. The diagram below displays the flow of interactions visually.
[[File:User_Story.png| center |Image: 50 pixels]]

====Instructor====
Instructors will be interacting with the implementation when the are observing student reviews. Once again, a similar story from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1989._Track_the_time_students_look_at_other_submissions E1989] will be used for the instructor with minor changes. Firstly, the instructor will navigate to a page that displays all current and previously reviews. They will then be able to select a review from the given list and look at statistics about resources accessed and time spent on each resource. Saved reviews and already submitted reviews will be tagged differently. The diagram below displays the flow of interactions visually.

[[File:Instructor_Story.png | center |Image: 50 pixels]]

== '''Database Schema''' ==
Our datatable is named '''submission_viewing_events'''. The attributes and their descriptions are provided in the spreadsheet below. We use map_id to join '''response_maps''' table for storing the primary information. '''Round''' contains an int variable associated with the specific round review, '''link''' contains a character string storing the external link the reviewer clicked on, '''start_at''' contains the starting time the external link was pressed, while '''end_at''' contains the time when the link was closed.

[[File:Db_FINAL.PNG | center]]

 

Below shows the database relationship with other tables. '''submission_viewing_events''' will be touching '''response_maps'''. The highlight demonstrate which field correspond to response_maps key.

[[File:Db_schema_FINAL.png | center]]

== '''Code Changes''' ==
Our implementation builds off of the work done in E1989. This previous project has a substantial amount of the functionality already completed for tracking and viewing external pages and certain types of files. The primary error in this implementation is that when multiple files are open, the times at which they record reviews are overlapped creating inaccurate review reports. The displayed review report will also need to be edited to present review reports in a visually appealing manner. The following changes were made:

=== '''Files Created''' ===
<hr/>

==== '''controllers/submission_viewing_events_controller.rb''' ====

Creates a controller for handling events of submission viewing reviews. Created using rails 'generate controller' function. Includes three methods

# record_start_time : function starts the time for links that have been visited by the user.
# record_end_time : records the end time for links that have been visited by the user.
# mark_end_time : records the end time for links that have no end times.

==== '''db/migrate/20200420201807_create_submission_viewing_events.rb''' ====

Migration file to create data table for handling log start and end time for each link/file in the review. Created using rails 'generate model' function. More info regarding schema is included in the Database section.

==== '''app/views/submission_viewing_events/index.html.haml''' ====

Created a simple index page for viewing of submission events.

==== '''app/views/submission_viewing_events/edit.html.haml''' ====

Created file to allow for editing capabilities of submission viewing events.

==== '''app/views/submission_viewing_events/_form.html.haml''' ====

Created partial form that was used to fill in edit.html.haml file, as well as a few others.

==== '''spec/controllers/submission_viewing_events_controller_spec.rb''' ====

Implemented test cases for created SubmissionViewingEventsController using Rspec as per expertiza standard.

=== '''Files Edited''' ===
<hr/>

==== '''db/schema.rb''' ====

Updated to include the SubmissionViewingEvents model migration, as executed via a 'rake db:migrate"

==== '''app/views/reports/_review_submissions_time_spent.html.erb'''====

will be edited to accurately log viewing times for multiple links open at the same time. This will include creating methods such as calculateTime to help with parsing review times of different links, and a function drawChart to display review times in a visually appealing manner.

==== '''app/views/reports/_review_report.html.erb'''====

will be edited to reflect chart made in _review_submissions_time_spent.html.erb

==== '''app/views/submission_viewing_events/new.html.haml'''====

Created new.html.haml for submission_viewing_events for assisting in setting up the views.

==== '''app/views/submission_viewing_events/show.html.haml'''====

Created show.html.haml for submission_viewing_events for assisting in setting up the views.

==== '''app/helpers/submitted_content_helper.rb'''====

Updated line 32 to incorporate file link for the return variable, ret.

===='''app/views/popup/view_review_scores_popup.html.erb'''====

Break up query in line 55 into two queries.

==== '''app/views/reports/_review_submissions_time_spent.html.erb'''====

Created a view for reports controller.

==== '''app/views/reports/_review_report.html.erb'''====

Made changes to _review_report to reflect changes in reports_controller

==== '''app/views/response/_submitted_files.html.erb''' ====

Added JavaScript to this file which allows tracking of start and end times of accessing a hyperlink. Most functionality is on-click for tracking these times.

==== '''config/routes.rb''' ====

Added collection for start and end times when hyperlink is accessed. Includes post and get calls for recording start and end times as necessary (see lines 420-428)

==== '''app/controllers/response_controller.rb''' ====

Added field @current_round to file for tracking the current round of reviews for a student. See lines 83 and 267 for variable instantiation.

==== '''app/views/response/view.html.erb''' ====

Edited to set submission check variable to false.

==== '''app/views/response/response.html.erb''' ====

Edited to contain two functions to track start and end time or review. Added hidden field tags to form to track timeouts, as well as a submission check to ensure reviewer is still working on review.

==== '''app/views/submitted_content/_main.html.erb''' ====

Added checks for local assignment submissions, where if true a partial specifically for hyperlinks and submitted files are loaded. See lines 10-20 for specific changes.

==== '''app/views/submitted_content/_hyperlink.html.erb''' ====

Adds functionality to ensure that user must click on a hyperlink instead of copying and pasting the link. From line 41-end there is more JavaScript that marks start and end times for accessing these hyperlinks.

== '''Testing Plan''' ==
===Rspec===
Automatic testing will be achieved using Rspec. The primary controller for testing will be controllers/submission_viewing_events_controller.rb, as edits will be made to mark_end_time and record_end_time methods to ensure that recorded review times for resources are not overlapping.

Proposed Rspec Tests:
* When a new review is started probe the Expertiza timer and ensure it returns the start value (0)
* When a saved review is started again probe the Expertiza timer and ensure it returns the time value stored in the database
* When an external link is clicked on a new review probe the timer link for that link and ensure it returns the start value (0)
* When an external link is clicked on a previously saved review probe the timer link for that link and ensure it returns and ensure it returns the time value stored in the database
* When a review is saved/submitted ensure that the time sent to the database matches time stored in database after execution
* When a review is clicked on by the instructor the data returned from date base should match test data.

===Manual Testing===
# Log in as instructor
# Assign a review to a student
# Log in as student
# Complete the dummy review in 5 minutes
# Log in as instructor
# Navigate to review report tab
# Verify that the review was completed ~5 minutes.

== '''References''' ==

=== Useful Links ===

[https://github.com/expertiza/expertiza Expertiza Repo] 
[https://github.com/rohanpillai20/expertiza E1791 Repo] 
[https://github.com/rohanpillai20/expertiza/tree/E1989_Merge_Fixes E1989 Repo]

=== Our Implementation ===

[https://github.com/jamcdon3/expertiza/tree/E2015 Github Repo:] 
[https://github.com/rohanpillai20/expertiza/pull/51 Pull Request:] 
[https://github.com/expertiza/expertiza/pull/1728/commits Pull commits]

=== Team Information ===
'''Mentor:''' 
Abhirav Kariya

'''Students:''' 
Hartley Leroy 
John McDonald 
Christian Morris 
Tyler Sattler

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-24T17:40:29Z

Tsattle: /* Useful Links */

__TOC__
== '''Abstract''' ==
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

== '''Problem Statement''' ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. It is important that functionality be added so Expertiza can track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

The overall amount of time directly spent on the review is most important. One can track the amount of time spent on the review by tracking the amount of time from when the page is opened untill when the review is saved/submitted. Therefore, being able to track the time from once a resource is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

The following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and resources should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

== '''Previous Implementations''' ==
Thus far, Expertiza does not have the completed aforementioned feature. Previous attempts to implement this functionality have been made but the work was not merged into Expertiza code base for various reason. These previous projects are summarized below:

#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://github.com/expertiza/expertiza/pull/1662/commits E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== '''Proposed Solution''' ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1662/commits E1989] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages and the reason it was not integrated into expertiza was due to the amount of white space in commits and unsatisfactory commit messages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both. Tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.
*There are a few solutions one could implement to fix such an issue, such as marking both the start time and end time for when an external link or application was accessed by a user. Another solution which we will attempt in our first iteration of development is to track the time that an external link was clicked, and use the submission time of the review as our estimated end time for the external link. We thought of this design choice because once the report is submitted, the access time to external links should be stopped since the review is complete.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints about the use of a tabular method that was implemented in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791], stating that the review report table becomes too cluttered, we intend to create a pop-up window that will display the results in a table or graph of some sort. The proposed pop up will display all necessary information in a neat and simple self contained form. The exact display is undetermined, however proposed solutions include another tabular design, bar graphs, pie charts, etc.

== '''User Stories''' ==
The following section outlines the predicted user interactions with our software. Two potential users have been identified; users and instructors.

====Student====
Students will be interacting with the implementation when filling out a review. A similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1989._Track_the_time_students_look_at_other_submissions E1989] is used, however small edits were made to provide clean code and a trackable commit history. Initially, the user will click on the review they want to complete. Once the link is clicked the time will start to be logged. Upon the clicking of an external link another another timer will begin tracking it. This process repeats until the submission is saved/submitted or the page is exited out of. In the case where a review was previously saved, the timer will pick up from the last tracked time. The diagram below displays the flow of interactions visually.
[[File:User_Story.png| center |Image: 50 pixels]]

====Instructor====
Instructors will be interacting with the implementation when the are observing student reviews. Once again, a similar story from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1989._Track_the_time_students_look_at_other_submissions E1989] will be used for the instructor with minor changes. Firstly, the instructor will navigate to a page that displays all current and previously reviews. They will then be able to select a review from the given list and look at statistics about resources accessed and time spent on each resource. Saved reviews and already submitted reviews will be tagged differently. The diagram below displays the flow of interactions visually.

[[File:Instructor_Story.png | center |Image: 50 pixels]]

== '''Database Schema''' ==
Our datatable is named '''submission_viewing_events'''. The attributes and their descriptions are provided in the spreadsheet below. We use map_id to join '''response_maps''' table for storing the primary information. '''Round''' contains an int variable associated with the specific round review, '''link''' contains a character string storing the external link the reviewer clicked on, '''start_at''' contains the starting time the external link was pressed, while '''end_at''' contains the time when the link was closed.

[[File:Db_FINAL.PNG | center]]

 

Below shows the database relationship with other tables. '''submission_viewing_events''' will be touching '''response_maps'''. The highlight demonstrate which field correspond to response_maps key.

[[File:Db_schema_FINAL.png | center]]

== '''Code Changes''' ==
Our implementation builds off of the work done in E1989. This previous project has a substantial amount of the functionality already completed for tracking and viewing external pages and certain types of files. The primary error in this implementation is that when multiple files are open, the times at which they record reviews are overlapped creating inaccurate review reports. The displayed review report will also need to be edited to present review reports in a visually appealing manner. The following changes were made:

=== '''Files Created''' ===
<hr/>

==== '''controllers/submission_viewing_events_controller.rb''' ====

Creates a controller for handling events of submission viewing reviews. Created using rails 'generate controller' function. Includes three methods

# record_start_time : function starts the time for links that have been visited by the user.
# record_end_time : records the end time for links that have been visited by the user.
# mark_end_time : records the end time for links that have no end times.

==== '''db/migrate/20200420201807_create_submission_viewing_events.rb''' ====

Migration file to create data table for handling log start and end time for each link/file in the review. Created using rails 'generate model' function. More info regarding schema is included in the Database section.

==== '''app/views/submission_viewing_events/index.html.haml''' ====

Created a simple index page for viewing of submission events.

==== '''app/views/submission_viewing_events/edit.html.haml''' ====

Created file to allow for editing capabilities of submission viewing events.

==== '''app/views/submission_viewing_events/_form.html.haml''' ====

Created partial form that was used to fill in edit.html.haml file, as well as a few others.

==== '''spec/controllers/submission_viewing_events_controller_spec.rb''' ====

Implemented test cases for created SubmissionViewingEventsController using Rspec as per expertiza standard.

=== '''Files Edited''' ===
<hr/>

==== '''db/schema.rb''' ====

Updated to include the SubmissionViewingEvents model migration, as executed via a 'rake db:migrate"

==== '''app/views/reports/_review_submissions_time_spent.html.erb'''====

will be edited to accurately log viewing times for multiple links open at the same time. This will include creating methods such as calculateTime to help with parsing review times of different links, and a function drawChart to display review times in a visually appealing manner.

==== '''app/views/reports/_review_report.html.erb'''====

will be edited to reflect chart made in _review_submissions_time_spent.html.erb

==== '''app/views/submission_viewing_events/new.html.haml'''====

Created new.html.haml for submission_viewing_events for assisting in setting up the views.

==== '''app/views/submission_viewing_events/show.html.haml'''====

Created show.html.haml for submission_viewing_events for assisting in setting up the views.

==== '''app/helpers/submitted_content_helper.rb'''====

Updated line 32 to incorporate file link for the return variable, ret.

===='''app/views/popup/view_review_scores_popup.html.erb'''====

Break up query in line 55 into two queries.

==== '''app/views/reports/_review_submissions_time_spent.html.erb'''====

Created a view for reports controller.

==== '''app/views/reports/_review_report.html.erb'''====

Made changes to _review_report to reflect changes in reports_controller

==== '''app/views/response/_submitted_files.html.erb''' ====

Added JavaScript to this file which allows tracking of start and end times of accessing a hyperlink. Most functionality is on-click for tracking these times.

==== '''config/routes.rb''' ====

Added collection for start and end times when hyperlink is accessed. Includes post and get calls for recording start and end times as necessary (see lines 420-428)

==== '''app/controllers/response_controller.rb''' ====

Added field @current_round to file for tracking the current round of reviews for a student. See lines 83 and 267 for variable instantiation.

==== '''app/views/response/view.html.erb''' ====

Edited to set submission check variable to false.

==== '''app/views/response/response.html.erb''' ====

Edited to contain two functions to track start and end time or review. Added hidden field tags to form to track timeouts, as well as a submission check to ensure reviewer is still working on review.

==== '''app/views/submitted_content/_main.html.erb''' ====

Added checks for local assignment submissions, where if true a partial specifically for hyperlinks and submitted files are loaded. See lines 10-20 for specific changes.

==== '''app/views/submitted_content/_hyperlink.html.erb''' ====

Adds functionality to ensure that user must click on a hyperlink instead of copying and pasting the link. From line 41-end there is more JavaScript that marks start and end times for accessing these hyperlinks.

== '''Testing Plan''' ==
===Rspec===
Automatic testing will be achieved using Rspec. The primary controller for testing will be controllers/submission_viewing_events_controller.rb, as edits will be made to mark_end_time and record_end_time methods to ensure that recorded review times for resources are not overlapping.

Proposed Rspec Tests:
* When a new review is started probe the Expertiza timer and ensure it returns the start value (0)
* When a saved review is started again probe the Expertiza timer and ensure it returns the time value stored in the database
* When an external link is clicked on a new review probe the timer link for that link and ensure it returns the start value (0)
* When an external link is clicked on a previously saved review probe the timer link for that link and ensure it returns and ensure it returns the time value stored in the database
* When a review is saved/submitted ensure that the time sent to the database matches time stored in database after execution
* When a review is clicked on by the instructor the data returned from date base should match test data.

===Manual Testing===
# Log in as instructor
# Assign a review to a student
# Log in as student
# Complete the dummy review in 5 minutes
# Log in as instructor
# Navigate to review report tab
# Verify that the review was completed ~5 minutes.

== '''References''' ==

=== Useful Links ===

[https://github.com/expertiza/expertiza Expertiza Repo] 
[https://github.com/rohanpillai20/expertiza E1791 Repo] 
[https://github.com/rohanpillai20/expertiza/tree/E1989_Merge_Fixes E1989 Repo]

=== Our Implementation ===

[https://github.com/jamcdon3/expertiza/tree/E2015 Github Repo:] 
[https://github.com/rohanpillai20/expertiza/pull/51 Pull Request:]

=== Team Information ===
'''Mentor:''' 
Abhirav Kariya

'''Students:''' 
Hartley Leroy 
John McDonald 
Christian Morris 
Tyler Sattler

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-24T17:37:48Z

Tsattle: /* Instructor */

__TOC__
== '''Abstract''' ==
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

== '''Problem Statement''' ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. It is important that functionality be added so Expertiza can track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

The overall amount of time directly spent on the review is most important. One can track the amount of time spent on the review by tracking the amount of time from when the page is opened untill when the review is saved/submitted. Therefore, being able to track the time from once a resource is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

The following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and resources should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

== '''Previous Implementations''' ==
Thus far, Expertiza does not have the completed aforementioned feature. Previous attempts to implement this functionality have been made but the work was not merged into Expertiza code base for various reason. These previous projects are summarized below:

#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://github.com/expertiza/expertiza/pull/1662/commits E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== '''Proposed Solution''' ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1662/commits E1989] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages and the reason it was not integrated into expertiza was due to the amount of white space in commits and unsatisfactory commit messages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both. Tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.
*There are a few solutions one could implement to fix such an issue, such as marking both the start time and end time for when an external link or application was accessed by a user. Another solution which we will attempt in our first iteration of development is to track the time that an external link was clicked, and use the submission time of the review as our estimated end time for the external link. We thought of this design choice because once the report is submitted, the access time to external links should be stopped since the review is complete.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints about the use of a tabular method that was implemented in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791], stating that the review report table becomes too cluttered, we intend to create a pop-up window that will display the results in a table or graph of some sort. The proposed pop up will display all necessary information in a neat and simple self contained form. The exact display is undetermined, however proposed solutions include another tabular design, bar graphs, pie charts, etc.

== '''User Stories''' ==
The following section outlines the predicted user interactions with our software. Two potential users have been identified; users and instructors.

====Student====
Students will be interacting with the implementation when filling out a review. A similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1989._Track_the_time_students_look_at_other_submissions E1989] is used, however small edits were made to provide clean code and a trackable commit history. Initially, the user will click on the review they want to complete. Once the link is clicked the time will start to be logged. Upon the clicking of an external link another another timer will begin tracking it. This process repeats until the submission is saved/submitted or the page is exited out of. In the case where a review was previously saved, the timer will pick up from the last tracked time. The diagram below displays the flow of interactions visually.
[[File:User_Story.png| center |Image: 50 pixels]]

====Instructor====
Instructors will be interacting with the implementation when the are observing student reviews. Once again, a similar story from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1989._Track_the_time_students_look_at_other_submissions E1989] will be used for the instructor with minor changes. Firstly, the instructor will navigate to a page that displays all current and previously reviews. They will then be able to select a review from the given list and look at statistics about resources accessed and time spent on each resource. Saved reviews and already submitted reviews will be tagged differently. The diagram below displays the flow of interactions visually.

[[File:Instructor_Story.png | center |Image: 50 pixels]]

== '''Database Schema''' ==
Our datatable is named '''submission_viewing_events'''. The attributes and their descriptions are provided in the spreadsheet below. We use map_id to join '''response_maps''' table for storing the primary information. '''Round''' contains an int variable associated with the specific round review, '''link''' contains a character string storing the external link the reviewer clicked on, '''start_at''' contains the starting time the external link was pressed, while '''end_at''' contains the time when the link was closed.

[[File:Db_FINAL.PNG | center]]

 

Below shows the database relationship with other tables. '''submission_viewing_events''' will be touching '''response_maps'''. The highlight demonstrate which field correspond to response_maps key.

[[File:Db_schema_FINAL.png | center]]

== '''Code Changes''' ==
Our implementation builds off of the work done in E1989. This previous project has a substantial amount of the functionality already completed for tracking and viewing external pages and certain types of files. The primary error in this implementation is that when multiple files are open, the times at which they record reviews are overlapped creating inaccurate review reports. The displayed review report will also need to be edited to present review reports in a visually appealing manner. The following changes were made:

=== '''Files Created''' ===
<hr/>

==== '''controllers/submission_viewing_events_controller.rb''' ====

Creates a controller for handling events of submission viewing reviews. Created using rails 'generate controller' function. Includes three methods

# record_start_time : function starts the time for links that have been visited by the user.
# record_end_time : records the end time for links that have been visited by the user.
# mark_end_time : records the end time for links that have no end times.

==== '''db/migrate/20200420201807_create_submission_viewing_events.rb''' ====

Migration file to create data table for handling log start and end time for each link/file in the review. Created using rails 'generate model' function. More info regarding schema is included in the Database section.

==== '''app/views/submission_viewing_events/index.html.haml''' ====

Created a simple index page for viewing of submission events.

==== '''app/views/submission_viewing_events/edit.html.haml''' ====

Created file to allow for editing capabilities of submission viewing events.

==== '''app/views/submission_viewing_events/_form.html.haml''' ====

Created partial form that was used to fill in edit.html.haml file, as well as a few others.

==== '''spec/controllers/submission_viewing_events_controller_spec.rb''' ====

Implemented test cases for created SubmissionViewingEventsController using Rspec as per expertiza standard.

=== '''Files Edited''' ===
<hr/>

==== '''db/schema.rb''' ====

Updated to include the SubmissionViewingEvents model migration, as executed via a 'rake db:migrate"

==== '''app/views/reports/_review_submissions_time_spent.html.erb'''====

will be edited to accurately log viewing times for multiple links open at the same time. This will include creating methods such as calculateTime to help with parsing review times of different links, and a function drawChart to display review times in a visually appealing manner.

==== '''app/views/reports/_review_report.html.erb'''====

will be edited to reflect chart made in _review_submissions_time_spent.html.erb

==== '''app/views/submission_viewing_events/new.html.haml'''====

Created new.html.haml for submission_viewing_events for assisting in setting up the views.

==== '''app/views/submission_viewing_events/show.html.haml'''====

Created show.html.haml for submission_viewing_events for assisting in setting up the views.

==== '''app/helpers/submitted_content_helper.rb'''====

Updated line 32 to incorporate file link for the return variable, ret.

===='''app/views/popup/view_review_scores_popup.html.erb'''====

Break up query in line 55 into two queries.

==== '''app/views/reports/_review_submissions_time_spent.html.erb'''====

Created a view for reports controller.

==== '''app/views/reports/_review_report.html.erb'''====

Made changes to _review_report to reflect changes in reports_controller

==== '''app/views/response/_submitted_files.html.erb''' ====

Added JavaScript to this file which allows tracking of start and end times of accessing a hyperlink. Most functionality is on-click for tracking these times.

==== '''config/routes.rb''' ====

Added collection for start and end times when hyperlink is accessed. Includes post and get calls for recording start and end times as necessary (see lines 420-428)

==== '''app/controllers/response_controller.rb''' ====

Added field @current_round to file for tracking the current round of reviews for a student. See lines 83 and 267 for variable instantiation.

==== '''app/views/response/view.html.erb''' ====

Edited to set submission check variable to false.

==== '''app/views/response/response.html.erb''' ====

Edited to contain two functions to track start and end time or review. Added hidden field tags to form to track timeouts, as well as a submission check to ensure reviewer is still working on review.

==== '''app/views/submitted_content/_main.html.erb''' ====

Added checks for local assignment submissions, where if true a partial specifically for hyperlinks and submitted files are loaded. See lines 10-20 for specific changes.

==== '''app/views/submitted_content/_hyperlink.html.erb''' ====

Adds functionality to ensure that user must click on a hyperlink instead of copying and pasting the link. From line 41-end there is more JavaScript that marks start and end times for accessing these hyperlinks.

== '''Testing Plan''' ==
===Rspec===
Automatic testing will be achieved using Rspec. The primary controller for testing will be controllers/submission_viewing_events_controller.rb, as edits will be made to mark_end_time and record_end_time methods to ensure that recorded review times for resources are not overlapping.

Proposed Rspec Tests:
* When a new review is started probe the Expertiza timer and ensure it returns the start value (0)
* When a saved review is started again probe the Expertiza timer and ensure it returns the time value stored in the database
* When an external link is clicked on a new review probe the timer link for that link and ensure it returns the start value (0)
* When an external link is clicked on a previously saved review probe the timer link for that link and ensure it returns and ensure it returns the time value stored in the database
* When a review is saved/submitted ensure that the time sent to the database matches time stored in database after execution
* When a review is clicked on by the instructor the data returned from date base should match test data.

===Manual Testing===
# Log in as instructor
# Assign a review to a student
# Log in as student
# Complete the dummy review in 5 minutes
# Log in as instructor
# Navigate to review report tab
# Verify that the review was completed ~5 minutes.

== '''References''' ==

=== Useful Links ===

[https://github.com/expertiza/expertiza Expertiza Repo] 
[https://github.com/rohanpillai20/expertiza E1791 Repo]

=== Our Implementation ===

[https://github.com/jamcdon3/expertiza/tree/E2015 Github Repo:] 
[https://github.com/rohanpillai20/expertiza/pull/51 Pull Request:]

=== Team Information ===
'''Mentor:''' 
Abhirav Kariya

'''Students:''' 
Hartley Leroy 
John McDonald 
Christian Morris 
Tyler Sattler

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-24T17:37:31Z

Tsattle: /* Student */

__TOC__
== '''Abstract''' ==
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

== '''Problem Statement''' ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. It is important that functionality be added so Expertiza can track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

The overall amount of time directly spent on the review is most important. One can track the amount of time spent on the review by tracking the amount of time from when the page is opened untill when the review is saved/submitted. Therefore, being able to track the time from once a resource is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

The following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and resources should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

== '''Previous Implementations''' ==
Thus far, Expertiza does not have the completed aforementioned feature. Previous attempts to implement this functionality have been made but the work was not merged into Expertiza code base for various reason. These previous projects are summarized below:

#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://github.com/expertiza/expertiza/pull/1662/commits E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== '''Proposed Solution''' ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1662/commits E1989] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages and the reason it was not integrated into expertiza was due to the amount of white space in commits and unsatisfactory commit messages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both. Tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.
*There are a few solutions one could implement to fix such an issue, such as marking both the start time and end time for when an external link or application was accessed by a user. Another solution which we will attempt in our first iteration of development is to track the time that an external link was clicked, and use the submission time of the review as our estimated end time for the external link. We thought of this design choice because once the report is submitted, the access time to external links should be stopped since the review is complete.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints about the use of a tabular method that was implemented in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791], stating that the review report table becomes too cluttered, we intend to create a pop-up window that will display the results in a table or graph of some sort. The proposed pop up will display all necessary information in a neat and simple self contained form. The exact display is undetermined, however proposed solutions include another tabular design, bar graphs, pie charts, etc.

== '''User Stories''' ==
The following section outlines the predicted user interactions with our software. Two potential users have been identified; users and instructors.

====Student====
Students will be interacting with the implementation when filling out a review. A similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1989._Track_the_time_students_look_at_other_submissions E1989] is used, however small edits were made to provide clean code and a trackable commit history. Initially, the user will click on the review they want to complete. Once the link is clicked the time will start to be logged. Upon the clicking of an external link another another timer will begin tracking it. This process repeats until the submission is saved/submitted or the page is exited out of. In the case where a review was previously saved, the timer will pick up from the last tracked time. The diagram below displays the flow of interactions visually.
[[File:User_Story.png| center |Image: 50 pixels]]

====Instructor====
Instructors will be interacting with the implementation when the are observing student reviews. Once again, a similar story from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] will be used for the instructor with minor changes. Firstly, the instructor will navigate to a page that displays all current and previously reviews. They will then be able to select a review from the given list and look at statistics about resources accessed and time spent on each resource. Saved reviews and already submitted reviews will be tagged differently. The diagram below displays the flow of interactions visually.

[[File:Instructor_Story.png | center |Image: 50 pixels]]

== '''Database Schema''' ==
Our datatable is named '''submission_viewing_events'''. The attributes and their descriptions are provided in the spreadsheet below. We use map_id to join '''response_maps''' table for storing the primary information. '''Round''' contains an int variable associated with the specific round review, '''link''' contains a character string storing the external link the reviewer clicked on, '''start_at''' contains the starting time the external link was pressed, while '''end_at''' contains the time when the link was closed.

[[File:Db_FINAL.PNG | center]]

 

Below shows the database relationship with other tables. '''submission_viewing_events''' will be touching '''response_maps'''. The highlight demonstrate which field correspond to response_maps key.

[[File:Db_schema_FINAL.png | center]]

== '''Code Changes''' ==
Our implementation builds off of the work done in E1989. This previous project has a substantial amount of the functionality already completed for tracking and viewing external pages and certain types of files. The primary error in this implementation is that when multiple files are open, the times at which they record reviews are overlapped creating inaccurate review reports. The displayed review report will also need to be edited to present review reports in a visually appealing manner. The following changes were made:

=== '''Files Created''' ===
<hr/>

==== '''controllers/submission_viewing_events_controller.rb''' ====

Creates a controller for handling events of submission viewing reviews. Created using rails 'generate controller' function. Includes three methods

# record_start_time : function starts the time for links that have been visited by the user.
# record_end_time : records the end time for links that have been visited by the user.
# mark_end_time : records the end time for links that have no end times.

==== '''db/migrate/20200420201807_create_submission_viewing_events.rb''' ====

Migration file to create data table for handling log start and end time for each link/file in the review. Created using rails 'generate model' function. More info regarding schema is included in the Database section.

==== '''app/views/submission_viewing_events/index.html.haml''' ====

Created a simple index page for viewing of submission events.

==== '''app/views/submission_viewing_events/edit.html.haml''' ====

Created file to allow for editing capabilities of submission viewing events.

==== '''app/views/submission_viewing_events/_form.html.haml''' ====

Created partial form that was used to fill in edit.html.haml file, as well as a few others.

==== '''spec/controllers/submission_viewing_events_controller_spec.rb''' ====

Implemented test cases for created SubmissionViewingEventsController using Rspec as per expertiza standard.

=== '''Files Edited''' ===
<hr/>

==== '''db/schema.rb''' ====

Updated to include the SubmissionViewingEvents model migration, as executed via a 'rake db:migrate"

==== '''app/views/reports/_review_submissions_time_spent.html.erb'''====

will be edited to accurately log viewing times for multiple links open at the same time. This will include creating methods such as calculateTime to help with parsing review times of different links, and a function drawChart to display review times in a visually appealing manner.

==== '''app/views/reports/_review_report.html.erb'''====

will be edited to reflect chart made in _review_submissions_time_spent.html.erb

==== '''app/views/submission_viewing_events/new.html.haml'''====

Created new.html.haml for submission_viewing_events for assisting in setting up the views.

==== '''app/views/submission_viewing_events/show.html.haml'''====

Created show.html.haml for submission_viewing_events for assisting in setting up the views.

==== '''app/helpers/submitted_content_helper.rb'''====

Updated line 32 to incorporate file link for the return variable, ret.

===='''app/views/popup/view_review_scores_popup.html.erb'''====

Break up query in line 55 into two queries.

==== '''app/views/reports/_review_submissions_time_spent.html.erb'''====

Created a view for reports controller.

==== '''app/views/reports/_review_report.html.erb'''====

Made changes to _review_report to reflect changes in reports_controller

==== '''app/views/response/_submitted_files.html.erb''' ====

Added JavaScript to this file which allows tracking of start and end times of accessing a hyperlink. Most functionality is on-click for tracking these times.

==== '''config/routes.rb''' ====

Added collection for start and end times when hyperlink is accessed. Includes post and get calls for recording start and end times as necessary (see lines 420-428)

==== '''app/controllers/response_controller.rb''' ====

Added field @current_round to file for tracking the current round of reviews for a student. See lines 83 and 267 for variable instantiation.

==== '''app/views/response/view.html.erb''' ====

Edited to set submission check variable to false.

==== '''app/views/response/response.html.erb''' ====

Edited to contain two functions to track start and end time or review. Added hidden field tags to form to track timeouts, as well as a submission check to ensure reviewer is still working on review.

==== '''app/views/submitted_content/_main.html.erb''' ====

Added checks for local assignment submissions, where if true a partial specifically for hyperlinks and submitted files are loaded. See lines 10-20 for specific changes.

==== '''app/views/submitted_content/_hyperlink.html.erb''' ====

Adds functionality to ensure that user must click on a hyperlink instead of copying and pasting the link. From line 41-end there is more JavaScript that marks start and end times for accessing these hyperlinks.

== '''Testing Plan''' ==
===Rspec===
Automatic testing will be achieved using Rspec. The primary controller for testing will be controllers/submission_viewing_events_controller.rb, as edits will be made to mark_end_time and record_end_time methods to ensure that recorded review times for resources are not overlapping.

Proposed Rspec Tests:
* When a new review is started probe the Expertiza timer and ensure it returns the start value (0)
* When a saved review is started again probe the Expertiza timer and ensure it returns the time value stored in the database
* When an external link is clicked on a new review probe the timer link for that link and ensure it returns the start value (0)
* When an external link is clicked on a previously saved review probe the timer link for that link and ensure it returns and ensure it returns the time value stored in the database
* When a review is saved/submitted ensure that the time sent to the database matches time stored in database after execution
* When a review is clicked on by the instructor the data returned from date base should match test data.

===Manual Testing===
# Log in as instructor
# Assign a review to a student
# Log in as student
# Complete the dummy review in 5 minutes
# Log in as instructor
# Navigate to review report tab
# Verify that the review was completed ~5 minutes.

== '''References''' ==

=== Useful Links ===

[https://github.com/expertiza/expertiza Expertiza Repo] 
[https://github.com/rohanpillai20/expertiza E1791 Repo]

=== Our Implementation ===

[https://github.com/jamcdon3/expertiza/tree/E2015 Github Repo:] 
[https://github.com/rohanpillai20/expertiza/pull/51 Pull Request:]

=== Team Information ===
'''Mentor:''' 
Abhirav Kariya

'''Students:''' 
Hartley Leroy 
John McDonald 
Christian Morris 
Tyler Sattler

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-24T17:35:53Z

Tsattle: /* Student */

__TOC__
== '''Abstract''' ==
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

== '''Problem Statement''' ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. It is important that functionality be added so Expertiza can track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

The overall amount of time directly spent on the review is most important. One can track the amount of time spent on the review by tracking the amount of time from when the page is opened untill when the review is saved/submitted. Therefore, being able to track the time from once a resource is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

The following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and resources should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

== '''Previous Implementations''' ==
Thus far, Expertiza does not have the completed aforementioned feature. Previous attempts to implement this functionality have been made but the work was not merged into Expertiza code base for various reason. These previous projects are summarized below:

#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://github.com/expertiza/expertiza/pull/1662/commits E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== '''Proposed Solution''' ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1662/commits E1989] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages and the reason it was not integrated into expertiza was due to the amount of white space in commits and unsatisfactory commit messages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both. Tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.
*There are a few solutions one could implement to fix such an issue, such as marking both the start time and end time for when an external link or application was accessed by a user. Another solution which we will attempt in our first iteration of development is to track the time that an external link was clicked, and use the submission time of the review as our estimated end time for the external link. We thought of this design choice because once the report is submitted, the access time to external links should be stopped since the review is complete.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints about the use of a tabular method that was implemented in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791], stating that the review report table becomes too cluttered, we intend to create a pop-up window that will display the results in a table or graph of some sort. The proposed pop up will display all necessary information in a neat and simple self contained form. The exact display is undetermined, however proposed solutions include another tabular design, bar graphs, pie charts, etc.

== '''User Stories''' ==
The following section outlines the predicted user interactions with our software. Two potential users have been identified; users and instructors.

====Student====
Students will be interacting with the implementation when filling out a review. A similar workflow from [https://github.com/expertiza/expertiza/pull/1662/commits E1989] is used, however small edits were made to provide clean code and a trackable commit history. Initially, the user will click on the review they want to complete. Once the link is clicked the time will start to be logged. Upon the clicking of an external link another another timer will begin tracking it. This process repeats until the submission is saved/submitted or the page is exited out of. In the case where a review was previously saved, the timer will pick up from the last tracked time. The diagram below displays the flow of interactions visually.
[[File:User_Story.png| center |Image: 50 pixels]]

====Instructor====
Instructors will be interacting with the implementation when the are observing student reviews. Once again, a similar story from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] will be used for the instructor with minor changes. Firstly, the instructor will navigate to a page that displays all current and previously reviews. They will then be able to select a review from the given list and look at statistics about resources accessed and time spent on each resource. Saved reviews and already submitted reviews will be tagged differently. The diagram below displays the flow of interactions visually.

[[File:Instructor_Story.png | center |Image: 50 pixels]]

== '''Database Schema''' ==
Our datatable is named '''submission_viewing_events'''. The attributes and their descriptions are provided in the spreadsheet below. We use map_id to join '''response_maps''' table for storing the primary information. '''Round''' contains an int variable associated with the specific round review, '''link''' contains a character string storing the external link the reviewer clicked on, '''start_at''' contains the starting time the external link was pressed, while '''end_at''' contains the time when the link was closed.

[[File:Db_FINAL.PNG | center]]

 

Below shows the database relationship with other tables. '''submission_viewing_events''' will be touching '''response_maps'''. The highlight demonstrate which field correspond to response_maps key.

[[File:Db_schema_FINAL.png | center]]

== '''Code Changes''' ==
Our implementation builds off of the work done in E1989. This previous project has a substantial amount of the functionality already completed for tracking and viewing external pages and certain types of files. The primary error in this implementation is that when multiple files are open, the times at which they record reviews are overlapped creating inaccurate review reports. The displayed review report will also need to be edited to present review reports in a visually appealing manner. The following changes were made:

=== '''Files Created''' ===
<hr/>

==== '''controllers/submission_viewing_events_controller.rb''' ====

Creates a controller for handling events of submission viewing reviews. Created using rails 'generate controller' function. Includes three methods

# record_start_time : function starts the time for links that have been visited by the user.
# record_end_time : records the end time for links that have been visited by the user.
# mark_end_time : records the end time for links that have no end times.

==== '''db/migrate/20200420201807_create_submission_viewing_events.rb''' ====

Migration file to create data table for handling log start and end time for each link/file in the review. Created using rails 'generate model' function. More info regarding schema is included in the Database section.

==== '''app/views/submission_viewing_events/index.html.haml''' ====

Created a simple index page for viewing of submission events.

==== '''app/views/submission_viewing_events/edit.html.haml''' ====

Created file to allow for editing capabilities of submission viewing events.

==== '''app/views/submission_viewing_events/_form.html.haml''' ====

Created partial form that was used to fill in edit.html.haml file, as well as a few others.

==== '''spec/controllers/submission_viewing_events_controller_spec.rb''' ====

Implemented test cases for created SubmissionViewingEventsController using Rspec as per expertiza standard.

=== '''Files Edited''' ===
<hr/>

==== '''db/schema.rb''' ====

Updated to include the SubmissionViewingEvents model migration, as executed via a 'rake db:migrate"

==== '''app/views/reports/_review_submissions_time_spent.html.erb'''====

will be edited to accurately log viewing times for multiple links open at the same time. This will include creating methods such as calculateTime to help with parsing review times of different links, and a function drawChart to display review times in a visually appealing manner.

==== '''app/views/reports/_review_report.html.erb'''====

will be edited to reflect chart made in _review_submissions_time_spent.html.erb

==== '''app/views/submission_viewing_events/new.html.haml'''====

Created new.html.haml for submission_viewing_events for assisting in setting up the views.

==== '''app/views/submission_viewing_events/show.html.haml'''====

Created show.html.haml for submission_viewing_events for assisting in setting up the views.

==== '''app/helpers/submitted_content_helper.rb'''====

Updated line 32 to incorporate file link for the return variable, ret.

===='''app/views/popup/view_review_scores_popup.html.erb'''====

Break up query in line 55 into two queries.

==== '''app/views/reports/_review_submissions_time_spent.html.erb'''====

Created a view for reports controller.

==== '''app/views/reports/_review_report.html.erb'''====

Made changes to _review_report to reflect changes in reports_controller

==== '''app/views/response/_submitted_files.html.erb''' ====

Added JavaScript to this file which allows tracking of start and end times of accessing a hyperlink. Most functionality is on-click for tracking these times.

==== '''config/routes.rb''' ====

Added collection for start and end times when hyperlink is accessed. Includes post and get calls for recording start and end times as necessary (see lines 420-428)

==== '''app/controllers/response_controller.rb''' ====

Added field @current_round to file for tracking the current round of reviews for a student. See lines 83 and 267 for variable instantiation.

==== '''app/views/response/view.html.erb''' ====

Edited to set submission check variable to false.

==== '''app/views/response/response.html.erb''' ====

Edited to contain two functions to track start and end time or review. Added hidden field tags to form to track timeouts, as well as a submission check to ensure reviewer is still working on review.

==== '''app/views/submitted_content/_main.html.erb''' ====

Added checks for local assignment submissions, where if true a partial specifically for hyperlinks and submitted files are loaded. See lines 10-20 for specific changes.

==== '''app/views/submitted_content/_hyperlink.html.erb''' ====

Adds functionality to ensure that user must click on a hyperlink instead of copying and pasting the link. From line 41-end there is more JavaScript that marks start and end times for accessing these hyperlinks.

== '''Testing Plan''' ==
===Rspec===
Automatic testing will be achieved using Rspec. The primary controller for testing will be controllers/submission_viewing_events_controller.rb, as edits will be made to mark_end_time and record_end_time methods to ensure that recorded review times for resources are not overlapping.

Proposed Rspec Tests:
* When a new review is started probe the Expertiza timer and ensure it returns the start value (0)
* When a saved review is started again probe the Expertiza timer and ensure it returns the time value stored in the database
* When an external link is clicked on a new review probe the timer link for that link and ensure it returns the start value (0)
* When an external link is clicked on a previously saved review probe the timer link for that link and ensure it returns and ensure it returns the time value stored in the database
* When a review is saved/submitted ensure that the time sent to the database matches time stored in database after execution
* When a review is clicked on by the instructor the data returned from date base should match test data.

===Manual Testing===
# Log in as instructor
# Assign a review to a student
# Log in as student
# Complete the dummy review in 5 minutes
# Log in as instructor
# Navigate to review report tab
# Verify that the review was completed ~5 minutes.

== '''References''' ==

=== Useful Links ===

[https://github.com/expertiza/expertiza Expertiza Repo] 
[https://github.com/rohanpillai20/expertiza E1791 Repo]

=== Our Implementation ===

[https://github.com/jamcdon3/expertiza/tree/E2015 Github Repo:] 
[https://github.com/rohanpillai20/expertiza/pull/51 Pull Request:]

=== Team Information ===
'''Mentor:''' 
Abhirav Kariya

'''Students:''' 
Hartley Leroy 
John McDonald 
Christian Morris 
Tyler Sattler

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-24T17:35:30Z

Tsattle: /* Student */

__TOC__
== '''Abstract''' ==
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

== '''Problem Statement''' ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. It is important that functionality be added so Expertiza can track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

The overall amount of time directly spent on the review is most important. One can track the amount of time spent on the review by tracking the amount of time from when the page is opened untill when the review is saved/submitted. Therefore, being able to track the time from once a resource is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

The following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and resources should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

== '''Previous Implementations''' ==
Thus far, Expertiza does not have the completed aforementioned feature. Previous attempts to implement this functionality have been made but the work was not merged into Expertiza code base for various reason. These previous projects are summarized below:

#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://github.com/expertiza/expertiza/pull/1662/commits E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== '''Proposed Solution''' ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1662/commits E1989] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages and the reason it was not integrated into expertiza was due to the amount of white space in commits and unsatisfactory commit messages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both. Tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.
*There are a few solutions one could implement to fix such an issue, such as marking both the start time and end time for when an external link or application was accessed by a user. Another solution which we will attempt in our first iteration of development is to track the time that an external link was clicked, and use the submission time of the review as our estimated end time for the external link. We thought of this design choice because once the report is submitted, the access time to external links should be stopped since the review is complete.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints about the use of a tabular method that was implemented in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791], stating that the review report table becomes too cluttered, we intend to create a pop-up window that will display the results in a table or graph of some sort. The proposed pop up will display all necessary information in a neat and simple self contained form. The exact display is undetermined, however proposed solutions include another tabular design, bar graphs, pie charts, etc.

== '''User Stories''' ==
The following section outlines the predicted user interactions with our software. Two potential users have been identified; users and instructors.

====Student====
Students will be interacting with the implementation when filling out a review. A similar workflow from [https://github.com/expertiza/expertiza/pull/1662/commits E1989] is used, however small edits were made to provide clean code and a valuable commit history. Initially, the user will click on the review they want to complete. Once the link is clicked the time will start to be logged. Upon the clicking of an external link another another timer will begin tracking it. This process repeats until the submission is saved/submitted or the page is exited out of. In the case where a review was previously saved, the timer will pick up from the last tracked time. The diagram below displays the flow of interactions visually.
[[File:User_Story.png| center |Image: 50 pixels]]

====Instructor====
Instructors will be interacting with the implementation when the are observing student reviews. Once again, a similar story from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] will be used for the instructor with minor changes. Firstly, the instructor will navigate to a page that displays all current and previously reviews. They will then be able to select a review from the given list and look at statistics about resources accessed and time spent on each resource. Saved reviews and already submitted reviews will be tagged differently. The diagram below displays the flow of interactions visually.

[[File:Instructor_Story.png | center |Image: 50 pixels]]

== '''Database Schema''' ==
Our datatable is named '''submission_viewing_events'''. The attributes and their descriptions are provided in the spreadsheet below. We use map_id to join '''response_maps''' table for storing the primary information. '''Round''' contains an int variable associated with the specific round review, '''link''' contains a character string storing the external link the reviewer clicked on, '''start_at''' contains the starting time the external link was pressed, while '''end_at''' contains the time when the link was closed.

[[File:Db_FINAL.PNG | center]]

 

Below shows the database relationship with other tables. '''submission_viewing_events''' will be touching '''response_maps'''. The highlight demonstrate which field correspond to response_maps key.

[[File:Db_schema_FINAL.png | center]]

== '''Code Changes''' ==
Our implementation builds off of the work done in E1989. This previous project has a substantial amount of the functionality already completed for tracking and viewing external pages and certain types of files. The primary error in this implementation is that when multiple files are open, the times at which they record reviews are overlapped creating inaccurate review reports. The displayed review report will also need to be edited to present review reports in a visually appealing manner. The following changes were made:

=== '''Files Created''' ===
<hr/>

==== '''controllers/submission_viewing_events_controller.rb''' ====

Creates a controller for handling events of submission viewing reviews. Created using rails 'generate controller' function. Includes three methods

# record_start_time : function starts the time for links that have been visited by the user.
# record_end_time : records the end time for links that have been visited by the user.
# mark_end_time : records the end time for links that have no end times.

==== '''db/migrate/20200420201807_create_submission_viewing_events.rb''' ====

Migration file to create data table for handling log start and end time for each link/file in the review. Created using rails 'generate model' function. More info regarding schema is included in the Database section.

==== '''app/views/submission_viewing_events/index.html.haml''' ====

Created a simple index page for viewing of submission events.

==== '''app/views/submission_viewing_events/edit.html.haml''' ====

Created file to allow for editing capabilities of submission viewing events.

==== '''app/views/submission_viewing_events/_form.html.haml''' ====

Created partial form that was used to fill in edit.html.haml file, as well as a few others.

==== '''spec/controllers/submission_viewing_events_controller_spec.rb''' ====

Implemented test cases for created SubmissionViewingEventsController using Rspec as per expertiza standard.

=== '''Files Edited''' ===
<hr/>

==== '''db/schema.rb''' ====

Updated to include the SubmissionViewingEvents model migration, as executed via a 'rake db:migrate"

==== '''app/views/reports/_review_submissions_time_spent.html.erb'''====

will be edited to accurately log viewing times for multiple links open at the same time. This will include creating methods such as calculateTime to help with parsing review times of different links, and a function drawChart to display review times in a visually appealing manner.

==== '''app/views/reports/_review_report.html.erb'''====

will be edited to reflect chart made in _review_submissions_time_spent.html.erb

==== '''app/views/submission_viewing_events/new.html.haml'''====

Created new.html.haml for submission_viewing_events for assisting in setting up the views.

==== '''app/views/submission_viewing_events/show.html.haml'''====

Created show.html.haml for submission_viewing_events for assisting in setting up the views.

==== '''app/helpers/submitted_content_helper.rb'''====

Updated line 32 to incorporate file link for the return variable, ret.

===='''app/views/popup/view_review_scores_popup.html.erb'''====

Break up query in line 55 into two queries.

==== '''app/views/reports/_review_submissions_time_spent.html.erb'''====

Created a view for reports controller.

==== '''app/views/reports/_review_report.html.erb'''====

Made changes to _review_report to reflect changes in reports_controller

==== '''app/views/response/_submitted_files.html.erb''' ====

Added JavaScript to this file which allows tracking of start and end times of accessing a hyperlink. Most functionality is on-click for tracking these times.

==== '''config/routes.rb''' ====

Added collection for start and end times when hyperlink is accessed. Includes post and get calls for recording start and end times as necessary (see lines 420-428)

==== '''app/controllers/response_controller.rb''' ====

Added field @current_round to file for tracking the current round of reviews for a student. See lines 83 and 267 for variable instantiation.

==== '''app/views/response/view.html.erb''' ====

Edited to set submission check variable to false.

==== '''app/views/response/response.html.erb''' ====

Edited to contain two functions to track start and end time or review. Added hidden field tags to form to track timeouts, as well as a submission check to ensure reviewer is still working on review.

==== '''app/views/submitted_content/_main.html.erb''' ====

Added checks for local assignment submissions, where if true a partial specifically for hyperlinks and submitted files are loaded. See lines 10-20 for specific changes.

==== '''app/views/submitted_content/_hyperlink.html.erb''' ====

Adds functionality to ensure that user must click on a hyperlink instead of copying and pasting the link. From line 41-end there is more JavaScript that marks start and end times for accessing these hyperlinks.

== '''Testing Plan''' ==
===Rspec===
Automatic testing will be achieved using Rspec. The primary controller for testing will be controllers/submission_viewing_events_controller.rb, as edits will be made to mark_end_time and record_end_time methods to ensure that recorded review times for resources are not overlapping.

Proposed Rspec Tests:
* When a new review is started probe the Expertiza timer and ensure it returns the start value (0)
* When a saved review is started again probe the Expertiza timer and ensure it returns the time value stored in the database
* When an external link is clicked on a new review probe the timer link for that link and ensure it returns the start value (0)
* When an external link is clicked on a previously saved review probe the timer link for that link and ensure it returns and ensure it returns the time value stored in the database
* When a review is saved/submitted ensure that the time sent to the database matches time stored in database after execution
* When a review is clicked on by the instructor the data returned from date base should match test data.

===Manual Testing===
# Log in as instructor
# Assign a review to a student
# Log in as student
# Complete the dummy review in 5 minutes
# Log in as instructor
# Navigate to review report tab
# Verify that the review was completed ~5 minutes.

== '''References''' ==

=== Useful Links ===

[https://github.com/expertiza/expertiza Expertiza Repo] 
[https://github.com/rohanpillai20/expertiza E1791 Repo]

=== Our Implementation ===

[https://github.com/jamcdon3/expertiza/tree/E2015 Github Repo:] 
[https://github.com/rohanpillai20/expertiza/pull/51 Pull Request:]

=== Team Information ===
'''Mentor:''' 
Abhirav Kariya

'''Students:''' 
Hartley Leroy 
John McDonald 
Christian Morris 
Tyler Sattler

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-24T17:28:07Z

Tsattle: /* Proposed Solution */

__TOC__
== '''Abstract''' ==
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

== '''Problem Statement''' ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. It is important that functionality be added so Expertiza can track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

The overall amount of time directly spent on the review is most important. One can track the amount of time spent on the review by tracking the amount of time from when the page is opened untill when the review is saved/submitted. Therefore, being able to track the time from once a resource is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

The following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and resources should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

== '''Previous Implementations''' ==
Thus far, Expertiza does not have the completed aforementioned feature. Previous attempts to implement this functionality have been made but the work was not merged into Expertiza code base for various reason. These previous projects are summarized below:

#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://github.com/expertiza/expertiza/pull/1662/commits E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== '''Proposed Solution''' ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1662/commits E1989] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages and the reason it was not integrated into expertiza was due to the amount of white space in commits and unsatisfactory commit messages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both. Tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.
*There are a few solutions one could implement to fix such an issue, such as marking both the start time and end time for when an external link or application was accessed by a user. Another solution which we will attempt in our first iteration of development is to track the time that an external link was clicked, and use the submission time of the review as our estimated end time for the external link. We thought of this design choice because once the report is submitted, the access time to external links should be stopped since the review is complete.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints about the use of a tabular method that was implemented in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791], stating that the review report table becomes too cluttered, we intend to create a pop-up window that will display the results in a table or graph of some sort. The proposed pop up will display all necessary information in a neat and simple self contained form. The exact display is undetermined, however proposed solutions include another tabular design, bar graphs, pie charts, etc.

== '''User Stories''' ==
The following section outlines the predicted user interactions with our software. Two potential users have been identified; users and instructors.

====Student====
Students will be interacting with the implementation when filling out a review. A similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] is used, however small edits were made to better suite our proposed implementation. Initially, the user will click on the review they want to complete. Once the link is clicked the time will start to be logged. Upon the clicking of an external link another another timer will begin tracking it. This process repeats until the submission is saved/submitted or the page is exited out of. In the case where a review was previously saved the timer will pick up from the last tracked time. The diagram below displays the flow of interactions visually.
[[File:User_Story.png| center |Image: 50 pixels]]

====Instructor====
Instructors will be interacting with the implementation when the are observing student reviews. Once again, a similar story from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] will be used for the instructor with minor changes. Firstly, the instructor will navigate to a page that displays all current and previously reviews. They will then be able to select a review from the given list and look at statistics about resources accessed and time spent on each resource. Saved reviews and already submitted reviews will be tagged differently. The diagram below displays the flow of interactions visually.

[[File:Instructor_Story.png | center |Image: 50 pixels]]

== '''Database Schema''' ==
Our datatable is named '''submission_viewing_events'''. The attributes and their descriptions are provided in the spreadsheet below. We use map_id to join '''response_maps''' table for storing the primary information. '''Round''' contains an int variable associated with the specific round review, '''link''' contains a character string storing the external link the reviewer clicked on, '''start_at''' contains the starting time the external link was pressed, while '''end_at''' contains the time when the link was closed.

[[File:Db_FINAL.PNG | center]]

 

Below shows the database relationship with other tables. '''submission_viewing_events''' will be touching '''response_maps'''. The highlight demonstrate which field correspond to response_maps key.

[[File:Db_schema_FINAL.png | center]]

== '''Code Changes''' ==
Our implementation builds off of the work done in E1989. This previous project has a substantial amount of the functionality already completed for tracking and viewing external pages and certain types of files. The primary error in this implementation is that when multiple files are open, the times at which they record reviews are overlapped creating inaccurate review reports. The displayed review report will also need to be edited to present review reports in a visually appealing manner. The following changes were made:

=== '''Files Created''' ===
<hr/>

==== '''controllers/submission_viewing_events_controller.rb''' ====

Creates a controller for handling events of submission viewing reviews. Created using rails 'generate controller' function. Includes three methods

# record_start_time : function starts the time for links that have been visited by the user.
# record_end_time : records the end time for links that have been visited by the user.
# mark_end_time : records the end time for links that have no end times.

==== '''20200420201807_create_submission_viewing_events.rb''' ====

Migration file to create data table for handling log start and end time for each link/file in the review. Created using rails 'generate model' function. More info regarding schema is included in the Database section.

==== '''app/views/submission_viewing_events/index.html.haml''' ====

Created a simple index page for viewing of submission events.

==== '''app/views/submission_viewing_events/edit.html.haml''' ====

Created file to allow for editing capabilities of submission viewing events.

==== '''app/views/submission_viewing_events/_form.html.haml''' ====

Created partial form that was used to fill in edit.html.haml file, as well as a few others.

=== '''Files Edited''' ===
<hr/>

==== '''db/schema.rb''' ====

Updated to include the SubmissionViewingEvents model migration, as executed via a 'rake db:migrate"

==== '''app/views/reports/_review_submissions_time_spent.html.erb'''====

will be edited to accurately log viewing times for multiple links open at the same time. This will include creating methods such as calculateTime to help with parsing review times of different links, and a function drawChart to display review times in a visually appealing manner.

==== '''app/views/reports/_review_report.html.erb'''====

will be edited to reflect chart made in _review_submissions_time_spent.html.erb

==== '''app/views/submission_viewing_events/new.html.haml'''====

Created new.html.haml for submission_viewing_events for assisting in setting up the views.

==== '''app/views/submission_viewing_events/show.html.haml'''====

Created show.html.haml for submission_viewing_events for assisting in setting up the views.

==== '''app/helpers/submitted_content_helper.rb'''====

Updated line 32 to incorporate file link for the return variable, ret.

===='''app/views/popup/view_review_scores_popup.html.erb'''====

Break up query in line 55 into two queries.

==== '''app/views/reports/_review_submissions_time_spent.html.erb'''====

Created a view for reports controller.

==== '''app/views/reports/_review_report.html.erb'''====

Made changes to _review_report to reflect changes in reports_controller

==== '''app/views/response/_submitted_files.html.erb''' ====

Added JavaScript to this file which allows tracking of start and end times of accessing a hyperlink. Most functionality is on-click for tracking these times.

==== '''config/routes.rb''' ====

Added collection for start and end times when hyperlink is accessed. Includes post and get calls for recording start and end times as necessary (see lines 420-428)

==== '''app/controllers/response_controller.rb''' ====

Added field @current_round to file for tracking the current round of reviews for a student. See lines 83 and 267 for variable instantiation.

==== '''app/views/response/view.html.erb''' ====

Edited to set submission check variable to false.

==== '''app/views/response/response.html.erb''' ====

Edited to contain two functions to track start and end time or review. Added hidden field tags to form to track timeouts, as well as a submission check to ensure reviewer is still working on review.

==== '''app/views/submitted_content/_main.html.erb''' ====

Added checks for local assignment submissions, where if true a partial specifically for hyperlinks and submitted files are loaded. See lines 10-20 for specific changes.

==== '''app/views/submitted_content/_hyperlink.html.erb''' ====

Adds functionality to ensure that user must click on a hyperlink instead of copying and pasting the link. From line 41-end there is more JavaScript that marks start and end times for accessing these hyperlinks.

== '''Testing Plan''' ==
===Rspec===
Automatic testing will be achieved using Rspec. The primary controller for testing will be controllers/submission_viewing_events_controller.rb, as edits will be made to mark_end_time and record_end_time methods to ensure that recorded review times for resources are not overlapping.

Proposed Rspec Tests:
* When a new review is started probe the Expertiza timer and ensure it returns the start value (0)
* When a saved review is started again probe the Expertiza timer and ensure it returns the time value stored in the database
* When an external link is clicked on a new review probe the timer link for that link and ensure it returns the start value (0)
* When an external link is clicked on a previously saved review probe the timer link for that link and ensure it returns and ensure it returns the time value stored in the database
* When a review is saved/submitted ensure that the time sent to the database matches time stored in database after execution
* When a review is clicked on by the instructor the data returned from date base should match test data.

===Manual Testing===
# Log in as instructor
# Assign a review to a student
# Log in as student
# Complete the dummy review in 5 minutes
# Log in as instructor
# Navigate to review report tab
# Verify that the review was completed ~5 minutes.

== '''References''' ==

=== Useful Links ===

[https://github.com/expertiza/expertiza Expertiza Repo] 
[https://github.com/rohanpillai20/expertiza E1791 Repo]

=== Our Implementation ===

[https://github.com/jamcdon3/expertiza/tree/E2015 Github Repo:] 
[https://github.com/rohanpillai20/expertiza/pull/51 Pull Request:]

=== Team Information ===
'''Mentor:''' 
Abhirav Kariya

'''Students:''' 
Hartley Leroy 
John McDonald 
Christian Morris 
Tyler Sattler

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-23T19:05:14Z

Tsattle: /* Database Schema */

__TOC__
== '''Abstract''' ==
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

== '''Problem Statement''' ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. It is important that functionality be added so Expertiza can track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

The overall amount of time directly spent on the review is most important. One can track the amount of time spent on the review by tracking the amount of time from when the page is opened untill when the review is saved/submitted. Therefore, being able to track the time from once a resource is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

The following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and resources should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

== '''Previous Implementations''' ==
Thus far, Expertiza does not have the completed aforementioned feature. Previous attempts to implement this functionality have been made but the work was not merged into Expertiza code base for various reason. These previous projects are summarized below:

#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://github.com/expertiza/expertiza/pull/1662/commits E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== '''Proposed Solution''' ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1124 E1791] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both. Tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.
*There are a few solutions one could implement to fix such an issue, such as marking both the start time and end time for when an external link or application was accessed by a user. Another solution which we will attempt in our first iteration of development is to track the time that an external link was clicked, and use the submission time of the review as our estimated end time for the external link. We thought of this design choice because once the report is submitted, the access time to external links should be stopped since the review is complete.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints about the use of a tabular method that was implemented in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791], stating that the review report table becomes too cluttered, we intend to create a pop-up window that will display the results in a table or graph of some sort. The proposed pop up will display all necessary information in a neat and simple self contained form. The exact display is undetermined, however proposed solutions include another tabular design, bar graphs, pie charts, etc.

== '''Code Changes''' ==
Our implementation builds off of the work done in E1791. This previous project has a substantial amount of the functionality already completed for tracking and viewing external pages and certain types of files. The primary error in this implementation is that when multiple files are open, the times at which they record reviews are overlapped creating inaccurate review reports. The displayed review report will also need to be edited to present review reports in a visually appealing manner. The following changes were made:

'''Files editted:''' 
# controllers/submission_viewing_events_controller.rb handles the start and end time of reviews. So, edits will need to be made to methods markEndTime() and endTime() to remove overlap issues.
# submission_viewing_events datatable to handle log start and end time for each link/file. Edits to algorithm for logging may present need to adjust structure of existing datatable.
# app/views/reports/_review_submissions_time_spent.html.erb will be edited to accurately log viewing times for multiple links open at the same time. This will include creating methods such as calculateTime to help with parsing review times of different links, and a function drawChart to display review times in a visually appealing manner.
# app/views/reports/_review_report.html.erb will be edited to reflect chart made in _review_submissions_time_spent.html.erb
# app/views/submission_viewing_events/new.html.haml Created new.html.haml for submission_viewing_events for assisting in setting up the views.
# app/views/submission_viewing_events/show.html.haml Created show.html.haml for submission_viewing_events for assisting in setting up the views.
# app/helpers/submitted_content_helper.rb Updated line 32 to incorporate file link for the return variable, ret.
# app/views/popup/view_review_scores_popup.html.erb Break up query in line 55 into two queries.
# app/views/reports/_review_submissions_time_spent.html.erb Created a view for reports controller.
# app/views/reports/_review_report.html.erb Made changes to _review_report to reflect changes in reports_controller

== '''User Stories''' ==
The following section outlines the predicted user interactions with our software. Two potential users have been identified; users and instructors.

====Student====
Students will be interacting with the implementation when filling out a review. A similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] is used, however small edits were made to better suite our proposed implementation. Initially, the user will click on the review they want to complete. Once the link is clicked the time will start to be logged. Upon the clicking of an external link another another timer will begin tracking it. This process repeats until the submission is saved/submitted or the page is exited out of. In the case where a review was previously saved the timer will pick up from the last tracked time. The diagram below displays the flow of interactions visually.
[[File:User_Story.png| center |Image: 50 pixels]]

====Instructor====
Instructors will be interacting with the implementation when the are observing student reviews. Once again, a similar story from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] will be used for the instructor with minor changes. Firstly, the instructor will navigate to a page that displays all current and previously reviews. They will then be able to select a review from the given list and look at statistics about resources accessed and time spent on each resource. Saved reviews and already submitted reviews will be tagged differently. The diagram below displays the flow of interactions visually.

[[File:Instructor_Story.png | center |Image: 50 pixels]]

== '''Database Schema''' ==
Our datatable is named '''submission_viewing_events'''. The attributes and their descriptions are provided in the spreadsheet below. We use map_id to join '''response_maps''' table for storing the primary information. '''Round''' contains an int variable associated with the specific round review, '''link''' contains a character string storing the external link the reviewer clicked on, '''start_at''' contains the starting time the external link was pressed, while '''end_at''' contains the time when the link was closed.

[[File:Db_FINAL.PNG | center]]

 

Below shows the database relationship with other tables. '''submission_viewing_events''' will be touching '''response_maps'''. The highlight demonstrate which field correspond to response_maps key.

[[File:Db_schema_FINAL.png | center]]

== '''Testing Plan''' ==
===Rspec===
Automatic testing will be achieved using Rspec. The primary controller for testing will be controllers/submission_viewing_events_controller.rb, as edits will be made to mark_end_time and record_end_time methods to ensure that recorded review times for resources are not overlapping.

Proposed Rspec Tests:
* When a new review is started probe the Expertiza timer and ensure it returns the start value (0)
* When a saved review is started again probe the Expertiza timer and ensure it returns the time value stored in the database
* When an external link is clicked on a new review probe the timer link for that link and ensure it returns the start value (0)
* When an external link is clicked on a previously saved review probe the timer link for that link and ensure it returns and ensure it returns the time value stored in the database
* When a review is saved/submitted ensure that the time sent to the database matches time stored in database after execution
* When a review is clicked on by the instructor the data returned from date base should match test data.

===Manual Testing===
# Log in as instructor
# Assign a review to a student
# Log in as student
# Complete the dummy review in 5 minutes
# Log in as instructor
# Navigate to review report tab
# Verify that the review was completed ~5 minutes.

== '''References''' ==

=== Useful Links ===

[https://github.com/expertiza/expertiza Expertiza Repo] 
[https://github.com/rohanpillai20/expertiza E1791 Repo]

=== Our Implementation ===

[https://github.com/jamcdon3/expertiza/tree/E2015 Github Repo:] 
[https://github.com/rohanpillai20/expertiza/pull/51 Pull Request:]

=== Team Information ===
'''Mentor:''' 
Abhirav Kariya

'''Students:''' 
Hartley Leroy 
John McDonald 
Christian Morris 
Tyler Sattler

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-23T19:03:09Z

Tsattle: /* Database Schema */

__TOC__
== '''Abstract''' ==
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

== '''Problem Statement''' ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. It is important that functionality be added so Expertiza can track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

The overall amount of time directly spent on the review is most important. One can track the amount of time spent on the review by tracking the amount of time from when the page is opened untill when the review is saved/submitted. Therefore, being able to track the time from once a resource is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

The following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and resources should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

== '''Previous Implementations''' ==
Thus far, Expertiza does not have the completed aforementioned feature. Previous attempts to implement this functionality have been made but the work was not merged into Expertiza code base for various reason. These previous projects are summarized below:

#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://github.com/expertiza/expertiza/pull/1662/commits E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== '''Proposed Solution''' ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1124 E1791] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both. Tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.
*There are a few solutions one could implement to fix such an issue, such as marking both the start time and end time for when an external link or application was accessed by a user. Another solution which we will attempt in our first iteration of development is to track the time that an external link was clicked, and use the submission time of the review as our estimated end time for the external link. We thought of this design choice because once the report is submitted, the access time to external links should be stopped since the review is complete.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints about the use of a tabular method that was implemented in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791], stating that the review report table becomes too cluttered, we intend to create a pop-up window that will display the results in a table or graph of some sort. The proposed pop up will display all necessary information in a neat and simple self contained form. The exact display is undetermined, however proposed solutions include another tabular design, bar graphs, pie charts, etc.

== '''Code Changes''' ==
Our implementation builds off of the work done in E1791. This previous project has a substantial amount of the functionality already completed for tracking and viewing external pages and certain types of files. The primary error in this implementation is that when multiple files are open, the times at which they record reviews are overlapped creating inaccurate review reports. The displayed review report will also need to be edited to present review reports in a visually appealing manner. The following changes were made:

'''Files editted:''' 
# controllers/submission_viewing_events_controller.rb handles the start and end time of reviews. So, edits will need to be made to methods markEndTime() and endTime() to remove overlap issues.
# submission_viewing_events datatable to handle log start and end time for each link/file. Edits to algorithm for logging may present need to adjust structure of existing datatable.
# app/views/reports/_review_submissions_time_spent.html.erb will be edited to accurately log viewing times for multiple links open at the same time. This will include creating methods such as calculateTime to help with parsing review times of different links, and a function drawChart to display review times in a visually appealing manner.
# app/views/reports/_review_report.html.erb will be edited to reflect chart made in _review_submissions_time_spent.html.erb
# app/views/submission_viewing_events/new.html.haml Created new.html.haml for submission_viewing_events for assisting in setting up the views.
# app/views/submission_viewing_events/show.html.haml Created show.html.haml for submission_viewing_events for assisting in setting up the views.
# app/helpers/submitted_content_helper.rb Updated line 32 to incorporate file link for the return variable, ret.
# app/views/popup/view_review_scores_popup.html.erb Break up query in line 55 into two queries.
# app/views/reports/_review_submissions_time_spent.html.erb Created a view for reports controller.
# app/views/reports/_review_report.html.erb Made changes to _review_report to reflect changes in reports_controller

== '''User Stories''' ==
The following section outlines the predicted user interactions with our software. Two potential users have been identified; users and instructors.

====Student====
Students will be interacting with the implementation when filling out a review. A similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] is used, however small edits were made to better suite our proposed implementation. Initially, the user will click on the review they want to complete. Once the link is clicked the time will start to be logged. Upon the clicking of an external link another another timer will begin tracking it. This process repeats until the submission is saved/submitted or the page is exited out of. In the case where a review was previously saved the timer will pick up from the last tracked time. The diagram below displays the flow of interactions visually.
[[File:User_Story.png| center |Image: 50 pixels]]

====Instructor====
Instructors will be interacting with the implementation when the are observing student reviews. Once again, a similar story from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] will be used for the instructor with minor changes. Firstly, the instructor will navigate to a page that displays all current and previously reviews. They will then be able to select a review from the given list and look at statistics about resources accessed and time spent on each resource. Saved reviews and already submitted reviews will be tagged differently. The diagram below displays the flow of interactions visually.

[[File:Instructor_Story.png | center |Image: 50 pixels]]

== '''Database Schema''' ==
Our datatable is named '''submission_viewing_events'''. The attributes and their descriptions are provided in the spreadsheet below. We use map_id to join '''response_maps table''' for storing the primary information. '''Round''' contains an int variable associated with the specific round review, '''link''' contains a character string storing the external link the reviewer clicked on, '''start_at''' contains the starting time the external link was pressed, while '''end_at''' contains the time when the link was closed.

[[File:Db_FINAL.PNG | center]]

 

Below shows the database relationship with other tables. '''submission_viewing_events''' will be touching '''response_maps'''. The highlight demonstrate which field correspond to response_maps key.

[[File:Db_schema_FINAL.png | center]]

== '''Testing Plan''' ==
===Rspec===
Automatic testing will be achieved using Rspec. The primary controller for testing will be controllers/submission_viewing_events_controller.rb, as edits will be made to mark_end_time and record_end_time methods to ensure that recorded review times for resources are not overlapping.

Proposed Rspec Tests:
* When a new review is started probe the Expertiza timer and ensure it returns the start value (0)
* When a saved review is started again probe the Expertiza timer and ensure it returns the time value stored in the database
* When an external link is clicked on a new review probe the timer link for that link and ensure it returns the start value (0)
* When an external link is clicked on a previously saved review probe the timer link for that link and ensure it returns and ensure it returns the time value stored in the database
* When a review is saved/submitted ensure that the time sent to the database matches time stored in database after execution
* When a review is clicked on by the instructor the data returned from date base should match test data.

===Manual Testing===
# Log in as instructor
# Assign a review to a student
# Log in as student
# Complete the dummy review in 5 minutes
# Log in as instructor
# Navigate to review report tab
# Verify that the review was completed ~5 minutes.

== '''References''' ==

=== Useful Links ===

[https://github.com/expertiza/expertiza Expertiza Repo] 
[https://github.com/rohanpillai20/expertiza E1791 Repo]

=== Our Implementation ===

[https://github.com/jamcdon3/expertiza/tree/E2015 Github Repo:] 
[https://github.com/rohanpillai20/expertiza/pull/51 Pull Request:]

=== Team Information ===
'''Mentor:''' 
Abhirav Kariya

'''Students:''' 
Hartley Leroy 
John McDonald 
Christian Morris 
Tyler Sattler

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-23T18:59:34Z

Tsattle: /* Database Schema */

__TOC__
== '''Abstract''' ==
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

== '''Problem Statement''' ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. It is important that functionality be added so Expertiza can track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

The overall amount of time directly spent on the review is most important. One can track the amount of time spent on the review by tracking the amount of time from when the page is opened untill when the review is saved/submitted. Therefore, being able to track the time from once a resource is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

The following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and resources should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

== '''Previous Implementations''' ==
Thus far, Expertiza does not have the completed aforementioned feature. Previous attempts to implement this functionality have been made but the work was not merged into Expertiza code base for various reason. These previous projects are summarized below:

#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://github.com/expertiza/expertiza/pull/1662/commits E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== '''Proposed Solution''' ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1124 E1791] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both. Tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.
*There are a few solutions one could implement to fix such an issue, such as marking both the start time and end time for when an external link or application was accessed by a user. Another solution which we will attempt in our first iteration of development is to track the time that an external link was clicked, and use the submission time of the review as our estimated end time for the external link. We thought of this design choice because once the report is submitted, the access time to external links should be stopped since the review is complete.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints about the use of a tabular method that was implemented in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791], stating that the review report table becomes too cluttered, we intend to create a pop-up window that will display the results in a table or graph of some sort. The proposed pop up will display all necessary information in a neat and simple self contained form. The exact display is undetermined, however proposed solutions include another tabular design, bar graphs, pie charts, etc.

== '''Code Changes''' ==
Our implementation builds off of the work done in E1791. This previous project has a substantial amount of the functionality already completed for tracking and viewing external pages and certain types of files. The primary error in this implementation is that when multiple files are open, the times at which they record reviews are overlapped creating inaccurate review reports. The displayed review report will also need to be edited to present review reports in a visually appealing manner. The following changes were made:

'''Files editted:''' 
# controllers/submission_viewing_events_controller.rb handles the start and end time of reviews. So, edits will need to be made to methods markEndTime() and endTime() to remove overlap issues.
# submission_viewing_events datatable to handle log start and end time for each link/file. Edits to algorithm for logging may present need to adjust structure of existing datatable.
# app/views/reports/_review_submissions_time_spent.html.erb will be edited to accurately log viewing times for multiple links open at the same time. This will include creating methods such as calculateTime to help with parsing review times of different links, and a function drawChart to display review times in a visually appealing manner.
# app/views/reports/_review_report.html.erb will be edited to reflect chart made in _review_submissions_time_spent.html.erb
# app/views/submission_viewing_events/new.html.haml Created new.html.haml for submission_viewing_events for assisting in setting up the views.
# app/views/submission_viewing_events/show.html.haml Created show.html.haml for submission_viewing_events for assisting in setting up the views.
# app/helpers/submitted_content_helper.rb Updated line 32 to incorporate file link for the return variable, ret.
# app/views/popup/view_review_scores_popup.html.erb Break up query in line 55 into two queries.
# app/views/reports/_review_submissions_time_spent.html.erb Created a view for reports controller.
# app/views/reports/_review_report.html.erb Made changes to _review_report to reflect changes in reports_controller

== '''User Stories''' ==
The following section outlines the predicted user interactions with our software. Two potential users have been identified; users and instructors.

====Student====
Students will be interacting with the implementation when filling out a review. A similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] is used, however small edits were made to better suite our proposed implementation. Initially, the user will click on the review they want to complete. Once the link is clicked the time will start to be logged. Upon the clicking of an external link another another timer will begin tracking it. This process repeats until the submission is saved/submitted or the page is exited out of. In the case where a review was previously saved the timer will pick up from the last tracked time. The diagram below displays the flow of interactions visually.
[[File:User_Story.png| center |Image: 50 pixels]]

====Instructor====
Instructors will be interacting with the implementation when the are observing student reviews. Once again, a similar story from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] will be used for the instructor with minor changes. Firstly, the instructor will navigate to a page that displays all current and previously reviews. They will then be able to select a review from the given list and look at statistics about resources accessed and time spent on each resource. Saved reviews and already submitted reviews will be tagged differently. The diagram below displays the flow of interactions visually.

[[File:Instructor_Story.png | center |Image: 50 pixels]]

== '''Database Schema''' ==
Our datatable is named '''submission_viewing_events'''. The attributes and their descriptions are provided in the spreadsheet below. We use map_id to join response_maps table for storing the primary information.

[[File:Db_FINAL.PNG | center]]

 

Below shows the database relationship with other tables. '''submission_viewing_events''' will be touching '''response_maps'''. The highlight demonstrate which field correspond to response_maps key.

[[File:Db_schema_FINAL.png | center]]

== '''Testing Plan''' ==
===Rspec===
Automatic testing will be achieved using Rspec. The primary controller for testing will be controllers/submission_viewing_events_controller.rb, as edits will be made to mark_end_time and record_end_time methods to ensure that recorded review times for resources are not overlapping.

Proposed Rspec Tests:
* When a new review is started probe the Expertiza timer and ensure it returns the start value (0)
* When a saved review is started again probe the Expertiza timer and ensure it returns the time value stored in the database
* When an external link is clicked on a new review probe the timer link for that link and ensure it returns the start value (0)
* When an external link is clicked on a previously saved review probe the timer link for that link and ensure it returns and ensure it returns the time value stored in the database
* When a review is saved/submitted ensure that the time sent to the database matches time stored in database after execution
* When a review is clicked on by the instructor the data returned from date base should match test data.

===Manual Testing===
# Log in as instructor
# Assign a review to a student
# Log in as student
# Complete the dummy review in 5 minutes
# Log in as instructor
# Navigate to review report tab
# Verify that the review was completed ~5 minutes.

== '''References''' ==

=== Useful Links ===

[https://github.com/expertiza/expertiza Expertiza Repo] 
[https://github.com/rohanpillai20/expertiza E1791 Repo]

=== Our Implementation ===

[https://github.com/jamcdon3/expertiza/tree/E2015 Github Repo:] 
[https://github.com/rohanpillai20/expertiza/pull/51 Pull Request:]

=== Team Information ===
'''Mentor:''' 
Abhirav Kariya

'''Students:''' 
Hartley Leroy 
John McDonald 
Christian Morris 
Tyler Sattler

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-23T18:57:00Z

Tsattle: /* Database Schema */

__TOC__
== '''Abstract''' ==
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

== '''Problem Statement''' ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. It is important that functionality be added so Expertiza can track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

The overall amount of time directly spent on the review is most important. One can track the amount of time spent on the review by tracking the amount of time from when the page is opened untill when the review is saved/submitted. Therefore, being able to track the time from once a resource is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

The following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and resources should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

== '''Previous Implementations''' ==
Thus far, Expertiza does not have the completed aforementioned feature. Previous attempts to implement this functionality have been made but the work was not merged into Expertiza code base for various reason. These previous projects are summarized below:

#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://github.com/expertiza/expertiza/pull/1662/commits E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== '''Proposed Solution''' ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1124 E1791] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both. Tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.
*There are a few solutions one could implement to fix such an issue, such as marking both the start time and end time for when an external link or application was accessed by a user. Another solution which we will attempt in our first iteration of development is to track the time that an external link was clicked, and use the submission time of the review as our estimated end time for the external link. We thought of this design choice because once the report is submitted, the access time to external links should be stopped since the review is complete.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints about the use of a tabular method that was implemented in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791], stating that the review report table becomes too cluttered, we intend to create a pop-up window that will display the results in a table or graph of some sort. The proposed pop up will display all necessary information in a neat and simple self contained form. The exact display is undetermined, however proposed solutions include another tabular design, bar graphs, pie charts, etc.

== '''Code Changes''' ==
Our implementation builds off of the work done in E1791. This previous project has a substantial amount of the functionality already completed for tracking and viewing external pages and certain types of files. The primary error in this implementation is that when multiple files are open, the times at which they record reviews are overlapped creating inaccurate review reports. The displayed review report will also need to be edited to present review reports in a visually appealing manner. The following changes were made:

'''Files editted:''' 
# controllers/submission_viewing_events_controller.rb handles the start and end time of reviews. So, edits will need to be made to methods markEndTime() and endTime() to remove overlap issues.
# submission_viewing_events datatable to handle log start and end time for each link/file. Edits to algorithm for logging may present need to adjust structure of existing datatable.
# app/views/reports/_review_submissions_time_spent.html.erb will be edited to accurately log viewing times for multiple links open at the same time. This will include creating methods such as calculateTime to help with parsing review times of different links, and a function drawChart to display review times in a visually appealing manner.
# app/views/reports/_review_report.html.erb will be edited to reflect chart made in _review_submissions_time_spent.html.erb
# app/views/submission_viewing_events/new.html.haml Created new.html.haml for submission_viewing_events for assisting in setting up the views.
# app/views/submission_viewing_events/show.html.haml Created show.html.haml for submission_viewing_events for assisting in setting up the views.
# app/helpers/submitted_content_helper.rb Updated line 32 to incorporate file link for the return variable, ret.
# app/views/popup/view_review_scores_popup.html.erb Break up query in line 55 into two queries.
# app/views/reports/_review_submissions_time_spent.html.erb Created a view for reports controller.
# app/views/reports/_review_report.html.erb Made changes to _review_report to reflect changes in reports_controller

== '''User Stories''' ==
The following section outlines the predicted user interactions with our software. Two potential users have been identified; users and instructors.

====Student====
Students will be interacting with the implementation when filling out a review. A similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] is used, however small edits were made to better suite our proposed implementation. Initially, the user will click on the review they want to complete. Once the link is clicked the time will start to be logged. Upon the clicking of an external link another another timer will begin tracking it. This process repeats until the submission is saved/submitted or the page is exited out of. In the case where a review was previously saved the timer will pick up from the last tracked time. The diagram below displays the flow of interactions visually.
[[File:User_Story.png| center |Image: 50 pixels]]

====Instructor====
Instructors will be interacting with the implementation when the are observing student reviews. Once again, a similar story from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] will be used for the instructor with minor changes. Firstly, the instructor will navigate to a page that displays all current and previously reviews. They will then be able to select a review from the given list and look at statistics about resources accessed and time spent on each resource. Saved reviews and already submitted reviews will be tagged differently. The diagram below displays the flow of interactions visually.

[[File:Instructor_Story.png | center |Image: 50 pixels]]

== '''Database Schema''' ==
Our datatable is named '''submission_viewing_events'''. The attributes and their descriptions are provided in the below spreadsheet. For the table, we would use map_id in table response, which uses response_map_id as the primary information. Then we need to record reviewer_id and reviewee_id, source_link for submitted links or file names, as well as time start_at and end_at, then store them in the table.

[[File:Db_FINAL.PNG | center]]

 

Below shows the database relationship with other tables. '''submission_viewing_events''' will be touching '''response_maps'''. The highlight demonstrate which field correspond to response_maps key.

[[File:Db_schema_FINAL.png | center]]

== '''Testing Plan''' ==
===Rspec===
Automatic testing will be achieved using Rspec. The primary controller for testing will be controllers/submission_viewing_events_controller.rb, as edits will be made to mark_end_time and record_end_time methods to ensure that recorded review times for resources are not overlapping.

Proposed Rspec Tests:
* When a new review is started probe the Expertiza timer and ensure it returns the start value (0)
* When a saved review is started again probe the Expertiza timer and ensure it returns the time value stored in the database
* When an external link is clicked on a new review probe the timer link for that link and ensure it returns the start value (0)
* When an external link is clicked on a previously saved review probe the timer link for that link and ensure it returns and ensure it returns the time value stored in the database
* When a review is saved/submitted ensure that the time sent to the database matches time stored in database after execution
* When a review is clicked on by the instructor the data returned from date base should match test data.

===Manual Testing===
# Log in as instructor
# Assign a review to a student
# Log in as student
# Complete the dummy review in 5 minutes
# Log in as instructor
# Navigate to review report tab
# Verify that the review was completed ~5 minutes.

== '''References''' ==

=== Useful Links ===

[https://github.com/expertiza/expertiza Expertiza Repo] 
[https://github.com/rohanpillai20/expertiza E1791 Repo]

=== Our Implementation ===

[https://github.com/jamcdon3/expertiza/tree/E2015 Github Repo:] 
[https://github.com/rohanpillai20/expertiza/pull/51 Pull Request:]

=== Team Information ===
'''Mentor:''' 
Abhirav Kariya

'''Students:''' 
Hartley Leroy 
John McDonald 
Christian Morris 
Tyler Sattler

File:Db FINAL.PNG

2020-04-23T18:56:43Z

Tsattle:

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-23T18:52:44Z

Tsattle: /* Database Schema */

__TOC__
== '''Abstract''' ==
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

== '''Problem Statement''' ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. It is important that functionality be added so Expertiza can track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

The overall amount of time directly spent on the review is most important. One can track the amount of time spent on the review by tracking the amount of time from when the page is opened untill when the review is saved/submitted. Therefore, being able to track the time from once a resource is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

The following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and resources should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

== '''Previous Implementations''' ==
Thus far, Expertiza does not have the completed aforementioned feature. Previous attempts to implement this functionality have been made but the work was not merged into Expertiza code base for various reason. These previous projects are summarized below:

#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://github.com/expertiza/expertiza/pull/1662/commits E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== '''Proposed Solution''' ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1124 E1791] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both. Tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.
*There are a few solutions one could implement to fix such an issue, such as marking both the start time and end time for when an external link or application was accessed by a user. Another solution which we will attempt in our first iteration of development is to track the time that an external link was clicked, and use the submission time of the review as our estimated end time for the external link. We thought of this design choice because once the report is submitted, the access time to external links should be stopped since the review is complete.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints about the use of a tabular method that was implemented in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791], stating that the review report table becomes too cluttered, we intend to create a pop-up window that will display the results in a table or graph of some sort. The proposed pop up will display all necessary information in a neat and simple self contained form. The exact display is undetermined, however proposed solutions include another tabular design, bar graphs, pie charts, etc.

== '''Code Changes''' ==
Our implementation builds off of the work done in E1791. This previous project has a substantial amount of the functionality already completed for tracking and viewing external pages and certain types of files. The primary error in this implementation is that when multiple files are open, the times at which they record reviews are overlapped creating inaccurate review reports. The displayed review report will also need to be edited to present review reports in a visually appealing manner. The following changes were made:

'''Files editted:''' 
# controllers/submission_viewing_events_controller.rb handles the start and end time of reviews. So, edits will need to be made to methods markEndTime() and endTime() to remove overlap issues.
# submission_viewing_events datatable to handle log start and end time for each link/file. Edits to algorithm for logging may present need to adjust structure of existing datatable.
# app/views/reports/_review_submissions_time_spent.html.erb will be edited to accurately log viewing times for multiple links open at the same time. This will include creating methods such as calculateTime to help with parsing review times of different links, and a function drawChart to display review times in a visually appealing manner.
# app/views/reports/_review_report.html.erb will be edited to reflect chart made in _review_submissions_time_spent.html.erb
# app/views/submission_viewing_events/new.html.haml Created new.html.haml for submission_viewing_events for assisting in setting up the views.
# app/views/submission_viewing_events/show.html.haml Created show.html.haml for submission_viewing_events for assisting in setting up the views.
# app/helpers/submitted_content_helper.rb Updated line 32 to incorporate file link for the return variable, ret.
# app/views/popup/view_review_scores_popup.html.erb Break up query in line 55 into two queries.
# app/views/reports/_review_submissions_time_spent.html.erb Created a view for reports controller.
# app/views/reports/_review_report.html.erb Made changes to _review_report to reflect changes in reports_controller

== '''User Stories''' ==
The following section outlines the predicted user interactions with our software. Two potential users have been identified; users and instructors.

====Student====
Students will be interacting with the implementation when filling out a review. A similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] is used, however small edits were made to better suite our proposed implementation. Initially, the user will click on the review they want to complete. Once the link is clicked the time will start to be logged. Upon the clicking of an external link another another timer will begin tracking it. This process repeats until the submission is saved/submitted or the page is exited out of. In the case where a review was previously saved the timer will pick up from the last tracked time. The diagram below displays the flow of interactions visually.
[[File:User_Story.png| center |Image: 50 pixels]]

====Instructor====
Instructors will be interacting with the implementation when the are observing student reviews. Once again, a similar story from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] will be used for the instructor with minor changes. Firstly, the instructor will navigate to a page that displays all current and previously reviews. They will then be able to select a review from the given list and look at statistics about resources accessed and time spent on each resource. Saved reviews and already submitted reviews will be tagged differently. The diagram below displays the flow of interactions visually.

[[File:Instructor_Story.png | center |Image: 50 pixels]]

== '''Database Schema''' ==
Our datatable is named '''submission_viewing_events'''. The attributes and their descriptions are provided in the below spreadsheet. For the table, we would use map_id in table response, which uses response_map_id as the primary information. Then we need to record reviewer_id and reviewee_id, source_link for submitted links or file names, as well as time start_at and end_at, then store them in the table.

[[File:Db_.PNG | center]]

 

Below shows the database relationship with other tables. '''submission_viewing_events''' will be touching '''response_maps'''. The highlight demonstrate which field correspond to response_maps key.

[[File:Db_schema_FINAL.png | center]]

== '''Testing Plan''' ==
===Rspec===
Automatic testing will be achieved using Rspec. The primary controller for testing will be controllers/submission_viewing_events_controller.rb, as edits will be made to mark_end_time and record_end_time methods to ensure that recorded review times for resources are not overlapping.

Proposed Rspec Tests:
* When a new review is started probe the Expertiza timer and ensure it returns the start value (0)
* When a saved review is started again probe the Expertiza timer and ensure it returns the time value stored in the database
* When an external link is clicked on a new review probe the timer link for that link and ensure it returns the start value (0)
* When an external link is clicked on a previously saved review probe the timer link for that link and ensure it returns and ensure it returns the time value stored in the database
* When a review is saved/submitted ensure that the time sent to the database matches time stored in database after execution
* When a review is clicked on by the instructor the data returned from date base should match test data.

===Manual Testing===
# Log in as instructor
# Assign a review to a student
# Log in as student
# Complete the dummy review in 5 minutes
# Log in as instructor
# Navigate to review report tab
# Verify that the review was completed ~5 minutes.

== '''References''' ==

=== Useful Links ===

[https://github.com/expertiza/expertiza Expertiza Repo] 
[https://github.com/rohanpillai20/expertiza E1791 Repo]

=== Our Implementation ===

[https://github.com/jamcdon3/expertiza/tree/E2015 Github Repo:] 
[https://github.com/rohanpillai20/expertiza/pull/51 Pull Request:]

=== Team Information ===
'''Mentor:''' 
Abhirav Kariya

'''Students:''' 
Hartley Leroy 
John McDonald 
Christian Morris 
Tyler Sattler

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-23T18:51:34Z

Tsattle: /* Database Schema */

__TOC__
== '''Abstract''' ==
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

== '''Problem Statement''' ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. It is important that functionality be added so Expertiza can track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

The overall amount of time directly spent on the review is most important. One can track the amount of time spent on the review by tracking the amount of time from when the page is opened untill when the review is saved/submitted. Therefore, being able to track the time from once a resource is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

The following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and resources should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

== '''Previous Implementations''' ==
Thus far, Expertiza does not have the completed aforementioned feature. Previous attempts to implement this functionality have been made but the work was not merged into Expertiza code base for various reason. These previous projects are summarized below:

#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://github.com/expertiza/expertiza/pull/1662/commits E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== '''Proposed Solution''' ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1124 E1791] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both. Tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.
*There are a few solutions one could implement to fix such an issue, such as marking both the start time and end time for when an external link or application was accessed by a user. Another solution which we will attempt in our first iteration of development is to track the time that an external link was clicked, and use the submission time of the review as our estimated end time for the external link. We thought of this design choice because once the report is submitted, the access time to external links should be stopped since the review is complete.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints about the use of a tabular method that was implemented in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791], stating that the review report table becomes too cluttered, we intend to create a pop-up window that will display the results in a table or graph of some sort. The proposed pop up will display all necessary information in a neat and simple self contained form. The exact display is undetermined, however proposed solutions include another tabular design, bar graphs, pie charts, etc.

== '''Code Changes''' ==
Our implementation builds off of the work done in E1791. This previous project has a substantial amount of the functionality already completed for tracking and viewing external pages and certain types of files. The primary error in this implementation is that when multiple files are open, the times at which they record reviews are overlapped creating inaccurate review reports. The displayed review report will also need to be edited to present review reports in a visually appealing manner. The following changes were made:

'''Files editted:''' 
# controllers/submission_viewing_events_controller.rb handles the start and end time of reviews. So, edits will need to be made to methods markEndTime() and endTime() to remove overlap issues.
# submission_viewing_events datatable to handle log start and end time for each link/file. Edits to algorithm for logging may present need to adjust structure of existing datatable.
# app/views/reports/_review_submissions_time_spent.html.erb will be edited to accurately log viewing times for multiple links open at the same time. This will include creating methods such as calculateTime to help with parsing review times of different links, and a function drawChart to display review times in a visually appealing manner.
# app/views/reports/_review_report.html.erb will be edited to reflect chart made in _review_submissions_time_spent.html.erb
# app/views/submission_viewing_events/new.html.haml Created new.html.haml for submission_viewing_events for assisting in setting up the views.
# app/views/submission_viewing_events/show.html.haml Created show.html.haml for submission_viewing_events for assisting in setting up the views.
# app/helpers/submitted_content_helper.rb Updated line 32 to incorporate file link for the return variable, ret.
# app/views/popup/view_review_scores_popup.html.erb Break up query in line 55 into two queries.
# app/views/reports/_review_submissions_time_spent.html.erb Created a view for reports controller.
# app/views/reports/_review_report.html.erb Made changes to _review_report to reflect changes in reports_controller

== '''User Stories''' ==
The following section outlines the predicted user interactions with our software. Two potential users have been identified; users and instructors.

====Student====
Students will be interacting with the implementation when filling out a review. A similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] is used, however small edits were made to better suite our proposed implementation. Initially, the user will click on the review they want to complete. Once the link is clicked the time will start to be logged. Upon the clicking of an external link another another timer will begin tracking it. This process repeats until the submission is saved/submitted or the page is exited out of. In the case where a review was previously saved the timer will pick up from the last tracked time. The diagram below displays the flow of interactions visually.
[[File:User_Story.png| center |Image: 50 pixels]]

====Instructor====
Instructors will be interacting with the implementation when the are observing student reviews. Once again, a similar story from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] will be used for the instructor with minor changes. Firstly, the instructor will navigate to a page that displays all current and previously reviews. They will then be able to select a review from the given list and look at statistics about resources accessed and time spent on each resource. Saved reviews and already submitted reviews will be tagged differently. The diagram below displays the flow of interactions visually.

[[File:Instructor_Story.png | center |Image: 50 pixels]]

== '''Database Schema''' ==
Our datatable is named '''submission_viewing_events'''. The attributes and their descriptions are provided in the below spreadsheet. For the table, we would use map_id in table response, which uses response_map_id as the primary information. Then we need to record reviewer_id and reviewee_id, source_link for submitted links or file names, as well as time start_at and end_at, then store them in the table.

[[File:Db_.PNG | center]]

 

Below shows the database relationship with other tables. '''submission_viewing_events''' will be touching '''response_maps'''. The boxes demonstrate which fields correspond to each other.

[[File:Db_schema_FINAL.png | center]]

== '''Testing Plan''' ==
===Rspec===
Automatic testing will be achieved using Rspec. The primary controller for testing will be controllers/submission_viewing_events_controller.rb, as edits will be made to mark_end_time and record_end_time methods to ensure that recorded review times for resources are not overlapping.

Proposed Rspec Tests:
* When a new review is started probe the Expertiza timer and ensure it returns the start value (0)
* When a saved review is started again probe the Expertiza timer and ensure it returns the time value stored in the database
* When an external link is clicked on a new review probe the timer link for that link and ensure it returns the start value (0)
* When an external link is clicked on a previously saved review probe the timer link for that link and ensure it returns and ensure it returns the time value stored in the database
* When a review is saved/submitted ensure that the time sent to the database matches time stored in database after execution
* When a review is clicked on by the instructor the data returned from date base should match test data.

===Manual Testing===
# Log in as instructor
# Assign a review to a student
# Log in as student
# Complete the dummy review in 5 minutes
# Log in as instructor
# Navigate to review report tab
# Verify that the review was completed ~5 minutes.

== '''References''' ==

=== Useful Links ===

[https://github.com/expertiza/expertiza Expertiza Repo] 
[https://github.com/rohanpillai20/expertiza E1791 Repo]

=== Our Implementation ===

[https://github.com/jamcdon3/expertiza/tree/E2015 Github Repo:] 
[https://github.com/rohanpillai20/expertiza/pull/51 Pull Request:]

=== Team Information ===
'''Mentor:''' 
Abhirav Kariya

'''Students:''' 
Hartley Leroy 
John McDonald 
Christian Morris 
Tyler Sattler

File:Db schema FINAL.png

2020-04-23T18:50:36Z

Tsattle:

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-23T17:28:51Z

Tsattle: /* Team Information */

__TOC__
== '''Abstract''' ==
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

== '''Problem Statement''' ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. It is important that functionality be added so Expertiza can track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

The overall amount of time directly spent on the review is most important. One can track the amount of time spent on the review by tracking the amount of time from when the page is opened untill when the review is saved/submitted. Therefore, being able to track the time from once a resource is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

The following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and resources should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

== '''Previous Implementations''' ==
Thus far, Expertiza does not have the completed aforementioned feature. Previous attempts to implement this functionality have been made but the work was not merged into Expertiza code base for various reason. These previous projects are summarized below:

#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://github.com/expertiza/expertiza/pull/1662/commits E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== '''Proposed Solution''' ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1124 E1791] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both. Tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.
*There are a few solutions one could implement to fix such an issue, such as marking both the start time and end time for when an external link or application was accessed by a user. Another solution which we will attempt in our first iteration of development is to track the time that an external link was clicked, and use the submission time of the review as our estimated end time for the external link. We thought of this design choice because once the report is submitted, the access time to external links should be stopped since the review is complete.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints about the use of a tabular method that was implemented in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791], stating that the review report table becomes too cluttered, we intend to create a pop-up window that will display the results in a table or graph of some sort. The proposed pop up will display all necessary information in a neat and simple self contained form. The exact display is undetermined, however proposed solutions include another tabular design, bar graphs, pie charts, etc.

== '''Code Changes''' ==
Our implementation builds off of the work done in E1791. This previous project has a substantial amount of the functionality already completed for tracking and viewing external pages and certain types of files. The primary error in this implementation is that when multiple files are open, the times at which they record reviews are overlapped creating inaccurate review reports. The displayed review report will also need to be edited to present review reports in a visually appealing manner. The following changes were made:

'''Files editted:''' 
# controllers/submission_viewing_events_controller.rb handles the start and end time of reviews. So, edits will need to be made to methods markEndTime() and endTime() to remove overlap issues.
# submission_viewing_events datatable to handle log start and end time for each link/file. Edits to algorithm for logging may present need to adjust structure of existing datatable.
# app/views/reports/_review_submissions_time_spent.html.erb will be edited to accurately log viewing times for multiple links open at the same time. This will include creating methods such as calculateTime to help with parsing review times of different links, and a function drawChart to display review times in a visually appealing manner.
# app/views/reports/_review_report.html.erb will be edited to reflect chart made in _review_submissions_time_spent.html.erb
# app/views/submission_viewing_events/new.html.haml Created new.html.haml for submission_viewing_events for assisting in setting up the views.
# app/views/submission_viewing_events/show.html.haml Created show.html.haml for submission_viewing_events for assisting in setting up the views.
# app/helpers/submitted_content_helper.rb Updated line 32 to incorporate file link for the return variable, ret.
# app/views/popup/view_review_scores_popup.html.erb Break up query in line 55 into two queries.
# app/views/reports/_review_submissions_time_spent.html.erb Created a view for reports controller.
# app/views/reports/_review_report.html.erb Made changes to _review_report to reflect changes in reports_controller

== '''User Stories''' ==
The following section outlines the predicted user interactions with our software. Two potential users have been identified; users and instructors.

====Student====
Students will be interacting with the implementation when filling out a review. A similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] is used, however small edits were made to better suite our proposed implementation. Initially, the user will click on the review they want to complete. Once the link is clicked the time will start to be logged. Upon the clicking of an external link another another timer will begin tracking it. This process repeats until the submission is saved/submitted or the page is exited out of. In the case where a review was previously saved the timer will pick up from the last tracked time. The diagram below displays the flow of interactions visually.
[[File:User_Story.png| center |Image: 50 pixels]]

====Instructor====
Instructors will be interacting with the implementation when the are observing student reviews. Once again, a similar story from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] will be used for the instructor with minor changes. Firstly, the instructor will navigate to a page that displays all current and previously reviews. They will then be able to select a review from the given list and look at statistics about resources accessed and time spent on each resource. Saved reviews and already submitted reviews will be tagged differently. The diagram below displays the flow of interactions visually.

[[File:Instructor_Story.png | center |Image: 50 pixels]]

== '''Database Schema''' ==
Our datatable is named '''submission_viewing_events'''. The attributes and their descriptions are provided in the below spreadsheet. For the table, we would use map_id in table response, which uses response_map_id as the primary information. Then we need to record reviewer_id and reviewee_id, source_link for submitted links or file names, as well as time start_at and end_at, then store them in the table.

[[File:Db_.PNG | center]]

 

Below shows the database relationship with other tables. '''submission_viewing_events''' will be touching '''response_maps'''. The boxes demonstrate which fields correspond to each other.

[[File:Db_schema1.png | center]]

== '''Testing Plan''' ==
===Rspec===
Automatic testing will be achieved using Rspec. The primary controller for testing will be controllers/submission_viewing_events_controller.rb, as edits will be made to mark_end_time and record_end_time methods to ensure that recorded review times for resources are not overlapping.

Proposed Rspec Tests:
* When a new review is started probe the Expertiza timer and ensure it returns the start value (0)
* When a saved review is started again probe the Expertiza timer and ensure it returns the time value stored in the database
* When an external link is clicked on a new review probe the timer link for that link and ensure it returns the start value (0)
* When an external link is clicked on a previously saved review probe the timer link for that link and ensure it returns and ensure it returns the time value stored in the database
* When a review is saved/submitted ensure that the time sent to the database matches time stored in database after execution
* When a review is clicked on by the instructor the data returned from date base should match test data.

===Manual Testing===
# Log in as instructor
# Assign a review to a student
# Log in as student
# Complete the dummy review in 5 minutes
# Log in as instructor
# Navigate to review report tab
# Verify that the review was completed ~5 minutes.

== '''References''' ==

=== Useful Links ===

[https://github.com/expertiza/expertiza Expertiza Repo] 
[https://github.com/rohanpillai20/expertiza E1791 Repo]

=== Our Implementation ===

[https://github.com/jamcdon3/expertiza/tree/E2015 Github Repo:] 
[https://github.com/rohanpillai20/expertiza/pull/51 Pull Request:]

=== Team Information ===
'''Mentor:''' 
Abhirav Kariya

'''Students:''' 
Hartley Leroy 
John McDonald 
Christian Morris 
Tyler Sattler

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-23T17:28:14Z

Tsattle: /* Team Information */

__TOC__
== '''Abstract''' ==
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

== '''Problem Statement''' ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. It is important that functionality be added so Expertiza can track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

The overall amount of time directly spent on the review is most important. One can track the amount of time spent on the review by tracking the amount of time from when the page is opened untill when the review is saved/submitted. Therefore, being able to track the time from once a resource is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

The following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and resources should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

== '''Previous Implementations''' ==
Thus far, Expertiza does not have the completed aforementioned feature. Previous attempts to implement this functionality have been made but the work was not merged into Expertiza code base for various reason. These previous projects are summarized below:

#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://github.com/expertiza/expertiza/pull/1662/commits E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== '''Proposed Solution''' ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1124 E1791] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both. Tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.
*There are a few solutions one could implement to fix such an issue, such as marking both the start time and end time for when an external link or application was accessed by a user. Another solution which we will attempt in our first iteration of development is to track the time that an external link was clicked, and use the submission time of the review as our estimated end time for the external link. We thought of this design choice because once the report is submitted, the access time to external links should be stopped since the review is complete.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints about the use of a tabular method that was implemented in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791], stating that the review report table becomes too cluttered, we intend to create a pop-up window that will display the results in a table or graph of some sort. The proposed pop up will display all necessary information in a neat and simple self contained form. The exact display is undetermined, however proposed solutions include another tabular design, bar graphs, pie charts, etc.

== '''Code Changes''' ==
Our implementation builds off of the work done in E1791. This previous project has a substantial amount of the functionality already completed for tracking and viewing external pages and certain types of files. The primary error in this implementation is that when multiple files are open, the times at which they record reviews are overlapped creating inaccurate review reports. The displayed review report will also need to be edited to present review reports in a visually appealing manner. The following changes were made:

'''Files editted:''' 
# controllers/submission_viewing_events_controller.rb handles the start and end time of reviews. So, edits will need to be made to methods markEndTime() and endTime() to remove overlap issues.
# submission_viewing_events datatable to handle log start and end time for each link/file. Edits to algorithm for logging may present need to adjust structure of existing datatable.
# app/views/reports/_review_submissions_time_spent.html.erb will be edited to accurately log viewing times for multiple links open at the same time. This will include creating methods such as calculateTime to help with parsing review times of different links, and a function drawChart to display review times in a visually appealing manner.
# app/views/reports/_review_report.html.erb will be edited to reflect chart made in _review_submissions_time_spent.html.erb
# app/views/submission_viewing_events/new.html.haml Created new.html.haml for submission_viewing_events for assisting in setting up the views.
# app/views/submission_viewing_events/show.html.haml Created show.html.haml for submission_viewing_events for assisting in setting up the views.
# app/helpers/submitted_content_helper.rb Updated line 32 to incorporate file link for the return variable, ret.
# app/views/popup/view_review_scores_popup.html.erb Break up query in line 55 into two queries.
# app/views/reports/_review_submissions_time_spent.html.erb Created a view for reports controller.
# app/views/reports/_review_report.html.erb Made changes to _review_report to reflect changes in reports_controller

== '''User Stories''' ==
The following section outlines the predicted user interactions with our software. Two potential users have been identified; users and instructors.

====Student====
Students will be interacting with the implementation when filling out a review. A similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] is used, however small edits were made to better suite our proposed implementation. Initially, the user will click on the review they want to complete. Once the link is clicked the time will start to be logged. Upon the clicking of an external link another another timer will begin tracking it. This process repeats until the submission is saved/submitted or the page is exited out of. In the case where a review was previously saved the timer will pick up from the last tracked time. The diagram below displays the flow of interactions visually.
[[File:User_Story.png| center |Image: 50 pixels]]

====Instructor====
Instructors will be interacting with the implementation when the are observing student reviews. Once again, a similar story from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] will be used for the instructor with minor changes. Firstly, the instructor will navigate to a page that displays all current and previously reviews. They will then be able to select a review from the given list and look at statistics about resources accessed and time spent on each resource. Saved reviews and already submitted reviews will be tagged differently. The diagram below displays the flow of interactions visually.

[[File:Instructor_Story.png | center |Image: 50 pixels]]

== '''Database Schema''' ==
Our datatable is named '''submission_viewing_events'''. The attributes and their descriptions are provided in the below spreadsheet. For the table, we would use map_id in table response, which uses response_map_id as the primary information. Then we need to record reviewer_id and reviewee_id, source_link for submitted links or file names, as well as time start_at and end_at, then store them in the table.

[[File:Db_.PNG | center]]

 

Below shows the database relationship with other tables. '''submission_viewing_events''' will be touching '''response_maps'''. The boxes demonstrate which fields correspond to each other.

[[File:Db_schema1.png | center]]

== '''Testing Plan''' ==
===Rspec===
Automatic testing will be achieved using Rspec. The primary controller for testing will be controllers/submission_viewing_events_controller.rb, as edits will be made to mark_end_time and record_end_time methods to ensure that recorded review times for resources are not overlapping.

Proposed Rspec Tests:
* When a new review is started probe the Expertiza timer and ensure it returns the start value (0)
* When a saved review is started again probe the Expertiza timer and ensure it returns the time value stored in the database
* When an external link is clicked on a new review probe the timer link for that link and ensure it returns the start value (0)
* When an external link is clicked on a previously saved review probe the timer link for that link and ensure it returns and ensure it returns the time value stored in the database
* When a review is saved/submitted ensure that the time sent to the database matches time stored in database after execution
* When a review is clicked on by the instructor the data returned from date base should match test data.

===Manual Testing===
# Log in as instructor
# Assign a review to a student
# Log in as student
# Complete the dummy review in 5 minutes
# Log in as instructor
# Navigate to review report tab
# Verify that the review was completed ~5 minutes.

== '''References''' ==

=== Useful Links ===

[https://github.com/expertiza/expertiza Expertiza Repo] 
[https://github.com/rohanpillai20/expertiza E1791 Repo]

=== Our Implementation ===

[https://github.com/jamcdon3/expertiza/tree/E2015 Github Repo:] 
[https://github.com/rohanpillai20/expertiza/pull/51 Pull Request:]

=== Team Information ===
'''Mentor:''' 
Abhirav Kariya

'''Students:''' 
Hartley Lero 
John McDonal 
Christian Morri 
Tyler Sattler

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-23T17:27:08Z

Tsattle: /* Code Changes */

__TOC__
== '''Abstract''' ==
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

== '''Problem Statement''' ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. It is important that functionality be added so Expertiza can track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

The overall amount of time directly spent on the review is most important. One can track the amount of time spent on the review by tracking the amount of time from when the page is opened untill when the review is saved/submitted. Therefore, being able to track the time from once a resource is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

The following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and resources should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

== '''Previous Implementations''' ==
Thus far, Expertiza does not have the completed aforementioned feature. Previous attempts to implement this functionality have been made but the work was not merged into Expertiza code base for various reason. These previous projects are summarized below:

#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://github.com/expertiza/expertiza/pull/1662/commits E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== '''Proposed Solution''' ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1124 E1791] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both. Tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.
*There are a few solutions one could implement to fix such an issue, such as marking both the start time and end time for when an external link or application was accessed by a user. Another solution which we will attempt in our first iteration of development is to track the time that an external link was clicked, and use the submission time of the review as our estimated end time for the external link. We thought of this design choice because once the report is submitted, the access time to external links should be stopped since the review is complete.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints about the use of a tabular method that was implemented in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791], stating that the review report table becomes too cluttered, we intend to create a pop-up window that will display the results in a table or graph of some sort. The proposed pop up will display all necessary information in a neat and simple self contained form. The exact display is undetermined, however proposed solutions include another tabular design, bar graphs, pie charts, etc.

== '''Code Changes''' ==
Our implementation builds off of the work done in E1791. This previous project has a substantial amount of the functionality already completed for tracking and viewing external pages and certain types of files. The primary error in this implementation is that when multiple files are open, the times at which they record reviews are overlapped creating inaccurate review reports. The displayed review report will also need to be edited to present review reports in a visually appealing manner. The following changes were made:

'''Files editted:''' 
# controllers/submission_viewing_events_controller.rb handles the start and end time of reviews. So, edits will need to be made to methods markEndTime() and endTime() to remove overlap issues.
# submission_viewing_events datatable to handle log start and end time for each link/file. Edits to algorithm for logging may present need to adjust structure of existing datatable.
# app/views/reports/_review_submissions_time_spent.html.erb will be edited to accurately log viewing times for multiple links open at the same time. This will include creating methods such as calculateTime to help with parsing review times of different links, and a function drawChart to display review times in a visually appealing manner.
# app/views/reports/_review_report.html.erb will be edited to reflect chart made in _review_submissions_time_spent.html.erb
# app/views/submission_viewing_events/new.html.haml Created new.html.haml for submission_viewing_events for assisting in setting up the views.
# app/views/submission_viewing_events/show.html.haml Created show.html.haml for submission_viewing_events for assisting in setting up the views.
# app/helpers/submitted_content_helper.rb Updated line 32 to incorporate file link for the return variable, ret.
# app/views/popup/view_review_scores_popup.html.erb Break up query in line 55 into two queries.
# app/views/reports/_review_submissions_time_spent.html.erb Created a view for reports controller.
# app/views/reports/_review_report.html.erb Made changes to _review_report to reflect changes in reports_controller

== '''User Stories''' ==
The following section outlines the predicted user interactions with our software. Two potential users have been identified; users and instructors.

====Student====
Students will be interacting with the implementation when filling out a review. A similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] is used, however small edits were made to better suite our proposed implementation. Initially, the user will click on the review they want to complete. Once the link is clicked the time will start to be logged. Upon the clicking of an external link another another timer will begin tracking it. This process repeats until the submission is saved/submitted or the page is exited out of. In the case where a review was previously saved the timer will pick up from the last tracked time. The diagram below displays the flow of interactions visually.
[[File:User_Story.png| center |Image: 50 pixels]]

====Instructor====
Instructors will be interacting with the implementation when the are observing student reviews. Once again, a similar story from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] will be used for the instructor with minor changes. Firstly, the instructor will navigate to a page that displays all current and previously reviews. They will then be able to select a review from the given list and look at statistics about resources accessed and time spent on each resource. Saved reviews and already submitted reviews will be tagged differently. The diagram below displays the flow of interactions visually.

[[File:Instructor_Story.png | center |Image: 50 pixels]]

== '''Database Schema''' ==
Our datatable is named '''submission_viewing_events'''. The attributes and their descriptions are provided in the below spreadsheet. For the table, we would use map_id in table response, which uses response_map_id as the primary information. Then we need to record reviewer_id and reviewee_id, source_link for submitted links or file names, as well as time start_at and end_at, then store them in the table.

[[File:Db_.PNG | center]]

 

Below shows the database relationship with other tables. '''submission_viewing_events''' will be touching '''response_maps'''. The boxes demonstrate which fields correspond to each other.

[[File:Db_schema1.png | center]]

== '''Testing Plan''' ==
===Rspec===
Automatic testing will be achieved using Rspec. The primary controller for testing will be controllers/submission_viewing_events_controller.rb, as edits will be made to mark_end_time and record_end_time methods to ensure that recorded review times for resources are not overlapping.

Proposed Rspec Tests:
* When a new review is started probe the Expertiza timer and ensure it returns the start value (0)
* When a saved review is started again probe the Expertiza timer and ensure it returns the time value stored in the database
* When an external link is clicked on a new review probe the timer link for that link and ensure it returns the start value (0)
* When an external link is clicked on a previously saved review probe the timer link for that link and ensure it returns and ensure it returns the time value stored in the database
* When a review is saved/submitted ensure that the time sent to the database matches time stored in database after execution
* When a review is clicked on by the instructor the data returned from date base should match test data.

===Manual Testing===
# Log in as instructor
# Assign a review to a student
# Log in as student
# Complete the dummy review in 5 minutes
# Log in as instructor
# Navigate to review report tab
# Verify that the review was completed ~5 minutes.

== '''References''' ==

=== Useful Links ===

[https://github.com/expertiza/expertiza Expertiza Repo] 
[https://github.com/rohanpillai20/expertiza E1791 Repo]

=== Our Implementation ===

[https://github.com/jamcdon3/expertiza/tree/E2015 Github Repo:] 
[https://github.com/rohanpillai20/expertiza/pull/51 Pull Request:]

=== Team Information ===
'''Mentor:''' 
Abhirav Kariya

'''Students:''' 
Hartley Leroy 
John McDonald 
Christian Morris 
Tyler Sattle

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-23T17:26:25Z

Tsattle: /* Code Changes */

__TOC__
== '''Abstract''' ==
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

== '''Problem Statement''' ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. It is important that functionality be added so Expertiza can track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

The overall amount of time directly spent on the review is most important. One can track the amount of time spent on the review by tracking the amount of time from when the page is opened untill when the review is saved/submitted. Therefore, being able to track the time from once a resource is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

The following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and resources should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

== '''Previous Implementations''' ==
Thus far, Expertiza does not have the completed aforementioned feature. Previous attempts to implement this functionality have been made but the work was not merged into Expertiza code base for various reason. These previous projects are summarized below:

#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://github.com/expertiza/expertiza/pull/1662/commits E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== '''Proposed Solution''' ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1124 E1791] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both. Tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.
*There are a few solutions one could implement to fix such an issue, such as marking both the start time and end time for when an external link or application was accessed by a user. Another solution which we will attempt in our first iteration of development is to track the time that an external link was clicked, and use the submission time of the review as our estimated end time for the external link. We thought of this design choice because once the report is submitted, the access time to external links should be stopped since the review is complete.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints about the use of a tabular method that was implemented in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791], stating that the review report table becomes too cluttered, we intend to create a pop-up window that will display the results in a table or graph of some sort. The proposed pop up will display all necessary information in a neat and simple self contained form. The exact display is undetermined, however proposed solutions include another tabular design, bar graphs, pie charts, etc.

== '''Code Changes''' ==
Our implementation builds off of the work done in E1791. This previous project has a substantial amount of the functionality already completed for tracking and viewing external pages and certain types of files. The primary error in this implementation is that when multiple files are open, the times at which they record reviews are overlapped creating inaccurate review reports. The displayed review report will also need to be edited to present review reports in a visually appealing manner. The following changes are expected to be made:

'''Files editted:''' 
# controllers/submission_viewing_events_controller.rb handles the start and end time of reviews. So, edits will need to be made to methods markEndTime() and endTime() to remove overlap issues.
# submission_viewing_events datatable to handle log start and end time for each link/file. Edits to algorithm for logging may present need to adjust structure of existing datatable.
# app/views/reports/_review_submissions_time_spent.html.erb will be edited to accurately log viewing times for multiple links open at the same time. This will include creating methods such as calculateTime to help with parsing review times of different links, and a function drawChart to display review times in a visually appealing manner.
# app/views/reports/_review_report.html.erb will be edited to reflect chart made in _review_submissions_time_spent.html.erb
# app/views/submission_viewing_events/new.html.haml Created new.html.haml for submission_viewing_events for assisting in setting up the views.
# app/views/submission_viewing_events/show.html.haml Created show.html.haml for submission_viewing_events for assisting in setting up the views.
# app/helpers/submitted_content_helper.rb Updated line 32 to incorporate file link for the return variable, ret.
# app/views/popup/view_review_scores_popup.html.erb Break up query in line 55 into two queries.
# app/views/reports/_review_submissions_time_spent.html.erb Created a view for reports controller.
# app/views/reports/_review_report.html.erb Made changes to _review_report to reflect changes in reports_controller

== '''User Stories''' ==
The following section outlines the predicted user interactions with our software. Two potential users have been identified; users and instructors.

====Student====
Students will be interacting with the implementation when filling out a review. A similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] is used, however small edits were made to better suite our proposed implementation. Initially, the user will click on the review they want to complete. Once the link is clicked the time will start to be logged. Upon the clicking of an external link another another timer will begin tracking it. This process repeats until the submission is saved/submitted or the page is exited out of. In the case where a review was previously saved the timer will pick up from the last tracked time. The diagram below displays the flow of interactions visually.
[[File:User_Story.png| center |Image: 50 pixels]]

====Instructor====
Instructors will be interacting with the implementation when the are observing student reviews. Once again, a similar story from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] will be used for the instructor with minor changes. Firstly, the instructor will navigate to a page that displays all current and previously reviews. They will then be able to select a review from the given list and look at statistics about resources accessed and time spent on each resource. Saved reviews and already submitted reviews will be tagged differently. The diagram below displays the flow of interactions visually.

[[File:Instructor_Story.png | center |Image: 50 pixels]]

== '''Database Schema''' ==
Our datatable is named '''submission_viewing_events'''. The attributes and their descriptions are provided in the below spreadsheet. For the table, we would use map_id in table response, which uses response_map_id as the primary information. Then we need to record reviewer_id and reviewee_id, source_link for submitted links or file names, as well as time start_at and end_at, then store them in the table.

[[File:Db_.PNG | center]]

 

Below shows the database relationship with other tables. '''submission_viewing_events''' will be touching '''response_maps'''. The boxes demonstrate which fields correspond to each other.

[[File:Db_schema1.png | center]]

== '''Testing Plan''' ==
===Rspec===
Automatic testing will be achieved using Rspec. The primary controller for testing will be controllers/submission_viewing_events_controller.rb, as edits will be made to mark_end_time and record_end_time methods to ensure that recorded review times for resources are not overlapping.

Proposed Rspec Tests:
* When a new review is started probe the Expertiza timer and ensure it returns the start value (0)
* When a saved review is started again probe the Expertiza timer and ensure it returns the time value stored in the database
* When an external link is clicked on a new review probe the timer link for that link and ensure it returns the start value (0)
* When an external link is clicked on a previously saved review probe the timer link for that link and ensure it returns and ensure it returns the time value stored in the database
* When a review is saved/submitted ensure that the time sent to the database matches time stored in database after execution
* When a review is clicked on by the instructor the data returned from date base should match test data.

===Manual Testing===
# Log in as instructor
# Assign a review to a student
# Log in as student
# Complete the dummy review in 5 minutes
# Log in as instructor
# Navigate to review report tab
# Verify that the review was completed ~5 minutes.

== '''References''' ==

=== Useful Links ===

[https://github.com/expertiza/expertiza Expertiza Repo] 
[https://github.com/rohanpillai20/expertiza E1791 Repo]

=== Our Implementation ===

[https://github.com/jamcdon3/expertiza/tree/E2015 Github Repo:] 
[https://github.com/rohanpillai20/expertiza/pull/51 Pull Request:]

=== Team Information ===
'''Mentor:''' 
Abhirav Kariya

'''Students:''' 
Hartley Leroy 
John McDonald 
Christian Morris 
Tyler Sattle

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-23T17:26:07Z

Tsattle: /* Code Changes */

__TOC__
== '''Abstract''' ==
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

== '''Problem Statement''' ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. It is important that functionality be added so Expertiza can track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

The overall amount of time directly spent on the review is most important. One can track the amount of time spent on the review by tracking the amount of time from when the page is opened untill when the review is saved/submitted. Therefore, being able to track the time from once a resource is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

The following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and resources should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

== '''Previous Implementations''' ==
Thus far, Expertiza does not have the completed aforementioned feature. Previous attempts to implement this functionality have been made but the work was not merged into Expertiza code base for various reason. These previous projects are summarized below:

#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://github.com/expertiza/expertiza/pull/1662/commits E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== '''Proposed Solution''' ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1124 E1791] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both. Tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.
*There are a few solutions one could implement to fix such an issue, such as marking both the start time and end time for when an external link or application was accessed by a user. Another solution which we will attempt in our first iteration of development is to track the time that an external link was clicked, and use the submission time of the review as our estimated end time for the external link. We thought of this design choice because once the report is submitted, the access time to external links should be stopped since the review is complete.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints about the use of a tabular method that was implemented in [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791], stating that the review report table becomes too cluttered, we intend to create a pop-up window that will display the results in a table or graph of some sort. The proposed pop up will display all necessary information in a neat and simple self contained form. The exact display is undetermined, however proposed solutions include another tabular design, bar graphs, pie charts, etc.

== '''Code Changes''' ==
Our implementation builds off of the work done in E1791. This previous project has a substantial amount of the functionality already completed for tracking and viewing external pages and certain types of files. The primary error in this implementation is that when multiple files are open, the times at which they record reviews are overlapped creating inaccurate review reports. The displayed review report will also need to be edited to present review reports in a visually appealing manner. The following changes are expected to be made:

'''Files to be editted:''' 
# controllers/submission_viewing_events_controller.rb handles the start and end time of reviews. So, edits will need to be made to methods markEndTime() and endTime() to remove overlap issues.
# submission_viewing_events datatable to handle log start and end time for each link/file. Edits to algorithm for logging may present need to adjust structure of existing datatable.
# app/views/reports/_review_submissions_time_spent.html.erb will be edited to accurately log viewing times for multiple links open at the same time. This will include creating methods such as calculateTime to help with parsing review times of different links, and a function drawChart to display review times in a visually appealing manner.
# app/views/reports/_review_report.html.erb will be edited to reflect chart made in _review_submissions_time_spent.html.erb
# app/views/submission_viewing_events/new.html.haml Created new.html.haml for submission_viewing_events for assisting in setting up the views.
# app/views/submission_viewing_events/show.html.haml Created show.html.haml for submission_viewing_events for assisting in setting up the views.
# app/helpers/submitted_content_helper.rb Updated line 32 to incorporate file link for the return variable, ret.
# app/views/popup/view_review_scores_popup.html.erb Break up query in line 55 into two queries.
# app/views/reports/_review_submissions_time_spent.html.erb Created a view for reports controller.
# app/views/reports/_review_report.html.erb Made changes to _review_report to reflect changes in reports_controller

== '''User Stories''' ==
The following section outlines the predicted user interactions with our software. Two potential users have been identified; users and instructors.

====Student====
Students will be interacting with the implementation when filling out a review. A similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] is used, however small edits were made to better suite our proposed implementation. Initially, the user will click on the review they want to complete. Once the link is clicked the time will start to be logged. Upon the clicking of an external link another another timer will begin tracking it. This process repeats until the submission is saved/submitted or the page is exited out of. In the case where a review was previously saved the timer will pick up from the last tracked time. The diagram below displays the flow of interactions visually.
[[File:User_Story.png| center |Image: 50 pixels]]

====Instructor====
Instructors will be interacting with the implementation when the are observing student reviews. Once again, a similar story from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] will be used for the instructor with minor changes. Firstly, the instructor will navigate to a page that displays all current and previously reviews. They will then be able to select a review from the given list and look at statistics about resources accessed and time spent on each resource. Saved reviews and already submitted reviews will be tagged differently. The diagram below displays the flow of interactions visually.

[[File:Instructor_Story.png | center |Image: 50 pixels]]

== '''Database Schema''' ==
Our datatable is named '''submission_viewing_events'''. The attributes and their descriptions are provided in the below spreadsheet. For the table, we would use map_id in table response, which uses response_map_id as the primary information. Then we need to record reviewer_id and reviewee_id, source_link for submitted links or file names, as well as time start_at and end_at, then store them in the table.

[[File:Db_.PNG | center]]

 

Below shows the database relationship with other tables. '''submission_viewing_events''' will be touching '''response_maps'''. The boxes demonstrate which fields correspond to each other.

[[File:Db_schema1.png | center]]

== '''Testing Plan''' ==
===Rspec===
Automatic testing will be achieved using Rspec. The primary controller for testing will be controllers/submission_viewing_events_controller.rb, as edits will be made to mark_end_time and record_end_time methods to ensure that recorded review times for resources are not overlapping.

Proposed Rspec Tests:
* When a new review is started probe the Expertiza timer and ensure it returns the start value (0)
* When a saved review is started again probe the Expertiza timer and ensure it returns the time value stored in the database
* When an external link is clicked on a new review probe the timer link for that link and ensure it returns the start value (0)
* When an external link is clicked on a previously saved review probe the timer link for that link and ensure it returns and ensure it returns the time value stored in the database
* When a review is saved/submitted ensure that the time sent to the database matches time stored in database after execution
* When a review is clicked on by the instructor the data returned from date base should match test data.

===Manual Testing===
# Log in as instructor
# Assign a review to a student
# Log in as student
# Complete the dummy review in 5 minutes
# Log in as instructor
# Navigate to review report tab
# Verify that the review was completed ~5 minutes.

== '''References''' ==

=== Useful Links ===

[https://github.com/expertiza/expertiza Expertiza Repo] 
[https://github.com/rohanpillai20/expertiza E1791 Repo]

=== Our Implementation ===

[https://github.com/jamcdon3/expertiza/tree/E2015 Github Repo:] 
[https://github.com/rohanpillai20/expertiza/pull/51 Pull Request:]

=== Team Information ===
'''Mentor:''' 
Abhirav Kariya

'''Students:''' 
Hartley Leroy 
John McDonald 
Christian Morris 
Tyler Sattle

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-14T00:23:18Z

Tsattle: /* Design pattern */

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-13T19:21:29Z

Tsattle: /* Database Schema */

__TOC__
== Problem Statement ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. It is important that functionality be added so Expertiza can track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

The overall amount of time directly spent on the review itself is most important. One can track the amount of time spent on the review itself quite easily by simply tracking the amount of time from when the page is opened untill when the review is saved/submitted. Therefore, being able to track the time from once a link is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

The following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and documents should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

=== Current Implementation ===
Thus far, Expertiza does not have the aforementioned feature. Previous attempts to implement this functionality have been made but the work was not merged into Expertiza code base for various reason. These previous projects are summarized below:

#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1989._Track_the_time_students_look_at_other_submissions E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== Proposed Solution ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1124 E1791] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both. Tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints on a tabular method, citing the review report table becoming too cluttered, we intend to create a pop-up window that will display the results in a table. Unlike the approach taken in project [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 from the fall of 2019], this project will work to display all information using the aforementioned tabular design in a pop-up window. With this approach, the table provides the information and estimates regarding all of the external links accessed throughout this review in a simple and uncluttered fashion.

=== Design pattern ===
'''Strategy:''' This project, for each review page, deals with different type of links. Javascript is used to track the access time for online links, such as github repo, youtube links, and more. For submitted files, such as txt, jpg, we will time it with views/response/_submitted_files.html.erb.

User 
A similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] is used, however small edits were made to the diagram to better suite our proposed implementation.
[[File:User_Story.png | center |Image: 100 pixels]]
Instructor 
Once again, a similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] will be used for an instructor to access the tabularized information regarding access times:
[[File:Instructor_Story.png | center |Image: 100 pixels]]

=== Files to be Added and Editted ===

# Create a controller to handle the start/end times of the files viewed by the user in => controllers/submission_viewing_events_controller.rb
# Create a datatable to handle log start and end time for each link/file. Schema for this table is provided in the below section.
# Edit and add views to display results in a user-friendly manner. Edits to views should be defined in both the wiki and through modular commits on the repository in order to clearly distinguish code changes, an issue that prevented [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1989._Track_the_time_students_look_at_other_submissions E1989] from pushing to base.

=== Database Schema ===

Our datatable will be named '''submission_viewing_events'''. The attributes and their descriptions are provided in the below spreadsheet. There is some uncertainty in how the time will be tracked separately for viewing downloadable files vs viewing the Expertiza assignment review page. Final form of the data table with this tracking feature will be elaborate on in future submissions.

[[File:Db_.PNG | center]]

 

Below shows the database relationship with other tables. '''submission_viewing_events''' will be touching '''response_maps'''. The boxes demonstrate which fields correspond to each other.

[[File:Db_schema1.png | center]]

== Testing Plan ==
===Rspec===
Automatic testing will be achieved using Rspec. We will test the changes made to controllers/submission_viewing_events_controller.rb to ensure proper test converge. Test cases are to be written in a meaningful and elegant manner, adhering to the following rules:

* Test incoming query messages by making assertions for what they send back
* Test incoming command messages by making assertions about direct public side effects
* Do not test private methods
* Do not test outgoing query messages
* Expect to send outgoing command messages

===Manual Testing===
1. Log in as instructor

2. Assign a review to a student

3. Log in as student

4. Complete the dummy review in 5 minutes

5. Log in as instructor

6. Navigate to review report tab

7. Verify that the review was completed ~5 minutes.

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-13T19:20:59Z

Tsattle: /* Database Schema */

__TOC__
== Problem Statement ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. It is important that functionality be added so Expertiza can track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

The overall amount of time directly spent on the review itself is most important. One can track the amount of time spent on the review itself quite easily by simply tracking the amount of time from when the page is opened untill when the review is saved/submitted. Therefore, being able to track the time from once a link is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

The following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and documents should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

=== Current Implementation ===
Thus far, Expertiza does not have the aforementioned feature. Previous attempts to implement this functionality have been made but the work was not merged into Expertiza code base for various reason. These previous projects are summarized below:

#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1989._Track_the_time_students_look_at_other_submissions E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== Proposed Solution ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1124 E1791] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both. Tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints on a tabular method, citing the review report table becoming too cluttered, we intend to create a pop-up window that will display the results in a table. Unlike the approach taken in project [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 from the fall of 2019], this project will work to display all information using the aforementioned tabular design in a pop-up window. With this approach, the table provides the information and estimates regarding all of the external links accessed throughout this review in a simple and uncluttered fashion.

=== Design pattern ===
'''Strategy:''' This project, for each review page, deals with different type of links. Javascript is used to track the access time for online links, such as github repo, youtube links, and more. For submitted files, such as txt, jpg, we will time it with views/response/_submitted_files.html.erb.

User 
A similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] is used, however small edits were made to the diagram to better suite our proposed implementation.
[[File:User_Story.png | center |Image: 100 pixels]]
Instructor 
Once again, a similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] will be used for an instructor to access the tabularized information regarding access times:
[[File:Instructor_Story.png | center |Image: 100 pixels]]

=== Files to be Added and Editted ===

# Create a controller to handle the start/end times of the files viewed by the user in => controllers/submission_viewing_events_controller.rb
# Create a datatable to handle log start and end time for each link/file. Schema for this table is provided in the below section.
# Edit and add views to display results in a user-friendly manner. Edits to views should be defined in both the wiki and through modular commits on the repository in order to clearly distinguish code changes, an issue that prevented [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1989._Track_the_time_students_look_at_other_submissions E1989] from pushing to base.

=== Database Schema ===

Our datatable will be named '''submission_viewing_events'''. The attributes and their descriptions are provided in the below spreadsheet. There is some uncertainty in how the time will be tracked separately for viewing downloadable files vs viewing the Expertiza assignment review page. Final form of the data table with this tracking feature will be elaborate on in future submissions.

[[File:Db_.PNG | center]]

 

Below shows the database relationship with other tables. '''submission_viewing_events''' will be touching '''response_maps'''. The boxes demonstrate which fields correspond to each other.

[[File:Db_schema1.PNG | center]]

== Testing Plan ==
===Rspec===
Automatic testing will be achieved using Rspec. We will test the changes made to controllers/submission_viewing_events_controller.rb to ensure proper test converge. Test cases are to be written in a meaningful and elegant manner, adhering to the following rules:

* Test incoming query messages by making assertions for what they send back
* Test incoming command messages by making assertions about direct public side effects
* Do not test private methods
* Do not test outgoing query messages
* Expect to send outgoing command messages

===Manual Testing===
1. Log in as instructor

2. Assign a review to a student

3. Log in as student

4. Complete the dummy review in 5 minutes

5. Log in as instructor

6. Navigate to review report tab

7. Verify that the review was completed ~5 minutes.

File:Db schema1.png

2020-04-13T19:18:34Z

Tsattle:

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-13T19:18:10Z

Tsattle: /* Database Schema */

__TOC__
== Problem Statement ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. It is important that functionality be added so Expertiza can track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

The overall amount of time directly spent on the review itself is most important. One can track the amount of time spent on the review itself quite easily by simply tracking the amount of time from when the page is opened untill when the review is saved/submitted. Therefore, being able to track the time from once a link is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

The following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and documents should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

=== Current Implementation ===
Thus far, Expertiza does not have the aforementioned feature. Previous attempts to implement this functionality have been made but the work was not merged into Expertiza code base for various reason. These previous projects are summarized below:

#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1989._Track_the_time_students_look_at_other_submissions E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== Proposed Solution ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1124 E1791] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both. Tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints on a tabular method, citing the review report table becoming too cluttered, we intend to create a pop-up window that will display the results in a table. Unlike the approach taken in project [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 from the fall of 2019], this project will work to display all information using the aforementioned tabular design in a pop-up window. With this approach, the table provides the information and estimates regarding all of the external links accessed throughout this review in a simple and uncluttered fashion.

=== Design pattern ===
'''Strategy:''' This project, for each review page, deals with different type of links. Javascript is used to track the access time for online links, such as github repo, youtube links, and more. For submitted files, such as txt, jpg, we will time it with views/response/_submitted_files.html.erb.

User 
A similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] is used, however small edits were made to the diagram to better suite our proposed implementation.
[[File:User_Story.png | center |Image: 100 pixels]]
Instructor 
Once again, a similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] will be used for an instructor to access the tabularized information regarding access times:
[[File:Instructor_Story.png | center |Image: 100 pixels]]

=== Files to be Added and Editted ===

# Create a controller to handle the start/end times of the files viewed by the user in => controllers/submission_viewing_events_controller.rb
# Create a datatable to handle log start and end time for each link/file. Schema for this table is provided in the below section.
# Edit and add views to display results in a user-friendly manner. Edits to views should be defined in both the wiki and through modular commits on the repository in order to clearly distinguish code changes, an issue that prevented [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1989._Track_the_time_students_look_at_other_submissions E1989] from pushing to base.

=== Database Schema ===

Our datatable will be named '''submission_viewing_events'''. The attributes and their descriptions are provided in the below spreadsheet. There is some uncertainty in how the time will be tracked separately for viewing downloadable files vs viewing the Expertiza assignment review page. Final form of the data table with this tracking feature will be elaborate on in future submissions.

[[File:Db_.PNG | center]]

 

== Testing Plan ==
===Rspec===
Automatic testing will be achieved using Rspec. We will test the changes made to controllers/submission_viewing_events_controller.rb to ensure proper test converge. Test cases are to be written in a meaningful and elegant manner, adhering to the following rules:

* Test incoming query messages by making assertions for what they send back
* Test incoming command messages by making assertions about direct public side effects
* Do not test private methods
* Do not test outgoing query messages
* Expect to send outgoing command messages

===Manual Testing===
1. Log in as instructor

2. Assign a review to a student

3. Log in as student

4. Complete the dummy review in 5 minutes

5. Log in as instructor

6. Navigate to review report tab

7. Verify that the review was completed ~5 minutes.

File:Db .PNG

2020-04-13T19:17:30Z

Tsattle:

CSC/ECE 517 Fall 2017/E1791. Track the time that students look at the other submissions - logging improvement

2020-04-13T19:15:59Z

Tsattle: /* Database shcema design */

== Introduction ==

The expertiza project takes advantage of peer-review among students to allow them to learn from each other. To track the review time that each student spend on each submitted resources is meaningful to instructors to study and improve the teach experience. However, the time tracking of specific content on these resources is not perfect in the expertiza system. The previous team working on E1705 project has solved part of such problems by tracking the active time of windows opened from the submitted links. But for the submitted files which could be downloaded for local review, there is only a rough approximation solution yet. In this project, our team is going to solve this problem as well as improving previous time tracking methods using mature third-party APIs to record link review time more accurately. To accomplish this goal, here are the general solutions we designed and implemented in this project:

*Designed a database schema for logging the time a reviewer spend on a submission;
*Designed and implemented dynamic partial components using Javascript and Ruby to open students’ submissions in new windows to view online;
*Used DOM to control the windows holding review submission files or links, and record the open and close time;
*Modify Review report (views/review_mapping/_review_report.html.erb) to show the total and detailed time spent on each review submissions with visualization.

== Problem Description and Solution ==
Our team is going to solve the submission review time tracking by attempting to open the downloaded files inside popup windows of the web browser in order to record the time on the client side.

=== Type of submitted files ===
For most of our tasks, there are two types of submitted files.

1. One kind is online links, such as github repo or pull request link, youtube video link, expertiza wiki page link, etc

2. The other one includes files such as pdf, txt, doc, images, etc and other download contents. (instructor can include more document types in /views/submitted_content/_submitted_files.html.erb)

=== Design pattern ===
'''Strategy''' In this project, for each review page, we need to deal with different type of links. For online links, such as github repo, youtube link, etc, we use javascript to open a new window detect time when the window is closed. For submitted files, such as txt, jpg, we will open it with views/response/_submitted_files.html.erb. For other files that need to be download and open locally, we can only make approximation for review time.

=== Database schema design ===
For this project, we need to design a database table to store all the time that we need to record for each review submission event. We would like to name the table as '''submission_viewing_events'''. For the table, we would use '''map_id''' in table response, which uses '''response_map_id''' as the primary information. Then we need to record '''reviewer_id''' and '''reviewee_id''', '''source_link''' for submitted links or file names, as well as time '''start_at''' and '''end_at''', then store them in the table.

[[File:E1791db.jpg | center]]

=== Time tracking mechanism ===

For each review, when the reviewer click on one link of the submitted files, we create an entry to the table review_time, we will write a function to record current time to the database.

For how to determine time when the reviewer complete with the opened link, there are different cases. If the reviewer click on save or submit button, close the page, or logout, we need to write to all open entry (without end_at) respect to this review and save current time to end_at. But for how to decide when the review close the opened link is a little complicated. For github and youtube links and txt, pdf, doc, image files, we will open submitted files in views/response/_submitted_files.html.erb so that when the user click on the link, it opens a popup window that shows the submission, record time when it opens and closes. This is done by controlling DOM using jQuery javascript library, and then send back the time records through Ajax. For the other files that need to be downloaded, we can only make an approximation by record the time when the reviewer click on the link until the time he/she enter the reviews.

For each task, reviewer might open each link several times, might also save the review process and restart it some times later, so we will have multiple records for each link. Every time the student click on the link, a new record is created and then the time in all records will be summed up to total time for every link and displayed on instructor page.

[[File:E1791_flowchart.png | center]]

=== View modification ===
After we record start_at and end_at time for each piece of review, we need to display time that each reviewer spent on each link. Because the reviewer may save the review and start again in the future, so for each link there might be several entries, we need to sum them together. We modifed code in review_mapping/_review_report.html.erb first to modify the view. This framework follows well the "open to extension and close to modification" principle, which makes further changes more feasible by adding additional view components without affecting current functions.
[[File:review_piechart.png | center]]

=== Edge cases ===
1. When user click on save or submit the review without closing opened windows, the system will search all records of response time for the reviewer and reviewee where end time is NULL, and update it with current time.

2. If the reviewer opens the reference links or download files, but leave them open and turn to focus other unrelated stuff, the review page will send a popup alert dialog to confirm if the review is still in review mode. If not, it will close these windows and save the time as approximation of end time. Otherwise, it will continue the review process.
[[File:E1791popup alert.jpg | center]]

3. In some cases, reviewer might shut down the computer, close the browser, log out without saving, etc., we set up periodically saving reviewing events automatically such that we will lose as less information as possible. Currently the period is 30 seconds and this can be changed. For the cases described, shut down computer etc., there will be records written in data base with end time NULL, next time when the reviewer restart the review, the system will just drop all the records with NULL end time and start a new query. Also if reviewer does not interact with the review page for a long time, it will pause the timer and commit all existing related time record in database. The time limit is now 2 minutes. Both the period and non-interaction time can be adjusted by instructors in code file /views/response/response.html.erb

== Test Plan ==
=== UI and Manual test ===
We will test the following cases during our development

1. When we work the review, if we click on GitHub link, GitHub pull request link, check whether the system record review time correctly.

2. When we work the review, if we click on doc, pdf, image link, check whether system open submitted files in views/response/_submitted_files.html.erb and recore the review time correctly.

3. Check if the reviewer save the process and start again with click on same clink, check whether the system will record all the entry, and on the view page take all entries for one link into account.

=== Rspec Test ===
Test of new model and function will be written and tested during project development:
* Test the success of a review time record given valid start and end time;

describe ResponseTimesController do
describe '#action_allowed?' do
it "should return true" do
expect(true).to be_truthy
end
end

* Test whether the start time is updated to the end time last saved in the database when the user resumes a review;

describe '#response_start_time' do
context 'when the link is opened and timed' do
it 'should update time record with start time as end time' do
response_time_records=double('ResponseTime')
allow(ResponseTime).to receive(:where).with([:map_id,:round,:link]).and_return(response_time_records)
dummy = double('BasicObject')
allow(ResponseTime).to receive(:end_at).and_return(dummy)
allow(dummy).to receive(:nil?).and_return(true)
allow(ResponseTime).to receive(:update_attributes).with(:end_at,:start_at).and_return(response_time_records)
expect(response.body).to be_blank
end
end
end

* Test whether the end time is updated as the current time when the review is saved to the database.

describe '#response_end_time' do
context 'when response does not have a end time' do
it 'should update time record with end time as current time' do
response_time_records=double('ResponseTime')
allow(ResponseTime).to receive(:where).with([:map_id,:round,:link]).and_return(response_time_records)
dummy = double('BasicObject')
allow(ResponseTime).to receive(:end_at).and_return(dummy)
allow(dummy).to receive(:nil?).and_return(true)
allow(ResponseTime).to receive(:update_attributes).with(:end_at,Time.now.to_date).and_return(response_time_records)
expect(response.body).to be_blank
end
end
end

== Related Files ==
submission_viewing_events.rb 
submission_viewing_events_controller.rb 
responses_controller.rb 
helper/review_mapping_helper.rb 
helpers/submitted_content_helper.rb 
response/response.html.erb 
review_mapping/_review_report.html.erb 
review_mapping/_review_submissions_time_spent.html.erb 
view/popup/reviewer_details_popup.html.erb 
view/submitted_content/_hyperlink.html.erb 
view/submitted_content/_submitted_files.html.erb 
db/migrate/20171117190721_create_response_times.rb 
config/routes.rb

== Future Work ==

In this project, we accomplished the requirement defined in the project instructions. However, due to the complexity of the Expertiza system and limited time period, there are still several points to improve in the future:

1. Improve the accuracy of review time record. To record the exact time that the user spends on each link or file, it is more accurate to track the active time of each new window or tab of these links or online files. We attempted this design using 'window.focus()', but it does not work once the user moved away from the review page and turned to other applications. So either tweaking the web setting or using browser APIs may solve this problem.

2. Notify the user when no response on the review page. Occasionally the user may open the review page to do the review, but is interrupted to focus on other applications. In this case, we stopped the time recording but try to alert the user that if he wants to continue the review. However, this notice cannot show in time if the user is not focusing on that review page. So a global alert is necessary to save the time and provide notice on time.

== Project Links ==
1. [https://github.com/expertiza/expertiza/pull/1124 Project Github repo]

2. [https://youtu.be/IMTBqiKth-k Project Video Demo]

==Team==
[mailto:sli41@ncsu.edu Shijie Li] 
[mailto:wsun12@ncsu.edu Wei Sun] 
[mailto:asundar2@ncsu.edu Aishwarya Sundararajan] 
[mailto:dbhanda@ncsu.edu Darshan Balakrishna Bhandari]

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-09T01:03:39Z

Tsattle: /* Manual Testing */

__TOC__
== Problem Statement ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. Given that fact it is important that Expertiza is able to track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

However, overall the amount of time directly spent on the review itself is most important. One can track the amount of time spent on the review itself quite easily by simply tracking the amount of time from when the page is opened till when the review is saved/submitted. Therefore, being able to track the time from once a link is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

Therefore, the following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and documents should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

=== Current Implementation ===
Thus far, Expertiza does not have the aforementioned feature, however previous work was undertaken by other teams. The prior work of other teams was not merged into the Expertiza code base do to the following issues.
#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1989._Track_the_time_students_look_at_other_submissions E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== Proposed Solution ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1124 E1791] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both, however tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints on a tabular method, citing the review report table becoming too cluttered, we intend to create a pop-up window that will display the results in a table. Unlike the approach taken in project [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 from the fall of 2019], this project will work to display all information using the aforementioned tabular design in a pop-up window. With this approach, the table provides the information and estimates regarding all of the external links accessed throughout this review in a simple and uncluttered fashion.

=== Design pattern ===
'''Strategy:''' This project, for each review page, deals with different type of links. Javascript is used to track the access time for online links, such as github repo, youtube links, and more. For submitted files, such as txt, jpg, we will time it with views/response/_submitted_files.html.erb.

Instructor 
A similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] will be used for an instructor to access the tabularized information regarding access times:
[[File:E1989_Instructor_flowchart.png | center]]

=== Database Schema ===
[[File:Db_schema.PNG]]

== Testing Plan ==
===Rspec===
Automatic testing will be achieved using rspec. We will test the changes made to controllers/submission_viewing_events_controller.rb and ensure the new implementation will pass.

===Manual Testing===
1. Log in as instructor

2. Assign a review to a student

3. Log in as student

4. Complete the dummy review in 5 minutes

5. Log in as instructor

6. Navigate to review report tab

7. Verify that the review was completed ~5 minutes.

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-09T01:03:08Z

Tsattle: /* Testing Plan */

__TOC__
== Problem Statement ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. Given that fact it is important that Expertiza is able to track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

However, overall the amount of time directly spent on the review itself is most important. One can track the amount of time spent on the review itself quite easily by simply tracking the amount of time from when the page is opened till when the review is saved/submitted. Therefore, being able to track the time from once a link is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

Therefore, the following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and documents should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

=== Current Implementation ===
Thus far, Expertiza does not have the aforementioned feature, however previous work was undertaken by other teams. The prior work of other teams was not merged into the Expertiza code base do to the following issues.
#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1989._Track_the_time_students_look_at_other_submissions E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== Proposed Solution ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1124 E1791] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both, however tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints on a tabular method, citing the review report table becoming too cluttered, we intend to create a pop-up window that will display the results in a table. Unlike the approach taken in project [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 from the fall of 2019], this project will work to display all information using the aforementioned tabular design in a pop-up window. With this approach, the table provides the information and estimates regarding all of the external links accessed throughout this review in a simple and uncluttered fashion.

=== Design pattern ===
'''Strategy:''' This project, for each review page, deals with different type of links. Javascript is used to track the access time for online links, such as github repo, youtube links, and more. For submitted files, such as txt, jpg, we will time it with views/response/_submitted_files.html.erb.

Instructor 
A similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] will be used for an instructor to access the tabularized information regarding access times:
[[File:E1989_Instructor_flowchart.png | center]]

=== Database Schema ===
[[File:Db_schema.PNG]]

== Testing Plan ==
===Rspec===
Automatic testing will be achieved using rspec. We will test the changes made to controllers/submission_viewing_events_controller.rb and ensure the new implementation will pass.

===Manual Testing===
1. Log in as instructor
2. Assign a review to a student
3. Log in as student
4. Complete the dummy review in 5 minutes
5. Log in as instructor
6. Navigate to review report tab
7. Verify that the review was completed ~5 minutes.

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-09T00:58:51Z

Tsattle: /* Testing Plan */

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-09T00:58:18Z

Tsattle: /* Testing Plan */

__TOC__
== Problem Statement ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. Given that fact it is important that Expertiza is able to track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

However, overall the amount of time directly spent on the review itself is most important. One can track the amount of time spent on the review itself quite easily by simply tracking the amount of time from when the page is opened till when the review is saved/submitted. Therefore, being able to track the time from once a link is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

Therefore, the following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and documents should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

=== Current Implementation ===
Thus far, Expertiza does not have the aforementioned feature, however previous work was undertaken by other teams. The prior work of other teams was not merged into the Expertiza code base do to the following issues.
#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1989._Track_the_time_students_look_at_other_submissions E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== Proposed Solution ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1124 E1791] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both, however tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints on a tabular method, citing the review report table becoming too cluttered, we intend to create a pop-up window that will display the results in a table. Unlike the approach taken in project [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 from the fall of 2019], this project will work to display all information using the aforementioned tabular design in a pop-up window. With this approach, the table provides the information and estimates regarding all of the external links accessed throughout this review in a simple and uncluttered fashion.

=== Design pattern ===
'''Strategy:''' This project, for each review page, deals with different type of links. Javascript is used to track the access time for online links, such as github repo, youtube links, and more. For submitted files, such as txt, jpg, we will time it with views/response/_submitted_files.html.erb.

Instructor 
A similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] will be used for an instructor to access the tabularized information regarding access times:
[[File:E1989_Instructor_flowchart.png | center]]

=== Database Schema ===
[[File:Db_schema.PNG]]

== Testing Plan ==
'''Rspec:''' Automatic testing will be achieved using rspec. We will test the changes made to controllers/submission_viewing_events_controller.rb and ensure the new implementation will pass.

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-09T00:57:36Z

Tsattle: /* Testing Plan */

__TOC__
== Problem Statement ==
Understanding how much time a student spends reviewing another's work is beneficial in order to better estimate the quality of said review. Given that fact it is important that Expertiza is able to track and display the given amount of time a student spends on a review.

The time spent on each review is a summation of multiple sources:
* Time spent of the Expertiza review itself
* Time spent looking at external links
* Time spent looking at downloadable files

However, overall the amount of time directly spent on the review itself is most important. One can track the amount of time spent on the review itself quite easily by simply tracking the amount of time from when the page is opened till when the review is saved/submitted. Therefore, being able to track the time from once a link is opened till when the review is saved/submitted will provide a reasonable estimate of the amount of time spent on each resource. This has the benefit of only needing to track information interacted with on the Expertiza review page, as opposed to other external files and links.

Therefore, the following tasks need to be accomplished:
# Time spent on an Expertiza review must be tracked
# Time spent on external links and documents should be tracked/estimated
# Overall time spent on the review should be displayed in a "user friendly manner"

=== Current Implementation ===
Thus far, Expertiza does not have the aforementioned feature, however previous work was undertaken by other teams. The prior work of other teams was not merged into the Expertiza code base do to the following issues.
#[https://github.com/expertiza/expertiza/pull/875 E1705] identified how to track the active time of windows opened from the submitted links.
#[https://github.com/expertiza/expertiza/pull/1124 E1791] provided detailed insights on how they planned to track time taken by a student in viewing a submission and possible edge cases. Further, they also implemented popups and figured out a way to open downloadable files. However, the details are rendered in a not-so-friendly manner and hence it was not merged.
#[https://github.com/expertiza/expertiza/pull/1309 E1872] tried to solve this by incorporating the statistics in the review reports page, but their UI made the page cluttered and not friendly. Further, it was hard to identify which statistic belonged to which review, and there were almost no tests. ([http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2018/E1872_Track_Time_Students_Look_At_Other_Submissions Wiki])
#[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2019_-_E1989._Track_the_time_students_look_at_other_submissions E1989] tried to solve this by building off of [https://github.com/expertiza/expertiza/pull/1124 E1791]. The team took the base code and attempted to implement the ability to track time spent on the review page, as well as other external links, however the code was not merged due to a large amount of white-space, as well as difficulty in distinguishing actual code changes.

== Proposed Solution ==
In review of previous iterations of this project, it was found that project [https://github.com/expertiza/expertiza/pull/1124 E1791] would prove to be a good starting point for completion of this project's requirements. This build has already implemented systems that help track time spent viewing external pages. To achieve our goals outlined in the [[#Problem Statement|Problem Statement]], the following changes need to be made:

; The time spent on the Expertiza assignment review page needs to be tracked.
*Due to Expertiza generating report text boxes with HTML iFrames, we will track whether or not the document hasFocus() to determine when a student is on the page or not.
*After 5 minutes of mouse/keyboard inactivity, a popup is displayed asking if the user is still working. At that point, the time contributed towards the total by the Expertiza page is paused until the user interacts with the popup to indicate they are still working. This is already implemented in project [https://github.com/expertiza/expertiza/pull/1124 E1791].

; The time spent viewing the external links/downloadable files needs to be tracked or estimated
*Currently, if a student has an external link open as well as the Expertiza page, time is being tracked for both, however tracking of external links may be unnecessary for the project, and instead an estimation approach may be taken. Either way it is likely that this measurement will be altered throughout development of this project.

; The overall time spent on the review needs to be displayed in a "user friendly manner" on the "Review Report" page.
*Due to complaints on a tabular method, citing the review report table becoming too cluttered, we intend to create a pop-up window that will display the results in a table. Unlike the approach taken in project [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 from the fall of 2019], this project will work to display all information using the aforementioned tabular design in a pop-up window. With this approach, the table provides the information and estimates regarding all of the external links accessed throughout this review in a simple and uncluttered fashion.

=== Design pattern ===
'''Strategy:''' This project, for each review page, deals with different type of links. Javascript is used to track the access time for online links, such as github repo, youtube links, and more. For submitted files, such as txt, jpg, we will time it with views/response/_submitted_files.html.erb.

Instructor 
A similar workflow from [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2017/E1791._Track_the_time_that_students_look_at_the_other_submissions_-_logging_improvement E1791 Fall '19] will be used for an instructor to access the tabularized information regarding access times:
[[File:E1989_Instructor_flowchart.png | center]]

=== Database Schema ===
[[File:Db_schema.PNG]]

=== Testing Plan ===
'''Rspec:'''Automatic testing will be achieved using rspec. We will test the changes made to controllers/submission_viewing_events_controller.rb and ensure the new implementation will pass.

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-09T00:55:01Z

Tsattle: /* Proposed Solution */

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-09T00:53:34Z

Tsattle: /* Database Table */

File:Db schema.PNG

2020-04-09T00:52:37Z

Tsattle:

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-09T00:25:25Z

Tsattle: /* Database */

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-09T00:23:55Z

Tsattle: /* Design pattern */

CSC/ECE 517 Spring 2020 / E2023 Track the Time Students Look at Other Submissions

2020-04-09T00:23:31Z

Tsattle: /* Proposed Solution */

CSC/ECE 517 Spring 2020 / E2001 Refactor Questionnaires Controller

2020-03-30T18:00:47Z

Tsattle: /* Manual Testing */

== E2001 Refactor questionnaires_controller.rb ==
This page provides a description of the Expertiza based OSS project
__TOC__
===About Expertiza===
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

=== About Questionnaires Controller ===
Questionnaire controller is the controller for the Questionnaire object. A Questionnaire can be of several types including the following:
* Review
* Metareview
* Author feedback
* Teammate Review
* Survey
* Assignment
* Global Survey
* Course Survey
* Quiz

Of these several different types of questionnaire's the questions, that can be added, have a different formats including:
* Criterion
* Drop down (multiple choice)
* Text box (short question)
* Text area (long question)

Within the controller itself the object can be copied (clone the given questionnaire), created, viewed, edited, updated, deleted, questions can be added, saved, or removed, and creating a questionnaire node for assignming questionnaire attributes.

The next section explores the database relationships with questionnaires_controller.rb.

===Database Relationships===
The following diagram visualizes connections in our database. The relationships between relevant tables that are touching questionnaire.rb are shown.

[[File:Db_relationship.png]]

=== Problem Statement ===
'''Background:''' In Expertiza, Questionnaire is a super-class utilized by all questionnaires, including rubrics, quizzes, and surveys. Rubrics are used to assess things such as project submissions and project teammates. All of the above-mentioned questionnaires are sub-classes of the Questionnaire super-class. Since this super-class is used in a multitude of locations ensuring that there are no issues in the code is very important since an error can cause malfunctions throughout Expertiza.

'''Problem:''' Questionnaires controller has been refactored repeatedly over the past few years, yet some improvements can still be made through refactoring to increase the quality and dryness of the code.

These problems are as follows:
* Unsafe reflection method const_get called with parameter value
* Hardwired variables in add_new_questions and save_new_questions
* Unnecessary checks for QuizQuestionnaire, checks can be removed
* Use guard clause to enclose methods instead of conditional
* Removed unnecessary method 'create_questionnaire'
* Break up create method into new 'create_questionnaire'
* Use each_key instead of keys.each
* Split lines of code to fit within recommended 160 character length
* Removed useless assignment of variable in save method
* Resolved issues involving use of unsafe reflection

=== Files Modified in Project ===
#app/controllers/questionnaires_controller.rb
#spec/controllers/questionnaires_controller_spec.rb

=== Issues and Improvements ===
====Use guard clause====

'''Problem'''

Method(s) save_new_questions, delete, and save_questions used conditional to wrap code instead of guard clause. Using guard clause can reduce complexity and number of lines in code.

'''Solution'''

For example, we go from:
<pre>
def save_new_questions(questionnaire_id)
if params[:new_question]
</pre>
To:
<pre>
def save_new_questions(questionnaire_id)
return unless params[:new_question]
</pre>

====QuizQuestionnaire checks====

'''Problem'''

Method(s) create and save_new_questions have unnecessary checks for if question type is QuizQuestionnaire.

'''Solution'''

We removed the check in both methods. We go from:
<pre>
if @questionnaire.type == "QuizQuestionnaire"
q.weight = 1 # setting the weight to 1 for quiz questionnaire since the model validates this field
end
</pre>

To:
<pre>
q.weight = 1
</pre>

====Hardwired Variables====

'''Problem'''

Method(s) save_new_questions and add_new_questions used hardwired variables. When applicable all values used should be stored as variables so the user knows the purpose of the variable, if that value is used in multiple areas it can be changed with a single change, and it's just messy. For instance both add_new_questions and save_new_questions used the same scalar value 1 for a similar task. We go from:
<pre>
if question.is_a? ScoredQuestion
question.weight = 1
question.max_label = 'Strongly agree'
question.min_label = 'Strongly disagree'
end
question.size = '50, 3' if question.is_a? Criterion
question.alternatives = '0|1|2|3|4|5' if question.is_a? Dropdown
question.size = '60, 5' if question.is_a? TextArea
question.size = '30' if question.is_a? TextField
</pre>
To our code which incorporates constants.
<pre>
if question.is_a? ScoredQuestion
question.weight = WEIGHT
question.max_label = LABEL_AGREE
question.min_label = LABEL_DISAGREE
end
question.size = SIZE_CRITERION if question.is_a? Criterion
question.alternatives = SIZE_ALT_DROPDOWN if question.is_a? Dropdown
question.size = SIZE_TXT_AREA if question.is_a? TextArea
question.size = SIZE_TXT_FIELD if question.is_a? TextField
</pre>
With our constants at the top of the code for easy accessibility:
<pre>
## Constants
# add_new_questions
LABEL_AGREE = 'Strongly agree' # label for scored question if agree
LABEL_DISAGREE = 'Strongly disagree' # label for scored question if disagree
WEIGHT = 1 # question weight
SIZE_CRITERION = '50, 3' # size of the question box if it's a criterion
SIZE_ALT_DROPDOWN = '0|1|2|3|4|5' # alternative to size if question is a dropdown
SIZE_TXT_AREA = '60, 5' # size of question box if text area
SIZE_TXT_FIELD = '30' # size of question box if text field
</pre>

====Unsafe Reflection====

'''Problem'''

Unsafe reflection method const_get called with parameter value

'''Solution'''

Remove the unsafe reflection through using a variable that checks for null values. We go from:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id,seq: i, type: params[:question][:type], break_before: true)
</pre>
To:
<pre>
question_type = params[:question][:type] unless params[:question][:type].nil?
question = Object.const_get(question_type).create(txt: '', questionnaire_id: questionnaire_id,seq: i, type: question_type, break_before: true)
</pre>

====Removed unnecessary method 'create_questionnaire'====

'''Problem'''

Method create_questionnaire, had no apparent calls to it. Aside from assigning a creator ID, it is similar in functionality to create, so we assume that the method was at some point created as a duplicate. We remove the method to make the code dry.

'''Solution'''

For example, we remove:
<pre>
def create_questionnaire
@questionnaire = Object.const_get(params[:questionnaire][:type]).new(questionnaire_params)
# Create Quiz content has been moved to Quiz Questionnaire Controller
if @questionnaire.type != "QuizQuestionnaire" # checking if it is a quiz questionnaire
@questionnaire.instructor_id = Ta.get_my_instructor(session[:user].id)
if session[:user].role.name == "Teaching Assistant"
save

redirect_to controller: 'tree_display', action: 'list'
end
end
</pre>

====Break up create method into new 'create_questionnaire'====

'''Problem'''

The create method itself was 49 lines long. This is too long to be viewable at a glance. Breaking it up into a second private method 'create_questionnaire' to handle attribute assigning and node creation.

'''Solution'''

For example, we go from:
def create
if params[:questionnaire][:name].blank?
flash[:error] = 'A rubric or survey must have a title.'
redirect_to controller: 'questionnaires', action: 'new', model: params[:questionnaire][:type], private: params[:questionnaire][:private]
else
questionnaire_private = params[:questionnaire][:private] == 'true'
display_type = params[:questionnaire][:type].split('Questionnaire')[0]
begin
@questionnaire = Object.const_get(params[:questionnaire][:type]).new if Questionnaire::QUESTIONNAIRE_TYPES.include? params[:questionnaire][:type]
rescue StandardError
flash[:error] = $ERROR_INFO
end
begin
@questionnaire.private = questionnaire_private
@questionnaire.name = params[:questionnaire][:name]
@questionnaire.instructor_id = session[:user].id
@questionnaire.min_question_score = params[:questionnaire][:min_question_score]
@questionnaire.max_question_score = params[:questionnaire][:max_question_score]
@questionnaire.type = params[:questionnaire][:type]
# Zhewei: Right now, the display_type in 'questionnaires' table and name in 'tree_folders' table are not consistent.
# In the future, we need to write migration files to make them consistency.
# E1903 : We are not sure of other type of cases, so have added a if statement. If there are only 5 cases, remove the if statement
if %w[AuthorFeedback CourseSurvey TeammateReview GlobalSurvey AssignmentSurvey].include?(display_type)
display_type = (display_type.split /(?=[A-Z])/).join("%")
end
@questionnaire.display_type = display_type
@questionnaire.instruction_loc = Questionnaire::DEFAULT_QUESTIONNAIRE_URL
@questionnaire.save
# Create node
tree_folder = TreeFolder.where(['name like ?', @questionnaire.display_type]).first
parent = FolderNode.find_by(node_object_id: tree_folder.id)
QuestionnaireNode.create(parent_id: parent.id, node_object_id: @questionnaire.id, type: 'QuestionnaireNode')
flash[:success] = 'You have successfully created a questionnaire!'
rescue StandardError
flash[:error] = $ERROR_INFO
end
redirect_to controller: 'questionnaires', action: 'edit', id: @questionnaire.id
end
end
To:
<pre>
def create
if params[:questionnaire][:name].blank?
flash[:error] = 'A rubric or survey must have a title.'
redirect_to controller: 'questionnaires', action: 'new', model: params[:questionnaire][:type], private: params[:questionnaire][:private]
else
questionnaire_private = params[:questionnaire][:private] == 'true'
display_type = params[:questionnaire][:type].split('Questionnaire')[0]
begin
@questionnaire = Object.const_get(params[:questionnaire][:type]).new if Questionnaire::QUESTIONNAIRE_TYPES.include? params[:questionnaire][:type]
rescue StandardError
flash[:error] = $ERROR_INFO
end
begin
create_questionnaire questionnaire_private, display_type
flash[:success] = 'You have successfully created a questionnaire!'
rescue StandardError
flash[:error] = $ERROR_INFO
end
redirect_to controller: 'questionnaires', action: 'edit', id: @questionnaire.id
end
end

def create_questions questionnaire_private, display_type
@questionnaire.private = questionnaire_private
@questionnaire.name = params[:questionnaire][:name]
@questionnaire.instructor_id = session[:user].id
@questionnaire.min_question_score = params[:questionnaire][:min_question_score]
@questionnaire.max_question_score = params[:questionnaire][:max_question_score]
@questionnaire.type = params[:questionnaire][:type]
# Zhewei: Right now, the display_type in 'questionnaires' table and name in 'tree_folders' table are not consistent.
# In the future, we need to write migration files to make them consistency.
# E1903 : We are not sure of other type of cases, so have added a if statement. If there are only 5 cases, remove the if statement
if %w[AuthorFeedback CourseSurvey TeammateReview GlobalSurvey AssignmentSurvey].include?(display_type)
display_type = (display_type.split /(?=[A-Z])/).join("%")
end
@questionnaire.display_type = display_type
@questionnaire.instruction_loc = Questionnaire::DEFAULT_QUESTIONNAIRE_URL
@questionnaire.save
tree_folder = TreeFolder.where(['name like ?', @questionnaire.display_type]).first
parent = FolderNode.find_by(node_object_id: tree_folder.id)
# Create node
QuestionnaireNode.create(parent_id: parent.id, node_object_id: @questionnaire.id, type: 'QuestionnaireNode')
end
</pre>

====Use each_key instead of keys.each====

'''Problem'''

The existing code uses keys.each to iterate through the hash. Keys.each is useful for modifying a hash, but in this implementation this is not necessary. So, each_key is used to improve performance timing.

'''Solution'''

For example, we go from:
<pre>
params[:new_question].keys.each do |question_key|
</pre>
To:
<pre>
params[:new_question].each_key do |question_key|
</pre>

====Split lines of code to fit within recommended 160 character length====

'''Problem'''

Some of the lines of code exceed the recommended 160 characters per line. To remediate, we simply split code across multiple lines and indent accordingly to maintain readability.

'''Solution'''

For example, we go from:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id, seq: i, type: params[:question][:type], break_before: true)
</pre>
To:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id,
seq: i, type: params[:question][:type], break_before: true)
</pre>

====Removed useless assignment of variable in save method====

'''Problem'''

The existing code included assignments of variables that were not used throughout the file. We assume that these variables were created to implement functionality that has since been removed through previous refactor attempts. In any case, we remove the variable keep the code dry.

'''Solution'''

For example, in the following method:
<pre>
def save
@questionnaire.save!

save_questions @questionnaire.id if !@questionnaire.id.nil? and @questionnaire.id > 0
# We do not create node for quiz questionnaires
if @questionnaire.type != "QuizQuestionnaire"
p_folder = TreeFolder.find_by(name: @questionnaire.display_type)
parent = FolderNode.find_by(node_object_id: p_folder.id)
# create_new_node_if_necessary(parent)
end
undo_link("Questionnaire \"#{@questionnaire.name}\" has been updated successfully. ")
end
</pre>
We remove the unnecessary variables and comments, resulting in the following method:
<pre>
def save
@questionnaire.save!
save_questions @questionnaire.id if !@questionnaire.id.nil? and @questionnaire.id > 0
undo_link("Questionnaire \"#{@questionnaire.name}\" has been updated successfully. ")
end
</pre>

====Created new method 'save_question_hash'====

'''Problem'''

The same do loop for hash iteration to update questions for a questionnaire existed in both the public methods 'update' and 'save_all_questions' methods. In order to remove repetition and make the code dry, this do loop was refactored into its own method 'save_question_hash'.

'''Solution'''

For example, in the following method:
<pre>
def save_all_questions
questionnaire_id = params[:id]
begin
if params[:save]
params[:question].each_pair do |k, v|
@question = Question.find(k)
# example of 'v' value
# {"seq"=>"1.0", "txt"=>"WOW", "weight"=>"1", "size"=>"50,3", "max_label"=>"Strong agree", "min_label"=>"Not agree"}
v.each_pair do |key, value|
@question.send(key + '=', value) if @question.send(key) != value
end

@question.save
flash[:success] = 'All questions have been successfully saved!'
end
end
rescue StandardError
flash[:error] = $ERROR_INFO
end
...
</pre>
We refactor the do loop into its own method:
<pre>
def save_question_hash(params)
params[:question].each_pair do |k, v|
@question = Question.find(k)
v.each_pair do |key, value|
@question.send(key + '=', value) if @question.send(key) != value
end
@question.save
flash[:success] = 'All questions have been successfully saved!'
end
end
</pre>

=== Testing Plan ===
In order to evaluate the changes to Expertiza throughout the OSS project two different methods were used. The first being automatic testing using RSpec and the second being manual testing through accessing the Expertiza project on one's local machine. More in depth discussion of these tests can be found below.
====RSpec Testing====
In many cases the issues were resolved by editing a few lines of code within various methods without the need for additional methods. Thus, adding more test was not needed in these cases. However, in order to ensure the code edits didn't cause any previously crafted test to fail an RSpec test was ran before each commit. If and only if all test passed could the commit be pushed.

The command utilized to test the questionnaires controller is as follows:
<pre>
rspec spec/controllers/questionnaires_controller_spec.rb
</pre>
However, if a VCL was utilized for development this following command was used instead.
<pre>
rspec /home/[UNITYID]/expertiza/spec/controllers/questionnaires_controller_spec.rb
</pre>

In one case the create_questionnaire method was removed, thus in order to keep the set of tests clean the following test block was removed from the testing file:
<pre>
describe '#create_questionnaire and #save' do
context 'when quiz is valid' do
before(:each) do
# create_quiz_questionnaire
allow_any_instance_of(QuestionnairesController).to receive(:valid_quiz).and_return('valid')
end

context 'when questionnaire type is not QuizQuestionnaire' do
it 'redirects to submitted_content#edit page' do
params = {aid: 1,
pid: 1,
questionnaire: {name: 'Test questionnaire',
type: 'ReviewQuestionnaire'}}
# create_questionnaire
allow(ReviewQuestionnaire).to receive(:new).with(any_args).and_return(review_questionnaire)
session = {user: build(:teaching_assistant, id: 1)}
allow(Ta).to receive(:get_my_instructor).with(1).and_return(6)
# save
allow(TreeFolder).to receive(:find_by).with(name: 'Review').and_return(double('TreeFolder', id: 1))
allow(FolderNode).to receive(:find_by).with(node_object_id: 1).and_return(double('FolderNode'))
allow_any_instance_of(QuestionnairesController).to receive(:undo_link).with(any_args).and_return('')
post :create_questionnaire, params, session
expect(flash[:note]).to be nil
expect(response).to redirect_to('/tree_display/list')
expect(controller.instance_variable_get(:@questionnaire).private).to eq false
expect(controller.instance_variable_get(:@questionnaire).name).to eq 'Test questionnaire'
expect(controller.instance_variable_get(:@questionnaire).min_question_score).to eq 0
expect(controller.instance_variable_get(:@questionnaire).max_question_score).to eq 5
expect(controller.instance_variable_get(:@questionnaire).type).to eq 'ReviewQuestionnaire'
expect(controller.instance_variable_get(:@questionnaire).instructor_id).to eq 6
end
end
end
end
</pre>

====Manual Testing====
'''Test Log in'''

Website url: http://152.46.18.99:8080/

Log in: instructor6

Password: password

'''Test Create questionnaire'''

1. After logging in click the Questionnaires tab.

2. Select the plus sign for Review

3. Enter "test1" for name (or something similiar), 0 for min, 10 for max, and no for review private.

4. Select Create

'''Test edit/add questions:'''

5. Change dropbox of question type to TextArea, select Add "1" more. Press the add button.

6. Change dropbox of question type to Criterion, select Add "2" more. Press the add button.

7. Edit question content: "Test question Textarea", "Test question Criterion1", and "Test question Criterion2" in that order.

8. Press Save review questionnaire.

9. Refresh page. All entries should still be available.

10. Select edit or view advice.

11. From descending order fill the boxes with the associated number. i.e. the first box has a 5 above it. Insert 5 in the box. Do this for both criterion.

12. Select save and redisplay advice, then press Back to Questionnaire

13. Going back to Edit/view advice shows the same numbers inputted earlier.

'''Test View Questionnaire'''

14. Select back

15. Click on the name Review: This should show a drop down showing different reviews made.

16. Find the review that was created.

17. Select the view icon to the right. The information should match what was created earlier.

'''Test Delete Questionnaire'''

18. Select Back.

19. Repeat steps 15-16

20. Select the big red X for delete. When prompted, select YES

21. Click on the name Review. The Questionnaire created previously will not be present anymore

These manual tests demonstrate some of the functionality of the questionnaire controller. Feel free to try your own test cases.

===References===
*Code Refactoring Best Practices[https://www.altexsoft.com/blog/engineering/code-refactoring-best-practices-when-and-when-not-to-do-it/]
*Expertiza on Github[https://github.com/expertiza/expertiza]
*Expertiza Project Fork[https://github.com/Sattlert2/expertiza/tree/master]
*Expertiza Website[https://expertiza.ncsu.edu/]
*RSpec Documentation[https://relishapp.com/rspec]

CSC/ECE 517 Spring 2020 / E2001 Refactor Questionnaires Controller

2020-03-30T17:52:02Z

Tsattle: /* Manual Testing */

== E2001 Refactor questionnaires_controller.rb ==
This page provides a description of the Expertiza based OSS project
__TOC__
===About Expertiza===
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

=== About Questionnaires Controller ===
Questionnaire controller is the controller for the Questionnaire object. A Questionnaire can be of several types including the following:
* Review
* Metareview
* Author feedback
* Teammate Review
* Survey
* Assignment
* Global Survey
* Course Survey
* Quiz

Of these several different types of questionnaire's the questions, that can be added, have a different formats including:
* Criterion
* Drop down (multiple choice)
* Text box (short question)
* Text area (long question)

Within the controller itself the object can be copied (clone the given questionnaire), created, viewed, edited, updated, deleted, questions can be added, saved, or removed, and creating a questionnaire node for assignming questionnaire attributes.

The next section explores the database relationships with questionnaires_controller.rb.

===Database Relationships===
The following diagram visualizes connections in our database. The relationships between relevant tables that are touching questionnaire.rb are shown.

[[File:Db_relationship.png]]

=== Problem Statement ===
'''Background:''' In Expertiza, Questionnaire is a super-class utilized by all questionnaires, including rubrics, quizzes, and surveys. Rubrics are used to assess things such as project submissions and project teammates. All of the above-mentioned questionnaires are sub-classes of the Questionnaire super-class. Since this super-class is used in a multitude of locations ensuring that there are no issues in the code is very important since an error can cause malfunctions throughout Expertiza.

'''Problem:''' Questionnaires controller has been refactored repeatedly over the past few years, yet some improvements can still be made through refactoring to increase the quality and dryness of the code.

These problems are as follows:
* Unsafe reflection method const_get called with parameter value
* Hardwired variables in add_new_questions and save_new_questions
* Unnecessary checks for QuizQuestionnaire, checks can be removed
* Use guard clause to enclose methods instead of conditional
* Removed unnecessary method 'create_questionnaire'
* Break up create method into new 'create_questionnaire'
* Use each_key instead of keys.each
* Split lines of code to fit within recommended 160 character length
* Removed useless assignment of variable in save method
* Resolved issues involving use of unsafe reflection

=== Files Modified in Project ===
#app/controllers/questionnaires_controller.rb
#spec/controllers/questionnaires_controller_spec.rb

=== Issues and Improvements ===
====Use guard clause====

'''Problem'''

Method(s) save_new_questions, delete, and save_questions used conditional to wrap code instead of guard clause. Using guard clause can reduce complexity and number of lines in code.

'''Solution'''

For example, we go from:
<pre>
def save_new_questions(questionnaire_id)
if params[:new_question]
</pre>
To:
<pre>
def save_new_questions(questionnaire_id)
return unless params[:new_question]
</pre>

====QuizQuestionnaire checks====

'''Problem'''

Method(s) create and save_new_questions have unnecessary checks for if question type is QuizQuestionnaire.

'''Solution'''

We removed the check in both methods. We go from:
<pre>
if @questionnaire.type == "QuizQuestionnaire"
q.weight = 1 # setting the weight to 1 for quiz questionnaire since the model validates this field
end
</pre>

To:
<pre>
q.weight = 1
</pre>

====Hardwired Variables====

'''Problem'''

Method(s) save_new_questions and add_new_questions used hardwired variables. When applicable all values used should be stored as variables so the user knows the purpose of the variable, if that value is used in multiple areas it can be changed with a single change, and it's just messy. For instance both add_new_questions and save_new_questions used the same scalar value 1 for a similar task. We go from:
<pre>
if question.is_a? ScoredQuestion
question.weight = 1
question.max_label = 'Strongly agree'
question.min_label = 'Strongly disagree'
end
question.size = '50, 3' if question.is_a? Criterion
question.alternatives = '0|1|2|3|4|5' if question.is_a? Dropdown
question.size = '60, 5' if question.is_a? TextArea
question.size = '30' if question.is_a? TextField
</pre>
To our code which incorporates constants.
<pre>
if question.is_a? ScoredQuestion
question.weight = WEIGHT
question.max_label = LABEL_AGREE
question.min_label = LABEL_DISAGREE
end
question.size = SIZE_CRITERION if question.is_a? Criterion
question.alternatives = SIZE_ALT_DROPDOWN if question.is_a? Dropdown
question.size = SIZE_TXT_AREA if question.is_a? TextArea
question.size = SIZE_TXT_FIELD if question.is_a? TextField
</pre>
With our constants at the top of the code for easy accessibility:
<pre>
## Constants
# add_new_questions
LABEL_AGREE = 'Strongly agree' # label for scored question if agree
LABEL_DISAGREE = 'Strongly disagree' # label for scored question if disagree
WEIGHT = 1 # question weight
SIZE_CRITERION = '50, 3' # size of the question box if it's a criterion
SIZE_ALT_DROPDOWN = '0|1|2|3|4|5' # alternative to size if question is a dropdown
SIZE_TXT_AREA = '60, 5' # size of question box if text area
SIZE_TXT_FIELD = '30' # size of question box if text field
</pre>

====Unsafe Reflection====

'''Problem'''

Unsafe reflection method const_get called with parameter value

'''Solution'''

Remove the unsafe reflection through using a variable that checks for null values. We go from:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id,seq: i, type: params[:question][:type], break_before: true)
</pre>
To:
<pre>
question_type = params[:question][:type] unless params[:question][:type].nil?
question = Object.const_get(question_type).create(txt: '', questionnaire_id: questionnaire_id,seq: i, type: question_type, break_before: true)
</pre>

====Removed unnecessary method 'create_questionnaire'====

'''Problem'''

Method create_questionnaire, had no apparent calls to it. Aside from assigning a creator ID, it is similar in functionality to create, so we assume that the method was at some point created as a duplicate. We remove the method to make the code dry.

'''Solution'''

For example, we remove:
<pre>
def create_questionnaire
@questionnaire = Object.const_get(params[:questionnaire][:type]).new(questionnaire_params)
# Create Quiz content has been moved to Quiz Questionnaire Controller
if @questionnaire.type != "QuizQuestionnaire" # checking if it is a quiz questionnaire
@questionnaire.instructor_id = Ta.get_my_instructor(session[:user].id)
if session[:user].role.name == "Teaching Assistant"
save

redirect_to controller: 'tree_display', action: 'list'
end
end
</pre>

====Break up create method into new 'create_questionnaire'====

'''Problem'''

The create method itself was 49 lines long. This is too long to be viewable at a glance. Breaking it up into a second private method 'create_questionnaire' to handle attribute assigning and node creation.

'''Solution'''

For example, we go from:
def create
if params[:questionnaire][:name].blank?
flash[:error] = 'A rubric or survey must have a title.'
redirect_to controller: 'questionnaires', action: 'new', model: params[:questionnaire][:type], private: params[:questionnaire][:private]
else
questionnaire_private = params[:questionnaire][:private] == 'true'
display_type = params[:questionnaire][:type].split('Questionnaire')[0]
begin
@questionnaire = Object.const_get(params[:questionnaire][:type]).new if Questionnaire::QUESTIONNAIRE_TYPES.include? params[:questionnaire][:type]
rescue StandardError
flash[:error] = $ERROR_INFO
end
begin
@questionnaire.private = questionnaire_private
@questionnaire.name = params[:questionnaire][:name]
@questionnaire.instructor_id = session[:user].id
@questionnaire.min_question_score = params[:questionnaire][:min_question_score]
@questionnaire.max_question_score = params[:questionnaire][:max_question_score]
@questionnaire.type = params[:questionnaire][:type]
# Zhewei: Right now, the display_type in 'questionnaires' table and name in 'tree_folders' table are not consistent.
# In the future, we need to write migration files to make them consistency.
# E1903 : We are not sure of other type of cases, so have added a if statement. If there are only 5 cases, remove the if statement
if %w[AuthorFeedback CourseSurvey TeammateReview GlobalSurvey AssignmentSurvey].include?(display_type)
display_type = (display_type.split /(?=[A-Z])/).join("%")
end
@questionnaire.display_type = display_type
@questionnaire.instruction_loc = Questionnaire::DEFAULT_QUESTIONNAIRE_URL
@questionnaire.save
# Create node
tree_folder = TreeFolder.where(['name like ?', @questionnaire.display_type]).first
parent = FolderNode.find_by(node_object_id: tree_folder.id)
QuestionnaireNode.create(parent_id: parent.id, node_object_id: @questionnaire.id, type: 'QuestionnaireNode')
flash[:success] = 'You have successfully created a questionnaire!'
rescue StandardError
flash[:error] = $ERROR_INFO
end
redirect_to controller: 'questionnaires', action: 'edit', id: @questionnaire.id
end
end
To:
<pre>
def create
if params[:questionnaire][:name].blank?
flash[:error] = 'A rubric or survey must have a title.'
redirect_to controller: 'questionnaires', action: 'new', model: params[:questionnaire][:type], private: params[:questionnaire][:private]
else
questionnaire_private = params[:questionnaire][:private] == 'true'
display_type = params[:questionnaire][:type].split('Questionnaire')[0]
begin
@questionnaire = Object.const_get(params[:questionnaire][:type]).new if Questionnaire::QUESTIONNAIRE_TYPES.include? params[:questionnaire][:type]
rescue StandardError
flash[:error] = $ERROR_INFO
end
begin
create_questionnaire questionnaire_private, display_type
flash[:success] = 'You have successfully created a questionnaire!'
rescue StandardError
flash[:error] = $ERROR_INFO
end
redirect_to controller: 'questionnaires', action: 'edit', id: @questionnaire.id
end
end

def create_questions questionnaire_private, display_type
@questionnaire.private = questionnaire_private
@questionnaire.name = params[:questionnaire][:name]
@questionnaire.instructor_id = session[:user].id
@questionnaire.min_question_score = params[:questionnaire][:min_question_score]
@questionnaire.max_question_score = params[:questionnaire][:max_question_score]
@questionnaire.type = params[:questionnaire][:type]
# Zhewei: Right now, the display_type in 'questionnaires' table and name in 'tree_folders' table are not consistent.
# In the future, we need to write migration files to make them consistency.
# E1903 : We are not sure of other type of cases, so have added a if statement. If there are only 5 cases, remove the if statement
if %w[AuthorFeedback CourseSurvey TeammateReview GlobalSurvey AssignmentSurvey].include?(display_type)
display_type = (display_type.split /(?=[A-Z])/).join("%")
end
@questionnaire.display_type = display_type
@questionnaire.instruction_loc = Questionnaire::DEFAULT_QUESTIONNAIRE_URL
@questionnaire.save
tree_folder = TreeFolder.where(['name like ?', @questionnaire.display_type]).first
parent = FolderNode.find_by(node_object_id: tree_folder.id)
# Create node
QuestionnaireNode.create(parent_id: parent.id, node_object_id: @questionnaire.id, type: 'QuestionnaireNode')
end
</pre>

====Use each_key instead of keys.each====

'''Problem'''

The existing code uses keys.each to iterate through the hash. Keys.each is useful for modifying a hash, but in this implementation this is not necessary. So, each_key is used to improve performance timing.

'''Solution'''

For example, we go from:
<pre>
params[:new_question].keys.each do |question_key|
</pre>
To:
<pre>
params[:new_question].each_key do |question_key|
</pre>

====Split lines of code to fit within recommended 160 character length====

'''Problem'''

Some of the lines of code exceed the recommended 160 characters per line. To remediate, we simply split code across multiple lines and indent accordingly to maintain readability.

'''Solution'''

For example, we go from:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id, seq: i, type: params[:question][:type], break_before: true)
</pre>
To:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id,
seq: i, type: params[:question][:type], break_before: true)
</pre>

====Removed useless assignment of variable in save method====

'''Problem'''

The existing code included assignments of variables that were not used throughout the file. We assume that these variables were created to implement functionality that has since been removed through previous refactor attempts. In any case, we remove the variable keep the code dry.

'''Solution'''

For example, in the following method:
<pre>
def save
@questionnaire.save!

save_questions @questionnaire.id if !@questionnaire.id.nil? and @questionnaire.id > 0
# We do not create node for quiz questionnaires
if @questionnaire.type != "QuizQuestionnaire"
p_folder = TreeFolder.find_by(name: @questionnaire.display_type)
parent = FolderNode.find_by(node_object_id: p_folder.id)
# create_new_node_if_necessary(parent)
end
undo_link("Questionnaire \"#{@questionnaire.name}\" has been updated successfully. ")
end
</pre>
We remove the unnecessary variables and comments, resulting in the following method:
<pre>
def save
@questionnaire.save!
save_questions @questionnaire.id if !@questionnaire.id.nil? and @questionnaire.id > 0
undo_link("Questionnaire \"#{@questionnaire.name}\" has been updated successfully. ")
end
</pre>

====Created new method 'save_question_hash'====

'''Problem'''

The same do loop for hash iteration to update questions for a questionnaire existed in both the public methods 'update' and 'save_all_questions' methods. In order to remove repetition and make the code dry, this do loop was refactored into its own method 'save_question_hash'.

'''Solution'''

For example, in the following method:
<pre>
def save_all_questions
questionnaire_id = params[:id]
begin
if params[:save]
params[:question].each_pair do |k, v|
@question = Question.find(k)
# example of 'v' value
# {"seq"=>"1.0", "txt"=>"WOW", "weight"=>"1", "size"=>"50,3", "max_label"=>"Strong agree", "min_label"=>"Not agree"}
v.each_pair do |key, value|
@question.send(key + '=', value) if @question.send(key) != value
end

@question.save
flash[:success] = 'All questions have been successfully saved!'
end
end
rescue StandardError
flash[:error] = $ERROR_INFO
end
...
</pre>
We refactor the do loop into its own method:
<pre>
def save_question_hash(params)
params[:question].each_pair do |k, v|
@question = Question.find(k)
v.each_pair do |key, value|
@question.send(key + '=', value) if @question.send(key) != value
end
@question.save
flash[:success] = 'All questions have been successfully saved!'
end
end
</pre>

=== Testing Plan ===
In order to evaluate the changes to Expertiza throughout the OSS project two different methods were used. The first being automatic testing using RSpec and the second being manual testing through accessing the Expertiza project on one's local machine. More in depth discussion of these tests can be found below.
====RSpec Testing====
In many cases the issues were resolved by editing a few lines of code within various methods without the need for additional methods. Thus, adding more test was not needed in these cases. However, in order to ensure the code edits didn't cause any previously crafted test to fail an RSpec test was ran before each commit. If and only if all test passed could the commit be pushed.

The command utilized to test the questionnaires controller is as follows:
<pre>
rspec spec/controllers/questionnaires_controller_spec.rb
</pre>
However, if a VCL was utilized for development this following command was used instead.
<pre>
rspec /home/[UNITYID]/expertiza/spec/controllers/questionnaires_controller_spec.rb
</pre>

In one case the create_questionnaire method was removed, thus in order to keep the set of tests clean the following test block was removed from the testing file:
<pre>
describe '#create_questionnaire and #save' do
context 'when quiz is valid' do
before(:each) do
# create_quiz_questionnaire
allow_any_instance_of(QuestionnairesController).to receive(:valid_quiz).and_return('valid')
end

context 'when questionnaire type is not QuizQuestionnaire' do
it 'redirects to submitted_content#edit page' do
params = {aid: 1,
pid: 1,
questionnaire: {name: 'Test questionnaire',
type: 'ReviewQuestionnaire'}}
# create_questionnaire
allow(ReviewQuestionnaire).to receive(:new).with(any_args).and_return(review_questionnaire)
session = {user: build(:teaching_assistant, id: 1)}
allow(Ta).to receive(:get_my_instructor).with(1).and_return(6)
# save
allow(TreeFolder).to receive(:find_by).with(name: 'Review').and_return(double('TreeFolder', id: 1))
allow(FolderNode).to receive(:find_by).with(node_object_id: 1).and_return(double('FolderNode'))
allow_any_instance_of(QuestionnairesController).to receive(:undo_link).with(any_args).and_return('')
post :create_questionnaire, params, session
expect(flash[:note]).to be nil
expect(response).to redirect_to('/tree_display/list')
expect(controller.instance_variable_get(:@questionnaire).private).to eq false
expect(controller.instance_variable_get(:@questionnaire).name).to eq 'Test questionnaire'
expect(controller.instance_variable_get(:@questionnaire).min_question_score).to eq 0
expect(controller.instance_variable_get(:@questionnaire).max_question_score).to eq 5
expect(controller.instance_variable_get(:@questionnaire).type).to eq 'ReviewQuestionnaire'
expect(controller.instance_variable_get(:@questionnaire).instructor_id).to eq 6
end
end
end
end
</pre>

====Manual Testing====
'''Test Log in'''

Website url: http://152.46.18.99:8080/

Log in: instructor6

Password: Password

'''Test Create questionnaire'''

1. After logging in click the Questionnaires tab.

2. Select the plus sign for Review

3. Enter "test1" for name (or something similiar), 0 for min, 10 for max, and no for review private.

4. Select Create

'''Test edit/add questions:'''

5. Change dropbox of question type to TextArea, select Add "1" more. Press the add button.

6. Change dropbox of question type to Criterion, select Add "2" more. Press the add button.

7. Edit question content: "Test question Textarea", "Test question Criterion1", and "Test question Criterion2" in that order.

8. Press Save review questionnaire.

9. Refresh page. All entries should still be available.

10. Select edit or view advice.

11. From descending order fill the boxes with the associated number. i.e. the first box has a 5 above it. Insert 5 in the box. Do this for both criterion.

12. Select save and redisplay advice, then press Back to Questionnaire

13. Going back to Edit/view advice shows the same numbers inputted earlier.

'''Test View Questionnaire'''

14. Select back

15. Click on the name Review: This should show a drop down showing different reviews made.

16. Find the review that was created.

17. Select the view icon to the right. The information should match what was created earlier.

'''Test Delete Questionnaire'''

18. Select Back.

19. Repeat steps 15-16

20. Select the big red X for delete. When prompted, select YES

21. Click on the name Review. The Questionnaire created previously will not be present anymore

These manual tests demonstrate some of the functionality of the questionnaire controller. Feel free to try your own test cases.

===References===
*Code Refactoring Best Practices[https://www.altexsoft.com/blog/engineering/code-refactoring-best-practices-when-and-when-not-to-do-it/]
*Expertiza on Github[https://github.com/expertiza/expertiza]
*Expertiza Project Fork[https://github.com/Sattlert2/expertiza/tree/master]
*Expertiza Website[https://expertiza.ncsu.edu/]
*RSpec Documentation[https://relishapp.com/rspec]

CSC/ECE 517 Spring 2020 / E2001 Refactor Questionnaires Controller

2020-03-30T17:51:06Z

Tsattle: /* Manual Testing */

== E2001 Refactor questionnaires_controller.rb ==
This page provides a description of the Expertiza based OSS project
__TOC__
===About Expertiza===
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

=== About Questionnaires Controller ===
Questionnaire controller is the controller for the Questionnaire object. A Questionnaire can be of several types including the following:
* Review
* Metareview
* Author feedback
* Teammate Review
* Survey
* Assignment
* Global Survey
* Course Survey
* Quiz

Of these several different types of questionnaire's the questions, that can be added, have a different formats including:
* Criterion
* Drop down (multiple choice)
* Text box (short question)
* Text area (long question)

Within the controller itself the object can be copied (clone the given questionnaire), created, viewed, edited, updated, deleted, questions can be added, saved, or removed, and creating a questionnaire node for assignming questionnaire attributes.

The next section explores the database relationships with questionnaires_controller.rb.

===Database Relationships===
The following diagram visualizes connections in our database. The relationships between relevant tables that are touching questionnaire.rb are shown.

[[File:Db_relationship.png]]

=== Problem Statement ===
'''Background:''' In Expertiza, Questionnaire is a super-class utilized by all questionnaires, including rubrics, quizzes, and surveys. Rubrics are used to assess things such as project submissions and project teammates. All of the above-mentioned questionnaires are sub-classes of the Questionnaire super-class. Since this super-class is used in a multitude of locations ensuring that there are no issues in the code is very important since an error can cause malfunctions throughout Expertiza.

'''Problem:''' Questionnaires controller has been refactored repeatedly over the past few years, yet some improvements can still be made through refactoring to increase the quality and dryness of the code.

These problems are as follows:
* Unsafe reflection method const_get called with parameter value
* Hardwired variables in add_new_questions and save_new_questions
* Unnecessary checks for QuizQuestionnaire, checks can be removed
* Use guard clause to enclose methods instead of conditional
* Removed unnecessary method 'create_questionnaire'
* Break up create method into new 'create_questionnaire'
* Use each_key instead of keys.each
* Split lines of code to fit within recommended 160 character length
* Removed useless assignment of variable in save method
* Resolved issues involving use of unsafe reflection

=== Files Modified in Project ===
#app/controllers/questionnaires_controller.rb
#spec/controllers/questionnaires_controller_spec.rb

=== Issues and Improvements ===
====Use guard clause====

'''Problem'''

Method(s) save_new_questions, delete, and save_questions used conditional to wrap code instead of guard clause. Using guard clause can reduce complexity and number of lines in code.

'''Solution'''

For example, we go from:
<pre>
def save_new_questions(questionnaire_id)
if params[:new_question]
</pre>
To:
<pre>
def save_new_questions(questionnaire_id)
return unless params[:new_question]
</pre>

====QuizQuestionnaire checks====

'''Problem'''

Method(s) create and save_new_questions have unnecessary checks for if question type is QuizQuestionnaire.

'''Solution'''

We removed the check in both methods. We go from:
<pre>
if @questionnaire.type == "QuizQuestionnaire"
q.weight = 1 # setting the weight to 1 for quiz questionnaire since the model validates this field
end
</pre>

To:
<pre>
q.weight = 1
</pre>

====Hardwired Variables====

'''Problem'''

Method(s) save_new_questions and add_new_questions used hardwired variables. When applicable all values used should be stored as variables so the user knows the purpose of the variable, if that value is used in multiple areas it can be changed with a single change, and it's just messy. For instance both add_new_questions and save_new_questions used the same scalar value 1 for a similar task. We go from:
<pre>
if question.is_a? ScoredQuestion
question.weight = 1
question.max_label = 'Strongly agree'
question.min_label = 'Strongly disagree'
end
question.size = '50, 3' if question.is_a? Criterion
question.alternatives = '0|1|2|3|4|5' if question.is_a? Dropdown
question.size = '60, 5' if question.is_a? TextArea
question.size = '30' if question.is_a? TextField
</pre>
To our code which incorporates constants.
<pre>
if question.is_a? ScoredQuestion
question.weight = WEIGHT
question.max_label = LABEL_AGREE
question.min_label = LABEL_DISAGREE
end
question.size = SIZE_CRITERION if question.is_a? Criterion
question.alternatives = SIZE_ALT_DROPDOWN if question.is_a? Dropdown
question.size = SIZE_TXT_AREA if question.is_a? TextArea
question.size = SIZE_TXT_FIELD if question.is_a? TextField
</pre>
With our constants at the top of the code for easy accessibility:
<pre>
## Constants
# add_new_questions
LABEL_AGREE = 'Strongly agree' # label for scored question if agree
LABEL_DISAGREE = 'Strongly disagree' # label for scored question if disagree
WEIGHT = 1 # question weight
SIZE_CRITERION = '50, 3' # size of the question box if it's a criterion
SIZE_ALT_DROPDOWN = '0|1|2|3|4|5' # alternative to size if question is a dropdown
SIZE_TXT_AREA = '60, 5' # size of question box if text area
SIZE_TXT_FIELD = '30' # size of question box if text field
</pre>

====Unsafe Reflection====

'''Problem'''

Unsafe reflection method const_get called with parameter value

'''Solution'''

Remove the unsafe reflection through using a variable that checks for null values. We go from:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id,seq: i, type: params[:question][:type], break_before: true)
</pre>
To:
<pre>
question_type = params[:question][:type] unless params[:question][:type].nil?
question = Object.const_get(question_type).create(txt: '', questionnaire_id: questionnaire_id,seq: i, type: question_type, break_before: true)
</pre>

====Removed unnecessary method 'create_questionnaire'====

'''Problem'''

Method create_questionnaire, had no apparent calls to it. Aside from assigning a creator ID, it is similar in functionality to create, so we assume that the method was at some point created as a duplicate. We remove the method to make the code dry.

'''Solution'''

For example, we remove:
<pre>
def create_questionnaire
@questionnaire = Object.const_get(params[:questionnaire][:type]).new(questionnaire_params)
# Create Quiz content has been moved to Quiz Questionnaire Controller
if @questionnaire.type != "QuizQuestionnaire" # checking if it is a quiz questionnaire
@questionnaire.instructor_id = Ta.get_my_instructor(session[:user].id)
if session[:user].role.name == "Teaching Assistant"
save

redirect_to controller: 'tree_display', action: 'list'
end
end
</pre>

====Break up create method into new 'create_questionnaire'====

'''Problem'''

The create method itself was 49 lines long. This is too long to be viewable at a glance. Breaking it up into a second private method 'create_questionnaire' to handle attribute assigning and node creation.

'''Solution'''

For example, we go from:
def create
if params[:questionnaire][:name].blank?
flash[:error] = 'A rubric or survey must have a title.'
redirect_to controller: 'questionnaires', action: 'new', model: params[:questionnaire][:type], private: params[:questionnaire][:private]
else
questionnaire_private = params[:questionnaire][:private] == 'true'
display_type = params[:questionnaire][:type].split('Questionnaire')[0]
begin
@questionnaire = Object.const_get(params[:questionnaire][:type]).new if Questionnaire::QUESTIONNAIRE_TYPES.include? params[:questionnaire][:type]
rescue StandardError
flash[:error] = $ERROR_INFO
end
begin
@questionnaire.private = questionnaire_private
@questionnaire.name = params[:questionnaire][:name]
@questionnaire.instructor_id = session[:user].id
@questionnaire.min_question_score = params[:questionnaire][:min_question_score]
@questionnaire.max_question_score = params[:questionnaire][:max_question_score]
@questionnaire.type = params[:questionnaire][:type]
# Zhewei: Right now, the display_type in 'questionnaires' table and name in 'tree_folders' table are not consistent.
# In the future, we need to write migration files to make them consistency.
# E1903 : We are not sure of other type of cases, so have added a if statement. If there are only 5 cases, remove the if statement
if %w[AuthorFeedback CourseSurvey TeammateReview GlobalSurvey AssignmentSurvey].include?(display_type)
display_type = (display_type.split /(?=[A-Z])/).join("%")
end
@questionnaire.display_type = display_type
@questionnaire.instruction_loc = Questionnaire::DEFAULT_QUESTIONNAIRE_URL
@questionnaire.save
# Create node
tree_folder = TreeFolder.where(['name like ?', @questionnaire.display_type]).first
parent = FolderNode.find_by(node_object_id: tree_folder.id)
QuestionnaireNode.create(parent_id: parent.id, node_object_id: @questionnaire.id, type: 'QuestionnaireNode')
flash[:success] = 'You have successfully created a questionnaire!'
rescue StandardError
flash[:error] = $ERROR_INFO
end
redirect_to controller: 'questionnaires', action: 'edit', id: @questionnaire.id
end
end
To:
<pre>
def create
if params[:questionnaire][:name].blank?
flash[:error] = 'A rubric or survey must have a title.'
redirect_to controller: 'questionnaires', action: 'new', model: params[:questionnaire][:type], private: params[:questionnaire][:private]
else
questionnaire_private = params[:questionnaire][:private] == 'true'
display_type = params[:questionnaire][:type].split('Questionnaire')[0]
begin
@questionnaire = Object.const_get(params[:questionnaire][:type]).new if Questionnaire::QUESTIONNAIRE_TYPES.include? params[:questionnaire][:type]
rescue StandardError
flash[:error] = $ERROR_INFO
end
begin
create_questionnaire questionnaire_private, display_type
flash[:success] = 'You have successfully created a questionnaire!'
rescue StandardError
flash[:error] = $ERROR_INFO
end
redirect_to controller: 'questionnaires', action: 'edit', id: @questionnaire.id
end
end

def create_questions questionnaire_private, display_type
@questionnaire.private = questionnaire_private
@questionnaire.name = params[:questionnaire][:name]
@questionnaire.instructor_id = session[:user].id
@questionnaire.min_question_score = params[:questionnaire][:min_question_score]
@questionnaire.max_question_score = params[:questionnaire][:max_question_score]
@questionnaire.type = params[:questionnaire][:type]
# Zhewei: Right now, the display_type in 'questionnaires' table and name in 'tree_folders' table are not consistent.
# In the future, we need to write migration files to make them consistency.
# E1903 : We are not sure of other type of cases, so have added a if statement. If there are only 5 cases, remove the if statement
if %w[AuthorFeedback CourseSurvey TeammateReview GlobalSurvey AssignmentSurvey].include?(display_type)
display_type = (display_type.split /(?=[A-Z])/).join("%")
end
@questionnaire.display_type = display_type
@questionnaire.instruction_loc = Questionnaire::DEFAULT_QUESTIONNAIRE_URL
@questionnaire.save
tree_folder = TreeFolder.where(['name like ?', @questionnaire.display_type]).first
parent = FolderNode.find_by(node_object_id: tree_folder.id)
# Create node
QuestionnaireNode.create(parent_id: parent.id, node_object_id: @questionnaire.id, type: 'QuestionnaireNode')
end
</pre>

====Use each_key instead of keys.each====

'''Problem'''

The existing code uses keys.each to iterate through the hash. Keys.each is useful for modifying a hash, but in this implementation this is not necessary. So, each_key is used to improve performance timing.

'''Solution'''

For example, we go from:
<pre>
params[:new_question].keys.each do |question_key|
</pre>
To:
<pre>
params[:new_question].each_key do |question_key|
</pre>

====Split lines of code to fit within recommended 160 character length====

'''Problem'''

Some of the lines of code exceed the recommended 160 characters per line. To remediate, we simply split code across multiple lines and indent accordingly to maintain readability.

'''Solution'''

For example, we go from:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id, seq: i, type: params[:question][:type], break_before: true)
</pre>
To:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id,
seq: i, type: params[:question][:type], break_before: true)
</pre>

====Removed useless assignment of variable in save method====

'''Problem'''

The existing code included assignments of variables that were not used throughout the file. We assume that these variables were created to implement functionality that has since been removed through previous refactor attempts. In any case, we remove the variable keep the code dry.

'''Solution'''

For example, in the following method:
<pre>
def save
@questionnaire.save!

save_questions @questionnaire.id if !@questionnaire.id.nil? and @questionnaire.id > 0
# We do not create node for quiz questionnaires
if @questionnaire.type != "QuizQuestionnaire"
p_folder = TreeFolder.find_by(name: @questionnaire.display_type)
parent = FolderNode.find_by(node_object_id: p_folder.id)
# create_new_node_if_necessary(parent)
end
undo_link("Questionnaire \"#{@questionnaire.name}\" has been updated successfully. ")
end
</pre>
We remove the unnecessary variables and comments, resulting in the following method:
<pre>
def save
@questionnaire.save!
save_questions @questionnaire.id if !@questionnaire.id.nil? and @questionnaire.id > 0
undo_link("Questionnaire \"#{@questionnaire.name}\" has been updated successfully. ")
end
</pre>

====Created new method 'save_question_hash'====

'''Problem'''

The same do loop for hash iteration to update questions for a questionnaire existed in both the public methods 'update' and 'save_all_questions' methods. In order to remove repetition and make the code dry, this do loop was refactored into its own method 'save_question_hash'.

'''Solution'''

For example, in the following method:
<pre>
def save_all_questions
questionnaire_id = params[:id]
begin
if params[:save]
params[:question].each_pair do |k, v|
@question = Question.find(k)
# example of 'v' value
# {"seq"=>"1.0", "txt"=>"WOW", "weight"=>"1", "size"=>"50,3", "max_label"=>"Strong agree", "min_label"=>"Not agree"}
v.each_pair do |key, value|
@question.send(key + '=', value) if @question.send(key) != value
end

@question.save
flash[:success] = 'All questions have been successfully saved!'
end
end
rescue StandardError
flash[:error] = $ERROR_INFO
end
...
</pre>
We refactor the do loop into its own method:
<pre>
def save_question_hash(params)
params[:question].each_pair do |k, v|
@question = Question.find(k)
v.each_pair do |key, value|
@question.send(key + '=', value) if @question.send(key) != value
end
@question.save
flash[:success] = 'All questions have been successfully saved!'
end
end
</pre>

=== Testing Plan ===
In order to evaluate the changes to Expertiza throughout the OSS project two different methods were used. The first being automatic testing using RSpec and the second being manual testing through accessing the Expertiza project on one's local machine. More in depth discussion of these tests can be found below.
====RSpec Testing====
In many cases the issues were resolved by editing a few lines of code within various methods without the need for additional methods. Thus, adding more test was not needed in these cases. However, in order to ensure the code edits didn't cause any previously crafted test to fail an RSpec test was ran before each commit. If and only if all test passed could the commit be pushed.

The command utilized to test the questionnaires controller is as follows:
<pre>
rspec spec/controllers/questionnaires_controller_spec.rb
</pre>
However, if a VCL was utilized for development this following command was used instead.
<pre>
rspec /home/[UNITYID]/expertiza/spec/controllers/questionnaires_controller_spec.rb
</pre>

In one case the create_questionnaire method was removed, thus in order to keep the set of tests clean the following test block was removed from the testing file:
<pre>
describe '#create_questionnaire and #save' do
context 'when quiz is valid' do
before(:each) do
# create_quiz_questionnaire
allow_any_instance_of(QuestionnairesController).to receive(:valid_quiz).and_return('valid')
end

context 'when questionnaire type is not QuizQuestionnaire' do
it 'redirects to submitted_content#edit page' do
params = {aid: 1,
pid: 1,
questionnaire: {name: 'Test questionnaire',
type: 'ReviewQuestionnaire'}}
# create_questionnaire
allow(ReviewQuestionnaire).to receive(:new).with(any_args).and_return(review_questionnaire)
session = {user: build(:teaching_assistant, id: 1)}
allow(Ta).to receive(:get_my_instructor).with(1).and_return(6)
# save
allow(TreeFolder).to receive(:find_by).with(name: 'Review').and_return(double('TreeFolder', id: 1))
allow(FolderNode).to receive(:find_by).with(node_object_id: 1).and_return(double('FolderNode'))
allow_any_instance_of(QuestionnairesController).to receive(:undo_link).with(any_args).and_return('')
post :create_questionnaire, params, session
expect(flash[:note]).to be nil
expect(response).to redirect_to('/tree_display/list')
expect(controller.instance_variable_get(:@questionnaire).private).to eq false
expect(controller.instance_variable_get(:@questionnaire).name).to eq 'Test questionnaire'
expect(controller.instance_variable_get(:@questionnaire).min_question_score).to eq 0
expect(controller.instance_variable_get(:@questionnaire).max_question_score).to eq 5
expect(controller.instance_variable_get(:@questionnaire).type).to eq 'ReviewQuestionnaire'
expect(controller.instance_variable_get(:@questionnaire).instructor_id).to eq 6
end
end
end
end
</pre>

====Manual Testing====
Test Log in:

Website url: http://152.46.18.99:8080/

Log in: instructor6

Password: Password

Test Create questionnaire:

1. After logging in click the Questionnaires tab.

2. Select the plus sign for Review

3. Enter "test1" for name (or something similiar), 0 for min, 10 for max, and no for review private.

4. Select Create

Test edit/add questions:

5. Change dropbox of question type to TextArea, select Add "1" more. Press the add button.

6. Change dropbox of question type to Criterion, select Add "2" more. Press the add button.

7. Edit question content: "Test question Textarea", "Test question Criterion1", and "Test question Criterion2" in that order.

8. Press Save review questionnaire.

9. Refresh page. All entries should still be available.

10. Select edit or view advice.

11. From descending order fill the boxes with the associated number. i.e. the first box has a 5 above it. Insert 5 in the box. Do this for both criterion.

12. Select save and redisplay advice, then press Back to Questionnaire

13. Going back to Edit/view advice shows the same numbers inputted earlier.

Test View Questionnaire

14. Select back

15. Click on the name Review: This should show a drop down showing different reviews made.

16. Find the review that was created.

17. Select the view icon to the right. The information should match what was created earlier.

Test Delete Questionnaire

18. Select Back.

19. Repeat steps 15-16

20. Select the big red X for delete. When prompted, select YES

21. Click on the name Review. The Questionnaire created previously will not be present anymore

These manual tests demonstrate some of the functionality of the questionnaire controller. Feel free to try your own test cases.

===References===
*Code Refactoring Best Practices[https://www.altexsoft.com/blog/engineering/code-refactoring-best-practices-when-and-when-not-to-do-it/]
*Expertiza on Github[https://github.com/expertiza/expertiza]
*Expertiza Project Fork[https://github.com/Sattlert2/expertiza/tree/master]
*Expertiza Website[https://expertiza.ncsu.edu/]
*RSpec Documentation[https://relishapp.com/rspec]

CSC/ECE 517 Spring 2020 / E2001 Refactor Questionnaires Controller

2020-03-30T17:44:35Z

Tsattle: /* Manual Testing */

== E2001 Refactor questionnaires_controller.rb ==
This page provides a description of the Expertiza based OSS project
__TOC__
===About Expertiza===
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

=== About Questionnaires Controller ===
Questionnaire controller is the controller for the Questionnaire object. A Questionnaire can be of several types including the following:
* Review
* Metareview
* Author feedback
* Teammate Review
* Survey
* Assignment
* Global Survey
* Course Survey
* Quiz

Of these several different types of questionnaire's the questions, that can be added, have a different formats including:
* Criterion
* Drop down (multiple choice)
* Text box (short question)
* Text area (long question)

Within the controller itself the object can be copied (clone the given questionnaire), created, viewed, edited, updated, deleted, questions can be added, saved, or removed, and creating a questionnaire node for assignming questionnaire attributes.

The next section explores the database relationships with questionnaires_controller.rb.

===Database Relationships===
The following diagram visualizes connections in our database. The relationships between relevant tables that are touching questionnaire.rb are shown.

[[File:Db_relationship.png]]

=== Problem Statement ===
'''Background:''' In Expertiza, Questionnaire is a super-class utilized by all questionnaires, including rubrics, quizzes, and surveys. Rubrics are used to assess things such as project submissions and project teammates. All of the above-mentioned questionnaires are sub-classes of the Questionnaire super-class. Since this super-class is used in a multitude of locations ensuring that there are no issues in the code is very important since an error can cause malfunctions throughout Expertiza.

'''Problem:''' Questionnaires controller has been refactored repeatedly over the past few years, yet some improvements can still be made through refactoring to increase the quality and dryness of the code.

These problems are as follows:
* Unsafe reflection method const_get called with parameter value
* Hardwired variables in add_new_questions and save_new_questions
* Unnecessary checks for QuizQuestionnaire, checks can be removed
* Use guard clause to enclose methods instead of conditional
* Removed unnecessary method 'create_questionnaire'
* Break up create method into new 'create_questionnaire'
* Use each_key instead of keys.each
* Split lines of code to fit within recommended 160 character length
* Removed useless assignment of variable in save method
* Resolved issues involving use of unsafe reflection

=== Files Modified in Project ===
#app/controllers/questionnaires_controller.rb
#spec/controllers/questionnaires_controller_spec.rb

=== Issues and Improvements ===
====Use guard clause====

'''Problem'''

Method(s) save_new_questions, delete, and save_questions used conditional to wrap code instead of guard clause. Using guard clause can reduce complexity and number of lines in code.

'''Solution'''

For example, we go from:
<pre>
def save_new_questions(questionnaire_id)
if params[:new_question]
</pre>
To:
<pre>
def save_new_questions(questionnaire_id)
return unless params[:new_question]
</pre>

====QuizQuestionnaire checks====

'''Problem'''

Method(s) create and save_new_questions have unnecessary checks for if question type is QuizQuestionnaire.

'''Solution'''

We removed the check in both methods. We go from:
<pre>
if @questionnaire.type == "QuizQuestionnaire"
q.weight = 1 # setting the weight to 1 for quiz questionnaire since the model validates this field
end
</pre>

To:
<pre>
q.weight = 1
</pre>

====Hardwired Variables====

'''Problem'''

Method(s) save_new_questions and add_new_questions used hardwired variables. When applicable all values used should be stored as variables so the user knows the purpose of the variable, if that value is used in multiple areas it can be changed with a single change, and it's just messy. For instance both add_new_questions and save_new_questions used the same scalar value 1 for a similar task. We go from:
<pre>
if question.is_a? ScoredQuestion
question.weight = 1
question.max_label = 'Strongly agree'
question.min_label = 'Strongly disagree'
end
question.size = '50, 3' if question.is_a? Criterion
question.alternatives = '0|1|2|3|4|5' if question.is_a? Dropdown
question.size = '60, 5' if question.is_a? TextArea
question.size = '30' if question.is_a? TextField
</pre>
To our code which incorporates constants.
<pre>
if question.is_a? ScoredQuestion
question.weight = WEIGHT
question.max_label = LABEL_AGREE
question.min_label = LABEL_DISAGREE
end
question.size = SIZE_CRITERION if question.is_a? Criterion
question.alternatives = SIZE_ALT_DROPDOWN if question.is_a? Dropdown
question.size = SIZE_TXT_AREA if question.is_a? TextArea
question.size = SIZE_TXT_FIELD if question.is_a? TextField
</pre>
With our constants at the top of the code for easy accessibility:
<pre>
## Constants
# add_new_questions
LABEL_AGREE = 'Strongly agree' # label for scored question if agree
LABEL_DISAGREE = 'Strongly disagree' # label for scored question if disagree
WEIGHT = 1 # question weight
SIZE_CRITERION = '50, 3' # size of the question box if it's a criterion
SIZE_ALT_DROPDOWN = '0|1|2|3|4|5' # alternative to size if question is a dropdown
SIZE_TXT_AREA = '60, 5' # size of question box if text area
SIZE_TXT_FIELD = '30' # size of question box if text field
</pre>

====Unsafe Reflection====

'''Problem'''

Unsafe reflection method const_get called with parameter value

'''Solution'''

Remove the unsafe reflection through using a variable that checks for null values. We go from:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id,seq: i, type: params[:question][:type], break_before: true)
</pre>
To:
<pre>
question_type = params[:question][:type] unless params[:question][:type].nil?
question = Object.const_get(question_type).create(txt: '', questionnaire_id: questionnaire_id,seq: i, type: question_type, break_before: true)
</pre>

====Removed unnecessary method 'create_questionnaire'====

'''Problem'''

Method create_questionnaire, had no apparent calls to it. Aside from assigning a creator ID, it is similar in functionality to create, so we assume that the method was at some point created as a duplicate. We remove the method to make the code dry.

'''Solution'''

For example, we remove:
<pre>
def create_questionnaire
@questionnaire = Object.const_get(params[:questionnaire][:type]).new(questionnaire_params)
# Create Quiz content has been moved to Quiz Questionnaire Controller
if @questionnaire.type != "QuizQuestionnaire" # checking if it is a quiz questionnaire
@questionnaire.instructor_id = Ta.get_my_instructor(session[:user].id)
if session[:user].role.name == "Teaching Assistant"
save

redirect_to controller: 'tree_display', action: 'list'
end
end
</pre>

====Break up create method into new 'create_questionnaire'====

'''Problem'''

The create method itself was 49 lines long. This is too long to be viewable at a glance. Breaking it up into a second private method 'create_questionnaire' to handle attribute assigning and node creation.

'''Solution'''

For example, we go from:
def create
if params[:questionnaire][:name].blank?
flash[:error] = 'A rubric or survey must have a title.'
redirect_to controller: 'questionnaires', action: 'new', model: params[:questionnaire][:type], private: params[:questionnaire][:private]
else
questionnaire_private = params[:questionnaire][:private] == 'true'
display_type = params[:questionnaire][:type].split('Questionnaire')[0]
begin
@questionnaire = Object.const_get(params[:questionnaire][:type]).new if Questionnaire::QUESTIONNAIRE_TYPES.include? params[:questionnaire][:type]
rescue StandardError
flash[:error] = $ERROR_INFO
end
begin
@questionnaire.private = questionnaire_private
@questionnaire.name = params[:questionnaire][:name]
@questionnaire.instructor_id = session[:user].id
@questionnaire.min_question_score = params[:questionnaire][:min_question_score]
@questionnaire.max_question_score = params[:questionnaire][:max_question_score]
@questionnaire.type = params[:questionnaire][:type]
# Zhewei: Right now, the display_type in 'questionnaires' table and name in 'tree_folders' table are not consistent.
# In the future, we need to write migration files to make them consistency.
# E1903 : We are not sure of other type of cases, so have added a if statement. If there are only 5 cases, remove the if statement
if %w[AuthorFeedback CourseSurvey TeammateReview GlobalSurvey AssignmentSurvey].include?(display_type)
display_type = (display_type.split /(?=[A-Z])/).join("%")
end
@questionnaire.display_type = display_type
@questionnaire.instruction_loc = Questionnaire::DEFAULT_QUESTIONNAIRE_URL
@questionnaire.save
# Create node
tree_folder = TreeFolder.where(['name like ?', @questionnaire.display_type]).first
parent = FolderNode.find_by(node_object_id: tree_folder.id)
QuestionnaireNode.create(parent_id: parent.id, node_object_id: @questionnaire.id, type: 'QuestionnaireNode')
flash[:success] = 'You have successfully created a questionnaire!'
rescue StandardError
flash[:error] = $ERROR_INFO
end
redirect_to controller: 'questionnaires', action: 'edit', id: @questionnaire.id
end
end
To:
<pre>
def create
if params[:questionnaire][:name].blank?
flash[:error] = 'A rubric or survey must have a title.'
redirect_to controller: 'questionnaires', action: 'new', model: params[:questionnaire][:type], private: params[:questionnaire][:private]
else
questionnaire_private = params[:questionnaire][:private] == 'true'
display_type = params[:questionnaire][:type].split('Questionnaire')[0]
begin
@questionnaire = Object.const_get(params[:questionnaire][:type]).new if Questionnaire::QUESTIONNAIRE_TYPES.include? params[:questionnaire][:type]
rescue StandardError
flash[:error] = $ERROR_INFO
end
begin
create_questionnaire questionnaire_private, display_type
flash[:success] = 'You have successfully created a questionnaire!'
rescue StandardError
flash[:error] = $ERROR_INFO
end
redirect_to controller: 'questionnaires', action: 'edit', id: @questionnaire.id
end
end

def create_questions questionnaire_private, display_type
@questionnaire.private = questionnaire_private
@questionnaire.name = params[:questionnaire][:name]
@questionnaire.instructor_id = session[:user].id
@questionnaire.min_question_score = params[:questionnaire][:min_question_score]
@questionnaire.max_question_score = params[:questionnaire][:max_question_score]
@questionnaire.type = params[:questionnaire][:type]
# Zhewei: Right now, the display_type in 'questionnaires' table and name in 'tree_folders' table are not consistent.
# In the future, we need to write migration files to make them consistency.
# E1903 : We are not sure of other type of cases, so have added a if statement. If there are only 5 cases, remove the if statement
if %w[AuthorFeedback CourseSurvey TeammateReview GlobalSurvey AssignmentSurvey].include?(display_type)
display_type = (display_type.split /(?=[A-Z])/).join("%")
end
@questionnaire.display_type = display_type
@questionnaire.instruction_loc = Questionnaire::DEFAULT_QUESTIONNAIRE_URL
@questionnaire.save
tree_folder = TreeFolder.where(['name like ?', @questionnaire.display_type]).first
parent = FolderNode.find_by(node_object_id: tree_folder.id)
# Create node
QuestionnaireNode.create(parent_id: parent.id, node_object_id: @questionnaire.id, type: 'QuestionnaireNode')
end
</pre>

====Use each_key instead of keys.each====

'''Problem'''

The existing code uses keys.each to iterate through the hash. Keys.each is useful for modifying a hash, but in this implementation this is not necessary. So, each_key is used to improve performance timing.

'''Solution'''

For example, we go from:
<pre>
params[:new_question].keys.each do |question_key|
</pre>
To:
<pre>
params[:new_question].each_key do |question_key|
</pre>

====Split lines of code to fit within recommended 160 character length====

'''Problem'''

Some of the lines of code exceed the recommended 160 characters per line. To remediate, we simply split code across multiple lines and indent accordingly to maintain readability.

'''Solution'''

For example, we go from:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id, seq: i, type: params[:question][:type], break_before: true)
</pre>
To:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id,
seq: i, type: params[:question][:type], break_before: true)
</pre>

====Removed useless assignment of variable in save method====

'''Problem'''

The existing code included assignments of variables that were not used throughout the file. We assume that these variables were created to implement functionality that has since been removed through previous refactor attempts. In any case, we remove the variable keep the code dry.

'''Solution'''

For example, in the following method:
<pre>
def save
@questionnaire.save!

save_questions @questionnaire.id if !@questionnaire.id.nil? and @questionnaire.id > 0
# We do not create node for quiz questionnaires
if @questionnaire.type != "QuizQuestionnaire"
p_folder = TreeFolder.find_by(name: @questionnaire.display_type)
parent = FolderNode.find_by(node_object_id: p_folder.id)
# create_new_node_if_necessary(parent)
end
undo_link("Questionnaire \"#{@questionnaire.name}\" has been updated successfully. ")
end
</pre>
We remove the unnecessary variables and comments, resulting in the following method:
<pre>
def save
@questionnaire.save!
save_questions @questionnaire.id if !@questionnaire.id.nil? and @questionnaire.id > 0
undo_link("Questionnaire \"#{@questionnaire.name}\" has been updated successfully. ")
end
</pre>

====Created new method 'save_question_hash'====

'''Problem'''

The same do loop for hash iteration to update questions for a questionnaire existed in both the public methods 'update' and 'save_all_questions' methods. In order to remove repetition and make the code dry, this do loop was refactored into its own method 'save_question_hash'.

'''Solution'''

For example, in the following method:
<pre>
def save_all_questions
questionnaire_id = params[:id]
begin
if params[:save]
params[:question].each_pair do |k, v|
@question = Question.find(k)
# example of 'v' value
# {"seq"=>"1.0", "txt"=>"WOW", "weight"=>"1", "size"=>"50,3", "max_label"=>"Strong agree", "min_label"=>"Not agree"}
v.each_pair do |key, value|
@question.send(key + '=', value) if @question.send(key) != value
end

@question.save
flash[:success] = 'All questions have been successfully saved!'
end
end
rescue StandardError
flash[:error] = $ERROR_INFO
end
...
</pre>
We refactor the do loop into its own method:
<pre>
def save_question_hash(params)
params[:question].each_pair do |k, v|
@question = Question.find(k)
v.each_pair do |key, value|
@question.send(key + '=', value) if @question.send(key) != value
end
@question.save
flash[:success] = 'All questions have been successfully saved!'
end
end
</pre>

=== Testing Plan ===
In order to evaluate the changes to Expertiza throughout the OSS project two different methods were used. The first being automatic testing using RSpec and the second being manual testing through accessing the Expertiza project on one's local machine. More in depth discussion of these tests can be found below.
====RSpec Testing====
In many cases the issues were resolved by editing a few lines of code within various methods without the need for additional methods. Thus, adding more test was not needed in these cases. However, in order to ensure the code edits didn't cause any previously crafted test to fail an RSpec test was ran before each commit. If and only if all test passed could the commit be pushed.

The command utilized to test the questionnaires controller is as follows:
<pre>
rspec spec/controllers/questionnaires_controller_spec.rb
</pre>
However, if a VCL was utilized for development this following command was used instead.
<pre>
rspec /home/[UNITYID]/expertiza/spec/controllers/questionnaires_controller_spec.rb
</pre>

In one case the create_questionnaire method was removed, thus in order to keep the set of tests clean the following test block was removed from the testing file:
<pre>
describe '#create_questionnaire and #save' do
context 'when quiz is valid' do
before(:each) do
# create_quiz_questionnaire
allow_any_instance_of(QuestionnairesController).to receive(:valid_quiz).and_return('valid')
end

context 'when questionnaire type is not QuizQuestionnaire' do
it 'redirects to submitted_content#edit page' do
params = {aid: 1,
pid: 1,
questionnaire: {name: 'Test questionnaire',
type: 'ReviewQuestionnaire'}}
# create_questionnaire
allow(ReviewQuestionnaire).to receive(:new).with(any_args).and_return(review_questionnaire)
session = {user: build(:teaching_assistant, id: 1)}
allow(Ta).to receive(:get_my_instructor).with(1).and_return(6)
# save
allow(TreeFolder).to receive(:find_by).with(name: 'Review').and_return(double('TreeFolder', id: 1))
allow(FolderNode).to receive(:find_by).with(node_object_id: 1).and_return(double('FolderNode'))
allow_any_instance_of(QuestionnairesController).to receive(:undo_link).with(any_args).and_return('')
post :create_questionnaire, params, session
expect(flash[:note]).to be nil
expect(response).to redirect_to('/tree_display/list')
expect(controller.instance_variable_get(:@questionnaire).private).to eq false
expect(controller.instance_variable_get(:@questionnaire).name).to eq 'Test questionnaire'
expect(controller.instance_variable_get(:@questionnaire).min_question_score).to eq 0
expect(controller.instance_variable_get(:@questionnaire).max_question_score).to eq 5
expect(controller.instance_variable_get(:@questionnaire).type).to eq 'ReviewQuestionnaire'
expect(controller.instance_variable_get(:@questionnaire).instructor_id).to eq 6
end
end
end
end
</pre>

====Manual Testing====
Test Log in:
Website url: http://152.46.18.99:8080/
Log in: instructor6
Password: Password

Test Create questionnaire:
1. After logging in click the Questionnaires tab.
2. Select the plus sign for Review
3. Enter "test1" for name (or something similiar), 0 for min, 10 for max, and no for review private.
4. Select Create
Test edit/add questions:
5. Change dropbox of question type to TextArea, select Add "1" more. Press the add button.
6. Change dropbox of question type to Criterion, select Add "2" more. Press the add button.
7. Edit question content: "Test question Textarea", "Test question Criterion1", and "Test question Criterion2" in that order.
8. Press Save review questionnaire.
9. Refresh page. All entries should still be available.
10. Select edit or view advice.
11. From descending order fill the boxes with the associated number. i.e. the first box has a 5 above it. Insert 5 in the box. Do this for both criterion.
12. Select save and redisplay advice, then press Back to Questionnaire
13. Going back to Edit/view advice shows the same numbers inputted earlier.
Test View Questionnaire
14. Select back
15. Click on the name Review: This should show a drop down showing different reviews made.
16. Find the review that was created.
17. Select the view icon to the right. The information should match what was imported earlier.
Test Delete Questionnaire
18. Select Back.
19. Repeat steps 15-16
20. Select the big red X for delete. When prompted, select YES
21. Click on the name Review. The Questionnaire created previously will not be present anymore

These manual tests demonstrate some of the functionality of the questionnaire controller. Feel free to try your own test cases.

===References===
*Code Refactoring Best Practices[https://www.altexsoft.com/blog/engineering/code-refactoring-best-practices-when-and-when-not-to-do-it/]
*Expertiza on Github[https://github.com/expertiza/expertiza]
*Expertiza Project Fork[https://github.com/Sattlert2/expertiza/tree/master]
*Expertiza Website[https://expertiza.ncsu.edu/]
*RSpec Documentation[https://relishapp.com/rspec]

CSC/ECE 517 Spring 2020 / E2001 Refactor Questionnaires Controller

2020-03-29T18:41:32Z

Tsattle: /* Database */

== E2001 Refactor questionnaires_controller.rb ==
This page provides a description of the Expertiza based OSS project
__TOC__
===About Expertiza===
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

=== About Questionnaires Controller ===
Questionnaire controller is the controller for the Questionnaire object. A Questionnaire can be of several types including the following:
* Review
* Metareview
* Author feedback
* Teammate Review
* Survey
* Assignment
* Global Survey
* Course Survey
* Quiz

Of these several different types of questionnaire's the questions, that can be added, have a different formats including:
* Criterion
* Drop down (multiple choice)
* Text box (short question)
* Text area (long question)

Within the controller itself the object can be copied (clone the given questionnaire), created, viewed, edited, updated, deleted, questions can be added, saved, or removed, and creating a questionnaire node for assignming questionnaire attributes.

The next section explores the database relationships with questionnaires_controller.rb.

===Database Relationships===
The following diagram visualizes connections in our database. The relationships between relevant tables that are touching questionnaire.rb are shown.

[[File:Db_relationship.png]]

=== Problem Statement ===
'''Background:''' In Expertiza, Questionnaire is a super-class utilized by all questionnaires, including rubrics, quizzes, and surveys. Rubrics are used to assess things such as project submissions and project teammates. All of the above-mentioned questionnaires are sub-classes of the Questionnaire super-class. Since this super-class is used in a multitude of locations ensuring that there are no issues in the code is very important since an error can cause malfunctions throughout Expertiza.

'''Problem:''' Questionnaires controller has been refactored repeatedly over the past few years, yet some improvements can still be made through refactoring to increase the quality and dryness of the code.

These problems are as follows:
* Unsafe reflection method const_get called with parameter value
* Hardwired variables in add_new_questions and save_new_questions
* Unnecessary checks for QuizQuestionnaire, checks can be removed
* Use guard clause to enclose methods instead of conditional
* Removed unnecessary method 'create_questionnaire'
* Break up create method into new 'create_questionnaire'
* Use each_key instead of keys.each
* Split lines of code to fit within recommended 160 character length
* Removed useless assignment of variable in save method
* Resolved issues involving use of unsafe reflection

=== Files Modified in Project ===
#app/controllers/questionnaires_controller.rb
#spec/controllers/questionnaires_controller_spec.rb

=== Issues and Improvements ===
====Use guard clause====

'''Problem'''

Method(s) save_new_questions, delete, and save_questions used conditional to wrap code instead of guard clause. Using guard clause can reduce complexity and number of lines in code.

'''Solution'''

For example, we go from:
<pre>
def save_new_questions(questionnaire_id)
if params[:new_question]
</pre>
To:
<pre>
def save_new_questions(questionnaire_id)
return unless params[:new_question]
</pre>

====QuizQuestionnaire checks====

'''Problem'''

Method(s) create and save_new_questions have unnecessary checks for if question type is QuizQuestionnaire.

'''Solution'''

We removed the check in both methods. We go from:
<pre>
if @questionnaire.type == "QuizQuestionnaire"
q.weight = 1 # setting the weight to 1 for quiz questionnaire since the model validates this field
end
</pre>

To:
<pre>
q.weight = 1
</pre>

====Hardwired Variables====

'''Problem'''

Method(s) save_new_questions and add_new_questions used hardwired variables. When applicable all values used should be stored as variables so the user knows the purpose of the variable, if that value is used in multiple areas it can be changed with a single change, and it's just messy. For instance both add_new_questions and save_new_questions used the same scalar value 1 for a similar task. We go from:
<pre>
if question.is_a? ScoredQuestion
question.weight = 1
question.max_label = 'Strongly agree'
question.min_label = 'Strongly disagree'
end
question.size = '50, 3' if question.is_a? Criterion
question.alternatives = '0|1|2|3|4|5' if question.is_a? Dropdown
question.size = '60, 5' if question.is_a? TextArea
question.size = '30' if question.is_a? TextField
</pre>
To our code which incorporates constants.
<pre>
if question.is_a? ScoredQuestion
question.weight = WEIGHT
question.max_label = LABEL_AGREE
question.min_label = LABEL_DISAGREE
end
question.size = SIZE_CRITERION if question.is_a? Criterion
question.alternatives = SIZE_ALT_DROPDOWN if question.is_a? Dropdown
question.size = SIZE_TXT_AREA if question.is_a? TextArea
question.size = SIZE_TXT_FIELD if question.is_a? TextField
</pre>
With our constants at the top of the code for easy accessibility:
<pre>
## Constants
# add_new_questions
LABEL_AGREE = 'Strongly agree' # label for scored question if agree
LABEL_DISAGREE = 'Strongly disagree' # label for scored question if disagree
WEIGHT = 1 # question weight
SIZE_CRITERION = '50, 3' # size of the question box if it's a criterion
SIZE_ALT_DROPDOWN = '0|1|2|3|4|5' # alternative to size if question is a dropdown
SIZE_TXT_AREA = '60, 5' # size of question box if text area
SIZE_TXT_FIELD = '30' # size of question box if text field
</pre>

====Unsafe Reflection====

'''Problem'''

Unsafe reflection method const_get called with parameter value

'''Solution'''

Remove the unsafe reflection through using a variable that checks for null values. We go from:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id,seq: i, type: params[:question][:type], break_before: true)
</pre>
To:
<pre>
question_type = params[:question][:type] unless params[:question][:type].nil?
question = Object.const_get(question_type).create(txt: '', questionnaire_id: questionnaire_id,seq: i, type: question_type, break_before: true)
</pre>

====Removed unnecessary method 'create_questionnaire'====

'''Problem'''

Method create_questionnaire, had no apparent calls to it. Aside from assigning a creator ID, it is similar in functionality to create, so we assume that the method was at some point created as a duplicate. We remove the method to make the code dry.

'''Solution'''

For example, we remove:
<pre>
def create_questionnaire
@questionnaire = Object.const_get(params[:questionnaire][:type]).new(questionnaire_params)
# Create Quiz content has been moved to Quiz Questionnaire Controller
if @questionnaire.type != "QuizQuestionnaire" # checking if it is a quiz questionnaire
@questionnaire.instructor_id = Ta.get_my_instructor(session[:user].id)
if session[:user].role.name == "Teaching Assistant"
save

redirect_to controller: 'tree_display', action: 'list'
end
end
</pre>

====Break up create method into new 'create_questionnaire'====

'''Problem'''

The create method itself was 49 lines long. This is too long to be viewable at a glance. Breaking it up into a second private method 'create_questionnaire' to handle attribute assigning and node creation.

'''Solution'''

For example, we go from:
def create
if params[:questionnaire][:name].blank?
flash[:error] = 'A rubric or survey must have a title.'
redirect_to controller: 'questionnaires', action: 'new', model: params[:questionnaire][:type], private: params[:questionnaire][:private]
else
questionnaire_private = params[:questionnaire][:private] == 'true'
display_type = params[:questionnaire][:type].split('Questionnaire')[0]
begin
@questionnaire = Object.const_get(params[:questionnaire][:type]).new if Questionnaire::QUESTIONNAIRE_TYPES.include? params[:questionnaire][:type]
rescue StandardError
flash[:error] = $ERROR_INFO
end
begin
@questionnaire.private = questionnaire_private
@questionnaire.name = params[:questionnaire][:name]
@questionnaire.instructor_id = session[:user].id
@questionnaire.min_question_score = params[:questionnaire][:min_question_score]
@questionnaire.max_question_score = params[:questionnaire][:max_question_score]
@questionnaire.type = params[:questionnaire][:type]
# Zhewei: Right now, the display_type in 'questionnaires' table and name in 'tree_folders' table are not consistent.
# In the future, we need to write migration files to make them consistency.
# E1903 : We are not sure of other type of cases, so have added a if statement. If there are only 5 cases, remove the if statement
if %w[AuthorFeedback CourseSurvey TeammateReview GlobalSurvey AssignmentSurvey].include?(display_type)
display_type = (display_type.split /(?=[A-Z])/).join("%")
end
@questionnaire.display_type = display_type
@questionnaire.instruction_loc = Questionnaire::DEFAULT_QUESTIONNAIRE_URL
@questionnaire.save
# Create node
tree_folder = TreeFolder.where(['name like ?', @questionnaire.display_type]).first
parent = FolderNode.find_by(node_object_id: tree_folder.id)
QuestionnaireNode.create(parent_id: parent.id, node_object_id: @questionnaire.id, type: 'QuestionnaireNode')
flash[:success] = 'You have successfully created a questionnaire!'
rescue StandardError
flash[:error] = $ERROR_INFO
end
redirect_to controller: 'questionnaires', action: 'edit', id: @questionnaire.id
end
end
To:
<pre>
def create
if params[:questionnaire][:name].blank?
flash[:error] = 'A rubric or survey must have a title.'
redirect_to controller: 'questionnaires', action: 'new', model: params[:questionnaire][:type], private: params[:questionnaire][:private]
else
questionnaire_private = params[:questionnaire][:private] == 'true'
display_type = params[:questionnaire][:type].split('Questionnaire')[0]
begin
@questionnaire = Object.const_get(params[:questionnaire][:type]).new if Questionnaire::QUESTIONNAIRE_TYPES.include? params[:questionnaire][:type]
rescue StandardError
flash[:error] = $ERROR_INFO
end
begin
create_questionnaire questionnaire_private, display_type
flash[:success] = 'You have successfully created a questionnaire!'
rescue StandardError
flash[:error] = $ERROR_INFO
end
redirect_to controller: 'questionnaires', action: 'edit', id: @questionnaire.id
end
end

def create_questions questionnaire_private, display_type
@questionnaire.private = questionnaire_private
@questionnaire.name = params[:questionnaire][:name]
@questionnaire.instructor_id = session[:user].id
@questionnaire.min_question_score = params[:questionnaire][:min_question_score]
@questionnaire.max_question_score = params[:questionnaire][:max_question_score]
@questionnaire.type = params[:questionnaire][:type]
# Zhewei: Right now, the display_type in 'questionnaires' table and name in 'tree_folders' table are not consistent.
# In the future, we need to write migration files to make them consistency.
# E1903 : We are not sure of other type of cases, so have added a if statement. If there are only 5 cases, remove the if statement
if %w[AuthorFeedback CourseSurvey TeammateReview GlobalSurvey AssignmentSurvey].include?(display_type)
display_type = (display_type.split /(?=[A-Z])/).join("%")
end
@questionnaire.display_type = display_type
@questionnaire.instruction_loc = Questionnaire::DEFAULT_QUESTIONNAIRE_URL
@questionnaire.save
tree_folder = TreeFolder.where(['name like ?', @questionnaire.display_type]).first
parent = FolderNode.find_by(node_object_id: tree_folder.id)
# Create node
QuestionnaireNode.create(parent_id: parent.id, node_object_id: @questionnaire.id, type: 'QuestionnaireNode')
end
</pre>

====Use each_key instead of keys.each====

'''Problem'''

The existing code uses keys.each to iterate through the hash. Keys.each is useful for modifying a hash, but in this implementation this is not necessary. So, each_key is used to improve performance timing.

'''Solution'''

For example, we go from:
<pre>
params[:new_question].keys.each do |question_key|
</pre>
To:
<pre>
params[:new_question].each_key do |question_key|
</pre>

====Split lines of code to fit within recommended 160 character length====

'''Problem'''

Some of the lines of code exceed the recommended 160 characters per line. To remediate, we simply split code across multiple lines and indent accordingly to maintain readability.

'''Solution'''

For example, we go from:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id, seq: i, type: params[:question][:type], break_before: true)
</pre>
To:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id,
seq: i, type: params[:question][:type], break_before: true)
</pre>

====Removed useless assignment of variable in save method====

'''Problem'''

The existing code included assignments of variables that were not used throughout the file. We assume that these variables were created to implement functionality that has since been removed through previous refactor attempts. In any case, we remove the variable keep the code dry.

'''Solution'''

For example, in the following method:
<pre>
def save
@questionnaire.save!

save_questions @questionnaire.id if !@questionnaire.id.nil? and @questionnaire.id > 0
# We do not create node for quiz questionnaires
if @questionnaire.type != "QuizQuestionnaire"
p_folder = TreeFolder.find_by(name: @questionnaire.display_type)
parent = FolderNode.find_by(node_object_id: p_folder.id)
# create_new_node_if_necessary(parent)
end
undo_link("Questionnaire \"#{@questionnaire.name}\" has been updated successfully. ")
end
</pre>
We remove the unnecessary variables and comments, resulting in the following method:
<pre>
def save
@questionnaire.save!
save_questions @questionnaire.id if !@questionnaire.id.nil? and @questionnaire.id > 0
undo_link("Questionnaire \"#{@questionnaire.name}\" has been updated successfully. ")
end
</pre>

=== Testing Plan ===
In order to evaluate the changes to Expertiza throughout the OSS project two different methods were used. The first being automatic testing using RSpec and the second being manual testing through accessing the Expertiza project on one's local machine. More in depth discussion of these tests can be found below.
====RSpec Testing====
In many cases the issues were resolved by editing a few lines of code within various methods without the need for additional methods. Thus, adding more test was not needed in these cases. However, in order to ensure the code edits didn't cause any previously crafted test to fail an RSpec test was ran before each commit. If and only if all test passed could the commit be pushed.

The command utilized to test the questionnaires controller is as follows:
<pre>
rspec spec/controllers/questionnaires_controller_spec.rb
</pre>
However, if a VCL was utilized for development this following command was used instead.
<pre>
rspec /home/[UNITYID]/expertiza/spec/controllers/questionnaires_controller_spec.rb
</pre>

In one case the create_questionnaire method was removed, thus in order to keep the set of tests clean the following test block was removed from the testing file:
<pre>
describe '#create_questionnaire and #save' do
context 'when quiz is valid' do
before(:each) do
# create_quiz_questionnaire
allow_any_instance_of(QuestionnairesController).to receive(:valid_quiz).and_return('valid')
end

context 'when questionnaire type is not QuizQuestionnaire' do
it 'redirects to submitted_content#edit page' do
params = {aid: 1,
pid: 1,
questionnaire: {name: 'Test questionnaire',
type: 'ReviewQuestionnaire'}}
# create_questionnaire
allow(ReviewQuestionnaire).to receive(:new).with(any_args).and_return(review_questionnaire)
session = {user: build(:teaching_assistant, id: 1)}
allow(Ta).to receive(:get_my_instructor).with(1).and_return(6)
# save
allow(TreeFolder).to receive(:find_by).with(name: 'Review').and_return(double('TreeFolder', id: 1))
allow(FolderNode).to receive(:find_by).with(node_object_id: 1).and_return(double('FolderNode'))
allow_any_instance_of(QuestionnairesController).to receive(:undo_link).with(any_args).and_return('')
post :create_questionnaire, params, session
expect(flash[:note]).to be nil
expect(response).to redirect_to('/tree_display/list')
expect(controller.instance_variable_get(:@questionnaire).private).to eq false
expect(controller.instance_variable_get(:@questionnaire).name).to eq 'Test questionnaire'
expect(controller.instance_variable_get(:@questionnaire).min_question_score).to eq 0
expect(controller.instance_variable_get(:@questionnaire).max_question_score).to eq 5
expect(controller.instance_variable_get(:@questionnaire).type).to eq 'ReviewQuestionnaire'
expect(controller.instance_variable_get(:@questionnaire).instructor_id).to eq 6
end
end
end
end
</pre>

====Manual Testing====
Manual testing was performed by running Expertiza on the local machine and creating the various types of questionnaires (i.e. rubrics, quizzes, and surveys) in the various locations they occurred albeit non-exhaustively . If a questionnaire was created and could be updated without throwing an error it was determined that the refactoring on the questionnaires controller had succeeded. This process was performed and confirmed by all team members in order to ensure accuracy.

===References===
*Code Refactoring Best Practices[https://www.altexsoft.com/blog/engineering/code-refactoring-best-practices-when-and-when-not-to-do-it/]
*Expertiza on Github[https://github.com/expertiza/expertiza]
*Expertiza Project Fork[https://github.com/Sattlert2/expertiza/tree/master]
*Expertiza Website[https://expertiza.ncsu.edu/]
*RSpec Documentation[https://relishapp.com/rspec]

CSC/ECE 517 Spring 2020 / E2001 Refactor Questionnaires Controller

2020-03-29T18:36:49Z

Tsattle: /* About Questionnaires Controller */

== E2001 Refactor questionnaires_controller.rb ==
This page provides a description of the Expertiza based OSS project
__TOC__
===About Expertiza===
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

=== About Questionnaires Controller ===
Questionnaire controller is the controller for the Questionnaire object. A Questionnaire can be of several types including the following:
* Review
* Metareview
* Author feedback
* Teammate Review
* Survey
* Assignment
* Global Survey
* Course Survey
* Quiz

Of these several different types of questionnaire's the questions, that can be added, have a different formats including:
* Criterion
* Drop down (multiple choice)
* Text box (short question)
* Text area (long question)

Within the controller itself the object can be copied (clone the given questionnaire), created, viewed, edited, updated, deleted, questions can be added, saved, or removed, and creating a questionnaire node for assignming questionnaire attributes.

The next section explores the database relationships with questionnaires_controller.rb.

===Database===
The following diagram visualizes connections in our database. The relationships between relevant tables that are touching questionnaire.rb are shown.

[[File:Db_relationship.png]]

=== Problem Statement ===
'''Background:''' In Expertiza, Questionnaire is a super-class utilized by all questionnaires, including rubrics, quizzes, and surveys. Rubrics are used to assess things such as project submissions and project teammates. All of the above-mentioned questionnaires are sub-classes of the Questionnaire super-class. Since this super-class is used in a multitude of locations ensuring that there are no issues in the code is very important since an error can cause malfunctions throughout Expertiza.

'''Problem:''' Questionnaires controller has been refactored repeatedly over the past few years, yet some improvements can still be made through refactoring to increase the quality and dryness of the code.

These problems are as follows:
* Unsafe reflection method const_get called with parameter value
* Hardwired variables in add_new_questions and save_new_questions
* Unnecessary checks for QuizQuestionnaire, checks can be removed
* Use guard clause to enclose methods instead of conditional
* Removed unnecessary method 'create_questionnaire'
* Break up create method into new 'create_questionnaire'
* Use each_key instead of keys.each
* Split lines of code to fit within recommended 160 character length
* Removed useless assignment of variable in save method
* Resolved issues involving use of unsafe reflection

=== Files Modified in Project ===
#app/controllers/questionnaires_controller.rb
#spec/controllers/questionnaires_controller_spec.rb

=== Issues and Improvements ===
====Use guard clause====

'''Problem'''

Method(s) save_new_questions, delete, and save_questions used conditional to wrap code instead of guard clause. Using guard clause can reduce complexity and number of lines in code.

'''Solution'''

For example, we go from:
<pre>
def save_new_questions(questionnaire_id)
if params[:new_question]
</pre>
To:
<pre>
def save_new_questions(questionnaire_id)
return unless params[:new_question]
</pre>

====QuizQuestionnaire checks====

'''Problem'''

Method(s) create and save_new_questions have unnecessary checks for if question type is QuizQuestionnaire.

'''Solution'''

We removed the check in both methods. We go from:
<pre>
if @questionnaire.type == "QuizQuestionnaire"
q.weight = 1 # setting the weight to 1 for quiz questionnaire since the model validates this field
end
</pre>

To:
<pre>
q.weight = 1
</pre>

====Hardwired Variables====

'''Problem'''

Method(s) save_new_questions and add_new_questions used hardwired variables. When applicable all values used should be stored as variables so the user knows the purpose of the variable, if that value is used in multiple areas it can be changed with a single change, and it's just messy. For instance both add_new_questions and save_new_questions used the same scalar value 1 for a similar task. We go from:
<pre>
if question.is_a? ScoredQuestion
question.weight = 1
question.max_label = 'Strongly agree'
question.min_label = 'Strongly disagree'
end
question.size = '50, 3' if question.is_a? Criterion
question.alternatives = '0|1|2|3|4|5' if question.is_a? Dropdown
question.size = '60, 5' if question.is_a? TextArea
question.size = '30' if question.is_a? TextField
</pre>
To our code which incorporates constants.
<pre>
if question.is_a? ScoredQuestion
question.weight = WEIGHT
question.max_label = LABEL_AGREE
question.min_label = LABEL_DISAGREE
end
question.size = SIZE_CRITERION if question.is_a? Criterion
question.alternatives = SIZE_ALT_DROPDOWN if question.is_a? Dropdown
question.size = SIZE_TXT_AREA if question.is_a? TextArea
question.size = SIZE_TXT_FIELD if question.is_a? TextField
</pre>
With our constants at the top of the code for easy accessibility:
<pre>
## Constants
# add_new_questions
LABEL_AGREE = 'Strongly agree' # label for scored question if agree
LABEL_DISAGREE = 'Strongly disagree' # label for scored question if disagree
WEIGHT = 1 # question weight
SIZE_CRITERION = '50, 3' # size of the question box if it's a criterion
SIZE_ALT_DROPDOWN = '0|1|2|3|4|5' # alternative to size if question is a dropdown
SIZE_TXT_AREA = '60, 5' # size of question box if text area
SIZE_TXT_FIELD = '30' # size of question box if text field
</pre>

====Unsafe Reflection====

'''Problem'''

Unsafe reflection method const_get called with parameter value

'''Solution'''

Remove the unsafe reflection through using a variable that checks for null values. We go from:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id,seq: i, type: params[:question][:type], break_before: true)
</pre>
To:
<pre>
question_type = params[:question][:type] unless params[:question][:type].nil?
question = Object.const_get(question_type).create(txt: '', questionnaire_id: questionnaire_id,seq: i, type: question_type, break_before: true)
</pre>

====Removed unnecessary method 'create_questionnaire'====

'''Problem'''

Method create_questionnaire, had no apparent calls to it. Aside from assigning a creator ID, it is similar in functionality to create, so we assume that the method was at some point created as a duplicate. We remove the method to make the code dry.

'''Solution'''

For example, we remove:
<pre>
def create_questionnaire
@questionnaire = Object.const_get(params[:questionnaire][:type]).new(questionnaire_params)
# Create Quiz content has been moved to Quiz Questionnaire Controller
if @questionnaire.type != "QuizQuestionnaire" # checking if it is a quiz questionnaire
@questionnaire.instructor_id = Ta.get_my_instructor(session[:user].id)
if session[:user].role.name == "Teaching Assistant"
save

redirect_to controller: 'tree_display', action: 'list'
end
end
</pre>

====Break up create method into new 'create_questionnaire'====

'''Problem'''

The create method itself was 49 lines long. This is too long to be viewable at a glance. Breaking it up into a second private method 'create_questionnaire' to handle attribute assigning and node creation.

'''Solution'''

For example, we go from:
def create
if params[:questionnaire][:name].blank?
flash[:error] = 'A rubric or survey must have a title.'
redirect_to controller: 'questionnaires', action: 'new', model: params[:questionnaire][:type], private: params[:questionnaire][:private]
else
questionnaire_private = params[:questionnaire][:private] == 'true'
display_type = params[:questionnaire][:type].split('Questionnaire')[0]
begin
@questionnaire = Object.const_get(params[:questionnaire][:type]).new if Questionnaire::QUESTIONNAIRE_TYPES.include? params[:questionnaire][:type]
rescue StandardError
flash[:error] = $ERROR_INFO
end
begin
@questionnaire.private = questionnaire_private
@questionnaire.name = params[:questionnaire][:name]
@questionnaire.instructor_id = session[:user].id
@questionnaire.min_question_score = params[:questionnaire][:min_question_score]
@questionnaire.max_question_score = params[:questionnaire][:max_question_score]
@questionnaire.type = params[:questionnaire][:type]
# Zhewei: Right now, the display_type in 'questionnaires' table and name in 'tree_folders' table are not consistent.
# In the future, we need to write migration files to make them consistency.
# E1903 : We are not sure of other type of cases, so have added a if statement. If there are only 5 cases, remove the if statement
if %w[AuthorFeedback CourseSurvey TeammateReview GlobalSurvey AssignmentSurvey].include?(display_type)
display_type = (display_type.split /(?=[A-Z])/).join("%")
end
@questionnaire.display_type = display_type
@questionnaire.instruction_loc = Questionnaire::DEFAULT_QUESTIONNAIRE_URL
@questionnaire.save
# Create node
tree_folder = TreeFolder.where(['name like ?', @questionnaire.display_type]).first
parent = FolderNode.find_by(node_object_id: tree_folder.id)
QuestionnaireNode.create(parent_id: parent.id, node_object_id: @questionnaire.id, type: 'QuestionnaireNode')
flash[:success] = 'You have successfully created a questionnaire!'
rescue StandardError
flash[:error] = $ERROR_INFO
end
redirect_to controller: 'questionnaires', action: 'edit', id: @questionnaire.id
end
end
To:
<pre>
def create
if params[:questionnaire][:name].blank?
flash[:error] = 'A rubric or survey must have a title.'
redirect_to controller: 'questionnaires', action: 'new', model: params[:questionnaire][:type], private: params[:questionnaire][:private]
else
questionnaire_private = params[:questionnaire][:private] == 'true'
display_type = params[:questionnaire][:type].split('Questionnaire')[0]
begin
@questionnaire = Object.const_get(params[:questionnaire][:type]).new if Questionnaire::QUESTIONNAIRE_TYPES.include? params[:questionnaire][:type]
rescue StandardError
flash[:error] = $ERROR_INFO
end
begin
create_questionnaire questionnaire_private, display_type
flash[:success] = 'You have successfully created a questionnaire!'
rescue StandardError
flash[:error] = $ERROR_INFO
end
redirect_to controller: 'questionnaires', action: 'edit', id: @questionnaire.id
end
end

def create_questions questionnaire_private, display_type
@questionnaire.private = questionnaire_private
@questionnaire.name = params[:questionnaire][:name]
@questionnaire.instructor_id = session[:user].id
@questionnaire.min_question_score = params[:questionnaire][:min_question_score]
@questionnaire.max_question_score = params[:questionnaire][:max_question_score]
@questionnaire.type = params[:questionnaire][:type]
# Zhewei: Right now, the display_type in 'questionnaires' table and name in 'tree_folders' table are not consistent.
# In the future, we need to write migration files to make them consistency.
# E1903 : We are not sure of other type of cases, so have added a if statement. If there are only 5 cases, remove the if statement
if %w[AuthorFeedback CourseSurvey TeammateReview GlobalSurvey AssignmentSurvey].include?(display_type)
display_type = (display_type.split /(?=[A-Z])/).join("%")
end
@questionnaire.display_type = display_type
@questionnaire.instruction_loc = Questionnaire::DEFAULT_QUESTIONNAIRE_URL
@questionnaire.save
tree_folder = TreeFolder.where(['name like ?', @questionnaire.display_type]).first
parent = FolderNode.find_by(node_object_id: tree_folder.id)
# Create node
QuestionnaireNode.create(parent_id: parent.id, node_object_id: @questionnaire.id, type: 'QuestionnaireNode')
end
</pre>

====Use each_key instead of keys.each====

'''Problem'''

The existing code uses keys.each to iterate through the hash. Keys.each is useful for modifying a hash, but in this implementation this is not necessary. So, each_key is used to improve performance timing.

'''Solution'''

For example, we go from:
<pre>
params[:new_question].keys.each do |question_key|
</pre>
To:
<pre>
params[:new_question].each_key do |question_key|
</pre>

====Split lines of code to fit within recommended 160 character length====

'''Problem'''

Some of the lines of code exceed the recommended 160 characters per line. To remediate, we simply split code across multiple lines and indent accordingly to maintain readability.

'''Solution'''

For example, we go from:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id, seq: i, type: params[:question][:type], break_before: true)
</pre>
To:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id,
seq: i, type: params[:question][:type], break_before: true)
</pre>

====Removed useless assignment of variable in save method====

'''Problem'''

The existing code included assignments of variables that were not used throughout the file. We assume that these variables were created to implement functionality that has since been removed through previous refactor attempts. In any case, we remove the variable keep the code dry.

'''Solution'''

For example, in the following method:
<pre>
def save
@questionnaire.save!

save_questions @questionnaire.id if !@questionnaire.id.nil? and @questionnaire.id > 0
# We do not create node for quiz questionnaires
if @questionnaire.type != "QuizQuestionnaire"
p_folder = TreeFolder.find_by(name: @questionnaire.display_type)
parent = FolderNode.find_by(node_object_id: p_folder.id)
# create_new_node_if_necessary(parent)
end
undo_link("Questionnaire \"#{@questionnaire.name}\" has been updated successfully. ")
end
</pre>
We remove the unnecessary variables and comments, resulting in the following method:
<pre>
def save
@questionnaire.save!
save_questions @questionnaire.id if !@questionnaire.id.nil? and @questionnaire.id > 0
undo_link("Questionnaire \"#{@questionnaire.name}\" has been updated successfully. ")
end
</pre>

=== Testing Plan ===
In order to evaluate the changes to Expertiza throughout the OSS project two different methods were used. The first being automatic testing using RSpec and the second being manual testing through accessing the Expertiza project on one's local machine. More in depth discussion of these tests can be found below.
====RSpec Testing====
In many cases the issues were resolved by editing a few lines of code within various methods without the need for additional methods. Thus, adding more test was not needed in these cases. However, in order to ensure the code edits didn't cause any previously crafted test to fail an RSpec test was ran before each commit. If and only if all test passed could the commit be pushed.

The command utilized to test the questionnaires controller is as follows:
<pre>
rspec spec/controllers/questionnaires_controller_spec.rb
</pre>
However, if a VCL was utilized for development this following command was used instead.
<pre>
rspec /home/[UNITYID]/expertiza/spec/controllers/questionnaires_controller_spec.rb
</pre>

In one case the create_questionnaire method was removed, thus in order to keep the set of tests clean the following test block was removed from the testing file:
<pre>
describe '#create_questionnaire and #save' do
context 'when quiz is valid' do
before(:each) do
# create_quiz_questionnaire
allow_any_instance_of(QuestionnairesController).to receive(:valid_quiz).and_return('valid')
end

context 'when questionnaire type is not QuizQuestionnaire' do
it 'redirects to submitted_content#edit page' do
params = {aid: 1,
pid: 1,
questionnaire: {name: 'Test questionnaire',
type: 'ReviewQuestionnaire'}}
# create_questionnaire
allow(ReviewQuestionnaire).to receive(:new).with(any_args).and_return(review_questionnaire)
session = {user: build(:teaching_assistant, id: 1)}
allow(Ta).to receive(:get_my_instructor).with(1).and_return(6)
# save
allow(TreeFolder).to receive(:find_by).with(name: 'Review').and_return(double('TreeFolder', id: 1))
allow(FolderNode).to receive(:find_by).with(node_object_id: 1).and_return(double('FolderNode'))
allow_any_instance_of(QuestionnairesController).to receive(:undo_link).with(any_args).and_return('')
post :create_questionnaire, params, session
expect(flash[:note]).to be nil
expect(response).to redirect_to('/tree_display/list')
expect(controller.instance_variable_get(:@questionnaire).private).to eq false
expect(controller.instance_variable_get(:@questionnaire).name).to eq 'Test questionnaire'
expect(controller.instance_variable_get(:@questionnaire).min_question_score).to eq 0
expect(controller.instance_variable_get(:@questionnaire).max_question_score).to eq 5
expect(controller.instance_variable_get(:@questionnaire).type).to eq 'ReviewQuestionnaire'
expect(controller.instance_variable_get(:@questionnaire).instructor_id).to eq 6
end
end
end
end
</pre>

====Manual Testing====
Manual testing was performed by running Expertiza on the local machine and creating the various types of questionnaires (i.e. rubrics, quizzes, and surveys) in the various locations they occurred albeit non-exhaustively . If a questionnaire was created and could be updated without throwing an error it was determined that the refactoring on the questionnaires controller had succeeded. This process was performed and confirmed by all team members in order to ensure accuracy.

===References===
*Code Refactoring Best Practices[https://www.altexsoft.com/blog/engineering/code-refactoring-best-practices-when-and-when-not-to-do-it/]
*Expertiza on Github[https://github.com/expertiza/expertiza]
*Expertiza Project Fork[https://github.com/Sattlert2/expertiza/tree/master]
*Expertiza Website[https://expertiza.ncsu.edu/]
*RSpec Documentation[https://relishapp.com/rspec]

CSC/ECE 517 Spring 2020 / E2001 Refactor Questionnaires Controller

2020-03-29T18:35:36Z

Tsattle: /* About Questionnaires Controller */

== E2001 Refactor questionnaires_controller.rb ==
This page provides a description of the Expertiza based OSS project
__TOC__
===About Expertiza===
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

=== About Questionnaires Controller ===
Questionnaire controller is the controller for the Questionnaire object. A Questionnaire can be of several types including the following:
* Review
* Metareview
* Author feedback
* Teammate Review
* Survey
* Assignment
* Global Survey
* Course Survey
* Quiz

Of these several different types of questionnaire's the questions can have a different formats including:
* Criterion
* Drop down (multiple choice)
* Text box (short question)
* Text area (long question)

Within the controller itself the object can be copied (clone the given questionnaire), created, viewed, edited, updated, deleted, questions can be added, saved, or removed, and creating a questionnaire node for assignming questionnaire attributes.

The next section explores the database relationships with questionnaires_controller.rb.

===Database===
The following diagram visualizes connections in our database. The relationships between relevant tables that are touching questionnaire.rb are shown.

[[File:Db_relationship.png]]

=== Problem Statement ===
'''Background:''' In Expertiza, Questionnaire is a super-class utilized by all questionnaires, including rubrics, quizzes, and surveys. Rubrics are used to assess things such as project submissions and project teammates. All of the above-mentioned questionnaires are sub-classes of the Questionnaire super-class. Since this super-class is used in a multitude of locations ensuring that there are no issues in the code is very important since an error can cause malfunctions throughout Expertiza.

'''Problem:''' Questionnaires controller has been refactored repeatedly over the past few years, yet some improvements can still be made through refactoring to increase the quality and dryness of the code.

These problems are as follows:
* Unsafe reflection method const_get called with parameter value
* Hardwired variables in add_new_questions and save_new_questions
* Unnecessary checks for QuizQuestionnaire, checks can be removed
* Use guard clause to enclose methods instead of conditional
* Removed unnecessary method 'create_questionnaire'
* Break up create method into new 'create_questionnaire'
* Use each_key instead of keys.each
* Split lines of code to fit within recommended 160 character length
* Removed useless assignment of variable in save method
* Resolved issues involving use of unsafe reflection

=== Files Modified in Project ===
#app/controllers/questionnaires_controller.rb
#spec/controllers/questionnaires_controller_spec.rb

=== Issues and Improvements ===
====Use guard clause====

'''Problem'''

Method(s) save_new_questions, delete, and save_questions used conditional to wrap code instead of guard clause. Using guard clause can reduce complexity and number of lines in code.

'''Solution'''

For example, we go from:
<pre>
def save_new_questions(questionnaire_id)
if params[:new_question]
</pre>
To:
<pre>
def save_new_questions(questionnaire_id)
return unless params[:new_question]
</pre>

====QuizQuestionnaire checks====

'''Problem'''

Method(s) create and save_new_questions have unnecessary checks for if question type is QuizQuestionnaire.

'''Solution'''

We removed the check in both methods. We go from:
<pre>
if @questionnaire.type == "QuizQuestionnaire"
q.weight = 1 # setting the weight to 1 for quiz questionnaire since the model validates this field
end
</pre>

To:
<pre>
q.weight = 1
</pre>

====Hardwired Variables====

'''Problem'''

Method(s) save_new_questions and add_new_questions used hardwired variables. When applicable all values used should be stored as variables so the user knows the purpose of the variable, if that value is used in multiple areas it can be changed with a single change, and it's just messy. For instance both add_new_questions and save_new_questions used the same scalar value 1 for a similar task. We go from:
<pre>
if question.is_a? ScoredQuestion
question.weight = 1
question.max_label = 'Strongly agree'
question.min_label = 'Strongly disagree'
end
question.size = '50, 3' if question.is_a? Criterion
question.alternatives = '0|1|2|3|4|5' if question.is_a? Dropdown
question.size = '60, 5' if question.is_a? TextArea
question.size = '30' if question.is_a? TextField
</pre>
To our code which incorporates constants.
<pre>
if question.is_a? ScoredQuestion
question.weight = WEIGHT
question.max_label = LABEL_AGREE
question.min_label = LABEL_DISAGREE
end
question.size = SIZE_CRITERION if question.is_a? Criterion
question.alternatives = SIZE_ALT_DROPDOWN if question.is_a? Dropdown
question.size = SIZE_TXT_AREA if question.is_a? TextArea
question.size = SIZE_TXT_FIELD if question.is_a? TextField
</pre>
With our constants at the top of the code for easy accessibility:
<pre>
## Constants
# add_new_questions
LABEL_AGREE = 'Strongly agree' # label for scored question if agree
LABEL_DISAGREE = 'Strongly disagree' # label for scored question if disagree
WEIGHT = 1 # question weight
SIZE_CRITERION = '50, 3' # size of the question box if it's a criterion
SIZE_ALT_DROPDOWN = '0|1|2|3|4|5' # alternative to size if question is a dropdown
SIZE_TXT_AREA = '60, 5' # size of question box if text area
SIZE_TXT_FIELD = '30' # size of question box if text field
</pre>

====Unsafe Reflection====

'''Problem'''

Unsafe reflection method const_get called with parameter value

'''Solution'''

Remove the unsafe reflection through using a variable that checks for null values. We go from:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id,seq: i, type: params[:question][:type], break_before: true)
</pre>
To:
<pre>
question_type = params[:question][:type] unless params[:question][:type].nil?
question = Object.const_get(question_type).create(txt: '', questionnaire_id: questionnaire_id,seq: i, type: question_type, break_before: true)
</pre>

====Removed unnecessary method 'create_questionnaire'====

'''Problem'''

Method create_questionnaire, had no apparent calls to it. Aside from assigning a creator ID, it is similar in functionality to create, so we assume that the method was at some point created as a duplicate. We remove the method to make the code dry.

'''Solution'''

For example, we remove:
<pre>
def create_questionnaire
@questionnaire = Object.const_get(params[:questionnaire][:type]).new(questionnaire_params)
# Create Quiz content has been moved to Quiz Questionnaire Controller
if @questionnaire.type != "QuizQuestionnaire" # checking if it is a quiz questionnaire
@questionnaire.instructor_id = Ta.get_my_instructor(session[:user].id)
if session[:user].role.name == "Teaching Assistant"
save

redirect_to controller: 'tree_display', action: 'list'
end
end
</pre>

====Break up create method into new 'create_questionnaire'====

'''Problem'''

The create method itself was 49 lines long. This is too long to be viewable at a glance. Breaking it up into a second private method 'create_questionnaire' to handle attribute assigning and node creation.

'''Solution'''

For example, we go from:
def create
if params[:questionnaire][:name].blank?
flash[:error] = 'A rubric or survey must have a title.'
redirect_to controller: 'questionnaires', action: 'new', model: params[:questionnaire][:type], private: params[:questionnaire][:private]
else
questionnaire_private = params[:questionnaire][:private] == 'true'
display_type = params[:questionnaire][:type].split('Questionnaire')[0]
begin
@questionnaire = Object.const_get(params[:questionnaire][:type]).new if Questionnaire::QUESTIONNAIRE_TYPES.include? params[:questionnaire][:type]
rescue StandardError
flash[:error] = $ERROR_INFO
end
begin
@questionnaire.private = questionnaire_private
@questionnaire.name = params[:questionnaire][:name]
@questionnaire.instructor_id = session[:user].id
@questionnaire.min_question_score = params[:questionnaire][:min_question_score]
@questionnaire.max_question_score = params[:questionnaire][:max_question_score]
@questionnaire.type = params[:questionnaire][:type]
# Zhewei: Right now, the display_type in 'questionnaires' table and name in 'tree_folders' table are not consistent.
# In the future, we need to write migration files to make them consistency.
# E1903 : We are not sure of other type of cases, so have added a if statement. If there are only 5 cases, remove the if statement
if %w[AuthorFeedback CourseSurvey TeammateReview GlobalSurvey AssignmentSurvey].include?(display_type)
display_type = (display_type.split /(?=[A-Z])/).join("%")
end
@questionnaire.display_type = display_type
@questionnaire.instruction_loc = Questionnaire::DEFAULT_QUESTIONNAIRE_URL
@questionnaire.save
# Create node
tree_folder = TreeFolder.where(['name like ?', @questionnaire.display_type]).first
parent = FolderNode.find_by(node_object_id: tree_folder.id)
QuestionnaireNode.create(parent_id: parent.id, node_object_id: @questionnaire.id, type: 'QuestionnaireNode')
flash[:success] = 'You have successfully created a questionnaire!'
rescue StandardError
flash[:error] = $ERROR_INFO
end
redirect_to controller: 'questionnaires', action: 'edit', id: @questionnaire.id
end
end
To:
<pre>
def create
if params[:questionnaire][:name].blank?
flash[:error] = 'A rubric or survey must have a title.'
redirect_to controller: 'questionnaires', action: 'new', model: params[:questionnaire][:type], private: params[:questionnaire][:private]
else
questionnaire_private = params[:questionnaire][:private] == 'true'
display_type = params[:questionnaire][:type].split('Questionnaire')[0]
begin
@questionnaire = Object.const_get(params[:questionnaire][:type]).new if Questionnaire::QUESTIONNAIRE_TYPES.include? params[:questionnaire][:type]
rescue StandardError
flash[:error] = $ERROR_INFO
end
begin
create_questionnaire questionnaire_private, display_type
flash[:success] = 'You have successfully created a questionnaire!'
rescue StandardError
flash[:error] = $ERROR_INFO
end
redirect_to controller: 'questionnaires', action: 'edit', id: @questionnaire.id
end
end

def create_questions questionnaire_private, display_type
@questionnaire.private = questionnaire_private
@questionnaire.name = params[:questionnaire][:name]
@questionnaire.instructor_id = session[:user].id
@questionnaire.min_question_score = params[:questionnaire][:min_question_score]
@questionnaire.max_question_score = params[:questionnaire][:max_question_score]
@questionnaire.type = params[:questionnaire][:type]
# Zhewei: Right now, the display_type in 'questionnaires' table and name in 'tree_folders' table are not consistent.
# In the future, we need to write migration files to make them consistency.
# E1903 : We are not sure of other type of cases, so have added a if statement. If there are only 5 cases, remove the if statement
if %w[AuthorFeedback CourseSurvey TeammateReview GlobalSurvey AssignmentSurvey].include?(display_type)
display_type = (display_type.split /(?=[A-Z])/).join("%")
end
@questionnaire.display_type = display_type
@questionnaire.instruction_loc = Questionnaire::DEFAULT_QUESTIONNAIRE_URL
@questionnaire.save
tree_folder = TreeFolder.where(['name like ?', @questionnaire.display_type]).first
parent = FolderNode.find_by(node_object_id: tree_folder.id)
# Create node
QuestionnaireNode.create(parent_id: parent.id, node_object_id: @questionnaire.id, type: 'QuestionnaireNode')
end
</pre>

====Use each_key instead of keys.each====

'''Problem'''

The existing code uses keys.each to iterate through the hash. Keys.each is useful for modifying a hash, but in this implementation this is not necessary. So, each_key is used to improve performance timing.

'''Solution'''

For example, we go from:
<pre>
params[:new_question].keys.each do |question_key|
</pre>
To:
<pre>
params[:new_question].each_key do |question_key|
</pre>

====Split lines of code to fit within recommended 160 character length====

'''Problem'''

Some of the lines of code exceed the recommended 160 characters per line. To remediate, we simply split code across multiple lines and indent accordingly to maintain readability.

'''Solution'''

For example, we go from:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id, seq: i, type: params[:question][:type], break_before: true)
</pre>
To:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id,
seq: i, type: params[:question][:type], break_before: true)
</pre>

====Removed useless assignment of variable in save method====

'''Problem'''

The existing code included assignments of variables that were not used throughout the file. We assume that these variables were created to implement functionality that has since been removed through previous refactor attempts. In any case, we remove the variable keep the code dry.

'''Solution'''

For example, in the following method:
<pre>
def save
@questionnaire.save!

save_questions @questionnaire.id if !@questionnaire.id.nil? and @questionnaire.id > 0
# We do not create node for quiz questionnaires
if @questionnaire.type != "QuizQuestionnaire"
p_folder = TreeFolder.find_by(name: @questionnaire.display_type)
parent = FolderNode.find_by(node_object_id: p_folder.id)
# create_new_node_if_necessary(parent)
end
undo_link("Questionnaire \"#{@questionnaire.name}\" has been updated successfully. ")
end
</pre>
We remove the unnecessary variables and comments, resulting in the following method:
<pre>
def save
@questionnaire.save!
save_questions @questionnaire.id if !@questionnaire.id.nil? and @questionnaire.id > 0
undo_link("Questionnaire \"#{@questionnaire.name}\" has been updated successfully. ")
end
</pre>

=== Testing Plan ===
In order to evaluate the changes to Expertiza throughout the OSS project two different methods were used. The first being automatic testing using RSpec and the second being manual testing through accessing the Expertiza project on one's local machine. More in depth discussion of these tests can be found below.
====RSpec Testing====
In many cases the issues were resolved by editing a few lines of code within various methods without the need for additional methods. Thus, adding more test was not needed in these cases. However, in order to ensure the code edits didn't cause any previously crafted test to fail an RSpec test was ran before each commit. If and only if all test passed could the commit be pushed.

The command utilized to test the questionnaires controller is as follows:
<pre>
rspec spec/controllers/questionnaires_controller_spec.rb
</pre>
However, if a VCL was utilized for development this following command was used instead.
<pre>
rspec /home/[UNITYID]/expertiza/spec/controllers/questionnaires_controller_spec.rb
</pre>

In one case the create_questionnaire method was removed, thus in order to keep the set of tests clean the following test block was removed from the testing file:
<pre>
describe '#create_questionnaire and #save' do
context 'when quiz is valid' do
before(:each) do
# create_quiz_questionnaire
allow_any_instance_of(QuestionnairesController).to receive(:valid_quiz).and_return('valid')
end

context 'when questionnaire type is not QuizQuestionnaire' do
it 'redirects to submitted_content#edit page' do
params = {aid: 1,
pid: 1,
questionnaire: {name: 'Test questionnaire',
type: 'ReviewQuestionnaire'}}
# create_questionnaire
allow(ReviewQuestionnaire).to receive(:new).with(any_args).and_return(review_questionnaire)
session = {user: build(:teaching_assistant, id: 1)}
allow(Ta).to receive(:get_my_instructor).with(1).and_return(6)
# save
allow(TreeFolder).to receive(:find_by).with(name: 'Review').and_return(double('TreeFolder', id: 1))
allow(FolderNode).to receive(:find_by).with(node_object_id: 1).and_return(double('FolderNode'))
allow_any_instance_of(QuestionnairesController).to receive(:undo_link).with(any_args).and_return('')
post :create_questionnaire, params, session
expect(flash[:note]).to be nil
expect(response).to redirect_to('/tree_display/list')
expect(controller.instance_variable_get(:@questionnaire).private).to eq false
expect(controller.instance_variable_get(:@questionnaire).name).to eq 'Test questionnaire'
expect(controller.instance_variable_get(:@questionnaire).min_question_score).to eq 0
expect(controller.instance_variable_get(:@questionnaire).max_question_score).to eq 5
expect(controller.instance_variable_get(:@questionnaire).type).to eq 'ReviewQuestionnaire'
expect(controller.instance_variable_get(:@questionnaire).instructor_id).to eq 6
end
end
end
end
</pre>

====Manual Testing====
Manual testing was performed by running Expertiza on the local machine and creating the various types of questionnaires (i.e. rubrics, quizzes, and surveys) in the various locations they occurred albeit non-exhaustively . If a questionnaire was created and could be updated without throwing an error it was determined that the refactoring on the questionnaires controller had succeeded. This process was performed and confirmed by all team members in order to ensure accuracy.

===References===
*Code Refactoring Best Practices[https://www.altexsoft.com/blog/engineering/code-refactoring-best-practices-when-and-when-not-to-do-it/]
*Expertiza on Github[https://github.com/expertiza/expertiza]
*Expertiza Project Fork[https://github.com/Sattlert2/expertiza/tree/master]
*Expertiza Website[https://expertiza.ncsu.edu/]
*RSpec Documentation[https://relishapp.com/rspec]

CSC/ECE 517 Spring 2020 / E2001 Refactor Questionnaires Controller

2020-03-29T18:33:39Z

Tsattle: /* E2001 Refactor questionnaires_controller.rb */

== E2001 Refactor questionnaires_controller.rb ==
This page provides a description of the Expertiza based OSS project
__TOC__
===About Expertiza===
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

=== About Questionnaires Controller ===
Questionnaire controller is the controller for the Questionnaire object. A Questionnaire can be of several types including the following:
* Review
* Metareview
* Author feedback
* Teammate Review
* Survey
* Assignment
* Global Survey
* Course Survey
* Quiz

Of these several different types of questionnaire's they can all have a different format including:
* Criterion
* Drop down (multiple choice)
* Text box (short question)
* Text area (long question)

Within the controller itself the object can be copied (clone the given questionnaire), created, viewed, edited, updated, deleted, questions can be added, saved, or removed, and creating a questionnaire node for assignming questionnaire attributes.

The next section explores the database relationships with questionnaires_controller.rb.

===Database===
The following diagram visualizes connections in our database. The relationships between relevant tables that are touching questionnaire.rb are shown.

[[File:Db_relationship.png]]

=== Problem Statement ===
'''Background:''' In Expertiza, Questionnaire is a super-class utilized by all questionnaires, including rubrics, quizzes, and surveys. Rubrics are used to assess things such as project submissions and project teammates. All of the above-mentioned questionnaires are sub-classes of the Questionnaire super-class. Since this super-class is used in a multitude of locations ensuring that there are no issues in the code is very important since an error can cause malfunctions throughout Expertiza.

'''Problem:''' Questionnaires controller has been refactored repeatedly over the past few years, yet some improvements can still be made through refactoring to increase the quality and dryness of the code.

These problems are as follows:
* Unsafe reflection method const_get called with parameter value
* Hardwired variables in add_new_questions and save_new_questions
* Unnecessary checks for QuizQuestionnaire, checks can be removed
* Use guard clause to enclose methods instead of conditional
* Removed unnecessary method 'create_questionnaire'
* Break up create method into new 'create_questionnaire'
* Use each_key instead of keys.each
* Split lines of code to fit within recommended 160 character length
* Removed useless assignment of variable in save method
* Resolved issues involving use of unsafe reflection

=== Files Modified in Project ===
#app/controllers/questionnaires_controller.rb
#spec/controllers/questionnaires_controller_spec.rb

=== Issues and Improvements ===
====Use guard clause====

'''Problem'''

Method(s) save_new_questions, delete, and save_questions used conditional to wrap code instead of guard clause. Using guard clause can reduce complexity and number of lines in code.

'''Solution'''

For example, we go from:
<pre>
def save_new_questions(questionnaire_id)
if params[:new_question]
</pre>
To:
<pre>
def save_new_questions(questionnaire_id)
return unless params[:new_question]
</pre>

====QuizQuestionnaire checks====

'''Problem'''

Method(s) create and save_new_questions have unnecessary checks for if question type is QuizQuestionnaire.

'''Solution'''

We removed the check in both methods. We go from:
<pre>
if @questionnaire.type == "QuizQuestionnaire"
q.weight = 1 # setting the weight to 1 for quiz questionnaire since the model validates this field
end
</pre>

To:
<pre>
q.weight = 1
</pre>

====Hardwired Variables====

'''Problem'''

Method(s) save_new_questions and add_new_questions used hardwired variables. When applicable all values used should be stored as variables so the user knows the purpose of the variable, if that value is used in multiple areas it can be changed with a single change, and it's just messy. For instance both add_new_questions and save_new_questions used the same scalar value 1 for a similar task. We go from:
<pre>
if question.is_a? ScoredQuestion
question.weight = 1
question.max_label = 'Strongly agree'
question.min_label = 'Strongly disagree'
end
question.size = '50, 3' if question.is_a? Criterion
question.alternatives = '0|1|2|3|4|5' if question.is_a? Dropdown
question.size = '60, 5' if question.is_a? TextArea
question.size = '30' if question.is_a? TextField
</pre>
To our code which incorporates constants.
<pre>
if question.is_a? ScoredQuestion
question.weight = WEIGHT
question.max_label = LABEL_AGREE
question.min_label = LABEL_DISAGREE
end
question.size = SIZE_CRITERION if question.is_a? Criterion
question.alternatives = SIZE_ALT_DROPDOWN if question.is_a? Dropdown
question.size = SIZE_TXT_AREA if question.is_a? TextArea
question.size = SIZE_TXT_FIELD if question.is_a? TextField
</pre>
With our constants at the top of the code for easy accessibility:
<pre>
## Constants
# add_new_questions
LABEL_AGREE = 'Strongly agree' # label for scored question if agree
LABEL_DISAGREE = 'Strongly disagree' # label for scored question if disagree
WEIGHT = 1 # question weight
SIZE_CRITERION = '50, 3' # size of the question box if it's a criterion
SIZE_ALT_DROPDOWN = '0|1|2|3|4|5' # alternative to size if question is a dropdown
SIZE_TXT_AREA = '60, 5' # size of question box if text area
SIZE_TXT_FIELD = '30' # size of question box if text field
</pre>

====Unsafe Reflection====

'''Problem'''

Unsafe reflection method const_get called with parameter value

'''Solution'''

Remove the unsafe reflection through using a variable that checks for null values. We go from:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id,seq: i, type: params[:question][:type], break_before: true)
</pre>
To:
<pre>
question_type = params[:question][:type] unless params[:question][:type].nil?
question = Object.const_get(question_type).create(txt: '', questionnaire_id: questionnaire_id,seq: i, type: question_type, break_before: true)
</pre>

====Removed unnecessary method 'create_questionnaire'====

'''Problem'''

Method create_questionnaire, had no apparent calls to it. Aside from assigning a creator ID, it is similar in functionality to create, so we assume that the method was at some point created as a duplicate. We remove the method to make the code dry.

'''Solution'''

For example, we remove:
<pre>
def create_questionnaire
@questionnaire = Object.const_get(params[:questionnaire][:type]).new(questionnaire_params)
# Create Quiz content has been moved to Quiz Questionnaire Controller
if @questionnaire.type != "QuizQuestionnaire" # checking if it is a quiz questionnaire
@questionnaire.instructor_id = Ta.get_my_instructor(session[:user].id)
if session[:user].role.name == "Teaching Assistant"
save

redirect_to controller: 'tree_display', action: 'list'
end
end
</pre>

====Break up create method into new 'create_questionnaire'====

'''Problem'''

The create method itself was 49 lines long. This is too long to be viewable at a glance. Breaking it up into a second private method 'create_questionnaire' to handle attribute assigning and node creation.

'''Solution'''

For example, we go from:
def create
if params[:questionnaire][:name].blank?
flash[:error] = 'A rubric or survey must have a title.'
redirect_to controller: 'questionnaires', action: 'new', model: params[:questionnaire][:type], private: params[:questionnaire][:private]
else
questionnaire_private = params[:questionnaire][:private] == 'true'
display_type = params[:questionnaire][:type].split('Questionnaire')[0]
begin
@questionnaire = Object.const_get(params[:questionnaire][:type]).new if Questionnaire::QUESTIONNAIRE_TYPES.include? params[:questionnaire][:type]
rescue StandardError
flash[:error] = $ERROR_INFO
end
begin
@questionnaire.private = questionnaire_private
@questionnaire.name = params[:questionnaire][:name]
@questionnaire.instructor_id = session[:user].id
@questionnaire.min_question_score = params[:questionnaire][:min_question_score]
@questionnaire.max_question_score = params[:questionnaire][:max_question_score]
@questionnaire.type = params[:questionnaire][:type]
# Zhewei: Right now, the display_type in 'questionnaires' table and name in 'tree_folders' table are not consistent.
# In the future, we need to write migration files to make them consistency.
# E1903 : We are not sure of other type of cases, so have added a if statement. If there are only 5 cases, remove the if statement
if %w[AuthorFeedback CourseSurvey TeammateReview GlobalSurvey AssignmentSurvey].include?(display_type)
display_type = (display_type.split /(?=[A-Z])/).join("%")
end
@questionnaire.display_type = display_type
@questionnaire.instruction_loc = Questionnaire::DEFAULT_QUESTIONNAIRE_URL
@questionnaire.save
# Create node
tree_folder = TreeFolder.where(['name like ?', @questionnaire.display_type]).first
parent = FolderNode.find_by(node_object_id: tree_folder.id)
QuestionnaireNode.create(parent_id: parent.id, node_object_id: @questionnaire.id, type: 'QuestionnaireNode')
flash[:success] = 'You have successfully created a questionnaire!'
rescue StandardError
flash[:error] = $ERROR_INFO
end
redirect_to controller: 'questionnaires', action: 'edit', id: @questionnaire.id
end
end
To:
<pre>
def create
if params[:questionnaire][:name].blank?
flash[:error] = 'A rubric or survey must have a title.'
redirect_to controller: 'questionnaires', action: 'new', model: params[:questionnaire][:type], private: params[:questionnaire][:private]
else
questionnaire_private = params[:questionnaire][:private] == 'true'
display_type = params[:questionnaire][:type].split('Questionnaire')[0]
begin
@questionnaire = Object.const_get(params[:questionnaire][:type]).new if Questionnaire::QUESTIONNAIRE_TYPES.include? params[:questionnaire][:type]
rescue StandardError
flash[:error] = $ERROR_INFO
end
begin
create_questionnaire questionnaire_private, display_type
flash[:success] = 'You have successfully created a questionnaire!'
rescue StandardError
flash[:error] = $ERROR_INFO
end
redirect_to controller: 'questionnaires', action: 'edit', id: @questionnaire.id
end
end

def create_questions questionnaire_private, display_type
@questionnaire.private = questionnaire_private
@questionnaire.name = params[:questionnaire][:name]
@questionnaire.instructor_id = session[:user].id
@questionnaire.min_question_score = params[:questionnaire][:min_question_score]
@questionnaire.max_question_score = params[:questionnaire][:max_question_score]
@questionnaire.type = params[:questionnaire][:type]
# Zhewei: Right now, the display_type in 'questionnaires' table and name in 'tree_folders' table are not consistent.
# In the future, we need to write migration files to make them consistency.
# E1903 : We are not sure of other type of cases, so have added a if statement. If there are only 5 cases, remove the if statement
if %w[AuthorFeedback CourseSurvey TeammateReview GlobalSurvey AssignmentSurvey].include?(display_type)
display_type = (display_type.split /(?=[A-Z])/).join("%")
end
@questionnaire.display_type = display_type
@questionnaire.instruction_loc = Questionnaire::DEFAULT_QUESTIONNAIRE_URL
@questionnaire.save
tree_folder = TreeFolder.where(['name like ?', @questionnaire.display_type]).first
parent = FolderNode.find_by(node_object_id: tree_folder.id)
# Create node
QuestionnaireNode.create(parent_id: parent.id, node_object_id: @questionnaire.id, type: 'QuestionnaireNode')
end
</pre>

====Use each_key instead of keys.each====

'''Problem'''

The existing code uses keys.each to iterate through the hash. Keys.each is useful for modifying a hash, but in this implementation this is not necessary. So, each_key is used to improve performance timing.

'''Solution'''

For example, we go from:
<pre>
params[:new_question].keys.each do |question_key|
</pre>
To:
<pre>
params[:new_question].each_key do |question_key|
</pre>

====Split lines of code to fit within recommended 160 character length====

'''Problem'''

Some of the lines of code exceed the recommended 160 characters per line. To remediate, we simply split code across multiple lines and indent accordingly to maintain readability.

'''Solution'''

For example, we go from:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id, seq: i, type: params[:question][:type], break_before: true)
</pre>
To:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id,
seq: i, type: params[:question][:type], break_before: true)
</pre>

====Removed useless assignment of variable in save method====

'''Problem'''

The existing code included assignments of variables that were not used throughout the file. We assume that these variables were created to implement functionality that has since been removed through previous refactor attempts. In any case, we remove the variable keep the code dry.

'''Solution'''

For example, in the following method:
<pre>
def save
@questionnaire.save!

save_questions @questionnaire.id if !@questionnaire.id.nil? and @questionnaire.id > 0
# We do not create node for quiz questionnaires
if @questionnaire.type != "QuizQuestionnaire"
p_folder = TreeFolder.find_by(name: @questionnaire.display_type)
parent = FolderNode.find_by(node_object_id: p_folder.id)
# create_new_node_if_necessary(parent)
end
undo_link("Questionnaire \"#{@questionnaire.name}\" has been updated successfully. ")
end
</pre>
We remove the unnecessary variables and comments, resulting in the following method:
<pre>
def save
@questionnaire.save!
save_questions @questionnaire.id if !@questionnaire.id.nil? and @questionnaire.id > 0
undo_link("Questionnaire \"#{@questionnaire.name}\" has been updated successfully. ")
end
</pre>

=== Testing Plan ===
In order to evaluate the changes to Expertiza throughout the OSS project two different methods were used. The first being automatic testing using RSpec and the second being manual testing through accessing the Expertiza project on one's local machine. More in depth discussion of these tests can be found below.
====RSpec Testing====
In many cases the issues were resolved by editing a few lines of code within various methods without the need for additional methods. Thus, adding more test was not needed in these cases. However, in order to ensure the code edits didn't cause any previously crafted test to fail an RSpec test was ran before each commit. If and only if all test passed could the commit be pushed.

The command utilized to test the questionnaires controller is as follows:
<pre>
rspec spec/controllers/questionnaires_controller_spec.rb
</pre>
However, if a VCL was utilized for development this following command was used instead.
<pre>
rspec /home/[UNITYID]/expertiza/spec/controllers/questionnaires_controller_spec.rb
</pre>

In one case the create_questionnaire method was removed, thus in order to keep the set of tests clean the following test block was removed from the testing file:
<pre>
describe '#create_questionnaire and #save' do
context 'when quiz is valid' do
before(:each) do
# create_quiz_questionnaire
allow_any_instance_of(QuestionnairesController).to receive(:valid_quiz).and_return('valid')
end

context 'when questionnaire type is not QuizQuestionnaire' do
it 'redirects to submitted_content#edit page' do
params = {aid: 1,
pid: 1,
questionnaire: {name: 'Test questionnaire',
type: 'ReviewQuestionnaire'}}
# create_questionnaire
allow(ReviewQuestionnaire).to receive(:new).with(any_args).and_return(review_questionnaire)
session = {user: build(:teaching_assistant, id: 1)}
allow(Ta).to receive(:get_my_instructor).with(1).and_return(6)
# save
allow(TreeFolder).to receive(:find_by).with(name: 'Review').and_return(double('TreeFolder', id: 1))
allow(FolderNode).to receive(:find_by).with(node_object_id: 1).and_return(double('FolderNode'))
allow_any_instance_of(QuestionnairesController).to receive(:undo_link).with(any_args).and_return('')
post :create_questionnaire, params, session
expect(flash[:note]).to be nil
expect(response).to redirect_to('/tree_display/list')
expect(controller.instance_variable_get(:@questionnaire).private).to eq false
expect(controller.instance_variable_get(:@questionnaire).name).to eq 'Test questionnaire'
expect(controller.instance_variable_get(:@questionnaire).min_question_score).to eq 0
expect(controller.instance_variable_get(:@questionnaire).max_question_score).to eq 5
expect(controller.instance_variable_get(:@questionnaire).type).to eq 'ReviewQuestionnaire'
expect(controller.instance_variable_get(:@questionnaire).instructor_id).to eq 6
end
end
end
end
</pre>

====Manual Testing====
Manual testing was performed by running Expertiza on the local machine and creating the various types of questionnaires (i.e. rubrics, quizzes, and surveys) in the various locations they occurred albeit non-exhaustively . If a questionnaire was created and could be updated without throwing an error it was determined that the refactoring on the questionnaires controller had succeeded. This process was performed and confirmed by all team members in order to ensure accuracy.

===References===
*Code Refactoring Best Practices[https://www.altexsoft.com/blog/engineering/code-refactoring-best-practices-when-and-when-not-to-do-it/]
*Expertiza on Github[https://github.com/expertiza/expertiza]
*Expertiza Project Fork[https://github.com/Sattlert2/expertiza/tree/master]
*Expertiza Website[https://expertiza.ncsu.edu/]
*RSpec Documentation[https://relishapp.com/rspec]

CSC/ECE 517 Spring 2020 / E2001 Refactor Questionnaires Controller

2020-03-23T19:03:19Z

Tsattle: /* Database */

== E2000 Refactor questionnaires_controller.rb ==
This page provides a description of the Expertiza based OSS project
__TOC__
===About Expertiza===
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

=== Problem Statement ===
'''Background:''' In Expertiza, Questionnaire is a super-class utilized by all questionnaires, including rubrics, quizzes, and surveys. Rubrics are used to assess things such as project submissions and project teammates. All of the above-mentioned questionnaires are sub-classes of the Questionnaire super-class. Since this super-class is used in a multitude of locations ensuring that there are no issues in the code is very important since an error can cause malfunctions throughout Expertiza.

'''Problem:''' Questionnaires controller has been refactored repeatedly over the past few years, yet some improvements can still be made through refactoring to increase the quality and dryness of the code.

These problems are as follows:
* Unsafe reflection method const_get called with parameter value
* Hardwired variables in add_new_questions and save_new_questions
* Unnecessary checks for QuizQuestionnaire, checks can be removed
* Use guard clause to enclose methods instead of conditional
* Removed unnecessary method 'create_questionnaire'
* Break up create method into new 'create_questionnaire'
* Use each_key instead of keys.each
* Split lines of code to fit within recommended 160 character length
* Removed useless assignment of variable in save method
* Resolved issues involving use of unsafe reflection

=== Files Modified in Project ===
#app/controllers/questionnaires_controller.rb
#spec/controllers/questionnaires_controller_spec.rb

=== Issues and Improvements ===
====Use guard clause====

'''Problem'''

Method(s) save_new_questions, delete, and save_questions used conditional to wrap code instead of guard clause. Using guard clause can reduce complexity and number of lines in code.

'''Solution'''

For example, we go from:
<pre>
def save_new_questions(questionnaire_id)
if params[:new_question]
</pre>
To:
<pre>
def save_new_questions(questionnaire_id)
return unless params[:new_question]
</pre>

====QuizQuestionnaire checks====

'''Problem'''

Method(s) create and save_new_questions have unnecessary checks for if question type is QuizQuestionnaire.

'''Solution'''

We removed the check in both methods. We go from:
<pre>
if @questionnaire.type == "QuizQuestionnaire"
q.weight = 1 # setting the weight to 1 for quiz questionnaire since the model validates this field
end
</pre>

To:
<pre>
q.weight = 1
</pre>

====Hardwired Variables====

'''Problem'''

Method(s) save_new_questions and add_new_questions used hardwired variables. When applicable all values used should be stored as variables so the user knows the purpose of the variable, if that value is used in multiple areas it can be changed with a single change, and it's just messy. For instance both add_new_questions and save_new_questions used the same scalar value 1 for a similar task. We go from:
<pre>
if question.is_a? ScoredQuestion
question.weight = 1
question.max_label = 'Strongly agree'
question.min_label = 'Strongly disagree'
end
question.size = '50, 3' if question.is_a? Criterion
question.alternatives = '0|1|2|3|4|5' if question.is_a? Dropdown
question.size = '60, 5' if question.is_a? TextArea
question.size = '30' if question.is_a? TextField
</pre>
To our code which incorporates constants.
<pre>
if question.is_a? ScoredQuestion
question.weight = WEIGHT
question.max_label = LABEL_AGREE
question.min_label = LABEL_DISAGREE
end
question.size = SIZE_CRITERION if question.is_a? Criterion
question.alternatives = SIZE_ALT_DROPDOWN if question.is_a? Dropdown
question.size = SIZE_TXT_AREA if question.is_a? TextArea
question.size = SIZE_TXT_FIELD if question.is_a? TextField
</pre>
With our constants at the top of the code for easy accessibility:
<pre>
## Constants
# add_new_questions
LABEL_AGREE = 'Strongly agree' # label for scored question if agree
LABEL_DISAGREE = 'Strongly disagree' # label for scored question if disagree
WEIGHT = 1 # question weight
SIZE_CRITERION = '50, 3' # size of the question box if it's a criterion
SIZE_ALT_DROPDOWN = '0|1|2|3|4|5' # alternative to size if question is a dropdown
SIZE_TXT_AREA = '60, 5' # size of question box if text area
SIZE_TXT_FIELD = '30' # size of question box if text field
</pre>

====Unsafe Reflection====

'''Problem'''

Unsafe reflection method const_get called with parameter value

'''Solution'''

Remove the unsafe reflection through using a variable that checks for null values. We go from:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id,seq: i, type: params[:question][:type], break_before: true)
</pre>
To:
<pre>
question_type = params[:question][:type] unless params[:question][:type].nil?
question = Object.const_get(question_type).create(txt: '', questionnaire_id: questionnaire_id,seq: i, type: question_type, break_before: true)
</pre>

====Removed unnecessary method 'create_questionnaire'====

'''Problem'''

Method create_questionnaire, had no apparent calls to it. Aside from assigning a creator ID, it is similar in functionality to create, so we assume that the method was at some point created as a duplicate. We remove the method to make the code dry.

'''Solution'''

For example, we remove:
<pre>
def create_questionnaire
@questionnaire = Object.const_get(params[:questionnaire][:type]).new(questionnaire_params)
# Create Quiz content has been moved to Quiz Questionnaire Controller
if @questionnaire.type != "QuizQuestionnaire" # checking if it is a quiz questionnaire
@questionnaire.instructor_id = Ta.get_my_instructor(session[:user].id)
if session[:user].role.name == "Teaching Assistant"
save

redirect_to controller: 'tree_display', action: 'list'
end
end
</pre>

====Break up create method into new 'create_questionnaire'====

'''Problem'''

The create method itself was 49 lines long. This is too long to be viewable at a glance. Breaking it up into a second private method 'create_questionnaire' to handle attribute assigning and node creation.

'''Solution'''

For example, we go from:
def create
if params[:questionnaire][:name].blank?
flash[:error] = 'A rubric or survey must have a title.'
redirect_to controller: 'questionnaires', action: 'new', model: params[:questionnaire][:type], private: params[:questionnaire][:private]
else
questionnaire_private = params[:questionnaire][:private] == 'true'
display_type = params[:questionnaire][:type].split('Questionnaire')[0]
begin
@questionnaire = Object.const_get(params[:questionnaire][:type]).new if Questionnaire::QUESTIONNAIRE_TYPES.include? params[:questionnaire][:type]
rescue StandardError
flash[:error] = $ERROR_INFO
end
begin
@questionnaire.private = questionnaire_private
@questionnaire.name = params[:questionnaire][:name]
@questionnaire.instructor_id = session[:user].id
@questionnaire.min_question_score = params[:questionnaire][:min_question_score]
@questionnaire.max_question_score = params[:questionnaire][:max_question_score]
@questionnaire.type = params[:questionnaire][:type]
# Zhewei: Right now, the display_type in 'questionnaires' table and name in 'tree_folders' table are not consistent.
# In the future, we need to write migration files to make them consistency.
# E1903 : We are not sure of other type of cases, so have added a if statement. If there are only 5 cases, remove the if statement
if %w[AuthorFeedback CourseSurvey TeammateReview GlobalSurvey AssignmentSurvey].include?(display_type)
display_type = (display_type.split /(?=[A-Z])/).join("%")
end
@questionnaire.display_type = display_type
@questionnaire.instruction_loc = Questionnaire::DEFAULT_QUESTIONNAIRE_URL
@questionnaire.save
# Create node
tree_folder = TreeFolder.where(['name like ?', @questionnaire.display_type]).first
parent = FolderNode.find_by(node_object_id: tree_folder.id)
QuestionnaireNode.create(parent_id: parent.id, node_object_id: @questionnaire.id, type: 'QuestionnaireNode')
flash[:success] = 'You have successfully created a questionnaire!'
rescue StandardError
flash[:error] = $ERROR_INFO
end
redirect_to controller: 'questionnaires', action: 'edit', id: @questionnaire.id
end
end
To:
<pre>
def create
if params[:questionnaire][:name].blank?
flash[:error] = 'A rubric or survey must have a title.'
redirect_to controller: 'questionnaires', action: 'new', model: params[:questionnaire][:type], private: params[:questionnaire][:private]
else
questionnaire_private = params[:questionnaire][:private] == 'true'
display_type = params[:questionnaire][:type].split('Questionnaire')[0]
begin
@questionnaire = Object.const_get(params[:questionnaire][:type]).new if Questionnaire::QUESTIONNAIRE_TYPES.include? params[:questionnaire][:type]
rescue StandardError
flash[:error] = $ERROR_INFO
end
begin
create_questionnaire questionnaire_private, display_type
flash[:success] = 'You have successfully created a questionnaire!'
rescue StandardError
flash[:error] = $ERROR_INFO
end
redirect_to controller: 'questionnaires', action: 'edit', id: @questionnaire.id
end
end

def create_questions questionnaire_private, display_type
@questionnaire.private = questionnaire_private
@questionnaire.name = params[:questionnaire][:name]
@questionnaire.instructor_id = session[:user].id
@questionnaire.min_question_score = params[:questionnaire][:min_question_score]
@questionnaire.max_question_score = params[:questionnaire][:max_question_score]
@questionnaire.type = params[:questionnaire][:type]
# Zhewei: Right now, the display_type in 'questionnaires' table and name in 'tree_folders' table are not consistent.
# In the future, we need to write migration files to make them consistency.
# E1903 : We are not sure of other type of cases, so have added a if statement. If there are only 5 cases, remove the if statement
if %w[AuthorFeedback CourseSurvey TeammateReview GlobalSurvey AssignmentSurvey].include?(display_type)
display_type = (display_type.split /(?=[A-Z])/).join("%")
end
@questionnaire.display_type = display_type
@questionnaire.instruction_loc = Questionnaire::DEFAULT_QUESTIONNAIRE_URL
@questionnaire.save
tree_folder = TreeFolder.where(['name like ?', @questionnaire.display_type]).first
parent = FolderNode.find_by(node_object_id: tree_folder.id)
# Create node
QuestionnaireNode.create(parent_id: parent.id, node_object_id: @questionnaire.id, type: 'QuestionnaireNode')
end
</pre>

====Use each_key instead of keys.each====

'''Problem'''

The existing code uses keys.each to iterate through the hash. Keys.each is useful for modifying a hash, but in this implementation this is not necessary. So, each_key is used to improve performance timing.

'''Solution'''

For example, we go from:
<pre>
params[:new_question].keys.each do |question_key|
</pre>
To:
<pre>
params[:new_question].each_key do |question_key|
</pre>

====Split lines of code to fit within recommended 160 character length====

'''Problem'''

Some of the lines of code exceed the recommended 160 characters per line. To remediate, we simply split code across multiple lines and indent accordingly to maintain readability.

'''Solution'''

For example, we go from:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id, seq: i, type: params[:question][:type], break_before: true)
</pre>
To:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id,
seq: i, type: params[:question][:type], break_before: true)
</pre>

====Removed useless assignment of variable in save method====

'''Problem'''

The existing code included assignments of variables that were not used throughout the file. We assume that these variables were created to implement functionality that has since been removed through previous refactor attempts. In any case, we remove the variable keep the code dry.

'''Solution'''

For example, in the following method:
<pre>
def save
@questionnaire.save!

save_questions @questionnaire.id if !@questionnaire.id.nil? and @questionnaire.id > 0
# We do not create node for quiz questionnaires
if @questionnaire.type != "QuizQuestionnaire"
p_folder = TreeFolder.find_by(name: @questionnaire.display_type)
parent = FolderNode.find_by(node_object_id: p_folder.id)
# create_new_node_if_necessary(parent)
end
undo_link("Questionnaire \"#{@questionnaire.name}\" has been updated successfully. ")
end
</pre>
We remove the unnecessary variables and comments, resulting in the following method:
<pre>
def save
@questionnaire.save!
save_questions @questionnaire.id if !@questionnaire.id.nil? and @questionnaire.id > 0
undo_link("Questionnaire \"#{@questionnaire.name}\" has been updated successfully. ")
end
</pre>

=== Testing Plan ===
In order to evaluate the changes to Expertiza throughout the OSS project two different methods were used. The first being automatic testing using RSpec and the second being manual testing through accessing the Expertiza project on one's local machine. More in depth discussion of these tests can be found below.
====RSpec Testing====
In many cases the issues were resolved by editing a few lines of code within various methods without the need for additional methods. Thus, adding more test was not needed in these cases. However, in order to ensure the code edits didn't cause any previously crafted test to fail an RSpec test was ran before each commit. If and only if all test passed could the commit be pushed.

The command utilized to test the questionnaires controller is as follows:
<pre>
rspec spec/controllers/questionnaires_controller_spec.rb
</pre>
However, if a VCL was utilized for development this following command was used instead.
<pre>
rspec /home/[UNITYID]/expertiza/spec/controllers/questionnaires_controller_spec.rb
</pre>

In one case the create_questionnaire method was removed, thus in order to keep the set of tests clean the following test block was removed from the testing file:
<pre>
describe '#create_questionnaire and #save' do
context 'when quiz is valid' do
before(:each) do
# create_quiz_questionnaire
allow_any_instance_of(QuestionnairesController).to receive(:valid_quiz).and_return('valid')
end

context 'when questionnaire type is not QuizQuestionnaire' do
it 'redirects to submitted_content#edit page' do
params = {aid: 1,
pid: 1,
questionnaire: {name: 'Test questionnaire',
type: 'ReviewQuestionnaire'}}
# create_questionnaire
allow(ReviewQuestionnaire).to receive(:new).with(any_args).and_return(review_questionnaire)
session = {user: build(:teaching_assistant, id: 1)}
allow(Ta).to receive(:get_my_instructor).with(1).and_return(6)
# save
allow(TreeFolder).to receive(:find_by).with(name: 'Review').and_return(double('TreeFolder', id: 1))
allow(FolderNode).to receive(:find_by).with(node_object_id: 1).and_return(double('FolderNode'))
allow_any_instance_of(QuestionnairesController).to receive(:undo_link).with(any_args).and_return('')
post :create_questionnaire, params, session
expect(flash[:note]).to be nil
expect(response).to redirect_to('/tree_display/list')
expect(controller.instance_variable_get(:@questionnaire).private).to eq false
expect(controller.instance_variable_get(:@questionnaire).name).to eq 'Test questionnaire'
expect(controller.instance_variable_get(:@questionnaire).min_question_score).to eq 0
expect(controller.instance_variable_get(:@questionnaire).max_question_score).to eq 5
expect(controller.instance_variable_get(:@questionnaire).type).to eq 'ReviewQuestionnaire'
expect(controller.instance_variable_get(:@questionnaire).instructor_id).to eq 6
end
end
end
end
</pre>

====Manual Testing====
Manual testing was performed by running Expertiza on the local machine and creating the various types of questionnaires (i.e. rubrics, quizzes, and surveys) in the various locations they occurred albeit non-exhaustively . If a questionnaire was created and could be updated without throwing an error it was determined that the refactoring on the questionnaires controller had succeeded. This process was performed and confirmed by all team members in order to ensure accuracy.

===Database===
Left Blank intentionally
[[File:Db_relationship.png]]

===References===
*Code Refactoring Best Practices[https://www.altexsoft.com/blog/engineering/code-refactoring-best-practices-when-and-when-not-to-do-it/]
*Expertiza on Github[https://github.com/expertiza/expertiza]
*Expertiza Project Fork[https://github.com/Sattlert2/expertiza/tree/master]
*Expertiza Website[https://expertiza.ncsu.edu/]
*RSpec Documentation[https://relishapp.com/rspec]

File:Db relationship.png

2020-03-23T19:02:19Z

Tsattle: Relationship of the questionnaire database with other databases.

Relationship of the questionnaire database with other databases.

CSC/ECE 517 Spring 2020 / E2001 Refactor Questionnaires Controller

2020-03-23T18:59:35Z

Tsattle: /* E2000 Refactor questionnaires_controller.rb */

== E2000 Refactor questionnaires_controller.rb ==
This page provides a description of the Expertiza based OSS project
__TOC__
===About Expertiza===
Expertiza is an open source software project created using Ruby on Rails. Expertiza allows instructors to craft new assignments and edit existing ones. This flexibility ensures that each round of students gets an experience that is appropriate to the given situation. It also allows the instructor to create a list of project options and have the students bid for their favorite project.

While their are a plethora of benefits for instructors, students also gain some benefits when using Expertiza. They are able to form teams and keep track of the past peers they have worked with, and are also able to manage the progress and submission of their assignments.

=== Problem Statement ===
'''Background:''' In Expertiza, Questionnaire is a super-class utilized by all questionnaires, including rubrics, quizzes, and surveys. Rubrics are used to assess things such as project submissions and project teammates. All of the above-mentioned questionnaires are sub-classes of the Questionnaire super-class. Since this super-class is used in a multitude of locations ensuring that there are no issues in the code is very important since an error can cause malfunctions throughout Expertiza.

'''Problem:''' Questionnaires controller has been refactored repeatedly over the past few years, yet some improvements can still be made through refactoring to increase the quality and dryness of the code.

These problems are as follows:
* Unsafe reflection method const_get called with parameter value
* Hardwired variables in add_new_questions and save_new_questions
* Unnecessary checks for QuizQuestionnaire, checks can be removed
* Use guard clause to enclose methods instead of conditional
* Removed unnecessary method 'create_questionnaire'
* Break up create method into new 'create_questionnaire'
* Use each_key instead of keys.each
* Split lines of code to fit within recommended 160 character length
* Removed useless assignment of variable in save method
* Resolved issues involving use of unsafe reflection

=== Files Modified in Project ===
#app/controllers/questionnaires_controller.rb
#spec/controllers/questionnaires_controller_spec.rb

=== Issues and Improvements ===
====Use guard clause====

'''Problem'''

Method(s) save_new_questions, delete, and save_questions used conditional to wrap code instead of guard clause. Using guard clause can reduce complexity and number of lines in code.

'''Solution'''

For example, we go from:
<pre>
def save_new_questions(questionnaire_id)
if params[:new_question]
</pre>
To:
<pre>
def save_new_questions(questionnaire_id)
return unless params[:new_question]
</pre>

====QuizQuestionnaire checks====

'''Problem'''

Method(s) create and save_new_questions have unnecessary checks for if question type is QuizQuestionnaire.

'''Solution'''

We removed the check in both methods. We go from:
<pre>
if @questionnaire.type == "QuizQuestionnaire"
q.weight = 1 # setting the weight to 1 for quiz questionnaire since the model validates this field
end
</pre>

To:
<pre>
q.weight = 1
</pre>

====Hardwired Variables====

'''Problem'''

Method(s) save_new_questions and add_new_questions used hardwired variables. When applicable all values used should be stored as variables so the user knows the purpose of the variable, if that value is used in multiple areas it can be changed with a single change, and it's just messy. For instance both add_new_questions and save_new_questions used the same scalar value 1 for a similar task. We go from:
<pre>
if question.is_a? ScoredQuestion
question.weight = 1
question.max_label = 'Strongly agree'
question.min_label = 'Strongly disagree'
end
question.size = '50, 3' if question.is_a? Criterion
question.alternatives = '0|1|2|3|4|5' if question.is_a? Dropdown
question.size = '60, 5' if question.is_a? TextArea
question.size = '30' if question.is_a? TextField
</pre>
To our code which incorporates constants.
<pre>
if question.is_a? ScoredQuestion
question.weight = WEIGHT
question.max_label = LABEL_AGREE
question.min_label = LABEL_DISAGREE
end
question.size = SIZE_CRITERION if question.is_a? Criterion
question.alternatives = SIZE_ALT_DROPDOWN if question.is_a? Dropdown
question.size = SIZE_TXT_AREA if question.is_a? TextArea
question.size = SIZE_TXT_FIELD if question.is_a? TextField
</pre>
With our constants at the top of the code for easy accessibility:
<pre>
## Constants
# add_new_questions
LABEL_AGREE = 'Strongly agree' # label for scored question if agree
LABEL_DISAGREE = 'Strongly disagree' # label for scored question if disagree
WEIGHT = 1 # question weight
SIZE_CRITERION = '50, 3' # size of the question box if it's a criterion
SIZE_ALT_DROPDOWN = '0|1|2|3|4|5' # alternative to size if question is a dropdown
SIZE_TXT_AREA = '60, 5' # size of question box if text area
SIZE_TXT_FIELD = '30' # size of question box if text field
</pre>

====Unsafe Reflection====

'''Problem'''

Unsafe reflection method const_get called with parameter value

'''Solution'''

Remove the unsafe reflection through using a variable that checks for null values. We go from:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id,seq: i, type: params[:question][:type], break_before: true)
</pre>
To:
<pre>
question_type = params[:question][:type] unless params[:question][:type].nil?
question = Object.const_get(question_type).create(txt: '', questionnaire_id: questionnaire_id,seq: i, type: question_type, break_before: true)
</pre>

====Removed unnecessary method 'create_questionnaire'====

'''Problem'''

Method create_questionnaire, had no apparent calls to it. Aside from assigning a creator ID, it is similar in functionality to create, so we assume that the method was at some point created as a duplicate. We remove the method to make the code dry.

'''Solution'''

For example, we remove:
<pre>
def create_questionnaire
@questionnaire = Object.const_get(params[:questionnaire][:type]).new(questionnaire_params)
# Create Quiz content has been moved to Quiz Questionnaire Controller
if @questionnaire.type != "QuizQuestionnaire" # checking if it is a quiz questionnaire
@questionnaire.instructor_id = Ta.get_my_instructor(session[:user].id)
if session[:user].role.name == "Teaching Assistant"
save

redirect_to controller: 'tree_display', action: 'list'
end
end
</pre>

====Break up create method into new 'create_questionnaire'====

'''Problem'''

The create method itself was 49 lines long. This is too long to be viewable at a glance. Breaking it up into a second private method 'create_questionnaire' to handle attribute assigning and node creation.

'''Solution'''

For example, we go from:
def create
if params[:questionnaire][:name].blank?
flash[:error] = 'A rubric or survey must have a title.'
redirect_to controller: 'questionnaires', action: 'new', model: params[:questionnaire][:type], private: params[:questionnaire][:private]
else
questionnaire_private = params[:questionnaire][:private] == 'true'
display_type = params[:questionnaire][:type].split('Questionnaire')[0]
begin
@questionnaire = Object.const_get(params[:questionnaire][:type]).new if Questionnaire::QUESTIONNAIRE_TYPES.include? params[:questionnaire][:type]
rescue StandardError
flash[:error] = $ERROR_INFO
end
begin
@questionnaire.private = questionnaire_private
@questionnaire.name = params[:questionnaire][:name]
@questionnaire.instructor_id = session[:user].id
@questionnaire.min_question_score = params[:questionnaire][:min_question_score]
@questionnaire.max_question_score = params[:questionnaire][:max_question_score]
@questionnaire.type = params[:questionnaire][:type]
# Zhewei: Right now, the display_type in 'questionnaires' table and name in 'tree_folders' table are not consistent.
# In the future, we need to write migration files to make them consistency.
# E1903 : We are not sure of other type of cases, so have added a if statement. If there are only 5 cases, remove the if statement
if %w[AuthorFeedback CourseSurvey TeammateReview GlobalSurvey AssignmentSurvey].include?(display_type)
display_type = (display_type.split /(?=[A-Z])/).join("%")
end
@questionnaire.display_type = display_type
@questionnaire.instruction_loc = Questionnaire::DEFAULT_QUESTIONNAIRE_URL
@questionnaire.save
# Create node
tree_folder = TreeFolder.where(['name like ?', @questionnaire.display_type]).first
parent = FolderNode.find_by(node_object_id: tree_folder.id)
QuestionnaireNode.create(parent_id: parent.id, node_object_id: @questionnaire.id, type: 'QuestionnaireNode')
flash[:success] = 'You have successfully created a questionnaire!'
rescue StandardError
flash[:error] = $ERROR_INFO
end
redirect_to controller: 'questionnaires', action: 'edit', id: @questionnaire.id
end
end
To:
<pre>
def create
if params[:questionnaire][:name].blank?
flash[:error] = 'A rubric or survey must have a title.'
redirect_to controller: 'questionnaires', action: 'new', model: params[:questionnaire][:type], private: params[:questionnaire][:private]
else
questionnaire_private = params[:questionnaire][:private] == 'true'
display_type = params[:questionnaire][:type].split('Questionnaire')[0]
begin
@questionnaire = Object.const_get(params[:questionnaire][:type]).new if Questionnaire::QUESTIONNAIRE_TYPES.include? params[:questionnaire][:type]
rescue StandardError
flash[:error] = $ERROR_INFO
end
begin
create_questionnaire questionnaire_private, display_type
flash[:success] = 'You have successfully created a questionnaire!'
rescue StandardError
flash[:error] = $ERROR_INFO
end
redirect_to controller: 'questionnaires', action: 'edit', id: @questionnaire.id
end
end

def create_questions questionnaire_private, display_type
@questionnaire.private = questionnaire_private
@questionnaire.name = params[:questionnaire][:name]
@questionnaire.instructor_id = session[:user].id
@questionnaire.min_question_score = params[:questionnaire][:min_question_score]
@questionnaire.max_question_score = params[:questionnaire][:max_question_score]
@questionnaire.type = params[:questionnaire][:type]
# Zhewei: Right now, the display_type in 'questionnaires' table and name in 'tree_folders' table are not consistent.
# In the future, we need to write migration files to make them consistency.
# E1903 : We are not sure of other type of cases, so have added a if statement. If there are only 5 cases, remove the if statement
if %w[AuthorFeedback CourseSurvey TeammateReview GlobalSurvey AssignmentSurvey].include?(display_type)
display_type = (display_type.split /(?=[A-Z])/).join("%")
end
@questionnaire.display_type = display_type
@questionnaire.instruction_loc = Questionnaire::DEFAULT_QUESTIONNAIRE_URL
@questionnaire.save
tree_folder = TreeFolder.where(['name like ?', @questionnaire.display_type]).first
parent = FolderNode.find_by(node_object_id: tree_folder.id)
# Create node
QuestionnaireNode.create(parent_id: parent.id, node_object_id: @questionnaire.id, type: 'QuestionnaireNode')
end
</pre>

====Use each_key instead of keys.each====

'''Problem'''

The existing code uses keys.each to iterate through the hash. Keys.each is useful for modifying a hash, but in this implementation this is not necessary. So, each_key is used to improve performance timing.

'''Solution'''

For example, we go from:
<pre>
params[:new_question].keys.each do |question_key|
</pre>
To:
<pre>
params[:new_question].each_key do |question_key|
</pre>

====Split lines of code to fit within recommended 160 character length====

'''Problem'''

Some of the lines of code exceed the recommended 160 characters per line. To remediate, we simply split code across multiple lines and indent accordingly to maintain readability.

'''Solution'''

For example, we go from:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id, seq: i, type: params[:question][:type], break_before: true)
</pre>
To:
<pre>
question = Object.const_get(params[:question][:type]).create(txt: '', questionnaire_id: questionnaire_id,
seq: i, type: params[:question][:type], break_before: true)
</pre>

====Removed useless assignment of variable in save method====

'''Problem'''

The existing code included assignments of variables that were not used throughout the file. We assume that these variables were created to implement functionality that has since been removed through previous refactor attempts. In any case, we remove the variable keep the code dry.

'''Solution'''

For example, in the following method:
<pre>
def save
@questionnaire.save!

save_questions @questionnaire.id if !@questionnaire.id.nil? and @questionnaire.id > 0
# We do not create node for quiz questionnaires
if @questionnaire.type != "QuizQuestionnaire"
p_folder = TreeFolder.find_by(name: @questionnaire.display_type)
parent = FolderNode.find_by(node_object_id: p_folder.id)
# create_new_node_if_necessary(parent)
end
undo_link("Questionnaire \"#{@questionnaire.name}\" has been updated successfully. ")
end
</pre>
We remove the unnecessary variables and comments, resulting in the following method:
<pre>
def save
@questionnaire.save!
save_questions @questionnaire.id if !@questionnaire.id.nil? and @questionnaire.id > 0
undo_link("Questionnaire \"#{@questionnaire.name}\" has been updated successfully. ")
end
</pre>

=== Testing Plan ===
In order to evaluate the changes to Expertiza throughout the OSS project two different methods were used. The first being automatic testing using RSpec and the second being manual testing through accessing the Expertiza project on one's local machine. More in depth discussion of these tests can be found below.
====RSpec Testing====
In many cases the issues were resolved by editing a few lines of code within various methods without the need for additional methods. Thus, adding more test was not needed in these cases. However, in order to ensure the code edits didn't cause any previously crafted test to fail an RSpec test was ran before each commit. If and only if all test passed could the commit be pushed.

The command utilized to test the questionnaires controller is as follows:
<pre>
rspec spec/controllers/questionnaires_controller_spec.rb
</pre>
However, if a VCL was utilized for development this following command was used instead.
<pre>
rspec /home/[UNITYID]/expertiza/spec/controllers/questionnaires_controller_spec.rb
</pre>

In one case the create_questionnaire method was removed, thus in order to keep the set of tests clean the following test block was removed from the testing file:
<pre>
describe '#create_questionnaire and #save' do
context 'when quiz is valid' do
before(:each) do
# create_quiz_questionnaire
allow_any_instance_of(QuestionnairesController).to receive(:valid_quiz).and_return('valid')
end

context 'when questionnaire type is not QuizQuestionnaire' do
it 'redirects to submitted_content#edit page' do
params = {aid: 1,
pid: 1,
questionnaire: {name: 'Test questionnaire',
type: 'ReviewQuestionnaire'}}
# create_questionnaire
allow(ReviewQuestionnaire).to receive(:new).with(any_args).and_return(review_questionnaire)
session = {user: build(:teaching_assistant, id: 1)}
allow(Ta).to receive(:get_my_instructor).with(1).and_return(6)
# save
allow(TreeFolder).to receive(:find_by).with(name: 'Review').and_return(double('TreeFolder', id: 1))
allow(FolderNode).to receive(:find_by).with(node_object_id: 1).and_return(double('FolderNode'))
allow_any_instance_of(QuestionnairesController).to receive(:undo_link).with(any_args).and_return('')
post :create_questionnaire, params, session
expect(flash[:note]).to be nil
expect(response).to redirect_to('/tree_display/list')
expect(controller.instance_variable_get(:@questionnaire).private).to eq false
expect(controller.instance_variable_get(:@questionnaire).name).to eq 'Test questionnaire'
expect(controller.instance_variable_get(:@questionnaire).min_question_score).to eq 0
expect(controller.instance_variable_get(:@questionnaire).max_question_score).to eq 5
expect(controller.instance_variable_get(:@questionnaire).type).to eq 'ReviewQuestionnaire'
expect(controller.instance_variable_get(:@questionnaire).instructor_id).to eq 6
end
end
end
end
</pre>

====Manual Testing====
Manual testing was performed by running Expertiza on the local machine and creating the various types of questionnaires (i.e. rubrics, quizzes, and surveys) in the various locations they occurred albeit non-exhaustively . If a questionnaire was created and could be updated without throwing an error it was determined that the refactoring on the questionnaires controller had succeeded. This process was performed and confirmed by all team members in order to ensure accuracy.

===Database===
Left Blank intentionally

===References===
*Code Refactoring Best Practices[https://www.altexsoft.com/blog/engineering/code-refactoring-best-practices-when-and-when-not-to-do-it/]
*Expertiza on Github[https://github.com/expertiza/expertiza]
*Expertiza Project Fork[https://github.com/Sattlert2/expertiza/tree/master]
*Expertiza Website[https://expertiza.ncsu.edu/]
*RSpec Documentation[https://relishapp.com/rspec]