Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2023 - E2383. Grading Audit Trail

2023-12-05T06:00:03Z

Ausem: /* Scenario 2: Grading histories of reviews */

=='''Introduction'''==

===Problem Statement===
In the current implementation of expertiza, any instructor can assign or edit a grade but there is no way to track who gave the grade and when.

A grading audit trail must be created and the following information needs to be stored:

1. When a grade is assigned by an instructor, there needs to be an indication of who did it and when it was done.
2. Comments previously provided by other instructors must also be preserved.
This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

Currently, there are two places need to add grading audit trail:

1. Review grade: Log in as instructor -> Manage -> Assignments -> View Review Report
2. Submission grade: Log in as instructor -> Manage -> Assignments -> View submissions
The grading audit trail can probably be implemented as the submission records history on Expertiza. The required page can be reached by logging in as instructor -> Manage -> Assignments -> View Submissions -> History

At the minimum, a grading log entry must include the instructor id, assignment id, student id, grade, comment and timestamp.

Previous student teams have attempted to implement this functionality, but their implementations had issues. Our solution will build on the work of teams E1934 and E2237, addressing the problems in their implementations.

== '''Overview of Major Changes By Previous Teams''' ==
===[https://wiki-expertiza.csc.ncsu.edu/index.php/E1934_-_Grading_Audit_Trail E1934]===
[https://youtu.be/yyxX_kRYxLc Their Screencast]

*Created a database called grading_history to store elements for the Grading Audit Trail (instructor id, assignment id, grade tyoe, student id, grade, comment and timestamp)
*Used MVC design to create a model, a controller, and a view for both of Review Grade and Submission Grade. These will be the links used in the View Submissions view and View Review Report view so that the grading trail for an assignments submission and reviews are seperate.
*Modified grades controller, so that every time, a grade is submitted or edited, grading_history_controller.rb will call a method to create an entry that saves into the database.
'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

This is the design plan in which they followed:

[[File:E1869 Grading Audit Trails UML.jpg]]

===[https://wiki-expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2022_-_E2237:_Grading_audit_trail E2237]===

*They fixed some issues that were causing the system to crash during testing
*Altered the Grading History view
*Explained the reasoning for changes made to files using diagrams and justifications
'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

This is the updated design flow in which they created to improve previous implementations further:

[[File:Kai diagram1.jpg]]

=='''Proposed Solution'''==
We plan on using the implementation of E2237 since it is the latest in the Grading Audit Trail projects and has the latest in terms of testing. These files cannot be added haphazardly since parts of the implementation is a cause to concern and caused the changes to not be implemented. It is also using an older version of expertiza so some parts may not be compatible.

We must first figure out exactly what changes and issues to address in their implementation by meeting with our mentor. We also need to reimplement the following files since none of their changes were implemented:

*app/controllers/grading_histories_controller.rb
'''
Calls the grading history view after validating Submission and Review Type.

'''

*app/models/grading_history.rb
'''
Model for Grading History.
'''

*app/models/review_grading_history.rb

'''
Model containing specifics of Review Grading History. Inherits Grading History.
'''

*app/models/submission_grading_history.rb
'''
Model containing specifics of Submission Grading History. Inherits Grading History.
'''

*app/views/grading_history/index_html.erb
'''
This is a view for grading audit trail, it will display all grading histories of a
submission/review
'''

*spec/features/grade_histories_spec.rb

'''
Feature test to check if the grades appear in chronological order
'''

*spec/features/helpers/grade_histories_helper.rb

'''
Helper file to facilitate the above mentioned feature test.
'''

=='''Reimplementation'''==
Since the previous teams implementations were not integrated we have to reimplement their files which we will do by looking at their commits and pull request to see what files are necessary and what can be left out to address the issues of their implementation.

'''[https://github.com/ErikLG360/expertiza/commit/e28a857695549cc91c477587707e48100d2bd333 Files being Reimplemented/Modified]'''

'''Reimplemented'''
*app/controllers/grading_histories_controller.rb
'''
This file was added to deal with allowing only the correct people to view the grading history, checking the assignment type whether it be a submission or review, and indexing all the grading history for the assignment in chronological order.
'''
*app/models/grading_history.rb
'''
This file was added to create the relationships that the grading history has with an instructor who is creating the parts of the grading history and the assignments that will have a grading history.
'''
*app/models/review_grading_history.rb
'''
This file creates the relationship that a participant will have a Review Grading History
'''
*app/models/submission_grading_history.rb
'''
This file create the relationship that a participant/grade_reciever will have a Submission Grading History
'''

*app/views/grading_histories/index.html.erb
'''
This file contains the view for the grading history table which will change depending on if its a Review or submission type
'''
*app/views/grading_histories/_form.html.erb
'''
This file contains the view for when a grading history contains any error when it is about to be saved
'''

'''Modified'''
*app/controllers/grades_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_submission was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of submissions and not reviews.
'''
*app/controllers/review_mapping_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_reviewer was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of reviews and not submissions.
'''
*app/views/assignments/list_submissions.html.erb
'''
It was modified to add the new hyperlink to display the grading history of a submission.
'''
*config/routes.rb
'''
It was to add the new route for grading histories
'''

=='''Solutions - Implemented'''==

'''E1934'''

'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

'''Solutions'''
:1. Found the correct location to put the Review Grading History link and also fix the previous teams creation of a grading history to work with the latest expertiza update.
Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/controllers/review_mapping_controller.rb]
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/views/reports/_review_report.html.erb]

:2. The previous implementatation of E2237 tackled this problem and moved it to the title.
[[File:GradingTableTitle.png|1100px]]
:3. The column widths were lessened by about 15px in the grading record page

Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/124bd12d23f75db0a68e2fac8a8487c5f7a7ed67 app/views/grading_histories/index.html.erb]

:4. There were no code climate issues regarding this issue

:5. All code climate changes are their own commits such as [https://github.com/ErikLG360/expertiza/commit/e95656f4d5e4f2ba4fc8d3f40716673ccafb41b1 This]

:6. This issue was resolved by not adding in their implementation for the list_review_mapping.html.erb

:7. This issue was resolved by not adding in the review_report_html.erb file

:8. This issue is resolved in the '''Reimplementation''' section of this document

'''E2237'''

'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

'''Solutions'''
:1. These files have not been added.
:2. The authentication already used the necessary parts
:3. The column width was reduced by 15px refer to the solution for E1934 number 3.
:4. Code for the review_mapping_controller was changed to match the current state of expertiza refer to the solution for E1934 number 1.

=='''Resulting Views'''==
This is the view in the view submissions page that displays the link for the Submissions Grading History which is circled in red.
[[File:SubmissionsGradingHistoryLink.jpeg|1100px]]

This is the resulting view after clicking the link:
[[File:SubmissionGradingHist.png|1100px]]

This is the view in the review report page that displays the link for the Reviews Grading History which is circled in red.
[[File:ReviewGradingHistoryLink.jpeg|1100px]]

This is the resulting view after clicking the Reviews Grading History link:
[[File:ReviewsGradingHist.png|1100px]]

=='''Testing Plan'''==

=== Rspec Unit Tests ===

==== For History of the Grades ====
The history of the grade and comments are related to the new model grading_history.rb and the new controller grading_history_controller.rb.

So the related RSpec tests are planned to be executed:

spec/controllers/grading_history_controller_test.rb

For the feature part, test if the grading history and instructor can be shown in chronological order:

spec/features/grade_histories_spec.rb
spec/helpers/grade_histories_helper_spec.rb

The link to test files inorder to test the creation of grading history with valid parameters is https://github.com/expertiza/expertiza/commit/067b52315ac1ff7ce1b89fc44121393cadbabc6a

=== Manual UI Tests ===
To start the test, we need to log in as instructor or TA first. These accounts should have access to the assignment. For example: we can use '''intructor6/password'''

==== Scenario 1: Grading histories of submissions ====
Step 1. Log in as instructor -> Manage -> Assignments -> View submissions
 
 
[[File: E2383 1.png|1100px]]
 
 
 
Step 2. The instructor can assign grades to a team by clicking 'Assign Grade' in the 'Team name' column:
 
 
[[File:E2383 2.png|1100px]]
 
 
 
Step 3. The instructor can view the grading audit trail by clicking 'Grading History' in the 'History' column, here is the record page:
 
 
[[File:E2383 3.png|1100px]]
 
 

==== Scenario 2: Grading histories of reviews ====
Step 1. Log in as instructor -> Manage -> Assignments -> View Reports
 
[[File:E2383 4.png|1100px]]
 
 
Step 2. Select 'Review Report' then click 'View', here is the Review Report page. The instructor can assign grades to a review by inputing 'Grade' and 'Comment' then clicking 'Save' button:
 
 
[[File:E2383 5.png|1100px]]
 
 
Step 3. The instructor/TA can view the grading audit trail by clicking 'Grading History' as Step 2 figure shows, here is the record page:
 
 
[[File:E2383 6.png|1100px]]
 
 

=='''Future Scope'''==
This project may need further improvement since it does not seem like there should be an abundance of files added and perhaps using the MVC design is not necessarily needed. There can also be a reduction of code since the difference between the two main grading histories is just whether it is a review or submission type.

=='''Relevant Links'''==
* '''Github Repository:''' https://github.com/ErikLG360/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2696
* '''VCL Server (Valid until 12/15/23):''' http://152.7.179.44:8080
* '''Video:''' https://drive.google.com/file/d/1HIrJtCsbZXSqGPHShuV6mbSTOKvV5MxT/view?usp=drive_link

=='''Contributors to this project'''==
*Amulya Usem
*Erik Lopez-Godinez
*Gowtham Pollam

*'''Mentor''': Srilekha Gudipati

CSC/ECE 517 Fall 2023 - E2383. Grading Audit Trail

2023-12-05T05:59:47Z

Ausem: /* Scenario 1: Grading histories of submissions */

=='''Introduction'''==

===Problem Statement===
In the current implementation of expertiza, any instructor can assign or edit a grade but there is no way to track who gave the grade and when.

A grading audit trail must be created and the following information needs to be stored:

1. When a grade is assigned by an instructor, there needs to be an indication of who did it and when it was done.
2. Comments previously provided by other instructors must also be preserved.
This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

Currently, there are two places need to add grading audit trail:

1. Review grade: Log in as instructor -> Manage -> Assignments -> View Review Report
2. Submission grade: Log in as instructor -> Manage -> Assignments -> View submissions
The grading audit trail can probably be implemented as the submission records history on Expertiza. The required page can be reached by logging in as instructor -> Manage -> Assignments -> View Submissions -> History

At the minimum, a grading log entry must include the instructor id, assignment id, student id, grade, comment and timestamp.

Previous student teams have attempted to implement this functionality, but their implementations had issues. Our solution will build on the work of teams E1934 and E2237, addressing the problems in their implementations.

== '''Overview of Major Changes By Previous Teams''' ==
===[https://wiki-expertiza.csc.ncsu.edu/index.php/E1934_-_Grading_Audit_Trail E1934]===
[https://youtu.be/yyxX_kRYxLc Their Screencast]

*Created a database called grading_history to store elements for the Grading Audit Trail (instructor id, assignment id, grade tyoe, student id, grade, comment and timestamp)
*Used MVC design to create a model, a controller, and a view for both of Review Grade and Submission Grade. These will be the links used in the View Submissions view and View Review Report view so that the grading trail for an assignments submission and reviews are seperate.
*Modified grades controller, so that every time, a grade is submitted or edited, grading_history_controller.rb will call a method to create an entry that saves into the database.
'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

This is the design plan in which they followed:

[[File:E1869 Grading Audit Trails UML.jpg]]

===[https://wiki-expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2022_-_E2237:_Grading_audit_trail E2237]===

*They fixed some issues that were causing the system to crash during testing
*Altered the Grading History view
*Explained the reasoning for changes made to files using diagrams and justifications
'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

This is the updated design flow in which they created to improve previous implementations further:

[[File:Kai diagram1.jpg]]

=='''Proposed Solution'''==
We plan on using the implementation of E2237 since it is the latest in the Grading Audit Trail projects and has the latest in terms of testing. These files cannot be added haphazardly since parts of the implementation is a cause to concern and caused the changes to not be implemented. It is also using an older version of expertiza so some parts may not be compatible.

We must first figure out exactly what changes and issues to address in their implementation by meeting with our mentor. We also need to reimplement the following files since none of their changes were implemented:

*app/controllers/grading_histories_controller.rb
'''
Calls the grading history view after validating Submission and Review Type.

'''

*app/models/grading_history.rb
'''
Model for Grading History.
'''

*app/models/review_grading_history.rb

'''
Model containing specifics of Review Grading History. Inherits Grading History.
'''

*app/models/submission_grading_history.rb
'''
Model containing specifics of Submission Grading History. Inherits Grading History.
'''

*app/views/grading_history/index_html.erb
'''
This is a view for grading audit trail, it will display all grading histories of a
submission/review
'''

*spec/features/grade_histories_spec.rb

'''
Feature test to check if the grades appear in chronological order
'''

*spec/features/helpers/grade_histories_helper.rb

'''
Helper file to facilitate the above mentioned feature test.
'''

=='''Reimplementation'''==
Since the previous teams implementations were not integrated we have to reimplement their files which we will do by looking at their commits and pull request to see what files are necessary and what can be left out to address the issues of their implementation.

'''[https://github.com/ErikLG360/expertiza/commit/e28a857695549cc91c477587707e48100d2bd333 Files being Reimplemented/Modified]'''

'''Reimplemented'''
*app/controllers/grading_histories_controller.rb
'''
This file was added to deal with allowing only the correct people to view the grading history, checking the assignment type whether it be a submission or review, and indexing all the grading history for the assignment in chronological order.
'''
*app/models/grading_history.rb
'''
This file was added to create the relationships that the grading history has with an instructor who is creating the parts of the grading history and the assignments that will have a grading history.
'''
*app/models/review_grading_history.rb
'''
This file creates the relationship that a participant will have a Review Grading History
'''
*app/models/submission_grading_history.rb
'''
This file create the relationship that a participant/grade_reciever will have a Submission Grading History
'''

*app/views/grading_histories/index.html.erb
'''
This file contains the view for the grading history table which will change depending on if its a Review or submission type
'''
*app/views/grading_histories/_form.html.erb
'''
This file contains the view for when a grading history contains any error when it is about to be saved
'''

'''Modified'''
*app/controllers/grades_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_submission was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of submissions and not reviews.
'''
*app/controllers/review_mapping_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_reviewer was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of reviews and not submissions.
'''
*app/views/assignments/list_submissions.html.erb
'''
It was modified to add the new hyperlink to display the grading history of a submission.
'''
*config/routes.rb
'''
It was to add the new route for grading histories
'''

=='''Solutions - Implemented'''==

'''E1934'''

'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

'''Solutions'''
:1. Found the correct location to put the Review Grading History link and also fix the previous teams creation of a grading history to work with the latest expertiza update.
Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/controllers/review_mapping_controller.rb]
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/views/reports/_review_report.html.erb]

:2. The previous implementatation of E2237 tackled this problem and moved it to the title.
[[File:GradingTableTitle.png|1100px]]
:3. The column widths were lessened by about 15px in the grading record page

Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/124bd12d23f75db0a68e2fac8a8487c5f7a7ed67 app/views/grading_histories/index.html.erb]

:4. There were no code climate issues regarding this issue

:5. All code climate changes are their own commits such as [https://github.com/ErikLG360/expertiza/commit/e95656f4d5e4f2ba4fc8d3f40716673ccafb41b1 This]

:6. This issue was resolved by not adding in their implementation for the list_review_mapping.html.erb

:7. This issue was resolved by not adding in the review_report_html.erb file

:8. This issue is resolved in the '''Reimplementation''' section of this document

'''E2237'''

'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

'''Solutions'''
:1. These files have not been added.
:2. The authentication already used the necessary parts
:3. The column width was reduced by 15px refer to the solution for E1934 number 3.
:4. Code for the review_mapping_controller was changed to match the current state of expertiza refer to the solution for E1934 number 1.

=='''Resulting Views'''==
This is the view in the view submissions page that displays the link for the Submissions Grading History which is circled in red.
[[File:SubmissionsGradingHistoryLink.jpeg|1100px]]

This is the resulting view after clicking the link:
[[File:SubmissionGradingHist.png|1100px]]

This is the view in the review report page that displays the link for the Reviews Grading History which is circled in red.
[[File:ReviewGradingHistoryLink.jpeg|1100px]]

This is the resulting view after clicking the Reviews Grading History link:
[[File:ReviewsGradingHist.png|1100px]]

=='''Testing Plan'''==

=== Rspec Unit Tests ===

==== For History of the Grades ====
The history of the grade and comments are related to the new model grading_history.rb and the new controller grading_history_controller.rb.

So the related RSpec tests are planned to be executed:

spec/controllers/grading_history_controller_test.rb

For the feature part, test if the grading history and instructor can be shown in chronological order:

spec/features/grade_histories_spec.rb
spec/helpers/grade_histories_helper_spec.rb

The link to test files inorder to test the creation of grading history with valid parameters is https://github.com/expertiza/expertiza/commit/067b52315ac1ff7ce1b89fc44121393cadbabc6a

=== Manual UI Tests ===
To start the test, we need to log in as instructor or TA first. These accounts should have access to the assignment. For example: we can use '''intructor6/password'''

==== Scenario 1: Grading histories of submissions ====
Step 1. Log in as instructor -> Manage -> Assignments -> View submissions
 
 
[[File: E2383 1.png|1100px]]
 
 
 
Step 2. The instructor can assign grades to a team by clicking 'Assign Grade' in the 'Team name' column:
 
 
[[File:E2383 2.png|1100px]]
 
 
 
Step 3. The instructor can view the grading audit trail by clicking 'Grading History' in the 'History' column, here is the record page:
 
 
[[File:E2383 3.png|1100px]]
 
 

==== Scenario 2: Grading histories of reviews ====
Step 1. Log in as instructor -> Manage -> Assignments -> View Reports
 
[[File:E2383 4.png|1100px]]
 
 
Step 2. Select 'Review Report' then click 'View', here is the Review Report page. The instructor can assign grades to a review by inputing 'Grade' and 'Comment' then clicking 'Save' button:
 
[[File:E2383 5.png|1100px]]
 
 
Step 3. The instructor/TA can view the grading audit trail by clicking 'Grading History' as Step 2 figure shows, here is the record page:
 
[[File:E2383 6.png|1100px]]
 
 

=='''Future Scope'''==
This project may need further improvement since it does not seem like there should be an abundance of files added and perhaps using the MVC design is not necessarily needed. There can also be a reduction of code since the difference between the two main grading histories is just whether it is a review or submission type.

=='''Relevant Links'''==
* '''Github Repository:''' https://github.com/ErikLG360/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2696
* '''VCL Server (Valid until 12/15/23):''' http://152.7.179.44:8080
* '''Video:''' https://drive.google.com/file/d/1HIrJtCsbZXSqGPHShuV6mbSTOKvV5MxT/view?usp=drive_link

=='''Contributors to this project'''==
*Amulya Usem
*Erik Lopez-Godinez
*Gowtham Pollam

*'''Mentor''': Srilekha Gudipati

CSC/ECE 517 Fall 2023 - E2383. Grading Audit Trail

2023-12-05T05:59:07Z

Ausem: /* Scenario 1: Grading histories of submissions */

=='''Introduction'''==

===Problem Statement===
In the current implementation of expertiza, any instructor can assign or edit a grade but there is no way to track who gave the grade and when.

A grading audit trail must be created and the following information needs to be stored:

1. When a grade is assigned by an instructor, there needs to be an indication of who did it and when it was done.
2. Comments previously provided by other instructors must also be preserved.
This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

Currently, there are two places need to add grading audit trail:

1. Review grade: Log in as instructor -> Manage -> Assignments -> View Review Report
2. Submission grade: Log in as instructor -> Manage -> Assignments -> View submissions
The grading audit trail can probably be implemented as the submission records history on Expertiza. The required page can be reached by logging in as instructor -> Manage -> Assignments -> View Submissions -> History

At the minimum, a grading log entry must include the instructor id, assignment id, student id, grade, comment and timestamp.

Previous student teams have attempted to implement this functionality, but their implementations had issues. Our solution will build on the work of teams E1934 and E2237, addressing the problems in their implementations.

== '''Overview of Major Changes By Previous Teams''' ==
===[https://wiki-expertiza.csc.ncsu.edu/index.php/E1934_-_Grading_Audit_Trail E1934]===
[https://youtu.be/yyxX_kRYxLc Their Screencast]

*Created a database called grading_history to store elements for the Grading Audit Trail (instructor id, assignment id, grade tyoe, student id, grade, comment and timestamp)
*Used MVC design to create a model, a controller, and a view for both of Review Grade and Submission Grade. These will be the links used in the View Submissions view and View Review Report view so that the grading trail for an assignments submission and reviews are seperate.
*Modified grades controller, so that every time, a grade is submitted or edited, grading_history_controller.rb will call a method to create an entry that saves into the database.
'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

This is the design plan in which they followed:

[[File:E1869 Grading Audit Trails UML.jpg]]

===[https://wiki-expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2022_-_E2237:_Grading_audit_trail E2237]===

*They fixed some issues that were causing the system to crash during testing
*Altered the Grading History view
*Explained the reasoning for changes made to files using diagrams and justifications
'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

This is the updated design flow in which they created to improve previous implementations further:

[[File:Kai diagram1.jpg]]

=='''Proposed Solution'''==
We plan on using the implementation of E2237 since it is the latest in the Grading Audit Trail projects and has the latest in terms of testing. These files cannot be added haphazardly since parts of the implementation is a cause to concern and caused the changes to not be implemented. It is also using an older version of expertiza so some parts may not be compatible.

We must first figure out exactly what changes and issues to address in their implementation by meeting with our mentor. We also need to reimplement the following files since none of their changes were implemented:

*app/controllers/grading_histories_controller.rb
'''
Calls the grading history view after validating Submission and Review Type.

'''

*app/models/grading_history.rb
'''
Model for Grading History.
'''

*app/models/review_grading_history.rb

'''
Model containing specifics of Review Grading History. Inherits Grading History.
'''

*app/models/submission_grading_history.rb
'''
Model containing specifics of Submission Grading History. Inherits Grading History.
'''

*app/views/grading_history/index_html.erb
'''
This is a view for grading audit trail, it will display all grading histories of a
submission/review
'''

*spec/features/grade_histories_spec.rb

'''
Feature test to check if the grades appear in chronological order
'''

*spec/features/helpers/grade_histories_helper.rb

'''
Helper file to facilitate the above mentioned feature test.
'''

=='''Reimplementation'''==
Since the previous teams implementations were not integrated we have to reimplement their files which we will do by looking at their commits and pull request to see what files are necessary and what can be left out to address the issues of their implementation.

'''[https://github.com/ErikLG360/expertiza/commit/e28a857695549cc91c477587707e48100d2bd333 Files being Reimplemented/Modified]'''

'''Reimplemented'''
*app/controllers/grading_histories_controller.rb
'''
This file was added to deal with allowing only the correct people to view the grading history, checking the assignment type whether it be a submission or review, and indexing all the grading history for the assignment in chronological order.
'''
*app/models/grading_history.rb
'''
This file was added to create the relationships that the grading history has with an instructor who is creating the parts of the grading history and the assignments that will have a grading history.
'''
*app/models/review_grading_history.rb
'''
This file creates the relationship that a participant will have a Review Grading History
'''
*app/models/submission_grading_history.rb
'''
This file create the relationship that a participant/grade_reciever will have a Submission Grading History
'''

*app/views/grading_histories/index.html.erb
'''
This file contains the view for the grading history table which will change depending on if its a Review or submission type
'''
*app/views/grading_histories/_form.html.erb
'''
This file contains the view for when a grading history contains any error when it is about to be saved
'''

'''Modified'''
*app/controllers/grades_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_submission was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of submissions and not reviews.
'''
*app/controllers/review_mapping_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_reviewer was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of reviews and not submissions.
'''
*app/views/assignments/list_submissions.html.erb
'''
It was modified to add the new hyperlink to display the grading history of a submission.
'''
*config/routes.rb
'''
It was to add the new route for grading histories
'''

=='''Solutions - Implemented'''==

'''E1934'''

'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

'''Solutions'''
:1. Found the correct location to put the Review Grading History link and also fix the previous teams creation of a grading history to work with the latest expertiza update.
Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/controllers/review_mapping_controller.rb]
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/views/reports/_review_report.html.erb]

:2. The previous implementatation of E2237 tackled this problem and moved it to the title.
[[File:GradingTableTitle.png|1100px]]
:3. The column widths were lessened by about 15px in the grading record page

Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/124bd12d23f75db0a68e2fac8a8487c5f7a7ed67 app/views/grading_histories/index.html.erb]

:4. There were no code climate issues regarding this issue

:5. All code climate changes are their own commits such as [https://github.com/ErikLG360/expertiza/commit/e95656f4d5e4f2ba4fc8d3f40716673ccafb41b1 This]

:6. This issue was resolved by not adding in their implementation for the list_review_mapping.html.erb

:7. This issue was resolved by not adding in the review_report_html.erb file

:8. This issue is resolved in the '''Reimplementation''' section of this document

'''E2237'''

'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

'''Solutions'''
:1. These files have not been added.
:2. The authentication already used the necessary parts
:3. The column width was reduced by 15px refer to the solution for E1934 number 3.
:4. Code for the review_mapping_controller was changed to match the current state of expertiza refer to the solution for E1934 number 1.

=='''Resulting Views'''==
This is the view in the view submissions page that displays the link for the Submissions Grading History which is circled in red.
[[File:SubmissionsGradingHistoryLink.jpeg|1100px]]

This is the resulting view after clicking the link:
[[File:SubmissionGradingHist.png|1100px]]

This is the view in the review report page that displays the link for the Reviews Grading History which is circled in red.
[[File:ReviewGradingHistoryLink.jpeg|1100px]]

This is the resulting view after clicking the Reviews Grading History link:
[[File:ReviewsGradingHist.png|1100px]]

=='''Testing Plan'''==

=== Rspec Unit Tests ===

==== For History of the Grades ====
The history of the grade and comments are related to the new model grading_history.rb and the new controller grading_history_controller.rb.

So the related RSpec tests are planned to be executed:

spec/controllers/grading_history_controller_test.rb

For the feature part, test if the grading history and instructor can be shown in chronological order:

spec/features/grade_histories_spec.rb
spec/helpers/grade_histories_helper_spec.rb

The link to test files inorder to test the creation of grading history with valid parameters is https://github.com/expertiza/expertiza/commit/067b52315ac1ff7ce1b89fc44121393cadbabc6a

=== Manual UI Tests ===
To start the test, we need to log in as instructor or TA first. These accounts should have access to the assignment. For example: we can use '''intructor6/password'''

==== Scenario 1: Grading histories of submissions ====
Step 1. Log in as instructor -> Manage -> Assignments -> View submissions
 
 
[[File: E2383 1.png|1100px]]
 
 
 
Step 2. The instructor can assign grades to a team by clicking 'Assign Grade' in the 'Team name' column:
 
[[File:E2383 2.png|1100px]]
 
 
 
Step 3. The instructor can view the grading audit trail by clicking 'Grading History' in the 'History' column, here is the record page:
 
[[File:E2383 3.png|1100px]]
 
 

==== Scenario 2: Grading histories of reviews ====
Step 1. Log in as instructor -> Manage -> Assignments -> View Reports
 
[[File:E2383 4.png|1100px]]
 
 
Step 2. Select 'Review Report' then click 'View', here is the Review Report page. The instructor can assign grades to a review by inputing 'Grade' and 'Comment' then clicking 'Save' button:
 
[[File:E2383 5.png|1100px]]
 
 
Step 3. The instructor/TA can view the grading audit trail by clicking 'Grading History' as Step 2 figure shows, here is the record page:
 
[[File:E2383 6.png|1100px]]
 
 

=='''Future Scope'''==
This project may need further improvement since it does not seem like there should be an abundance of files added and perhaps using the MVC design is not necessarily needed. There can also be a reduction of code since the difference between the two main grading histories is just whether it is a review or submission type.

=='''Relevant Links'''==
* '''Github Repository:''' https://github.com/ErikLG360/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2696
* '''VCL Server (Valid until 12/15/23):''' http://152.7.179.44:8080
* '''Video:''' https://drive.google.com/file/d/1HIrJtCsbZXSqGPHShuV6mbSTOKvV5MxT/view?usp=drive_link

=='''Contributors to this project'''==
*Amulya Usem
*Erik Lopez-Godinez
*Gowtham Pollam

*'''Mentor''': Srilekha Gudipati

CSC/ECE 517 Fall 2023 - E2383. Grading Audit Trail

2023-12-05T05:57:20Z

Ausem: /* Solutions - Implemented */

=='''Introduction'''==

===Problem Statement===
In the current implementation of expertiza, any instructor can assign or edit a grade but there is no way to track who gave the grade and when.

A grading audit trail must be created and the following information needs to be stored:

1. When a grade is assigned by an instructor, there needs to be an indication of who did it and when it was done.
2. Comments previously provided by other instructors must also be preserved.
This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

Currently, there are two places need to add grading audit trail:

1. Review grade: Log in as instructor -> Manage -> Assignments -> View Review Report
2. Submission grade: Log in as instructor -> Manage -> Assignments -> View submissions
The grading audit trail can probably be implemented as the submission records history on Expertiza. The required page can be reached by logging in as instructor -> Manage -> Assignments -> View Submissions -> History

At the minimum, a grading log entry must include the instructor id, assignment id, student id, grade, comment and timestamp.

Previous student teams have attempted to implement this functionality, but their implementations had issues. Our solution will build on the work of teams E1934 and E2237, addressing the problems in their implementations.

== '''Overview of Major Changes By Previous Teams''' ==
===[https://wiki-expertiza.csc.ncsu.edu/index.php/E1934_-_Grading_Audit_Trail E1934]===
[https://youtu.be/yyxX_kRYxLc Their Screencast]

*Created a database called grading_history to store elements for the Grading Audit Trail (instructor id, assignment id, grade tyoe, student id, grade, comment and timestamp)
*Used MVC design to create a model, a controller, and a view for both of Review Grade and Submission Grade. These will be the links used in the View Submissions view and View Review Report view so that the grading trail for an assignments submission and reviews are seperate.
*Modified grades controller, so that every time, a grade is submitted or edited, grading_history_controller.rb will call a method to create an entry that saves into the database.
'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

This is the design plan in which they followed:

[[File:E1869 Grading Audit Trails UML.jpg]]

===[https://wiki-expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2022_-_E2237:_Grading_audit_trail E2237]===

*They fixed some issues that were causing the system to crash during testing
*Altered the Grading History view
*Explained the reasoning for changes made to files using diagrams and justifications
'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

This is the updated design flow in which they created to improve previous implementations further:

[[File:Kai diagram1.jpg]]

=='''Proposed Solution'''==
We plan on using the implementation of E2237 since it is the latest in the Grading Audit Trail projects and has the latest in terms of testing. These files cannot be added haphazardly since parts of the implementation is a cause to concern and caused the changes to not be implemented. It is also using an older version of expertiza so some parts may not be compatible.

We must first figure out exactly what changes and issues to address in their implementation by meeting with our mentor. We also need to reimplement the following files since none of their changes were implemented:

*app/controllers/grading_histories_controller.rb
'''
Calls the grading history view after validating Submission and Review Type.

'''

*app/models/grading_history.rb
'''
Model for Grading History.
'''

*app/models/review_grading_history.rb

'''
Model containing specifics of Review Grading History. Inherits Grading History.
'''

*app/models/submission_grading_history.rb
'''
Model containing specifics of Submission Grading History. Inherits Grading History.
'''

*app/views/grading_history/index_html.erb
'''
This is a view for grading audit trail, it will display all grading histories of a
submission/review
'''

*spec/features/grade_histories_spec.rb

'''
Feature test to check if the grades appear in chronological order
'''

*spec/features/helpers/grade_histories_helper.rb

'''
Helper file to facilitate the above mentioned feature test.
'''

=='''Reimplementation'''==
Since the previous teams implementations were not integrated we have to reimplement their files which we will do by looking at their commits and pull request to see what files are necessary and what can be left out to address the issues of their implementation.

'''[https://github.com/ErikLG360/expertiza/commit/e28a857695549cc91c477587707e48100d2bd333 Files being Reimplemented/Modified]'''

'''Reimplemented'''
*app/controllers/grading_histories_controller.rb
'''
This file was added to deal with allowing only the correct people to view the grading history, checking the assignment type whether it be a submission or review, and indexing all the grading history for the assignment in chronological order.
'''
*app/models/grading_history.rb
'''
This file was added to create the relationships that the grading history has with an instructor who is creating the parts of the grading history and the assignments that will have a grading history.
'''
*app/models/review_grading_history.rb
'''
This file creates the relationship that a participant will have a Review Grading History
'''
*app/models/submission_grading_history.rb
'''
This file create the relationship that a participant/grade_reciever will have a Submission Grading History
'''

*app/views/grading_histories/index.html.erb
'''
This file contains the view for the grading history table which will change depending on if its a Review or submission type
'''
*app/views/grading_histories/_form.html.erb
'''
This file contains the view for when a grading history contains any error when it is about to be saved
'''

'''Modified'''
*app/controllers/grades_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_submission was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of submissions and not reviews.
'''
*app/controllers/review_mapping_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_reviewer was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of reviews and not submissions.
'''
*app/views/assignments/list_submissions.html.erb
'''
It was modified to add the new hyperlink to display the grading history of a submission.
'''
*config/routes.rb
'''
It was to add the new route for grading histories
'''

=='''Solutions - Implemented'''==

'''E1934'''

'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

'''Solutions'''
:1. Found the correct location to put the Review Grading History link and also fix the previous teams creation of a grading history to work with the latest expertiza update.
Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/controllers/review_mapping_controller.rb]
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/views/reports/_review_report.html.erb]

:2. The previous implementatation of E2237 tackled this problem and moved it to the title.
[[File:GradingTableTitle.png|1100px]]
:3. The column widths were lessened by about 15px in the grading record page

Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/124bd12d23f75db0a68e2fac8a8487c5f7a7ed67 app/views/grading_histories/index.html.erb]

:4. There were no code climate issues regarding this issue

:5. All code climate changes are their own commits such as [https://github.com/ErikLG360/expertiza/commit/e95656f4d5e4f2ba4fc8d3f40716673ccafb41b1 This]

:6. This issue was resolved by not adding in their implementation for the list_review_mapping.html.erb

:7. This issue was resolved by not adding in the review_report_html.erb file

:8. This issue is resolved in the '''Reimplementation''' section of this document

'''E2237'''

'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

'''Solutions'''
:1. These files have not been added.
:2. The authentication already used the necessary parts
:3. The column width was reduced by 15px refer to the solution for E1934 number 3.
:4. Code for the review_mapping_controller was changed to match the current state of expertiza refer to the solution for E1934 number 1.

=='''Resulting Views'''==
This is the view in the view submissions page that displays the link for the Submissions Grading History which is circled in red.
[[File:SubmissionsGradingHistoryLink.jpeg|1100px]]

This is the resulting view after clicking the link:
[[File:SubmissionGradingHist.png|1100px]]

This is the view in the review report page that displays the link for the Reviews Grading History which is circled in red.
[[File:ReviewGradingHistoryLink.jpeg|1100px]]

This is the resulting view after clicking the Reviews Grading History link:
[[File:ReviewsGradingHist.png|1100px]]

=='''Testing Plan'''==

=== Rspec Unit Tests ===

==== For History of the Grades ====
The history of the grade and comments are related to the new model grading_history.rb and the new controller grading_history_controller.rb.

So the related RSpec tests are planned to be executed:

spec/controllers/grading_history_controller_test.rb

For the feature part, test if the grading history and instructor can be shown in chronological order:

spec/features/grade_histories_spec.rb
spec/helpers/grade_histories_helper_spec.rb

The link to test files inorder to test the creation of grading history with valid parameters is https://github.com/expertiza/expertiza/commit/067b52315ac1ff7ce1b89fc44121393cadbabc6a

=== Manual UI Tests ===
To start the test, we need to log in as instructor or TA first. These accounts should have access to the assignment. For example: we can use '''intructor6/password'''

==== Scenario 1: Grading histories of submissions ====
Step 1. Log in as instructor -> Manage -> Assignments -> View submissions
 
[[File: E2383 1.png|1100px]]
 
 
Step 2. The instructor can assign grades to a team by clicking 'Assign Grade' in the 'Team name' column:
 
[[File:E2383 2.png|1100px]]
 
 
Step 3. The instructor can view the grading audit trail by clicking 'Grading History' in the 'History' column, here is the record page:
 
[[File:E2383 3.png|1100px]]
 
 
==== Scenario 2: Grading histories of reviews ====
Step 1. Log in as instructor -> Manage -> Assignments -> View Reports
 
[[File:E2383 4.png|1100px]]
 
 
Step 2. Select 'Review Report' then click 'View', here is the Review Report page. The instructor can assign grades to a review by inputing 'Grade' and 'Comment' then clicking 'Save' button:
 
[[File:E2383 5.png|1100px]]
 
 
Step 3. The instructor/TA can view the grading audit trail by clicking 'Grading History' as Step 2 figure shows, here is the record page:
 
[[File:E2383 6.png|1100px]]
 
 

=='''Future Scope'''==
This project may need further improvement since it does not seem like there should be an abundance of files added and perhaps using the MVC design is not necessarily needed. There can also be a reduction of code since the difference between the two main grading histories is just whether it is a review or submission type.

=='''Relevant Links'''==
* '''Github Repository:''' https://github.com/ErikLG360/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2696
* '''VCL Server (Valid until 12/15/23):''' http://152.7.179.44:8080
* '''Video:''' https://drive.google.com/file/d/1HIrJtCsbZXSqGPHShuV6mbSTOKvV5MxT/view?usp=drive_link

=='''Contributors to this project'''==
*Amulya Usem
*Erik Lopez-Godinez
*Gowtham Pollam

*'''Mentor''': Srilekha Gudipati

CSC/ECE 517 Fall 2023 - E2383. Grading Audit Trail

2023-12-05T05:57:04Z

Ausem: /* Resulting Views */

=='''Introduction'''==

===Problem Statement===
In the current implementation of expertiza, any instructor can assign or edit a grade but there is no way to track who gave the grade and when.

A grading audit trail must be created and the following information needs to be stored:

1. When a grade is assigned by an instructor, there needs to be an indication of who did it and when it was done.
2. Comments previously provided by other instructors must also be preserved.
This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

Currently, there are two places need to add grading audit trail:

1. Review grade: Log in as instructor -> Manage -> Assignments -> View Review Report
2. Submission grade: Log in as instructor -> Manage -> Assignments -> View submissions
The grading audit trail can probably be implemented as the submission records history on Expertiza. The required page can be reached by logging in as instructor -> Manage -> Assignments -> View Submissions -> History

At the minimum, a grading log entry must include the instructor id, assignment id, student id, grade, comment and timestamp.

Previous student teams have attempted to implement this functionality, but their implementations had issues. Our solution will build on the work of teams E1934 and E2237, addressing the problems in their implementations.

== '''Overview of Major Changes By Previous Teams''' ==
===[https://wiki-expertiza.csc.ncsu.edu/index.php/E1934_-_Grading_Audit_Trail E1934]===
[https://youtu.be/yyxX_kRYxLc Their Screencast]

*Created a database called grading_history to store elements for the Grading Audit Trail (instructor id, assignment id, grade tyoe, student id, grade, comment and timestamp)
*Used MVC design to create a model, a controller, and a view for both of Review Grade and Submission Grade. These will be the links used in the View Submissions view and View Review Report view so that the grading trail for an assignments submission and reviews are seperate.
*Modified grades controller, so that every time, a grade is submitted or edited, grading_history_controller.rb will call a method to create an entry that saves into the database.
'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

This is the design plan in which they followed:

[[File:E1869 Grading Audit Trails UML.jpg]]

===[https://wiki-expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2022_-_E2237:_Grading_audit_trail E2237]===

*They fixed some issues that were causing the system to crash during testing
*Altered the Grading History view
*Explained the reasoning for changes made to files using diagrams and justifications
'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

This is the updated design flow in which they created to improve previous implementations further:

[[File:Kai diagram1.jpg]]

=='''Proposed Solution'''==
We plan on using the implementation of E2237 since it is the latest in the Grading Audit Trail projects and has the latest in terms of testing. These files cannot be added haphazardly since parts of the implementation is a cause to concern and caused the changes to not be implemented. It is also using an older version of expertiza so some parts may not be compatible.

We must first figure out exactly what changes and issues to address in their implementation by meeting with our mentor. We also need to reimplement the following files since none of their changes were implemented:

*app/controllers/grading_histories_controller.rb
'''
Calls the grading history view after validating Submission and Review Type.

'''

*app/models/grading_history.rb
'''
Model for Grading History.
'''

*app/models/review_grading_history.rb

'''
Model containing specifics of Review Grading History. Inherits Grading History.
'''

*app/models/submission_grading_history.rb
'''
Model containing specifics of Submission Grading History. Inherits Grading History.
'''

*app/views/grading_history/index_html.erb
'''
This is a view for grading audit trail, it will display all grading histories of a
submission/review
'''

*spec/features/grade_histories_spec.rb

'''
Feature test to check if the grades appear in chronological order
'''

*spec/features/helpers/grade_histories_helper.rb

'''
Helper file to facilitate the above mentioned feature test.
'''

=='''Reimplementation'''==
Since the previous teams implementations were not integrated we have to reimplement their files which we will do by looking at their commits and pull request to see what files are necessary and what can be left out to address the issues of their implementation.

'''[https://github.com/ErikLG360/expertiza/commit/e28a857695549cc91c477587707e48100d2bd333 Files being Reimplemented/Modified]'''

'''Reimplemented'''
*app/controllers/grading_histories_controller.rb
'''
This file was added to deal with allowing only the correct people to view the grading history, checking the assignment type whether it be a submission or review, and indexing all the grading history for the assignment in chronological order.
'''
*app/models/grading_history.rb
'''
This file was added to create the relationships that the grading history has with an instructor who is creating the parts of the grading history and the assignments that will have a grading history.
'''
*app/models/review_grading_history.rb
'''
This file creates the relationship that a participant will have a Review Grading History
'''
*app/models/submission_grading_history.rb
'''
This file create the relationship that a participant/grade_reciever will have a Submission Grading History
'''

*app/views/grading_histories/index.html.erb
'''
This file contains the view for the grading history table which will change depending on if its a Review or submission type
'''
*app/views/grading_histories/_form.html.erb
'''
This file contains the view for when a grading history contains any error when it is about to be saved
'''

'''Modified'''
*app/controllers/grades_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_submission was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of submissions and not reviews.
'''
*app/controllers/review_mapping_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_reviewer was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of reviews and not submissions.
'''
*app/views/assignments/list_submissions.html.erb
'''
It was modified to add the new hyperlink to display the grading history of a submission.
'''
*config/routes.rb
'''
It was to add the new route for grading histories
'''

=='''Solutions - Implemented'''==

'''E1934'''

'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

'''Solutions'''
:1. Found the correct location to put the Review Grading History link and also fix the previous teams creation of a grading history to work with the latest expertiza update.
Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/controllers/review_mapping_controller.rb]
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/views/reports/_review_report.html.erb]

:2. The previous implementatation of E2237 tackled this problem and moved it to the title.
[[File:GradingTableTitle.png]]
:3. The column widths were lessened by about 15px in the grading record page

Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/124bd12d23f75db0a68e2fac8a8487c5f7a7ed67 app/views/grading_histories/index.html.erb]

:4. There were no code climate issues regarding this issue

:5. All code climate changes are their own commits such as [https://github.com/ErikLG360/expertiza/commit/e95656f4d5e4f2ba4fc8d3f40716673ccafb41b1 This]

:6. This issue was resolved by not adding in their implementation for the list_review_mapping.html.erb

:7. This issue was resolved by not adding in the review_report_html.erb file

:8. This issue is resolved in the '''Reimplementation''' section of this document

'''E2237'''

'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

'''Solutions'''
:1. These files have not been added.
:2. The authentication already used the necessary parts
:3. The column width was reduced by 15px refer to the solution for E1934 number 3.
:4. Code for the review_mapping_controller was changed to match the current state of expertiza refer to the solution for E1934 number 1.

=='''Resulting Views'''==
This is the view in the view submissions page that displays the link for the Submissions Grading History which is circled in red.
[[File:SubmissionsGradingHistoryLink.jpeg|1100px]]

This is the resulting view after clicking the link:
[[File:SubmissionGradingHist.png|1100px]]

This is the view in the review report page that displays the link for the Reviews Grading History which is circled in red.
[[File:ReviewGradingHistoryLink.jpeg|1100px]]

This is the resulting view after clicking the Reviews Grading History link:
[[File:ReviewsGradingHist.png|1100px]]

=='''Testing Plan'''==

=== Rspec Unit Tests ===

==== For History of the Grades ====
The history of the grade and comments are related to the new model grading_history.rb and the new controller grading_history_controller.rb.

So the related RSpec tests are planned to be executed:

spec/controllers/grading_history_controller_test.rb

For the feature part, test if the grading history and instructor can be shown in chronological order:

spec/features/grade_histories_spec.rb
spec/helpers/grade_histories_helper_spec.rb

The link to test files inorder to test the creation of grading history with valid parameters is https://github.com/expertiza/expertiza/commit/067b52315ac1ff7ce1b89fc44121393cadbabc6a

=== Manual UI Tests ===
To start the test, we need to log in as instructor or TA first. These accounts should have access to the assignment. For example: we can use '''intructor6/password'''

==== Scenario 1: Grading histories of submissions ====
Step 1. Log in as instructor -> Manage -> Assignments -> View submissions
 
[[File: E2383 1.png|1100px]]
 
 
Step 2. The instructor can assign grades to a team by clicking 'Assign Grade' in the 'Team name' column:
 
[[File:E2383 2.png|1100px]]
 
 
Step 3. The instructor can view the grading audit trail by clicking 'Grading History' in the 'History' column, here is the record page:
 
[[File:E2383 3.png|1100px]]
 
 
==== Scenario 2: Grading histories of reviews ====
Step 1. Log in as instructor -> Manage -> Assignments -> View Reports
 
[[File:E2383 4.png|1100px]]
 
 
Step 2. Select 'Review Report' then click 'View', here is the Review Report page. The instructor can assign grades to a review by inputing 'Grade' and 'Comment' then clicking 'Save' button:
 
[[File:E2383 5.png|1100px]]
 
 
Step 3. The instructor/TA can view the grading audit trail by clicking 'Grading History' as Step 2 figure shows, here is the record page:
 
[[File:E2383 6.png|1100px]]
 
 

=='''Future Scope'''==
This project may need further improvement since it does not seem like there should be an abundance of files added and perhaps using the MVC design is not necessarily needed. There can also be a reduction of code since the difference between the two main grading histories is just whether it is a review or submission type.

=='''Relevant Links'''==
* '''Github Repository:''' https://github.com/ErikLG360/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2696
* '''VCL Server (Valid until 12/15/23):''' http://152.7.179.44:8080
* '''Video:''' https://drive.google.com/file/d/1HIrJtCsbZXSqGPHShuV6mbSTOKvV5MxT/view?usp=drive_link

=='''Contributors to this project'''==
*Amulya Usem
*Erik Lopez-Godinez
*Gowtham Pollam

*'''Mentor''': Srilekha Gudipati

CSC/ECE 517 Fall 2023 - E2383. Grading Audit Trail

2023-12-05T05:55:44Z

Ausem: /* Manual UI Tests */

=='''Introduction'''==

===Problem Statement===
In the current implementation of expertiza, any instructor can assign or edit a grade but there is no way to track who gave the grade and when.

A grading audit trail must be created and the following information needs to be stored:

1. When a grade is assigned by an instructor, there needs to be an indication of who did it and when it was done.
2. Comments previously provided by other instructors must also be preserved.
This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

Currently, there are two places need to add grading audit trail:

1. Review grade: Log in as instructor -> Manage -> Assignments -> View Review Report
2. Submission grade: Log in as instructor -> Manage -> Assignments -> View submissions
The grading audit trail can probably be implemented as the submission records history on Expertiza. The required page can be reached by logging in as instructor -> Manage -> Assignments -> View Submissions -> History

At the minimum, a grading log entry must include the instructor id, assignment id, student id, grade, comment and timestamp.

Previous student teams have attempted to implement this functionality, but their implementations had issues. Our solution will build on the work of teams E1934 and E2237, addressing the problems in their implementations.

== '''Overview of Major Changes By Previous Teams''' ==
===[https://wiki-expertiza.csc.ncsu.edu/index.php/E1934_-_Grading_Audit_Trail E1934]===
[https://youtu.be/yyxX_kRYxLc Their Screencast]

*Created a database called grading_history to store elements for the Grading Audit Trail (instructor id, assignment id, grade tyoe, student id, grade, comment and timestamp)
*Used MVC design to create a model, a controller, and a view for both of Review Grade and Submission Grade. These will be the links used in the View Submissions view and View Review Report view so that the grading trail for an assignments submission and reviews are seperate.
*Modified grades controller, so that every time, a grade is submitted or edited, grading_history_controller.rb will call a method to create an entry that saves into the database.
'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

This is the design plan in which they followed:

[[File:E1869 Grading Audit Trails UML.jpg]]

===[https://wiki-expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2022_-_E2237:_Grading_audit_trail E2237]===

*They fixed some issues that were causing the system to crash during testing
*Altered the Grading History view
*Explained the reasoning for changes made to files using diagrams and justifications
'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

This is the updated design flow in which they created to improve previous implementations further:

[[File:Kai diagram1.jpg]]

=='''Proposed Solution'''==
We plan on using the implementation of E2237 since it is the latest in the Grading Audit Trail projects and has the latest in terms of testing. These files cannot be added haphazardly since parts of the implementation is a cause to concern and caused the changes to not be implemented. It is also using an older version of expertiza so some parts may not be compatible.

We must first figure out exactly what changes and issues to address in their implementation by meeting with our mentor. We also need to reimplement the following files since none of their changes were implemented:

*app/controllers/grading_histories_controller.rb
'''
Calls the grading history view after validating Submission and Review Type.

'''

*app/models/grading_history.rb
'''
Model for Grading History.
'''

*app/models/review_grading_history.rb

'''
Model containing specifics of Review Grading History. Inherits Grading History.
'''

*app/models/submission_grading_history.rb
'''
Model containing specifics of Submission Grading History. Inherits Grading History.
'''

*app/views/grading_history/index_html.erb
'''
This is a view for grading audit trail, it will display all grading histories of a
submission/review
'''

*spec/features/grade_histories_spec.rb

'''
Feature test to check if the grades appear in chronological order
'''

*spec/features/helpers/grade_histories_helper.rb

'''
Helper file to facilitate the above mentioned feature test.
'''

=='''Reimplementation'''==
Since the previous teams implementations were not integrated we have to reimplement their files which we will do by looking at their commits and pull request to see what files are necessary and what can be left out to address the issues of their implementation.

'''[https://github.com/ErikLG360/expertiza/commit/e28a857695549cc91c477587707e48100d2bd333 Files being Reimplemented/Modified]'''

'''Reimplemented'''
*app/controllers/grading_histories_controller.rb
'''
This file was added to deal with allowing only the correct people to view the grading history, checking the assignment type whether it be a submission or review, and indexing all the grading history for the assignment in chronological order.
'''
*app/models/grading_history.rb
'''
This file was added to create the relationships that the grading history has with an instructor who is creating the parts of the grading history and the assignments that will have a grading history.
'''
*app/models/review_grading_history.rb
'''
This file creates the relationship that a participant will have a Review Grading History
'''
*app/models/submission_grading_history.rb
'''
This file create the relationship that a participant/grade_reciever will have a Submission Grading History
'''

*app/views/grading_histories/index.html.erb
'''
This file contains the view for the grading history table which will change depending on if its a Review or submission type
'''
*app/views/grading_histories/_form.html.erb
'''
This file contains the view for when a grading history contains any error when it is about to be saved
'''

'''Modified'''
*app/controllers/grades_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_submission was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of submissions and not reviews.
'''
*app/controllers/review_mapping_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_reviewer was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of reviews and not submissions.
'''
*app/views/assignments/list_submissions.html.erb
'''
It was modified to add the new hyperlink to display the grading history of a submission.
'''
*config/routes.rb
'''
It was to add the new route for grading histories
'''

=='''Solutions - Implemented'''==

'''E1934'''

'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

'''Solutions'''
:1. Found the correct location to put the Review Grading History link and also fix the previous teams creation of a grading history to work with the latest expertiza update.
Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/controllers/review_mapping_controller.rb]
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/views/reports/_review_report.html.erb]

:2. The previous implementatation of E2237 tackled this problem and moved it to the title.
[[File:GradingTableTitle.png]]
:3. The column widths were lessened by about 15px in the grading record page

Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/124bd12d23f75db0a68e2fac8a8487c5f7a7ed67 app/views/grading_histories/index.html.erb]

:4. There were no code climate issues regarding this issue

:5. All code climate changes are their own commits such as [https://github.com/ErikLG360/expertiza/commit/e95656f4d5e4f2ba4fc8d3f40716673ccafb41b1 This]

:6. This issue was resolved by not adding in their implementation for the list_review_mapping.html.erb

:7. This issue was resolved by not adding in the review_report_html.erb file

:8. This issue is resolved in the '''Reimplementation''' section of this document

'''E2237'''

'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

'''Solutions'''
:1. These files have not been added.
:2. The authentication already used the necessary parts
:3. The column width was reduced by 15px refer to the solution for E1934 number 3.
:4. Code for the review_mapping_controller was changed to match the current state of expertiza refer to the solution for E1934 number 1.

=='''Resulting Views'''==
This is the view in the view submissions page that displays the link for the Submissions Grading History which is circled in red.
[[File:SubmissionsGradingHistoryLink.jpeg]]

This is the resulting view after clicking the link:
[[File:SubmissionGradingHist.png]]

This is the view in the review report page that displays the link for the Reviews Grading History which is circled in red.
[[File:ReviewGradingHistoryLink.jpeg]]

This is the resulting view after clicking the Reviews Grading History link:
[[File:ReviewsGradingHist.png]]

=='''Testing Plan'''==

=== Rspec Unit Tests ===

==== For History of the Grades ====
The history of the grade and comments are related to the new model grading_history.rb and the new controller grading_history_controller.rb.

So the related RSpec tests are planned to be executed:

spec/controllers/grading_history_controller_test.rb

For the feature part, test if the grading history and instructor can be shown in chronological order:

spec/features/grade_histories_spec.rb
spec/helpers/grade_histories_helper_spec.rb

The link to test files inorder to test the creation of grading history with valid parameters is https://github.com/expertiza/expertiza/commit/067b52315ac1ff7ce1b89fc44121393cadbabc6a

=== Manual UI Tests ===
To start the test, we need to log in as instructor or TA first. These accounts should have access to the assignment. For example: we can use '''intructor6/password'''

==== Scenario 1: Grading histories of submissions ====
Step 1. Log in as instructor -> Manage -> Assignments -> View submissions
 
[[File: E2383 1.png|1100px]]
 
 
Step 2. The instructor can assign grades to a team by clicking 'Assign Grade' in the 'Team name' column:
 
[[File:E2383 2.png|1100px]]
 
 
Step 3. The instructor can view the grading audit trail by clicking 'Grading History' in the 'History' column, here is the record page:
 
[[File:E2383 3.png|1100px]]
 
 
==== Scenario 2: Grading histories of reviews ====
Step 1. Log in as instructor -> Manage -> Assignments -> View Reports
 
[[File:E2383 4.png|1100px]]
 
 
Step 2. Select 'Review Report' then click 'View', here is the Review Report page. The instructor can assign grades to a review by inputing 'Grade' and 'Comment' then clicking 'Save' button:
 
[[File:E2383 5.png|1100px]]
 
 
Step 3. The instructor/TA can view the grading audit trail by clicking 'Grading History' as Step 2 figure shows, here is the record page:
 
[[File:E2383 6.png|1100px]]
 
 

=='''Future Scope'''==
This project may need further improvement since it does not seem like there should be an abundance of files added and perhaps using the MVC design is not necessarily needed. There can also be a reduction of code since the difference between the two main grading histories is just whether it is a review or submission type.

=='''Relevant Links'''==
* '''Github Repository:''' https://github.com/ErikLG360/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2696
* '''VCL Server (Valid until 12/15/23):''' http://152.7.179.44:8080
* '''Video:''' https://drive.google.com/file/d/1HIrJtCsbZXSqGPHShuV6mbSTOKvV5MxT/view?usp=drive_link

=='''Contributors to this project'''==
*Amulya Usem
*Erik Lopez-Godinez
*Gowtham Pollam

*'''Mentor''': Srilekha Gudipati

File:E2383 6.png

2023-12-05T05:54:24Z

Ausem:

File:E2383 5.png

2023-12-05T05:53:58Z

Ausem:

File:E2383 4.png

2023-12-05T05:53:34Z

Ausem:

File:E2383 3.png

2023-12-05T05:53:03Z

Ausem:

File:E2383 2.png

2023-12-05T05:52:35Z

Ausem:

File:E2383 1.png

2023-12-05T05:49:24Z

Ausem:

CSC/ECE 517 Fall 2023 - E2383. Grading Audit Trail

2023-12-05T05:40:01Z

Ausem: /* Testing Plan */

=='''Introduction'''==

===Problem Statement===
In the current implementation of expertiza, any instructor can assign or edit a grade but there is no way to track who gave the grade and when.

A grading audit trail must be created and the following information needs to be stored:

1. When a grade is assigned by an instructor, there needs to be an indication of who did it and when it was done.
2. Comments previously provided by other instructors must also be preserved.
This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

Currently, there are two places need to add grading audit trail:

1. Review grade: Log in as instructor -> Manage -> Assignments -> View Review Report
2. Submission grade: Log in as instructor -> Manage -> Assignments -> View submissions
The grading audit trail can probably be implemented as the submission records history on Expertiza. The required page can be reached by logging in as instructor -> Manage -> Assignments -> View Submissions -> History

At the minimum, a grading log entry must include the instructor id, assignment id, student id, grade, comment and timestamp.

Previous student teams have attempted to implement this functionality, but their implementations had issues. Our solution will build on the work of teams E1934 and E2237, addressing the problems in their implementations.

== '''Overview of Major Changes By Previous Teams''' ==
===[https://wiki-expertiza.csc.ncsu.edu/index.php/E1934_-_Grading_Audit_Trail E1934]===
[https://youtu.be/yyxX_kRYxLc Their Screencast]

*Created a database called grading_history to store elements for the Grading Audit Trail (instructor id, assignment id, grade tyoe, student id, grade, comment and timestamp)
*Used MVC design to create a model, a controller, and a view for both of Review Grade and Submission Grade. These will be the links used in the View Submissions view and View Review Report view so that the grading trail for an assignments submission and reviews are seperate.
*Modified grades controller, so that every time, a grade is submitted or edited, grading_history_controller.rb will call a method to create an entry that saves into the database.
'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

This is the design plan in which they followed:

[[File:E1869 Grading Audit Trails UML.jpg]]

===[https://wiki-expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2022_-_E2237:_Grading_audit_trail E2237]===

*They fixed some issues that were causing the system to crash during testing
*Altered the Grading History view
*Explained the reasoning for changes made to files using diagrams and justifications
'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

This is the updated design flow in which they created to improve previous implementations further:

[[File:Kai diagram1.jpg]]

=='''Proposed Solution'''==
We plan on using the implementation of E2237 since it is the latest in the Grading Audit Trail projects and has the latest in terms of testing. These files cannot be added haphazardly since parts of the implementation is a cause to concern and caused the changes to not be implemented. It is also using an older version of expertiza so some parts may not be compatible.

We must first figure out exactly what changes and issues to address in their implementation by meeting with our mentor. We also need to reimplement the following files since none of their changes were implemented:

*app/controllers/grading_histories_controller.rb
'''
Calls the grading history view after validating Submission and Review Type.

'''

*app/models/grading_history.rb
'''
Model for Grading History.
'''

*app/models/review_grading_history.rb

'''
Model containing specifics of Review Grading History. Inherits Grading History.
'''

*app/models/submission_grading_history.rb
'''
Model containing specifics of Submission Grading History. Inherits Grading History.
'''

*app/views/grading_history/index_html.erb
'''
This is a view for grading audit trail, it will display all grading histories of a
submission/review
'''

*spec/features/grade_histories_spec.rb

'''
Feature test to check if the grades appear in chronological order
'''

*spec/features/helpers/grade_histories_helper.rb

'''
Helper file to facilitate the above mentioned feature test.
'''

=='''Reimplementation'''==
Since the previous teams implementations were not integrated we have to reimplement their files which we will do by looking at their commits and pull request to see what files are necessary and what can be left out to address the issues of their implementation.

'''[https://github.com/ErikLG360/expertiza/commit/e28a857695549cc91c477587707e48100d2bd333 Files being Reimplemented/Modified]'''

'''Reimplemented'''
*app/controllers/grading_histories_controller.rb
'''
This file was added to deal with allowing only the correct people to view the grading history, checking the assignment type whether it be a submission or review, and indexing all the grading history for the assignment in chronological order.
'''
*app/models/grading_history.rb
'''
This file was added to create the relationships that the grading history has with an instructor who is creating the parts of the grading history and the assignments that will have a grading history.
'''
*app/models/review_grading_history.rb
'''
This file creates the relationship that a participant will have a Review Grading History
'''
*app/models/submission_grading_history.rb
'''
This file create the relationship that a participant/grade_reciever will have a Submission Grading History
'''

*app/views/grading_histories/index.html.erb
'''
This file contains the view for the grading history table which will change depending on if its a Review or submission type
'''
*app/views/grading_histories/_form.html.erb
'''
This file contains the view for when a grading history contains any error when it is about to be saved
'''

'''Modified'''
*app/controllers/grades_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_submission was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of submissions and not reviews.
'''
*app/controllers/review_mapping_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_reviewer was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of reviews and not submissions.
'''
*app/views/assignments/list_submissions.html.erb
'''
It was modified to add the new hyperlink to display the grading history of a submission.
'''
*config/routes.rb
'''
It was to add the new route for grading histories
'''

=='''Solutions - Implemented'''==

'''E1934'''

'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

'''Solutions'''
:1. Found the correct location to put the Review Grading History link and also fix the previous teams creation of a grading history to work with the latest expertiza update.
Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/controllers/review_mapping_controller.rb]
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/views/reports/_review_report.html.erb]

:2. The previous implementatation of E2237 tackled this problem and moved it to the title.
[[File:GradingTableTitle.png]]
:3. The column widths were lessened by about 15px in the grading record page

Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/124bd12d23f75db0a68e2fac8a8487c5f7a7ed67 app/views/grading_histories/index.html.erb]

:4. There were no code climate issues regarding this issue

:5. All code climate changes are their own commits such as [https://github.com/ErikLG360/expertiza/commit/e95656f4d5e4f2ba4fc8d3f40716673ccafb41b1 This]

:6. This issue was resolved by not adding in their implementation for the list_review_mapping.html.erb

:7. This issue was resolved by not adding in the review_report_html.erb file

:8. This issue is resolved in the '''Reimplementation''' section of this document

'''E2237'''

'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

'''Solutions'''
:1. These files have not been added.
:2. The authentication already used the necessary parts
:3. The column width was reduced by 15px refer to the solution for E1934 number 3.
:4. Code for the review_mapping_controller was changed to match the current state of expertiza refer to the solution for E1934 number 1.

=='''Resulting Views'''==
This is the view in the view submissions page that displays the link for the Submissions Grading History which is circled in red.
[[File:SubmissionsGradingHistoryLink.jpeg]]

This is the resulting view after clicking the link:
[[File:SubmissionGradingHist.png]]

This is the view in the review report page that displays the link for the Reviews Grading History which is circled in red.
[[File:ReviewGradingHistoryLink.jpeg]]

This is the resulting view after clicking the Reviews Grading History link:
[[File:ReviewsGradingHist.png]]

=='''Testing Plan'''==

=== Rspec Unit Tests ===

==== For History of the Grades ====
The history of the grade and comments are related to the new model grading_history.rb and the new controller grading_history_controller.rb.

So the related RSpec tests are planned to be executed:

spec/controllers/grading_history_controller_test.rb

For the feature part, test if the grading history and instructor can be shown in chronological order:

spec/features/grade_histories_spec.rb
spec/helpers/grade_histories_helper_spec.rb

The link to test files inorder to test the creation of grading history with valid parameters is https://github.com/expertiza/expertiza/commit/067b52315ac1ff7ce1b89fc44121393cadbabc6a

=== Manual UI Tests ===
To start the test, we need to log in as instructor or TA first. These accounts should have access to the assignment. For example: we can use '''intructor6/password'''

==== Scenario 1: Grading histories of submissions ====
Step 1. Log in as instructor -> Manage -> Assignments -> View submissions
 
[[File:E2158_view_submisson.png|1100px]]
 
 
Step 2. The instructor can assign grades to a team by clicking 'Assign Grade' in the 'Team name' column:
 
[[File:E2158_grading_history_submisson1.png|1100px]]
 
 
Step 3. The instructor can view the grading audit trail by clicking 'Grading History' in the 'History' column, here is the record page:
 
[[File:E2158_grading_history_submisson2.png|1100px]]
 
 
==== Scenario 2: Grading histories of reviews ====
Step 1. Log in as instructor -> Manage -> Assignments -> View Reports
 
[[File:E2158_view_report.png|1100px]]
 
 
Step 2. Select 'Review Report' then click 'View', here is the Review Report page. The instructor can assign grades to a review by inputing 'Grade' and 'Comment' then clicking 'Save' button:
 
[[File:E2158_grading_history_report1.png|1100px]]
 
 
Step 3. The instructor/TA can view the grading audit trail by clicking 'Grading History' as Step 2 figure shows, here is the record page:
 
[[File:E2158_grading_history_report2.png|1100px]]
 
 

=='''Future Scope'''==
This project may need further improvement since it does not seem like there should be an abundance of files added and perhaps using the MVC design is not necessarily needed. There can also be a reduction of code since the difference between the two main grading histories is just whether it is a review or submission type.

=='''Relevant Links'''==
* '''Github Repository:''' https://github.com/ErikLG360/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2696
* '''VCL Server (Valid until 12/15/23):''' http://152.7.179.44:8080
* '''Video:''' https://drive.google.com/file/d/1HIrJtCsbZXSqGPHShuV6mbSTOKvV5MxT/view?usp=drive_link

=='''Contributors to this project'''==
*Amulya Usem
*Erik Lopez-Godinez
*Gowtham Pollam

*'''Mentor''': Srilekha Gudipati

File:Screenshot 2023-12-05 at 12.02.23 AM.png

2023-12-05T05:05:29Z

Ausem:

File:Screenshot 2023-12-05 at 12.02.05 AM.png

2023-12-05T05:05:06Z

Ausem:

CSC/ECE 517 Fall 2023 - E2383. Grading Audit Trail

2023-12-05T05:01:30Z

Ausem: /* Solutions - Implemented */

=='''Introduction'''==

===Problem Statement===
In the current implementation of expertiza, any instructor can assign or edit a grade but there is no way to track who gave the grade and when.

A grading audit trail must be created and the following information needs to be stored:

1. When a grade is assigned by an instructor, there needs to be an indication of who did it and when it was done.
2. Comments previously provided by other instructors must also be preserved.
This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

Currently, there are two places need to add grading audit trail:

1. Review grade: Log in as instructor -> Manage -> Assignments -> View Review Report
2. Submission grade: Log in as instructor -> Manage -> Assignments -> View submissions
The grading audit trail can probably be implemented as the submission records history on Expertiza. The required page can be reached by logging in as instructor -> Manage -> Assignments -> View Submissions -> History

At the minimum, a grading log entry must include the instructor id, assignment id, student id, grade, comment and timestamp.

Previous student teams have attempted to implement this functionality, but their implementations had issues. Our solution will build on the work of teams E1934 and E2237, addressing the problems in their implementations.

== '''Overview of Major Changes By Previous Teams''' ==
===[https://wiki-expertiza.csc.ncsu.edu/index.php/E1934_-_Grading_Audit_Trail E1934]===
[https://youtu.be/yyxX_kRYxLc Their Screencast]

*Created a database called grading_history to store elements for the Grading Audit Trail (instructor id, assignment id, grade tyoe, student id, grade, comment and timestamp)
*Used MVC design to create a model, a controller, and a view for both of Review Grade and Submission Grade. These will be the links used in the View Submissions view and View Review Report view so that the grading trail for an assignments submission and reviews are seperate.
*Modified grades controller, so that every time, a grade is submitted or edited, grading_history_controller.rb will call a method to create an entry that saves into the database.
'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

===[https://wiki-expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2022_-_E2237:_Grading_audit_trail E2237]===

*They fixed some issues that were causing the system to crash during testing
*Altered the Grading History view
*Explained the reasoning for changes made to files using diagrams and justifications
'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

=='''Proposed Solution'''==
We plan on using the implementation of E2237 since it is the latest in the Grading Audit Trail projects and has the latest in terms of testing. These files cannot be added haphazardly since parts of the implementation is a cause to concern and caused the changes to not be implemented. It is also using an older version of expertiza so some parts may not be compatible.

We must first figure out exactly what changes and issues to address in their implementation by meeting with our mentor. We also need to reimplement the following files since none of their changes were implemented:

*app/controllers/grading_histories_controller.rb
'''
Calls the grading history view after validating Submission and Review Type.

'''

*app/models/grading_history.rb
'''
Model for Grading History.
'''

*app/models/review_grading_history.rb

'''
Model containing specifics of Review Grading History. Inherits Grading History.
'''

*app/models/submission_grading_history.rb
'''
Model containing specifics of Submission Grading History. Inherits Grading History.
'''

*app/views/grading_history/index_html.erb
'''
This is a view for grading audit trail, it will display all grading histories of a
submission/review
'''

*spec/features/grade_histories_spec.rb

'''
Feature test to check if the grades appear in chronological order
'''

*spec/features/helpers/grade_histories_helper.rb

'''
Helper file to facilitate the above mentioned feature test.
'''

=='''Reimplementation'''==
Since the previous teams implementations were not integrated we have to reimplement their files which we will do by looking at their commits and pull request to see what files are necessary and what can be left out to address the issues of their implementation.

'''[https://github.com/ErikLG360/expertiza/commit/e28a857695549cc91c477587707e48100d2bd333 Files being Reimplemented/Modified]'''

'''Reimplemented'''
*app/controllers/grading_histories_controller.rb
'''
This file was added to deal with allowing only the correct people to view the grading history, checking the assignment type whether it be a submission or review, and indexing all the grading history for the assignment in chronological order.
'''
*app/models/grading_history.rb
'''
This file was added to create the relationships that the grading history has with an instructor who is creating the parts of the grading history and the assignments that will have a grading history.
'''
*app/models/review_grading_history.rb
'''
This file creates the relationship that a participant will have a Review Grading History
'''
*app/models/submission_grading_history.rb
'''
This file create the relationship that a participant/grade_reciever will have a Submission Grading History
'''

*app/views/grading_histories/index.html.erb
'''
This file contains the view for the grading history table which will change depending on if its a Review or submission type
'''
*app/views/grading_histories/_form.html.erb
'''
This file contains the view for when a grading history contains any error when it is about to be saved
'''

'''Modified'''
*app/controllers/grades_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_submission was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of submissions and not reviews.
'''
*app/controllers/review_mapping_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_reviewer was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of reviews and not submissions.
'''
*app/views/assignments/list_submissions.html.erb
'''
It was modified to add the new hyperlink to display the grading history of a submission.
'''
*config/routes.rb
'''
It was to add the new route for grading histories
'''

=='''Solutions - Implemented'''==

'''E1934'''

'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

'''Solutions'''
:1. Found the correct location to put the Review Grading History link and also fix the previous teams creation of a grading history to work with the latest expertiza update.
Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/controllers/review_mapping_controller.rb]
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/views/reports/_review_report.html.erb]

:2. The previous implementatation of E2237 tackled this problem and moved it to the title.
[[File:GradingTableTitle.png]]
:3. The column widths were lessened by about 15px in the grading record page

Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/124bd12d23f75db0a68e2fac8a8487c5f7a7ed67 app/views/grading_histories/index.html.erb]

:4. There were no code climate issues regarding this issue

:5. All code climate changes are their own commits such as [https://github.com/ErikLG360/expertiza/commit/e95656f4d5e4f2ba4fc8d3f40716673ccafb41b1 This]

:6. This issue was resolved by not adding in their implementation for the list_review_mapping.html.erb

:7. This issue was resolved by not adding in the review_report_html.erb file

:8. This issue is resolved in the '''Reimplementation''' section of this document

'''E2237'''

'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

'''Solutions'''
:1. These files have not been added.
:2. The authentication already used the necessary parts
:3. The column width was reduced by 15px refer to the solution for E1934 number 3.
:4. Code for the review_mapping_controller was changed to match the current state of expertiza refer to the solution for E1934 number 1.

=='''Testing Plan'''==
We have added a test case to test if a grading history is getting created when valid parameters are used.
The files include
spec/controllers/grading_histories_controller_test.rb
spec/factories/factories.rb
spec/features/grade_histories_spec.rb
spec/helpers/grade_histories_helper_spec.rb

https://github.com/expertiza/expertiza/commit/067b52315ac1ff7ce1b89fc44121393cadbabc6a

=='''Future Scope'''==
This project may need further improvement since it does not seem like there should be an abundance of files added and perhaps using the MVC design is not necessarily needed. There can also be a reduction of code since the difference between the two main grading histories is just whether it is a review or submission type.

=='''Relevant Links'''==
* '''Github Repository:''' https://github.com/ErikLG360/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2696
* '''VCL Server (Valid until 12/15/23):''' http://152.7.179.44:8080
* '''Video:''' https://drive.google.com/file/d/1HIrJtCsbZXSqGPHShuV6mbSTOKvV5MxT/view?usp=drive_link

=='''Contributors to this project'''==
*Amulya Usem
*Erik Lopez-Godinez
*Gowtham Pollam

*'''Mentor''': Srilekha Gudipati

CSC/ECE 517 Fall 2023 - E2383. Grading Audit Trail

2023-12-05T05:00:40Z

Ausem: /* Testing Plan */

=='''Introduction'''==

===Problem Statement===
In the current implementation of expertiza, any instructor can assign or edit a grade but there is no way to track who gave the grade and when.

A grading audit trail must be created and the following information needs to be stored:

1. When a grade is assigned by an instructor, there needs to be an indication of who did it and when it was done.
2. Comments previously provided by other instructors must also be preserved.
This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

Currently, there are two places need to add grading audit trail:

1. Review grade: Log in as instructor -> Manage -> Assignments -> View Review Report
2. Submission grade: Log in as instructor -> Manage -> Assignments -> View submissions
The grading audit trail can probably be implemented as the submission records history on Expertiza. The required page can be reached by logging in as instructor -> Manage -> Assignments -> View Submissions -> History

At the minimum, a grading log entry must include the instructor id, assignment id, student id, grade, comment and timestamp.

Previous student teams have attempted to implement this functionality, but their implementations had issues. Our solution will build on the work of teams E1934 and E2237, addressing the problems in their implementations.

== '''Overview of Major Changes By Previous Teams''' ==
===[https://wiki-expertiza.csc.ncsu.edu/index.php/E1934_-_Grading_Audit_Trail E1934]===
[https://youtu.be/yyxX_kRYxLc Their Screencast]

*Created a database called grading_history to store elements for the Grading Audit Trail (instructor id, assignment id, grade tyoe, student id, grade, comment and timestamp)
*Used MVC design to create a model, a controller, and a view for both of Review Grade and Submission Grade. These will be the links used in the View Submissions view and View Review Report view so that the grading trail for an assignments submission and reviews are seperate.
*Modified grades controller, so that every time, a grade is submitted or edited, grading_history_controller.rb will call a method to create an entry that saves into the database.
'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

===[https://wiki-expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2022_-_E2237:_Grading_audit_trail E2237]===

*They fixed some issues that were causing the system to crash during testing
*Altered the Grading History view
*Explained the reasoning for changes made to files using diagrams and justifications
'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

=='''Proposed Solution'''==
We plan on using the implementation of E2237 since it is the latest in the Grading Audit Trail projects and has the latest in terms of testing. These files cannot be added haphazardly since parts of the implementation is a cause to concern and caused the changes to not be implemented. It is also using an older version of expertiza so some parts may not be compatible.

We must first figure out exactly what changes and issues to address in their implementation by meeting with our mentor. We also need to reimplement the following files since none of their changes were implemented:

*app/controllers/grading_histories_controller.rb
'''
Calls the grading history view after validating Submission and Review Type.

'''

*app/models/grading_history.rb
'''
Model for Grading History.
'''

*app/models/review_grading_history.rb

'''
Model containing specifics of Review Grading History. Inherits Grading History.
'''

*app/models/submission_grading_history.rb
'''
Model containing specifics of Submission Grading History. Inherits Grading History.
'''

*app/views/grading_history/index_html.erb
'''
This is a view for grading audit trail, it will display all grading histories of a
submission/review
'''

*spec/features/grade_histories_spec.rb

'''
Feature test to check if the grades appear in chronological order
'''

*spec/features/helpers/grade_histories_helper.rb

'''
Helper file to facilitate the above mentioned feature test.
'''

=='''Reimplementation'''==
Since the previous teams implementations were not integrated we have to reimplement their files which we will do by looking at their commits and pull request to see what files are necessary and what can be left out to address the issues of their implementation.

'''[https://github.com/ErikLG360/expertiza/commit/e28a857695549cc91c477587707e48100d2bd333 Files being Reimplemented/Modified]'''

'''Reimplemented'''
*app/controllers/grading_histories_controller.rb
'''
This file was added to deal with allowing only the correct people to view the grading history, checking the assignment type whether it be a submission or review, and indexing all the grading history for the assignment in chronological order.
'''
*app/models/grading_history.rb
'''
This file was added to create the relationships that the grading history has with an instructor who is creating the parts of the grading history and the assignments that will have a grading history.
'''
*app/models/review_grading_history.rb
'''
This file creates the relationship that a participant will have a Review Grading History
'''
*app/models/submission_grading_history.rb
'''
This file create the relationship that a participant/grade_reciever will have a Submission Grading History
'''

*app/views/grading_histories/index.html.erb
'''
This file contains the view for the grading history table which will change depending on if its a Review or submission type
'''
*app/views/grading_histories/_form.html.erb
'''
This file contains the view for when a grading history contains any error when it is about to be saved
'''

'''Modified'''
*app/controllers/grades_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_submission was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of submissions and not reviews.
'''
*app/controllers/review_mapping_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_reviewer was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of reviews and not submissions.
'''
*app/views/assignments/list_submissions.html.erb
'''
It was modified to add the new hyperlink to display the grading history of a submission.
'''
*config/routes.rb
'''
It was to add the new route for grading histories
'''

=='''Solutions - Implemented'''==

'''E1934'''

'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

'''Solutions'''
:1. Found the correct location to put the Review Grading History link and also fix the previous teams creation of a grading history to work with the latest expertiza update.
Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/controllers/review_mapping_controller.rb]
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/views/reports/_review_report.html.erb]

:2. The previous implementatation of E2237 tackled this problem and moved it to the title.
[[File:GradingTableTitle.png]]
:3. The column widths were lessened by about 15px in the grading record page

Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/124bd12d23f75db0a68e2fac8a8487c5f7a7ed67 app/views/grading_histories/index.html.erb]

:4. There were no code climate issues regarding this issue

:5. All code climate changes are their own commits such as [https://github.com/ErikLG360/expertiza/commit/e95656f4d5e4f2ba4fc8d3f40716673ccafb41b1 This]

:6. This issue was resolved by not adding in their implementation for the list_review_mapping.html.erb

:7. This issue was resolved by not adding in the review_report_html.erb file

:8. This issue is resolved in the '''Reimplementation''' section of this document

'''E2237'''

'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

'''Solutions'''
:1. These files have not been reimplemented.
:2. The authentication already used the necessary parts
:3. The column width was reduced by 15px refer to the solution for E1934 number 3.
:4. Code for the review_mapping_controller was changed to match the current state of expertiza refer to the solution for E1934 number 1.

=='''Testing Plan'''==
We have added a test case to test if a grading history is getting created when valid parameters are used.
The files include
spec/controllers/grading_histories_controller_test.rb
spec/factories/factories.rb
spec/features/grade_histories_spec.rb
spec/helpers/grade_histories_helper_spec.rb

https://github.com/expertiza/expertiza/commit/067b52315ac1ff7ce1b89fc44121393cadbabc6a

=='''Future Scope'''==
This project may need further improvement since it does not seem like there should be an abundance of files added and perhaps using the MVC design is not necessarily needed. There can also be a reduction of code since the difference between the two main grading histories is just whether it is a review or submission type.

=='''Relevant Links'''==
* '''Github Repository:''' https://github.com/ErikLG360/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2696
* '''VCL Server (Valid until 12/15/23):''' http://152.7.179.44:8080
* '''Video:''' https://drive.google.com/file/d/1HIrJtCsbZXSqGPHShuV6mbSTOKvV5MxT/view?usp=drive_link

=='''Contributors to this project'''==
*Amulya Usem
*Erik Lopez-Godinez
*Gowtham Pollam

*'''Mentor''': Srilekha Gudipati

CSC/ECE 517 Fall 2023 - E2383. Grading Audit Trail

2023-12-05T05:00:26Z

Ausem: /* Testing Plan */

=='''Introduction'''==

===Problem Statement===
In the current implementation of expertiza, any instructor can assign or edit a grade but there is no way to track who gave the grade and when.

A grading audit trail must be created and the following information needs to be stored:

1. When a grade is assigned by an instructor, there needs to be an indication of who did it and when it was done.
2. Comments previously provided by other instructors must also be preserved.
This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

Currently, there are two places need to add grading audit trail:

1. Review grade: Log in as instructor -> Manage -> Assignments -> View Review Report
2. Submission grade: Log in as instructor -> Manage -> Assignments -> View submissions
The grading audit trail can probably be implemented as the submission records history on Expertiza. The required page can be reached by logging in as instructor -> Manage -> Assignments -> View Submissions -> History

At the minimum, a grading log entry must include the instructor id, assignment id, student id, grade, comment and timestamp.

Previous student teams have attempted to implement this functionality, but their implementations had issues. Our solution will build on the work of teams E1934 and E2237, addressing the problems in their implementations.

== '''Overview of Major Changes By Previous Teams''' ==
===[https://wiki-expertiza.csc.ncsu.edu/index.php/E1934_-_Grading_Audit_Trail E1934]===
[https://youtu.be/yyxX_kRYxLc Their Screencast]

*Created a database called grading_history to store elements for the Grading Audit Trail (instructor id, assignment id, grade tyoe, student id, grade, comment and timestamp)
*Used MVC design to create a model, a controller, and a view for both of Review Grade and Submission Grade. These will be the links used in the View Submissions view and View Review Report view so that the grading trail for an assignments submission and reviews are seperate.
*Modified grades controller, so that every time, a grade is submitted or edited, grading_history_controller.rb will call a method to create an entry that saves into the database.
'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

===[https://wiki-expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2022_-_E2237:_Grading_audit_trail E2237]===

*They fixed some issues that were causing the system to crash during testing
*Altered the Grading History view
*Explained the reasoning for changes made to files using diagrams and justifications
'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

=='''Proposed Solution'''==
We plan on using the implementation of E2237 since it is the latest in the Grading Audit Trail projects and has the latest in terms of testing. These files cannot be added haphazardly since parts of the implementation is a cause to concern and caused the changes to not be implemented. It is also using an older version of expertiza so some parts may not be compatible.

We must first figure out exactly what changes and issues to address in their implementation by meeting with our mentor. We also need to reimplement the following files since none of their changes were implemented:

*app/controllers/grading_histories_controller.rb
'''
Calls the grading history view after validating Submission and Review Type.

'''

*app/models/grading_history.rb
'''
Model for Grading History.
'''

*app/models/review_grading_history.rb

'''
Model containing specifics of Review Grading History. Inherits Grading History.
'''

*app/models/submission_grading_history.rb
'''
Model containing specifics of Submission Grading History. Inherits Grading History.
'''

*app/views/grading_history/index_html.erb
'''
This is a view for grading audit trail, it will display all grading histories of a
submission/review
'''

*spec/features/grade_histories_spec.rb

'''
Feature test to check if the grades appear in chronological order
'''

*spec/features/helpers/grade_histories_helper.rb

'''
Helper file to facilitate the above mentioned feature test.
'''

=='''Reimplementation'''==
Since the previous teams implementations were not integrated we have to reimplement their files which we will do by looking at their commits and pull request to see what files are necessary and what can be left out to address the issues of their implementation.

'''[https://github.com/ErikLG360/expertiza/commit/e28a857695549cc91c477587707e48100d2bd333 Files being Reimplemented/Modified]'''

'''Reimplemented'''
*app/controllers/grading_histories_controller.rb
'''
This file was added to deal with allowing only the correct people to view the grading history, checking the assignment type whether it be a submission or review, and indexing all the grading history for the assignment in chronological order.
'''
*app/models/grading_history.rb
'''
This file was added to create the relationships that the grading history has with an instructor who is creating the parts of the grading history and the assignments that will have a grading history.
'''
*app/models/review_grading_history.rb
'''
This file creates the relationship that a participant will have a Review Grading History
'''
*app/models/submission_grading_history.rb
'''
This file create the relationship that a participant/grade_reciever will have a Submission Grading History
'''

*app/views/grading_histories/index.html.erb
'''
This file contains the view for the grading history table which will change depending on if its a Review or submission type
'''
*app/views/grading_histories/_form.html.erb
'''
This file contains the view for when a grading history contains any error when it is about to be saved
'''

'''Modified'''
*app/controllers/grades_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_submission was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of submissions and not reviews.
'''
*app/controllers/review_mapping_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_reviewer was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of reviews and not submissions.
'''
*app/views/assignments/list_submissions.html.erb
'''
It was modified to add the new hyperlink to display the grading history of a submission.
'''
*config/routes.rb
'''
It was to add the new route for grading histories
'''

=='''Solutions - Implemented'''==

'''E1934'''

'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

'''Solutions'''
:1. Found the correct location to put the Review Grading History link and also fix the previous teams creation of a grading history to work with the latest expertiza update.
Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/controllers/review_mapping_controller.rb]
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/views/reports/_review_report.html.erb]

:2. The previous implementatation of E2237 tackled this problem and moved it to the title.
[[File:GradingTableTitle.png]]
:3. The column widths were lessened by about 15px in the grading record page

Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/124bd12d23f75db0a68e2fac8a8487c5f7a7ed67 app/views/grading_histories/index.html.erb]

:4. There were no code climate issues regarding this issue

:5. All code climate changes are their own commits such as [https://github.com/ErikLG360/expertiza/commit/e95656f4d5e4f2ba4fc8d3f40716673ccafb41b1 This]

:6. This issue was resolved by not adding in their implementation for the list_review_mapping.html.erb

:7. This issue was resolved by not adding in the review_report_html.erb file

:8. This issue is resolved in the '''Reimplementation''' section of this document

'''E2237'''

'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

'''Solutions'''
:1. These files have not been reimplemented.
:2. The authentication already used the necessary parts
:3. The column width was reduced by 15px refer to the solution for E1934 number 3.
:4. Code for the review_mapping_controller was changed to match the current state of expertiza refer to the solution for E1934 number 1.

=='''Testing Plan'''==
We have added a test case to test if a grading history is getting created when valid parameters are used.
The files include
spec/controllers/grading_histories_controller_test.rb
spec/factories/factories.rb
spec/features/grade_histories_spec.rb
spec/helpers/grade_histories_helper_spec.rb

https://github.com/expertiza/expertiza/commit/067b52315ac1ff7ce1b89fc44121393cadbabc6a[https://github.com/expertiza/expertiza/commit/067b52315ac1ff7ce1b89fc44121393cadbabc6a]

=='''Future Scope'''==
This project may need further improvement since it does not seem like there should be an abundance of files added and perhaps using the MVC design is not necessarily needed. There can also be a reduction of code since the difference between the two main grading histories is just whether it is a review or submission type.

=='''Relevant Links'''==
* '''Github Repository:''' https://github.com/ErikLG360/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2696
* '''VCL Server (Valid until 12/15/23):''' http://152.7.179.44:8080
* '''Video:''' https://drive.google.com/file/d/1HIrJtCsbZXSqGPHShuV6mbSTOKvV5MxT/view?usp=drive_link

=='''Contributors to this project'''==
*Amulya Usem
*Erik Lopez-Godinez
*Gowtham Pollam

*'''Mentor''': Srilekha Gudipati

CSC/ECE 517 Fall 2023 - E2383. Grading Audit Trail

2023-12-05T04:59:46Z

Ausem: /* Testing Plan */

=='''Introduction'''==

===Problem Statement===
In the current implementation of expertiza, any instructor can assign or edit a grade but there is no way to track who gave the grade and when.

A grading audit trail must be created and the following information needs to be stored:

1. When a grade is assigned by an instructor, there needs to be an indication of who did it and when it was done.
2. Comments previously provided by other instructors must also be preserved.
This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

Currently, there are two places need to add grading audit trail:

1. Review grade: Log in as instructor -> Manage -> Assignments -> View Review Report
2. Submission grade: Log in as instructor -> Manage -> Assignments -> View submissions
The grading audit trail can probably be implemented as the submission records history on Expertiza. The required page can be reached by logging in as instructor -> Manage -> Assignments -> View Submissions -> History

At the minimum, a grading log entry must include the instructor id, assignment id, student id, grade, comment and timestamp.

Previous student teams have attempted to implement this functionality, but their implementations had issues. Our solution will build on the work of teams E1934 and E2237, addressing the problems in their implementations.

== '''Overview of Major Changes By Previous Teams''' ==
===[https://wiki-expertiza.csc.ncsu.edu/index.php/E1934_-_Grading_Audit_Trail E1934]===
[https://youtu.be/yyxX_kRYxLc Their Screencast]

*Created a database called grading_history to store elements for the Grading Audit Trail (instructor id, assignment id, grade tyoe, student id, grade, comment and timestamp)
*Used MVC design to create a model, a controller, and a view for both of Review Grade and Submission Grade. These will be the links used in the View Submissions view and View Review Report view so that the grading trail for an assignments submission and reviews are seperate.
*Modified grades controller, so that every time, a grade is submitted or edited, grading_history_controller.rb will call a method to create an entry that saves into the database.
'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

===[https://wiki-expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2022_-_E2237:_Grading_audit_trail E2237]===

*They fixed some issues that were causing the system to crash during testing
*Altered the Grading History view
*Explained the reasoning for changes made to files using diagrams and justifications
'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

=='''Proposed Solution'''==
We plan on using the implementation of E2237 since it is the latest in the Grading Audit Trail projects and has the latest in terms of testing. These files cannot be added haphazardly since parts of the implementation is a cause to concern and caused the changes to not be implemented. It is also using an older version of expertiza so some parts may not be compatible.

We must first figure out exactly what changes and issues to address in their implementation by meeting with our mentor. We also need to reimplement the following files since none of their changes were implemented:

*app/controllers/grading_histories_controller.rb
'''
Calls the grading history view after validating Submission and Review Type.

'''

*app/models/grading_history.rb
'''
Model for Grading History.
'''

*app/models/review_grading_history.rb

'''
Model containing specifics of Review Grading History. Inherits Grading History.
'''

*app/models/submission_grading_history.rb
'''
Model containing specifics of Submission Grading History. Inherits Grading History.
'''

*app/views/grading_history/index_html.erb
'''
This is a view for grading audit trail, it will display all grading histories of a
submission/review
'''

*spec/features/grade_histories_spec.rb

'''
Feature test to check if the grades appear in chronological order
'''

*spec/features/helpers/grade_histories_helper.rb

'''
Helper file to facilitate the above mentioned feature test.
'''

=='''Reimplementation'''==
Since the previous teams implementations were not integrated we have to reimplement their files which we will do by looking at their commits and pull request to see what files are necessary and what can be left out to address the issues of their implementation.

'''[https://github.com/ErikLG360/expertiza/commit/e28a857695549cc91c477587707e48100d2bd333 Files being Reimplemented/Modified]'''

'''Reimplemented'''
*app/controllers/grading_histories_controller.rb
'''
This file was added to deal with allowing only the correct people to view the grading history, checking the assignment type whether it be a submission or review, and indexing all the grading history for the assignment in chronological order.
'''
*app/models/grading_history.rb
'''
This file was added to create the relationships that the grading history has with an instructor who is creating the parts of the grading history and the assignments that will have a grading history.
'''
*app/models/review_grading_history.rb
'''
This file creates the relationship that a participant will have a Review Grading History
'''
*app/models/submission_grading_history.rb
'''
This file create the relationship that a participant/grade_reciever will have a Submission Grading History
'''

*app/views/grading_histories/index.html.erb
'''
This file contains the view for the grading history table which will change depending on if its a Review or submission type
'''
*app/views/grading_histories/_form.html.erb
'''
This file contains the view for when a grading history contains any error when it is about to be saved
'''

'''Modified'''
*app/controllers/grades_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_submission was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of submissions and not reviews.
'''
*app/controllers/review_mapping_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_reviewer was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of reviews and not submissions.
'''
*app/views/assignments/list_submissions.html.erb
'''
It was modified to add the new hyperlink to display the grading history of a submission.
'''
*config/routes.rb
'''
It was to add the new route for grading histories
'''

=='''Solutions - Implemented'''==

'''E1934'''

'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

'''Solutions'''
:1. Found the correct location to put the Review Grading History link and also fix the previous teams creation of a grading history to work with the latest expertiza update.
Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/controllers/review_mapping_controller.rb]
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/views/reports/_review_report.html.erb]

:2. The previous implementatation of E2237 tackled this problem and moved it to the title.
[[File:GradingTableTitle.png]]
:3. The column widths were lessened by about 15px in the grading record page

Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/124bd12d23f75db0a68e2fac8a8487c5f7a7ed67 app/views/grading_histories/index.html.erb]

:4.

:5. All code climate changes are their own commits such as [https://github.com/ErikLG360/expertiza/commit/e95656f4d5e4f2ba4fc8d3f40716673ccafb41b1 This]

:6. This issue was resolved by not adding in their implementation for the list_review_mapping.html.erb

:7. This issue was resolved by not adding in the review_report_html.erb file

:8. This issue is resolved in the '''Reimplementation''' section of this document

'''E2237'''

'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

'''Solutions'''
:1. These files have not been reimplemented.
:2.
:3. The column width was reduced by 15px refer to the solution for E1934 number 3.
:4. Code for the review_mapping_controller was changed to match the current state of expertiza refer to the solution for E1934 number 1.

=='''Testing Plan'''==
We have added a test case to test if a grading history is getting created when valid parameters are used.
The files include
spec/controllers/grading_histories_controller_test.rb
spec/factories/factories.rb
spec/features/grade_histories_spec.rb
spec/helpers/grade_histories_helper_spec.rb

[[[https://github.com/expertiza/expertiza/commit/067b52315ac1ff7ce1b89fc44121393cadbabc6a]
]]

=='''Future Scope'''==
This project may need further improvement since it does not seem like there should be an abundance of files added and perhaps using the MVC design is not necessarily needed. There can also be a reduction of code since the difference between the two main grading histories is just whether it is a review or submission type.

=='''Relevant Links'''==
* '''Github Repository:''' https://github.com/ErikLG360/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2696
* '''VCL Server (Valid until 12/15/23):''' http://152.7.179.44:8080
* '''Video:''' https://drive.google.com/file/d/1HIrJtCsbZXSqGPHShuV6mbSTOKvV5MxT/view?usp=drive_link

=='''Contributors to this project'''==
*Amulya Usem
*Erik Lopez-Godinez
*Gowtham Pollam

*'''Mentor''': Srilekha Gudipati

CSC/ECE 517 Fall 2023 - E2383. Grading Audit Trail

2023-12-05T04:58:59Z

Ausem: /* Reimplementation */

=='''Introduction'''==

===Problem Statement===
In the current implementation of expertiza, any instructor can assign or edit a grade but there is no way to track who gave the grade and when.

A grading audit trail must be created and the following information needs to be stored:

1. When a grade is assigned by an instructor, there needs to be an indication of who did it and when it was done.
2. Comments previously provided by other instructors must also be preserved.
This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

Currently, there are two places need to add grading audit trail:

1. Review grade: Log in as instructor -> Manage -> Assignments -> View Review Report
2. Submission grade: Log in as instructor -> Manage -> Assignments -> View submissions
The grading audit trail can probably be implemented as the submission records history on Expertiza. The required page can be reached by logging in as instructor -> Manage -> Assignments -> View Submissions -> History

At the minimum, a grading log entry must include the instructor id, assignment id, student id, grade, comment and timestamp.

Previous student teams have attempted to implement this functionality, but their implementations had issues. Our solution will build on the work of teams E1934 and E2237, addressing the problems in their implementations.

== '''Overview of Major Changes By Previous Teams''' ==
===[https://wiki-expertiza.csc.ncsu.edu/index.php/E1934_-_Grading_Audit_Trail E1934]===
[https://youtu.be/yyxX_kRYxLc Their Screencast]

*Created a database called grading_history to store elements for the Grading Audit Trail (instructor id, assignment id, grade tyoe, student id, grade, comment and timestamp)
*Used MVC design to create a model, a controller, and a view for both of Review Grade and Submission Grade. These will be the links used in the View Submissions view and View Review Report view so that the grading trail for an assignments submission and reviews are seperate.
*Modified grades controller, so that every time, a grade is submitted or edited, grading_history_controller.rb will call a method to create an entry that saves into the database.
'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

===[https://wiki-expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2022_-_E2237:_Grading_audit_trail E2237]===

*They fixed some issues that were causing the system to crash during testing
*Altered the Grading History view
*Explained the reasoning for changes made to files using diagrams and justifications
'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

=='''Proposed Solution'''==
We plan on using the implementation of E2237 since it is the latest in the Grading Audit Trail projects and has the latest in terms of testing. These files cannot be added haphazardly since parts of the implementation is a cause to concern and caused the changes to not be implemented. It is also using an older version of expertiza so some parts may not be compatible.

We must first figure out exactly what changes and issues to address in their implementation by meeting with our mentor. We also need to reimplement the following files since none of their changes were implemented:

*app/controllers/grading_histories_controller.rb
'''
Calls the grading history view after validating Submission and Review Type.

'''

*app/models/grading_history.rb
'''
Model for Grading History.
'''

*app/models/review_grading_history.rb

'''
Model containing specifics of Review Grading History. Inherits Grading History.
'''

*app/models/submission_grading_history.rb
'''
Model containing specifics of Submission Grading History. Inherits Grading History.
'''

*app/views/grading_history/index_html.erb
'''
This is a view for grading audit trail, it will display all grading histories of a
submission/review
'''

*spec/features/grade_histories_spec.rb

'''
Feature test to check if the grades appear in chronological order
'''

*spec/features/helpers/grade_histories_helper.rb

'''
Helper file to facilitate the above mentioned feature test.
'''

=='''Reimplementation'''==
Since the previous teams implementations were not integrated we have to reimplement their files which we will do by looking at their commits and pull request to see what files are necessary and what can be left out to address the issues of their implementation.

'''[https://github.com/ErikLG360/expertiza/commit/e28a857695549cc91c477587707e48100d2bd333 Files being Reimplemented/Modified]'''

'''Reimplemented'''
*app/controllers/grading_histories_controller.rb
'''
This file was added to deal with allowing only the correct people to view the grading history, checking the assignment type whether it be a submission or review, and indexing all the grading history for the assignment in chronological order.
'''
*app/models/grading_history.rb
'''
This file was added to create the relationships that the grading history has with an instructor who is creating the parts of the grading history and the assignments that will have a grading history.
'''
*app/models/review_grading_history.rb
'''
This file creates the relationship that a participant will have a Review Grading History
'''
*app/models/submission_grading_history.rb
'''
This file create the relationship that a participant/grade_reciever will have a Submission Grading History
'''

*app/views/grading_histories/index.html.erb
'''
This file contains the view for the grading history table which will change depending on if its a Review or submission type
'''
*app/views/grading_histories/_form.html.erb
'''
This file contains the view for when a grading history contains any error when it is about to be saved
'''

'''Modified'''
*app/controllers/grades_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_submission was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of submissions and not reviews.
'''
*app/controllers/review_mapping_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_reviewer was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of reviews and not submissions.
'''
*app/views/assignments/list_submissions.html.erb
'''
It was modified to add the new hyperlink to display the grading history of a submission.
'''
*config/routes.rb
'''
It was to add the new route for grading histories
'''

=='''Solutions - Implemented'''==

'''E1934'''

'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

'''Solutions'''
:1. Found the correct location to put the Review Grading History link and also fix the previous teams creation of a grading history to work with the latest expertiza update.
Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/controllers/review_mapping_controller.rb]
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/views/reports/_review_report.html.erb]

:2. The previous implementatation of E2237 tackled this problem and moved it to the title.
[[File:GradingTableTitle.png]]
:3. The column widths were lessened by about 15px in the grading record page

Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/124bd12d23f75db0a68e2fac8a8487c5f7a7ed67 app/views/grading_histories/index.html.erb]

:4.

:5. All code climate changes are their own commits such as [https://github.com/ErikLG360/expertiza/commit/e95656f4d5e4f2ba4fc8d3f40716673ccafb41b1 This]

:6. This issue was resolved by not adding in their implementation for the list_review_mapping.html.erb

:7. This issue was resolved by not adding in the review_report_html.erb file

:8. This issue is resolved in the '''Reimplementation''' section of this document

'''E2237'''

'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

'''Solutions'''
:1. These files have not been reimplemented.
:2.
:3. The column width was reduced by 15px refer to the solution for E1934 number 3.
:4. Code for the review_mapping_controller was changed to match the current state of expertiza refer to the solution for E1934 number 1.

=='''Testing Plan'''==
We have added a test case to test if a grading history is getting created when valid parameters are used.
The files include
spec/controllers/grading_histories_controller_test.rb
spec/factories/factories.rb
spec/features/grade_histories_spec.rb
spec/helpers/grade_histories_helper_spec.rb

[https://github.com/expertiza/expertiza/commit/067b52315ac1ff7ce1b89fc44121393cadbabc6a]

=='''Future Scope'''==
This project may need further improvement since it does not seem like there should be an abundance of files added and perhaps using the MVC design is not necessarily needed. There can also be a reduction of code since the difference between the two main grading histories is just whether it is a review or submission type.

=='''Relevant Links'''==
* '''Github Repository:''' https://github.com/ErikLG360/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2696
* '''VCL Server (Valid until 12/15/23):''' http://152.7.179.44:8080
* '''Video:''' https://drive.google.com/file/d/1HIrJtCsbZXSqGPHShuV6mbSTOKvV5MxT/view?usp=drive_link

=='''Contributors to this project'''==
*Amulya Usem
*Erik Lopez-Godinez
*Gowtham Pollam

*'''Mentor''': Srilekha Gudipati

CSC/ECE 517 Fall 2023 - E2383. Grading Audit Trail

2023-12-05T04:57:05Z

Ausem: /* Proposed Solution */

=='''Introduction'''==

===Problem Statement===
In the current implementation of expertiza, any instructor can assign or edit a grade but there is no way to track who gave the grade and when.

A grading audit trail must be created and the following information needs to be stored:

1. When a grade is assigned by an instructor, there needs to be an indication of who did it and when it was done.
2. Comments previously provided by other instructors must also be preserved.
This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

Currently, there are two places need to add grading audit trail:

1. Review grade: Log in as instructor -> Manage -> Assignments -> View Review Report
2. Submission grade: Log in as instructor -> Manage -> Assignments -> View submissions
The grading audit trail can probably be implemented as the submission records history on Expertiza. The required page can be reached by logging in as instructor -> Manage -> Assignments -> View Submissions -> History

At the minimum, a grading log entry must include the instructor id, assignment id, student id, grade, comment and timestamp.

Previous student teams have attempted to implement this functionality, but their implementations had issues. Our solution will build on the work of teams E1934 and E2237, addressing the problems in their implementations.

== '''Overview of Major Changes By Previous Teams''' ==
===[https://wiki-expertiza.csc.ncsu.edu/index.php/E1934_-_Grading_Audit_Trail E1934]===
[https://youtu.be/yyxX_kRYxLc Their Screencast]

*Created a database called grading_history to store elements for the Grading Audit Trail (instructor id, assignment id, grade tyoe, student id, grade, comment and timestamp)
*Used MVC design to create a model, a controller, and a view for both of Review Grade and Submission Grade. These will be the links used in the View Submissions view and View Review Report view so that the grading trail for an assignments submission and reviews are seperate.
*Modified grades controller, so that every time, a grade is submitted or edited, grading_history_controller.rb will call a method to create an entry that saves into the database.
'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

===[https://wiki-expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2022_-_E2237:_Grading_audit_trail E2237]===

*They fixed some issues that were causing the system to crash during testing
*Altered the Grading History view
*Explained the reasoning for changes made to files using diagrams and justifications
'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

=='''Proposed Solution'''==
We plan on using the implementation of E2237 since it is the latest in the Grading Audit Trail projects and has the latest in terms of testing. These files cannot be added haphazardly since parts of the implementation is a cause to concern and caused the changes to not be implemented. It is also using an older version of expertiza so some parts may not be compatible.

We must first figure out exactly what changes and issues to address in their implementation by meeting with our mentor. We also need to reimplement the following files since none of their changes were implemented:

*app/controllers/grading_histories_controller.rb
'''
Calls the grading history view after validating Submission and Review Type.

'''

*app/models/grading_history.rb
'''
Model for Grading History.
'''

*app/models/review_grading_history.rb

'''
Model containing specifics of Review Grading History. Inherits Grading History.
'''

*app/models/submission_grading_history.rb
'''
Model containing specifics of Submission Grading History. Inherits Grading History.
'''

*app/views/grading_history/index_html.erb
'''
This is a view for grading audit trail, it will display all grading histories of a
submission/review
'''

*spec/features/grade_histories_spec.rb

'''
Feature test to check if the grades appear in chronological order
'''

*spec/features/helpers/grade_histories_helper.rb

'''
Helper file to facilitate the above mentioned feature test.
'''

=='''Reimplementation'''==
Since the previous teams implementations were not integrated we have to reimplement their files which we will do by looking at their commits and pull request to see what files are necessary and what can be left out to address the issues of their implementation.

'''[https://github.com/ErikLG360/expertiza/commit/e28a857695549cc91c477587707e48100d2bd333 Files being Reimplemented/Modified]'''

'''Reimplemented'''
*app/controllers/grading_histories_controller.rb
'''
This file was added because it was from the previous teams implementation which concerned the MVC of the grading_history they created. It dealt with allowing only the correct people to view the
grading history, checking the assignment type whether it be a submission or review, and indexing all the grading history for the assignment in chronological order.
'''
*app/models/grading_history.rb
'''
This file was added to follow the previous teams MVC of the grading_history they created. It was used to create the relationships that the grading history has with an instructor who is creating
the parts of the grading history and the assignments that will have a grading history.
'''
*app/models/review_grading_history.rb
'''
This file creates the relationship that a participant will have a Review Grading History
'''
*app/models/submission_grading_history.rb
'''
This file create the relationship that a participant/grade_reciever will have a Submission Grading History
'''

*app/views/grading_histories/index.html.erb
'''
This file contains the view for the grading history table which will change depending on if its a Review or submission type
'''
*app/views/grading_histories/_form.html.erb
'''
This file contains the view for when a grading history contains any error when it is about to be saved
'''

'''Modified'''
*app/controllers/grades_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_submission was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of submissions and not reviews.
'''
*app/controllers/review_mapping_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_reviewer was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of reviews and not submissions.
'''
*app/views/assignments/list_submissions.html.erb
'''
It was modified to add the new hyperlink to display the grading history of a submission.
'''
*config/routes.rb
'''
It was to add the new route for grading histories
'''

=='''Solutions - Implemented'''==

'''E1934'''

'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

'''Solutions'''
:1. Found the correct location to put the Review Grading History link and also fix the previous teams creation of a grading history to work with the latest expertiza update.
Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/controllers/review_mapping_controller.rb]
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/views/reports/_review_report.html.erb]

:2. The previous implementatation of E2237 tackled this problem and moved it to the title.
[[File:GradingTableTitle.png]]
:3. The column widths were lessened by about 15px in the grading record page

Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/124bd12d23f75db0a68e2fac8a8487c5f7a7ed67 app/views/grading_histories/index.html.erb]

:4.

:5. All code climate changes are their own commits such as [https://github.com/ErikLG360/expertiza/commit/e95656f4d5e4f2ba4fc8d3f40716673ccafb41b1 This]

:6. This issue was resolved by not adding in their implementation for the list_review_mapping.html.erb

:7. This issue was resolved by not adding in the review_report_html.erb file

:8. This issue is resolved in the '''Reimplementation''' section of this document

'''E2237'''

'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

'''Solutions'''
:1. These files have not been reimplemented.
:2.
:3. The column width was reduced by 15px refer to the solution for E1934 number 3.
:4. Code for the review_mapping_controller was changed to match the current state of expertiza refer to the solution for E1934 number 1.

=='''Testing Plan'''==
We have added a test case to test if a grading history is getting created when valid parameters are used.
The files include
spec/controllers/grading_histories_controller_test.rb
spec/factories/factories.rb
spec/features/grade_histories_spec.rb
spec/helpers/grade_histories_helper_spec.rb

[https://github.com/expertiza/expertiza/commit/067b52315ac1ff7ce1b89fc44121393cadbabc6a]

=='''Future Scope'''==
This project may need further improvement since it does not seem like there should be an abundance of files added and perhaps using the MVC design is not necessarily needed. There can also be a reduction of code since the difference between the two main grading histories is just whether it is a review or submission type.

=='''Relevant Links'''==
* '''Github Repository:''' https://github.com/ErikLG360/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2696
* '''VCL Server (Valid until 12/15/23):''' http://152.7.179.44:8080
* '''Video:''' https://drive.google.com/file/d/1HIrJtCsbZXSqGPHShuV6mbSTOKvV5MxT/view?usp=drive_link

=='''Contributors to this project'''==
*Amulya Usem
*Erik Lopez-Godinez
*Gowtham Pollam

*'''Mentor''': Srilekha Gudipati

CSC/ECE 517 Fall 2023 - E2383. Grading Audit Trail

2023-12-05T04:55:38Z

Ausem: /* Proposed Solution */

=='''Introduction'''==

===Problem Statement===
In the current implementation of expertiza, any instructor can assign or edit a grade but there is no way to track who gave the grade and when.

A grading audit trail must be created and the following information needs to be stored:

1. When a grade is assigned by an instructor, there needs to be an indication of who did it and when it was done.
2. Comments previously provided by other instructors must also be preserved.
This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

Currently, there are two places need to add grading audit trail:

1. Review grade: Log in as instructor -> Manage -> Assignments -> View Review Report
2. Submission grade: Log in as instructor -> Manage -> Assignments -> View submissions
The grading audit trail can probably be implemented as the submission records history on Expertiza. The required page can be reached by logging in as instructor -> Manage -> Assignments -> View Submissions -> History

At the minimum, a grading log entry must include the instructor id, assignment id, student id, grade, comment and timestamp.

Previous student teams have attempted to implement this functionality, but their implementations had issues. Our solution will build on the work of teams E1934 and E2237, addressing the problems in their implementations.

== '''Overview of Major Changes By Previous Teams''' ==
===[https://wiki-expertiza.csc.ncsu.edu/index.php/E1934_-_Grading_Audit_Trail E1934]===
[https://youtu.be/yyxX_kRYxLc Their Screencast]

*Created a database called grading_history to store elements for the Grading Audit Trail (instructor id, assignment id, grade tyoe, student id, grade, comment and timestamp)
*Used MVC design to create a model, a controller, and a view for both of Review Grade and Submission Grade. These will be the links used in the View Submissions view and View Review Report view so that the grading trail for an assignments submission and reviews are seperate.
*Modified grades controller, so that every time, a grade is submitted or edited, grading_history_controller.rb will call a method to create an entry that saves into the database.
'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

===[https://wiki-expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2022_-_E2237:_Grading_audit_trail E2237]===

*They fixed some issues that were causing the system to crash during testing
*Altered the Grading History view
*Explained the reasoning for changes made to files using diagrams and justifications
'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

=='''Proposed Solution'''==
We plan on using the implementation of E2237 since it is the latest in the Grading Audit Trail projects and has the latest in terms of testing. These files cannot be added haphazardly since parts of the implementation is a cause to concern and caused the changes to not be implemented. It is also using an older version of expertiza so some parts may not be compatible.

We must first figure out exactly what changes and issues to address in their implementation by meeting with our mentor. We also need to reimplement the following files since none of their changes were implemented:

*app/controllers/grading_histories_controller.rb
'''
Calls the grading history view after validating Submission and Review Type.

'''

*app/models/grading_history.rb
'''
Model for Grading History.
'''

*app/models/review_grading_history.rb

'''
Model containing specifics of Review Grading History. Inherits Grading History.
'''

*app/models/submission_grading_history.rb
'''
Model containing specifics of Submission Grading History. Inherits Grading History.
'''

*app/views/grading_history/index_html.erb
'''
This is a view for grading audit trail, it will display all grading histories of a
submission/review
'''

*spec/features/grade_histories_spec.rb

'''
Feature test to check if the grades appear in chronological order
'''

*spec/features/helpers/grade_histories_helper.rb

'''
Helper file to facilitate the above mentioned feature test.
'''

=== Code changes ===
====1. \app\controllers\grades_controller.rb====
Add create submission record function
<pre>
GradingHistory.create(instructor_id: session[:user].id,
assignment_id: participant.assignment.id,
grading_type: "Submission",
grade_receiver_id: @team.id,
grade: @team.grade_for_submission,
comment: @team.comment_for_submission)
</pre>

====2. \app\controllers\grading_histories_controller.rb====
Create grading_histories_controller.rb
<pre>
class GradingHistoriesController < ApplicationController
before_action :set_grading_history, only: %i[show]

def action_allowed?
return true if ['Super-Administrator', 'Administrator'].include? current_role_name
check_type(params[:grade_type])
if @assignment.instructor_id == current_user.id
true
elsif TaMapping.exists?(ta_id: current_user.id, course_id: @assignment.course_id) &&
(TaMapping.where(course_id: @assignment.course_id).include? TaMapping.where(ta_id: current_user.id, course_id: @assignment.course_id).first)
true
elsif @assignment.course_id && Course.find(@assignment.course_id).instructor_id == current_user.id
true
end
end

def check_type(type)
if type.eql? "Submission"
assignment_team = AssignmentTeam.find(params[:grade_receiver_id])
@assignment = Assignment.find(assignment_team.parent_id)
end
if type.eql? "Review"
participant_id = params[:participant_id]
grade_receiver = AssignmentParticipant.find(participant_id)
@assignment = Assignment.find(grade_receiver.parent_id)
end
end

def index
@grading_histories = GradingHistory.where(grade_receiver_id: params[:grade_receiver_id], grading_type: params[:grade_type]).reverse_order
end
end
</pre>

====3. \app\controllers\review_mapping_controller.rb====
Add create review record function
<pre>
GradingHistory.create(instructor_id: session[:user].id,
assignment_id: params[:assignment_id],
grading_type: "Review",
grade_receiver_id: Participant.find(params[:participant_id]).user_id,
grade: params[:grade_for_reviewer],
comment: params[:comment_for_reviewer])
</pre>

====4. \app\helpers\grading_histories_helper.rb====
Create grading_histories_helper.rb
<pre>
module GradingHistoriesHelper
end
</pre>

====5. \app\models\grading_history.rb====
Create grading_history.rb
<pre>
class GradingHistory < ActiveRecord::Base
attr_protected
belongs_to :instructor, inverse_of: :instructor_id
belongs_to :assignment, inverse_of: :assignment_id
end
</pre>

====6. \app\models\review_grading_history.rb====
Create review_grading_history.rb
<pre>
class ReviewGradingHistory < GradingHistory
attr_protected
belongs_to :grade_receiver, class_name: 'Participant', inverse_of: :grade_receiver_id
end
</pre>

====7. \app\models\submission_grading_history.rb====
Create submission_grading_history.rb
<pre>
class SubmissionGradingHistory < GradingHistory
attr_protected
belongs_to :grade_receiver, class_name: 'Team', inverse_of: :grade_receiver_id
end
</pre>

====8. \app\views\assignments\list_submissions.html.erb====
Add "Grading History" link to submissions page
====9. \app\views\grading_histories\index.html.erb====
Create grading histories index page
====10. \app\views\reports\_review_report.html.erb====
Add "Grading History" link to review report page
====11. \config\routes.rb====
Configure the routes
<pre>
resources :grading_histories, only: [:index]
</pre>
====12. \app\views\assignments\list_submissions.html.erb====
Create table grading_histories
<pre>
class CreateGradingHistories < ActiveRecord::Migration
def change
create_table :grading_histories do |t|
t.integer :instructor_id
t.integer :assignment_id
t.string :grading_type
t.integer :grade_receiver_id
t.integer :grade
t.text :comment
t.timestamps null: false
end
end
end
</pre>

=== History of Comment and Grade for Reviews ===

Added the link "history" to a proper place as the expected design picture shows.

==== Review History Flow====

=='''Reimplementation'''==
Since the previous teams implementations were not integrated we have to reimplement their files which we will do by looking at their commits and pull request to see what files are necessary and what can be left out to address the issues of their implementation.

'''[https://github.com/ErikLG360/expertiza/commit/e28a857695549cc91c477587707e48100d2bd333 Files being Reimplemented/Modified]'''

'''Reimplemented'''
*app/controllers/grading_histories_controller.rb
'''
This file was added because it was from the previous teams implementation which concerned the MVC of the grading_history they created. It dealt with allowing only the correct people to view the
grading history, checking the assignment type whether it be a submission or review, and indexing all the grading history for the assignment in chronological order.
'''
*app/models/grading_history.rb
'''
This file was added to follow the previous teams MVC of the grading_history they created. It was used to create the relationships that the grading history has with an instructor who is creating
the parts of the grading history and the assignments that will have a grading history.
'''
*app/models/review_grading_history.rb
'''
This file creates the relationship that a participant will have a Review Grading History
'''
*app/models/submission_grading_history.rb
'''
This file create the relationship that a participant/grade_reciever will have a Submission Grading History
'''

*app/views/grading_histories/index.html.erb
'''
This file contains the view for the grading history table which will change depending on if its a Review or submission type
'''
*app/views/grading_histories/_form.html.erb
'''
This file contains the view for when a grading history contains any error when it is about to be saved
'''

'''Modified'''
*app/controllers/grades_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_submission was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of submissions and not reviews.
'''
*app/controllers/review_mapping_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_reviewer was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of reviews and not submissions.
'''
*app/views/assignments/list_submissions.html.erb
'''
It was modified to add the new hyperlink to display the grading history of a submission.
'''
*config/routes.rb
'''
It was to add the new route for grading histories
'''

=='''Solutions - Implemented'''==

'''E1934'''

'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

'''Solutions'''
:1. Found the correct location to put the Review Grading History link and also fix the previous teams creation of a grading history to work with the latest expertiza update.
Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/controllers/review_mapping_controller.rb]
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/views/reports/_review_report.html.erb]

:2. The previous implementatation of E2237 tackled this problem and moved it to the title.
[[File:GradingTableTitle.png]]
:3. The column widths were lessened by about 15px in the grading record page

Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/124bd12d23f75db0a68e2fac8a8487c5f7a7ed67 app/views/grading_histories/index.html.erb]

:4.

:5. All code climate changes are their own commits such as [https://github.com/ErikLG360/expertiza/commit/e95656f4d5e4f2ba4fc8d3f40716673ccafb41b1 This]

:6. This issue was resolved by not adding in their implementation for the list_review_mapping.html.erb

:7. This issue was resolved by not adding in the review_report_html.erb file

:8. This issue is resolved in the '''Reimplementation''' section of this document

'''E2237'''

'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

'''Solutions'''
:1. These files have not been reimplemented.
:2.
:3. The column width was reduced by 15px refer to the solution for E1934 number 3.
:4. Code for the review_mapping_controller was changed to match the current state of expertiza refer to the solution for E1934 number 1.

=='''Testing Plan'''==
We have added a test case to test if a grading history is getting created when valid parameters are used.
The files include
spec/controllers/grading_histories_controller_test.rb
spec/factories/factories.rb
spec/features/grade_histories_spec.rb
spec/helpers/grade_histories_helper_spec.rb

[https://github.com/expertiza/expertiza/commit/067b52315ac1ff7ce1b89fc44121393cadbabc6a]

=='''Future Scope'''==
This project may need further improvement since it does not seem like there should be an abundance of files added and perhaps using the MVC design is not necessarily needed. There can also be a reduction of code since the difference between the two main grading histories is just whether it is a review or submission type.

=='''Relevant Links'''==
* '''Github Repository:''' https://github.com/ErikLG360/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2696
* '''VCL Server (Valid until 12/15/23):''' http://152.7.179.44:8080
* '''Video:''' https://drive.google.com/file/d/1HIrJtCsbZXSqGPHShuV6mbSTOKvV5MxT/view?usp=drive_link

=='''Contributors to this project'''==
*Amulya Usem
*Erik Lopez-Godinez
*Gowtham Pollam

*'''Mentor''': Srilekha Gudipati

CSC/ECE 517 Fall 2023 - E2383. Grading Audit Trail

2023-12-05T04:47:56Z

Ausem: /* Problem Statement */

=='''Introduction'''==

===Problem Statement===
In the current implementation of expertiza, any instructor can assign or edit a grade but there is no way to track who gave the grade and when.

A grading audit trail must be created and the following information needs to be stored:

1. When a grade is assigned by an instructor, there needs to be an indication of who did it and when it was done.
2. Comments previously provided by other instructors must also be preserved.
This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

Currently, there are two places need to add grading audit trail:

1. Review grade: Log in as instructor -> Manage -> Assignments -> View Review Report
2. Submission grade: Log in as instructor -> Manage -> Assignments -> View submissions
The grading audit trail can probably be implemented as the submission records history on Expertiza. The required page can be reached by logging in as instructor -> Manage -> Assignments -> View Submissions -> History

At the minimum, a grading log entry must include the instructor id, assignment id, student id, grade, comment and timestamp.

Previous student teams have attempted to implement this functionality, but their implementations had issues. Our solution will build on the work of teams E1934 and E2237, addressing the problems in their implementations.

== '''Overview of Major Changes By Previous Teams''' ==
===[https://wiki-expertiza.csc.ncsu.edu/index.php/E1934_-_Grading_Audit_Trail E1934]===
[https://youtu.be/yyxX_kRYxLc Their Screencast]

*Created a database called grading_history to store elements for the Grading Audit Trail (instructor id, assignment id, grade tyoe, student id, grade, comment and timestamp)
*Used MVC design to create a model, a controller, and a view for both of Review Grade and Submission Grade. These will be the links used in the View Submissions view and View Review Report view so that the grading trail for an assignments submission and reviews are seperate.
*Modified grades controller, so that every time, a grade is submitted or edited, grading_history_controller.rb will call a method to create an entry that saves into the database.
'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

===[https://wiki-expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2022_-_E2237:_Grading_audit_trail E2237]===

*They fixed some issues that were causing the system to crash during testing
*Altered the Grading History view
*Explained the reasoning for changes made to files using diagrams and justifications
'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

=='''Proposed Solution'''==
We plan on using the implementation of E2237 since it is the latest in the Grading Audit Trail projects and has the latest in terms of testing. These files cannot be added haphazardly since parts of the implementation is a cause to concern and caused the changes to not be implemented. It is also using an older version of expertiza so some parts may not be compatible.

We must first figure out exactly what changes and issues to address in their implementation by meeting with our mentor. We also need to reimplement the following files since none of their changes were implemented:

*app/controllers/grading_histories_controller.rb
'''
Calls the grading history view after validating Submission and Review Type.

'''

*app/models/grading_history.rb
'''
Model for Grading History.
'''

*app/models/review_grading_history.rb

'''
Model containing specifics of Review Grading History. Inherits Grading History.
'''

*app/models/submission_grading_history.rb
'''
Model containing specifics of Submission Grading History. Inherits Grading History.
'''

*app/views/grading_history/index_html.erb
'''
This is a view for grading audit trail, it will display all grading histories of a
submission/review
'''

*spec/features/grade_histories_spec.rb

'''
Feature test to check if the grades appear in chronological order
'''

*spec/features/helpers/grade_histories_helper.rb

'''
Helper file to facilitate the above mentioned feature test.
'''

=='''Reimplementation'''==
Since the previous teams implementations were not integrated we have to reimplement their files which we will do by looking at their commits and pull request to see what files are necessary and what can be left out to address the issues of their implementation.

'''[https://github.com/ErikLG360/expertiza/commit/e28a857695549cc91c477587707e48100d2bd333 Files being Reimplemented/Modified]'''

'''Reimplemented'''
*app/controllers/grading_histories_controller.rb
'''
This file was added because it was from the previous teams implementation which concerned the MVC of the grading_history they created. It dealt with allowing only the correct people to view the
grading history, checking the assignment type whether it be a submission or review, and indexing all the grading history for the assignment in chronological order.
'''
*app/models/grading_history.rb
'''
This file was added to follow the previous teams MVC of the grading_history they created. It was used to create the relationships that the grading history has with an instructor who is creating
the parts of the grading history and the assignments that will have a grading history.
'''
*app/models/review_grading_history.rb
'''
This file creates the relationship that a participant will have a Review Grading History
'''
*app/models/submission_grading_history.rb
'''
This file create the relationship that a participant/grade_reciever will have a Submission Grading History
'''

*app/views/grading_histories/index.html.erb
'''
This file contains the view for the grading history table which will change depending on if its a Review or submission type
'''
*app/views/grading_histories/_form.html.erb
'''
This file contains the view for when a grading history contains any error when it is about to be saved
'''

'''Modified'''
*app/controllers/grades_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_submission was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of submissions and not reviews.
'''
*app/controllers/review_mapping_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_reviewer was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of reviews and not submissions.
'''
*app/views/assignments/list_submissions.html.erb
'''
It was modified to add the new hyperlink to display the grading history of a submission.
'''
*config/routes.rb
'''
It was to add the new route for grading histories
'''

=='''Solutions - Implemented'''==

'''E1934'''

'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

'''Solutions'''
:1. Found the correct location to put the Review Grading History link and also fix the previous teams creation of a grading history to work with the latest expertiza update.
Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/controllers/review_mapping_controller.rb]
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/views/reports/_review_report.html.erb]

:2. The previous implementatation of E2237 tackled this problem and moved it to the title.
[[File:GradingTableTitle.png]]
:3. The column widths were lessened by about 15px in the grading record page

Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/124bd12d23f75db0a68e2fac8a8487c5f7a7ed67 app/views/grading_histories/index.html.erb]

:4.

:5. All code climate changes are their own commits such as [https://github.com/ErikLG360/expertiza/commit/e95656f4d5e4f2ba4fc8d3f40716673ccafb41b1 This]

:6. This issue was resolved by not adding in their implementation for the list_review_mapping.html.erb

:7. This issue was resolved by not adding in the review_report_html.erb file

:8. This issue is resolved in the '''Reimplementation''' section of this document

'''E2237'''

'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

'''Solutions'''
:1. These files have not been reimplemented.
:2.
:3. The column width was reduced by 15px refer to the solution for E1934 number 3.
:4. Code for the review_mapping_controller was changed to match the current state of expertiza refer to the solution for E1934 number 1.

=='''Testing Plan'''==
We have added a test case to test if a grading history is getting created when valid parameters are used.
The files include
spec/controllers/grading_histories_controller_test.rb
spec/factories/factories.rb
spec/features/grade_histories_spec.rb
spec/helpers/grade_histories_helper_spec.rb

[https://github.com/expertiza/expertiza/commit/067b52315ac1ff7ce1b89fc44121393cadbabc6a]

=='''Future Scope'''==
This project may need further improvement since it does not seem like there should be an abundance of files added and perhaps using the MVC design is not necessarily needed. There can also be a reduction of code since the difference between the two main grading histories is just whether it is a review or submission type.

=='''Relevant Links'''==
* '''Github Repository:''' https://github.com/ErikLG360/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2696
* '''VCL Server (Valid until 12/15/23):''' http://152.7.179.44:8080
* '''Video:''' https://drive.google.com/file/d/1HIrJtCsbZXSqGPHShuV6mbSTOKvV5MxT/view?usp=drive_link

=='''Contributors to this project'''==
*Amulya Usem
*Erik Lopez-Godinez
*Gowtham Pollam

*'''Mentor''': Srilekha Gudipati

CSC/ECE 517 Fall 2023 - E2383. Grading Audit Trail

2023-12-05T04:47:18Z

Ausem:

=='''Introduction'''==

===Problem Statement===
In the current implementation of expertiza, any instructor can assign or edit a grade but there is no way to track who gave the grade and when.
Inorder to solve this, a grading audit trail must be created and the following information needs to be stored:
:1. When a grade is assigned by an instructor, there needs to be an indication of who did it and when it was done.
:2. Comments previously provided by other instructors must also be preserved.

This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

Previous student teams have attempted to implement this functionality, but their implementations had issues. Our solution will build on the work of teams E1934 and E2237, addressing the problems in their implementations.

== '''Overview of Major Changes By Previous Teams''' ==
===[https://wiki-expertiza.csc.ncsu.edu/index.php/E1934_-_Grading_Audit_Trail E1934]===
[https://youtu.be/yyxX_kRYxLc Their Screencast]

*Created a database called grading_history to store elements for the Grading Audit Trail (instructor id, assignment id, grade tyoe, student id, grade, comment and timestamp)
*Used MVC design to create a model, a controller, and a view for both of Review Grade and Submission Grade. These will be the links used in the View Submissions view and View Review Report view so that the grading trail for an assignments submission and reviews are seperate.
*Modified grades controller, so that every time, a grade is submitted or edited, grading_history_controller.rb will call a method to create an entry that saves into the database.
'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

===[https://wiki-expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2022_-_E2237:_Grading_audit_trail E2237]===

*They fixed some issues that were causing the system to crash during testing
*Altered the Grading History view
*Explained the reasoning for changes made to files using diagrams and justifications
'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

=='''Proposed Solution'''==
We plan on using the implementation of E2237 since it is the latest in the Grading Audit Trail projects and has the latest in terms of testing. These files cannot be added haphazardly since parts of the implementation is a cause to concern and caused the changes to not be implemented. It is also using an older version of expertiza so some parts may not be compatible.

We must first figure out exactly what changes and issues to address in their implementation by meeting with our mentor. We also need to reimplement the following files since none of their changes were implemented:

*app/controllers/grading_histories_controller.rb
'''
Calls the grading history view after validating Submission and Review Type.

'''

*app/models/grading_history.rb
'''
Model for Grading History.
'''

*app/models/review_grading_history.rb

'''
Model containing specifics of Review Grading History. Inherits Grading History.
'''

*app/models/submission_grading_history.rb
'''
Model containing specifics of Submission Grading History. Inherits Grading History.
'''

*app/views/grading_history/index_html.erb
'''
This is a view for grading audit trail, it will display all grading histories of a
submission/review
'''

*spec/features/grade_histories_spec.rb

'''
Feature test to check if the grades appear in chronological order
'''

*spec/features/helpers/grade_histories_helper.rb

'''
Helper file to facilitate the above mentioned feature test.
'''

=='''Reimplementation'''==
Since the previous teams implementations were not integrated we have to reimplement their files which we will do by looking at their commits and pull request to see what files are necessary and what can be left out to address the issues of their implementation.

'''[https://github.com/ErikLG360/expertiza/commit/e28a857695549cc91c477587707e48100d2bd333 Files being Reimplemented/Modified]'''

'''Reimplemented'''
*app/controllers/grading_histories_controller.rb
'''
This file was added because it was from the previous teams implementation which concerned the MVC of the grading_history they created. It dealt with allowing only the correct people to view the
grading history, checking the assignment type whether it be a submission or review, and indexing all the grading history for the assignment in chronological order.
'''
*app/models/grading_history.rb
'''
This file was added to follow the previous teams MVC of the grading_history they created. It was used to create the relationships that the grading history has with an instructor who is creating
the parts of the grading history and the assignments that will have a grading history.
'''
*app/models/review_grading_history.rb
'''
This file creates the relationship that a participant will have a Review Grading History
'''
*app/models/submission_grading_history.rb
'''
This file create the relationship that a participant/grade_reciever will have a Submission Grading History
'''

*app/views/grading_histories/index.html.erb
'''
This file contains the view for the grading history table which will change depending on if its a Review or submission type
'''
*app/views/grading_histories/_form.html.erb
'''
This file contains the view for when a grading history contains any error when it is about to be saved
'''

'''Modified'''
*app/controllers/grades_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_submission was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of submissions and not reviews.
'''
*app/controllers/review_mapping_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_reviewer was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of reviews and not submissions.
'''
*app/views/assignments/list_submissions.html.erb
'''
It was modified to add the new hyperlink to display the grading history of a submission.
'''
*config/routes.rb
'''
It was to add the new route for grading histories
'''

=='''Solutions - Implemented'''==

'''E1934'''

'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

'''Solutions'''
:1. Found the correct location to put the Review Grading History link and also fix the previous teams creation of a grading history to work with the latest expertiza update.
Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/controllers/review_mapping_controller.rb]
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/views/reports/_review_report.html.erb]

:2. The previous implementatation of E2237 tackled this problem and moved it to the title.
[[File:GradingTableTitle.png]]
:3. The column widths were lessened by about 15px in the grading record page

Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/124bd12d23f75db0a68e2fac8a8487c5f7a7ed67 app/views/grading_histories/index.html.erb]

:4.

:5. All code climate changes are their own commits such as [https://github.com/ErikLG360/expertiza/commit/e95656f4d5e4f2ba4fc8d3f40716673ccafb41b1 This]

:6. This issue was resolved by not adding in their implementation for the list_review_mapping.html.erb

:7. This issue was resolved by not adding in the review_report_html.erb file

:8. This issue is resolved in the '''Reimplementation''' section of this document

'''E2237'''

'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

'''Solutions'''
:1. These files have not been reimplemented.
:2.
:3. The column width was reduced by 15px refer to the solution for E1934 number 3.
:4. Code for the review_mapping_controller was changed to match the current state of expertiza refer to the solution for E1934 number 1.

=='''Testing Plan'''==
We have added a test case to test if a grading history is getting created when valid parameters are used.
The files include
spec/controllers/grading_histories_controller_test.rb
spec/factories/factories.rb
spec/features/grade_histories_spec.rb
spec/helpers/grade_histories_helper_spec.rb

[https://github.com/expertiza/expertiza/commit/067b52315ac1ff7ce1b89fc44121393cadbabc6a]

=='''Future Scope'''==
This project may need further improvement since it does not seem like there should be an abundance of files added and perhaps using the MVC design is not necessarily needed. There can also be a reduction of code since the difference between the two main grading histories is just whether it is a review or submission type.

=='''Relevant Links'''==
* '''Github Repository:''' https://github.com/ErikLG360/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2696
* '''VCL Server (Valid until 12/15/23):''' http://152.7.179.44:8080
* '''Video:''' https://drive.google.com/file/d/1HIrJtCsbZXSqGPHShuV6mbSTOKvV5MxT/view?usp=drive_link

=='''Contributors to this project'''==
*Amulya Usem
*Erik Lopez-Godinez
*Gowtham Pollam

*'''Mentor''': Srilekha Gudipati

CSC/ECE 517 Fall 2023 - E2383. Grading Audit Trail

2023-12-05T04:04:11Z

Ausem:

=='''Introduction'''==

===Problem Statement===
After an instructor gave a grade to an assignment, there is no way to track who gave the grade.
A grading audit trail must be created and the following information needs to be stored:
:1. When a grade is assigned by an instructor, there needs to be an indication of who did it and when it was done.
:2. Comments previously provided by other instructors must also be preserved.

This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

There have been previous attempts from teams to implement such functionality and our implementation will be based on '''E1934''' and '''E2237'''. Each of these implementations have problems of their own that we need to address.

== '''Overview of Major Changes By Previous Teams''' ==
===[https://wiki-expertiza.csc.ncsu.edu/index.php/E1934_-_Grading_Audit_Trail E1934]===
[https://youtu.be/yyxX_kRYxLc Their Screencast]

*Created a database called grading_history to store elements for the Grading Audit Trail (instructor id, assignment id, grade tyoe, student id, grade, comment and timestamp)
*Used MVC design to create a model, a controller, and a view for both of Review Grade and Submission Grade. These will be the links used in the View Submissions view and View Review Report view so that the grading trail for an assignments submission and reviews are seperate.
*Modified grades controller, so that every time, a grade is submitted or edited, grading_history_controller.rb will call a method to create an entry that saves into the database.
'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

===[https://wiki-expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2022_-_E2237:_Grading_audit_trail E2237]===

*They fixed some issues that were causing the system to crash during testing
*Altered the Grading History view
*Explained the reasoning for changes made to files using diagrams and justifications
'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

=='''Proposed Solution'''==
We plan on using the implementation of E2237 since it is the latest in the Grading Audit Trail projects and has the latest in terms of testing. These files cannot be added haphazardly since parts of the implementation is a cause to concern and caused the changes to not be implemented. It is also using an older version of expertiza so some parts may not be compatible.

We must first figure out exactly what changes and issues to address in their implementation by meeting with our mentor. We also need to reimplement the following files since none of their changes were implemented:

*app/controllers/grading_histories_controller.rb
'''
Calls the grading history view after validating Submission and Review Type.

'''

*app/models/grading_history.rb
'''
Model for Grading History.
'''

*app/models/review_grading_history.rb

'''
Model containing specifics of Review Grading History. Inherits Grading History.
'''

*app/models/submission_grading_history.rb
'''
Model containing specifics of Submission Grading History. Inherits Grading History.
'''

*app/views/grading_history/index_html.erb
'''
This is a view for grading audit trail, it will display all grading histories of a
submission/review
'''

*spec/features/grade_histories_spec.rb

'''
Feature test to check if the grades appear in chronological order
'''

*spec/features/helpers/grade_histories_helper.rb

'''
Helper file to facilitate the above mentioned feature test.
'''

=='''Reimplementation'''==
Since the previous teams implementations were not integrated we have to reimplement their files which we will do by looking at their commits and pull request to see what files are necessary and what can be left out to address the issues of their implementation.

'''[https://github.com/ErikLG360/expertiza/commit/e28a857695549cc91c477587707e48100d2bd333 Files being Reimplemented/Modified]'''

'''Reimplemented'''
*app/controllers/grading_histories_controller.rb
'''
This file was added because it was from the previous teams implementation which concerned the MVC of the grading_history they created. It dealt with allowing only the correct people to view the
grading history, checking the assignment type whether it be a submission or review, and indexing all the grading history for the assignment in chronological order.
'''
*app/models/grading_history.rb
'''
This file was added to follow the previous teams MVC of the grading_history they created. It was used to create the relationships that the grading history has with an instructor who is creating
the parts of the grading history and the assignments that will have a grading history.
'''
*app/models/review_grading_history.rb
'''
This file creates the relationship that a participant will have a Review Grading History
'''
*app/models/submission_grading_history.rb
'''
This file create the relationship that a participant/grade_reciever will have a Submission Grading History
'''

*app/views/grading_histories/index.html.erb
'''
This file contains the view for the grading history table which will change depending on if its a Review or submission type
'''
*app/views/grading_histories/_form.html.erb
'''
This file contains the view for when a grading history contains any error when it is about to be saved
'''

'''Modified'''
*app/controllers/grades_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_submission was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of submissions and not reviews.
'''
*app/controllers/review_mapping_controller.rb
'''
This file was modified based off the previous teams implementation because when the method save_grade_and_comment_for_reviewer was called it should also create a grading history so that
the grading audit can be created and added to. This was mainly focusing on the grading history of reviews and not submissions.
'''
*app/views/assignments/list_submissions.html.erb
'''
It was modified to add the new hyperlink to display the grading history of a submission.
'''
*config/routes.rb
'''
It was to add the new route for grading histories
'''

=='''Solutions - Implemented'''==

'''E1934'''

'''Problems/Issues'''
:1. For review grades, the “Grading History” link must not be in a separate column. It should be in :smaller text below the in the “Save” button.
:2. In the view grading record page, remove the receiver column and add it to the title
:3. Restrict the column width on the grading record page
:4. Add comments on list_submissions.html.erb to indicate that the alignment was changed to fix code climate issues
:5. Ensure that white space changes are separate commits
:6. Revert changes made to list_review_mapping.html.erb
:7. Remove the review_report_html.erb file
:8. Design doc – mention why each of those files were changed

'''Solutions'''
:1. Found the correct location to put the Review Grading History link and also fix the previous teams creation of a grading history to work with the latest expertiza update.
Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/controllers/review_mapping_controller.rb]
*[https://github.com/ErikLG360/expertiza/commit/c0352cb73f7de1fba72938df2953ee82cb84bb6a app/views/reports/_review_report.html.erb]

:2. The previous implementatation of E2237 tackled this problem and moved it to the title.
[[File:GradingTableTitle.png]]
:3. The column widths were lessened by about 15px in the grading record page

Files changed include:
*[https://github.com/ErikLG360/expertiza/commit/124bd12d23f75db0a68e2fac8a8487c5f7a7ed67 app/views/grading_histories/index.html.erb]

:4.

:5. All code climate changes are their own commits such as [https://github.com/ErikLG360/expertiza/commit/e95656f4d5e4f2ba4fc8d3f40716673ccafb41b1 This]

:6. This issue was resolved by not adding in their implementation for the list_review_mapping.html.erb

:7. This issue was resolved by not adding in the review_report_html.erb file

:8. This issue is resolved in the '''Reimplementation''' section of this document

'''E2237'''

'''Problems/Issues'''
:1. Redundant files generated by scaffolding need to be removed, along with debugging code. Ex) Coffee created by scaffolding and console logging for debugging.
:2. Authentication could be done using existing utilities, no need to create their own.
:3. Some formatting changes could be done especially on how cells span in review report page. Ex) Formatting change for spans in between cells in review report.
:4. Code from previous implementation is a concern.

'''Solutions'''
:1. These files have not been reimplemented.
:2.
:3. The column width was lessed by 15px refer to the solution for E1934 number 3.
:4. Code for the review_mapping_controller was changed to match the current state of expertiza refer to the solution for E1934 number 1.

=='''Testing Plan'''==
The Testing that we will implement will build from E2237 since the previous tests crash and was something they solved. We also plan to implement test using the given Test Skeleton.

=='''Future Scope'''==
This project may need further improvement since it does not seem like there should be an abundance of files added and perhaps using the MVC design is not necessarily needed. There can also be a reduction of code since the difference between the two main grading histories is just whether it is a review or submission type.

=='''Relevant Links'''==
* '''Github Repository:''' https://github.com/ErikLG360/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2696
* '''VCL Server (Valid until 12/15/23):''' http://152.7.179.44:8080
* '''Video:''' https://drive.google.com/file/d/1HIrJtCsbZXSqGPHShuV6mbSTOKvV5MxT/view?usp=drive_link

=='''Contributors to this project'''==
*Amulya Usem
*Erik Lopez-Godinez
*Gowtham Pollam

*'''Mentor''': Srilekha Gudipati

CSC/ECE 517 Fall 2023 - E2350. Allow reviewers to bid on what to review

2023-11-07T05:04:12Z

Ausem:

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Srilekha Gudipati (sngudipa)

=== Team Members ===
* Amulya Usem (ausem)
* Gowtham Pollam (gpollam)
* Basaveswara Mukesh Suryadevara (bsuryad)

=== Links ===
* Pull request [https://github.com/expertiza/expertiza/pull/2686]
* Github repo [https://github.com/amulyausem/expertiza]
* Deployed server [http://152.7.177.6:8080/]
Credentials : username - instructor6 password - password

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

What needs to be done
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Soultions =

=== Review_bids_others_work is a DRY violation ===

The file <code>review_bids_others_work.html.erb</code> has been refactored in order to resolve DRY violation by removing redundant code without impacting the current functionality.

[[File:Sol1.png|700px]]

=== Run_bidding algorithm should be assign_reviewers ===

<code>run_bidding_algorithm</code> was refactored to <code>assign_reviewers</code>. Accordingly, all the other instances of this were modified too.

[[File:Sol2.png|700px]]

[[File:Screenshot 2023-10-30 at 11.13.09 PM.png|700px]]

=== Currently it doesn't work if some student does not bid. In this case, the algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===

The code was modified to assign random reviews to students in case they didn't bid for any.

[[File:Screenshot 2023-10-30 at 11.17.02 PM.png|700px]]

=== Figure out why running the bidding algorithm only works on assignments with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===

Currently, it is mandatory to have a team but we can still make the team be assigned a project even if the team has only one member since there is no settings to place a minimum member cap. Although the member will have to create a team and assign a name so that the member can place a bid.

=== Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===

We have included a count variable in <code>assign_bidding</code> of controller <code>review_bids_controller.rb</code>. It helps us to keep track of the number of students bidding for reviews and is shown to the users in the view page.

[[File:Screenshot 2023-10-30 at 11.17.19 PM.png|700px]]

=== Ability to allow the algorithm to run again after running once. ===

<code>can_choose_topic_to_review</code> attribute is handled so as to allow the user to refrain from clicking the button to run the algorithm again if done once already. So the attribute was removed for the visibility of the button <code>Run Review Algorithm</code> allowing the user to click and run the algorithm multiple times

[[File:Screenshot 2023-10-30 at 11.18.30 PM.png|700px]]

=== Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===

The methods in review_bid.rb are to get bidding data, to assign review topics, assign topic to reviewer and for getting individual reviewer_ids bidding data. These all are class methods. All the methods in review_bid.rb are converted into instance methods and other occurances were refactored to create an object and then call these methods.

[[File:Screenshot 2023-10-30 at 11.18.06 PM.png|700px]]

[[File:Screenshot 2023-10-30 at 11.18.17 PM.png|700px]]

=== In the previous implementation wiki, there are edge cases that are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===

Test cases were added and existing cases were modified for some edge scenarios.

[[File:Screenshot 2023-11-07 at 12.00.13 AM.png|700px]]

[[File:Screenshot 2023-11-07 at 12.00.26 AM.png|700px]]

[[File:Screenshot 2023-11-07 at 12.00.36 AM.png|700px]]

=== Test whether the topic changes color depending on the number of outstanding bids ===

A test case was added in <code>review_bids_helper_spec.rb</code> that test the changes in background color based on the number of participants and outstanding size.

[[File:Screenshot 2023-10-30 at 11.18.47 PM.png|700px]]

= Test Plan =

=== RSpec ===

* The main task is to ensure existing functionality remains intact post-integration of new code and refactoring of review_bid.rb.
* Refactor tests in response to methods in review_bid.rb transitioning to instance methods.
* For requirement 5, implement tests to validate the correct increment and decrement of the newly introduced attribute.
* For requirement 6, introduce a test case to verify the "Run Review Algorithm" button's enablement for algorithm re-execution.
* For requirement 9, a test in review_bids_helper_spec.rb assesses the background color alteration contingent on participant numbers and outstanding bid size.
* Develop additional test cases to ascertain the random allocation of reviews when a student has not placed a bid.

=== Physical Testing ===

* With the UI under development in a separate project, verification via direct links is essential.
* Execute a full functionality sweep to detect any disruptions caused by the recent code refactoring.
* For requirement 5, a manual check to confirm the visibility and accuracy of the bidding count is necessary at http://152.7.177.6:8080/review_bids/200.

= References =

*https://github.com/expertiza/expertiza/pull/2150
*https://www.youtube.com/watch?v=wxXALQNWFcc
*https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review

File:Screenshot 2023-11-07 at 12.00.36 AM.png

2023-11-07T05:01:41Z

Ausem:

File:Screenshot 2023-11-07 at 12.00.26 AM.png

2023-11-07T05:01:27Z

Ausem:

File:Screenshot 2023-11-07 at 12.00.13 AM.png

2023-11-07T05:01:10Z

Ausem:

CSC/ECE 517 Fall 2023 - E2350. Allow reviewers to bid on what to review

2023-11-07T04:59:25Z

Ausem:

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Srilekha Gudipati (sngudipa)

=== Team Members ===
* Amulya Usem (ausem)
* Gowtham Pollam (gpollam)
* Basaveswara Mukesh Suryadevara (bsuryad)

=== Links ===
* Pull request [https://github.com/expertiza/expertiza/pull/2686]
* Github repo [https://github.com/amulyausem/expertiza]
* Deployed server [http://152.7.177.6:8080/]
Credentials : username - instructor6 password - password

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

What needs to be done
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Soultions =

=== Review_bids_others_work is a DRY violation ===

The file <code>review_bids_others_work.html.erb</code> has been refactored in order to resolve DRY violation by removing redundant code without impacting the current functionality.

[[File:Sol1.png|700px]]

=== Run_bidding algorithm should be assign_reviewers ===

<code>run_bidding_algorithm</code> was refactored to <code>assign_reviewers</code>. Accordingly, all the other instances of this were modified too.

[[File:Sol2.png|700px]]

[[File:Screenshot 2023-10-30 at 11.13.09 PM.png|700px]]

=== Currently it doesn't work if some student does not bid. In this case, the algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===

The code was modified to assign random reviews to students in case they didn't bid for any.

[[File:Screenshot 2023-10-30 at 11.17.02 PM.png|700px]]

=== Figure out why running the bidding algorithm only works on assignments with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===

Currently, it is mandatory to have a team but we can still make the team be assigned a project even if the team has only one member since there is no settings to place a minimum member cap. Although the member will have to create a team and assign a name so that the member can place a bid.

=== Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===

We have included a count variable in <code>assign_bidding</code> of controller <code>review_bids_controller.rb</code>. It helps us to keep track of the number of students bidding for reviews and is shown to the users in the view page.

[[File:Screenshot 2023-10-30 at 11.17.19 PM.png|700px]]

=== Ability to allow the algorithm to run again after running once. ===

<code>can_choose_topic_to_review</code> attribute is handled so as to allow the user to refrain from clicking the button to run the algorithm again if done once already. So the attribute was removed for the visibility of the button <code>Run Review Algorithm</code> allowing the user to click and run the algorithm multiple times

[[File:Screenshot 2023-10-30 at 11.18.30 PM.png|700px]]

=== Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===

The methods in review_bid.rb are to get bidding data, to assign review topics, assign topic to reviewer and for getting individual reviewer_ids bidding data. These all are class methods. All the methods in review_bid.rb are converted into instance methods and other occurances were refactored to create an object and then call these methods.

[[File:Screenshot 2023-10-30 at 11.18.06 PM.png|700px]]

[[File:Screenshot 2023-10-30 at 11.18.17 PM.png|700px]]

=== In the previous implementation wiki, there are edge cases that are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===

Test cases were added and existing cases were modified for several scenarios.

=== Test whether the topic changes color depending on the number of outstanding bids ===

A test case was added in <code>review_bids_helper_spec.rb</code> that test the changes in background color based on the number of participants and outstanding size.

[[File:Screenshot 2023-10-30 at 11.18.47 PM.png|700px]]

= Test Plan =

=== RSpec ===

* The main task is to ensure existing functionality remains intact post-integration of new code and refactoring of review_bid.rb.
* Refactor tests in response to methods in review_bid.rb transitioning to instance methods.
* For requirement 5, implement tests to validate the correct increment and decrement of the newly introduced attribute.
* For requirement 6, introduce a test case to verify the "Run Review Algorithm" button's enablement for algorithm re-execution.
* For requirement 9, a test in review_bids_helper_spec.rb assesses the background color alteration contingent on participant numbers and outstanding bid size.
* Develop additional test cases to ascertain the random allocation of reviews when a student has not placed a bid.

=== Physical Testing ===

* With the UI under development in a separate project, verification via direct links is essential.
* Execute a full functionality sweep to detect any disruptions caused by the recent code refactoring.
* For requirement 5, a manual check to confirm the visibility and accuracy of the bidding count is necessary at http://152.7.177.6:8080/review_bids/200.

= References =

*https://github.com/expertiza/expertiza/pull/2150
*https://www.youtube.com/watch?v=wxXALQNWFcc
*https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review

CSC/ECE 517 Fall 2023 - E2350. Allow reviewers to bid on what to review

2023-11-02T17:53:33Z

Ausem:

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Srilekha Gudipati (sngudipa)

=== Team Members ===
* Amulya Usem (ausem)
* Gowtham Pollam (gpollam)
* Basaveswara Mukesh Suryadevara (bsuryad)

=== Links ===
* Pull request [https://github.com/expertiza/expertiza/pull/2686]
* Github repo [https://github.com/amulyausem/expertiza]
* Deployed server [http://152.7.177.6:8080/]
Credentials : username - instructor6 password - password

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

What needs to be done
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Soultions =

=== Review_bids_others_work is a DRY violation ===

The file <code>review_bids_others_work.html.erb</code> has been refactored in order to resolve DRY violation by removing redundant code without impacting the current functionality.

[[File:Sol1.png|700px]]

=== Run_bidding algorithm should be assign_reviewers ===

<code>run_bidding_algorithm</code> was refactored to <code>assign_reviewers</code>. Accordingly, all the other instances of this were modified too.

[[File:Sol2.png|700px]]

[[File:Screenshot 2023-10-30 at 11.13.09 PM.png|700px]]

=== Currently it doesn't work if some student does not bid. In this case, the algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===

The code was modified to assign random reviews to students in case they didn't bid for any.

[[File:Screenshot 2023-10-30 at 11.17.02 PM.png|700px]]

=== Figure out why running the bidding algorithm only works on assignments with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===

Currently, it is mandatory to have a team but we can still make the team be assigned a project even if the team has only one member since there is no settings to place a minimum member cap. Although the member will have to create a team and assign a name so that the member can place a bid.

=== Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===

We have included a count variable in <code>assign_bidding</code> of controller <code>review_bids_controller.rb</code>. It helps us to keep track of the number of students bidding for reviews and is shown to the users in the view page.

[[File:Screenshot 2023-10-30 at 11.17.19 PM.png|700px]]

=== Ability to allow the algorithm to run again after running once. ===

Dependency on <code>can_choose_topic_to_review</code> attribute was removed for the visibility of the button <code>Run Review Algorithm</code> allowing the user to click and run the algorithm multiple times

[[File:Screenshot 2023-10-30 at 11.18.30 PM.png|700px]]

=== Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===

The methods in review_bid.rb are to get bidding data, to assign review topics, assign topic to reviewer and for getting individual reviewer_ids bidding data. These all are class methods. All the methods in review_bid.rb are converted into instance methods and other occurances were refactored to create an object and then call these methods.

[[File:Screenshot 2023-10-30 at 11.18.06 PM.png|700px]]

[[File:Screenshot 2023-10-30 at 11.18.17 PM.png|700px]]

=== In the previous implementation wiki, there are edge cases that are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===

More test cases for edge scenarios are to be implemented.

=== Test whether the topic changes color depending on the number of outstanding bids ===

A test case was added in <code>review_bids_helper_spec.rb</code> that test the changes in background color based on the number of participants and outstanding size.

[[File:Screenshot 2023-10-30 at 11.18.47 PM.png|700px]]

= Test Plan =

'''RSpec'''
*The main task here is to make sure the functionality didn't break due to addition of new code and refactoring the existing code.

*Since the methods in review_bid.rb were changed to instance methods, the corresponding testing files were refactored as well.
*For requirement 5, since a new attribute was added, we need to test if it is getting properly incremented and decremented.
*For requirement 6, we need to add a test case to check if the Run Review Algorithm button is enabled to run the algorithm again
*For requirement 9, a new test case was added in review_bids_helper_spec.rb that tests the changes in background color based on the number of participants and outstanding size.
*More test cases will be added for testing if reviews are being assigned randomly when the student doesn't bid.

'''Physical Testing'''
*Since there is no UI and it is being implemented in a different project, we have to make sure the changes are done using the direct links.
*We will have to run the project and check for all possible functionality that might get affected because of the refactoring done.
*For requirement 5, we will have to check if the count of bidding is displayed. It can be viewed at http://152.7.177.6:8080/review_bids/200

= References =

*https://github.com/expertiza/expertiza/pull/2150
*https://www.youtube.com/watch?v=wxXALQNWFcc
*https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review

CSC/ECE 517 Fall 2023 - E2350. Allow reviewers to bid on what to review

2023-11-02T17:47:57Z

Ausem:

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Srilekha Gudipati (sngudipa)

=== Team Members ===
* Amulya Usem (ausem)
* Gowtham Pollam (gpollam)
* Basaveswara Mukesh Suryadevara (bsuryad)

=== Links ===
* Pull request [https://github.com/expertiza/expertiza/pull/2686]
* Github repo [https://github.com/amulyausem/expertiza]
* Deployed server [http://152.7.177.6:8080/]
Credentials : username - instructor6 password - password

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

What needs to be done
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Soultions =

=== Review_bids_others_work is a DRY violation ===

The file <code>review_bids_others_work.html.erb</code> has been refactored in order to resolve DRY violation by removing redundant code without impacting the current functionality.

[[File:Sol1.png|700px]]

=== Run_bidding algorithm should be assign_reviewers ===

<code>run_bidding_algorithm</code> was refactored to <code>assign_reviewers</code>. Accordingly, all the other instances of this were modified too.

[[File:Sol2.png|700px]]

[[File:Screenshot 2023-10-30 at 11.13.09 PM.png|700px]]

=== Currently it doesn't work if some student does not bid. In this case, the algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===

The code was modified to assign random reviews to students in case they didn't bid for any.

[[File:Screenshot 2023-10-30 at 11.17.02 PM.png|700px]]

=== Figure out why running the bidding algorithm only works on assignments with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===

Currently, it is mandatory to have a team but we can still make the team be assigned a project even if the team has only one member since there is no settings to place a minimum member cap. Although the member will have to create a team and assign a name so that the member can place a bid.

=== Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===

We have included a count variable in <code>assign_bidding</code> of controller <code>review_bids_controller.rb</code>. It helps us to keep track of the number of students bidding for reviews and is shown to the users in the view page.

[[File:Screenshot 2023-10-30 at 11.17.19 PM.png|700px]]

=== Ability to allow the algorithm to run again after running once. ===

Dependency on <code>can_choose_topic_to_review</code> attribute was removed for the visibility of the button <code>Run Review Algorithm</code> allowing the user to click and run the algorithm multiple times

[[File:Screenshot 2023-10-30 at 11.18.30 PM.png|700px]]

=== Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===

The methods in review_bid.rb are to get bidding data, to assign review topics, assign topic to reviewer and for getting individual reviewer_ids bidding data. These all are class methods. All the methods in review_bid.rb are converted into instance methods and other occurances were refactored to create an object and then call these methods.

[[File:Screenshot 2023-10-30 at 11.18.06 PM.png|700px]]

[[File:Screenshot 2023-10-30 at 11.18.17 PM.png|700px]]

=== In the previous implementation wiki, there are edge cases that are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===

More test cases for edge scenarios are to be implemented.

=== Test whether the topic changes color depending on the number of outstanding bids ===

A test case was added in <code>review_bids_helper_spec.rb</code> that test the changes in background color based on the number of participants and outstanding size.

[[File:Screenshot 2023-10-30 at 11.18.47 PM.png|700px]]

= Test Plan =

'''RSpec'''
*The main task here is to make sure the functionality didn't break due to addition of new code and refactoring the existing code.

*Since the methods in review_bid.rb were changed to instance methods, the corresponding testing files were refactored as well.
*For requirement 5, since a new attribute was added, we need to test if it is getting properly incremented and decremented.
*For requirement 6, we need to add a test case to check if the Run Review Algorithm button is enabled to run the algorithm again
*For requirement 9, a new test case was added in review_bids_helper_spec.rb that tests the changes in background color based on the number of participants and outstanding size.
*More test cases will be added for testing if reviews are being assigned randomly when the student doesn't bid.

'''Physical Testing'''
*We will have to run the project and check for all possible functionality that might get affected because of the refactoring done.
*For requirement 5, we will have to check if the count of bidding is displayed.

= References =

*https://github.com/expertiza/expertiza/pull/2150
*https://www.youtube.com/watch?v=wxXALQNWFcc
*https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review

CSC/ECE 517 Fall 2023 - E2350. Allow reviewers to bid on what to review

2023-11-02T17:47:43Z

Ausem: /* Test Plan */

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Srilekha Gudipati (sngudipa)

=== Team Members ===
* Amulya Usem (ausem)
* Gowtham Pollam (gpollam)
* Basaveswara Mukesh Suryadevara (bsuryad)

=== Links ===
* Pull request [https://github.com/expertiza/expertiza/pull/2686]
* Github repo [https://github.com/amulyausem/expertiza]
* Deployed server [http://152.7.177.6:8080/]
Credentials : username - instructor6 password - password

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

What needs to be done
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Soultions =

=== Review_bids_others_work is a DRY violation ===

The file <code>review_bids_others_work.html.erb</code> has been refactored in order to resolve DRY violation by removing redundant code without impacting the current functionality.

[[File:Sol1.png|700px]]

=== Run_bidding algorithm should be assign_reviewers ===

<code>run_bidding_algorithm</code> was refactored to <code>assign_reviewers</code>. Accordingly, all the other instances of this were modified too.

[[File:Sol2.png|700px]]

[[File:Screenshot 2023-10-30 at 11.13.09 PM.png|700px]]

=== Currently it doesn't work if some student does not bid. In this case, the algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===

The code was modified to assign random reviews to students in case they didn't bid for any.

[[File:Screenshot 2023-10-30 at 11.17.02 PM.png|700px]]

=== Figure out why running the bidding algorithm only works on assignments with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===

Currently, it is mandatory to have a team but we can still make the team be assigned a project even if the team has only one member since there is no settings to place a minimum member cap. Although the member will have to create a team and assign a name so that the member can place a bid.

=== Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===

We have included a count variable in <code>assign_bidding</code> of controller <code>review_bids_controller.rb</code>. It helps us to keep track of the number of students bidding for reviews and is shown to the users in the view page.

[[File:Screenshot 2023-10-30 at 11.17.19 PM.png|700px]]

=== Ability to allow the algorithm to run again after running once. ===

Dependency on <code>can_choose_topic_to_review</code> attribute was removed for the visibility of the button <code>Run Review Algorithm</code> allowing the user to click and run the algorithm multiple times

[[File:Screenshot 2023-10-30 at 11.18.30 PM.png|700px]]

=== Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===

The methods in review_bid.rb are to get bidding data, to assign review topics, assign topic to reviewer and for getting individual reviewer_ids bidding data. These all are class methods. All the methods in review_bid.rb are converted into instance methods and other occurances were refactored to create an object and then call these methods.

[[File:Screenshot 2023-10-30 at 11.18.06 PM.png|700px]]

[[File:Screenshot 2023-10-30 at 11.18.17 PM.png|700px]]

=== In the previous implementation wiki, there are edge cases that are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===

More test cases for edge scenarios are to be implemented.

=== Test whether the topic changes color depending on the number of outstanding bids ===

A test case was added in <code>review_bids_helper_spec.rb</code> that test the changes in background color based on the number of participants and outstanding size.

[[File:Screenshot 2023-10-30 at 11.18.47 PM.png|700px]]

= Test Plan =

'''RSpec'''
*The main task here is to make sure the functionality didn't break due to addition of new code and refactoring the existing code.

*Since the methods in review_bid.rb were changed to instance methods, the corresponding testing files were refactored as well.
*For requirement 5, since a new attribute was added, we need to test if it is getting properly incremented and decremented.
*For requirement 6, we need to add a test case to check if the Run Review Algorithm button is enabled to run the algorithm again
*For requirement 9, a new test case was added in review_bids_helper_spec.rb that tests the changes in background color based on the number of participants and outstanding size.
*More test cases will be added for testing if reviews are being assigned randomly when the student doesn't bid.

'''Physical Testing'''
*We will have to run the project and check for all possible functionality that might get affected because of the refactoring done.
*For requirement 5, we will have to check if the count of bidding is displayed.

= References =

*https://github.com/expertiza/expertiza/pull/2150
*https://www.youtube.com/watch?v=wxXALQNWFcc
*https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review

CSC/ECE 517 Fall 2023 - E2350. Allow reviewers to bid on what to review

2023-11-02T17:46:58Z

Ausem:

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Srilekha Gudipati (sngudipa)

=== Team Members ===
* Amulya Usem (ausem)
* Gowtham Pollam (gpollam)
* Basaveswara Mukesh Suryadevara (bsuryad)

=== Links ===
* Pull request [https://github.com/expertiza/expertiza/pull/2686]
* Github repo [https://github.com/amulyausem/expertiza]
* Deployed server [http://152.7.177.6:8080/]
Credentials : username - instructor6 password - password

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

What needs to be done
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Soultions =

=== Review_bids_others_work is a DRY violation ===

The file <code>review_bids_others_work.html.erb</code> has been refactored in order to resolve DRY violation by removing redundant code without impacting the current functionality.

[[File:Sol1.png|700px]]

=== Run_bidding algorithm should be assign_reviewers ===

<code>run_bidding_algorithm</code> was refactored to <code>assign_reviewers</code>. Accordingly, all the other instances of this were modified too.

[[File:Sol2.png|700px]]

[[File:Screenshot 2023-10-30 at 11.13.09 PM.png|700px]]

=== Currently it doesn't work if some student does not bid. In this case, the algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===

The code was modified to assign random reviews to students in case they didn't bid for any.

[[File:Screenshot 2023-10-30 at 11.17.02 PM.png|700px]]

=== Figure out why running the bidding algorithm only works on assignments with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===

Currently, it is mandatory to have a team but we can still make the team be assigned a project even if the team has only one member since there is no settings to place a minimum member cap. Although the member will have to create a team and assign a name so that the member can place a bid.

=== Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===

We have included a count variable in <code>assign_bidding</code> of controller <code>review_bids_controller.rb</code>. It helps us to keep track of the number of students bidding for reviews and is shown to the users in the view page.

[[File:Screenshot 2023-10-30 at 11.17.19 PM.png|700px]]

=== Ability to allow the algorithm to run again after running once. ===

Dependency on <code>can_choose_topic_to_review</code> attribute was removed for the visibility of the button <code>Run Review Algorithm</code> allowing the user to click and run the algorithm multiple times

[[File:Screenshot 2023-10-30 at 11.18.30 PM.png|700px]]

=== Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===

The methods in review_bid.rb are to get bidding data, to assign review topics, assign topic to reviewer and for getting individual reviewer_ids bidding data. These all are class methods. All the methods in review_bid.rb are converted into instance methods and other occurances were refactored to create an object and then call these methods.

[[File:Screenshot 2023-10-30 at 11.18.06 PM.png|700px]]

[[File:Screenshot 2023-10-30 at 11.18.17 PM.png|700px]]

=== In the previous implementation wiki, there are edge cases that are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===

More test cases for edge scenarios are to be implemented.

=== Test whether the topic changes color depending on the number of outstanding bids ===

A test case was added in <code>review_bids_helper_spec.rb</code> that test the changes in background color based on the number of participants and outstanding size.

[[File:Screenshot 2023-10-30 at 11.18.47 PM.png|700px]]

= Test Plan =

RSpec
The main task here is to make sure the functionality didn't break due to addition of new code and refactoring the existing code.

Since the methods in review_bid.rb were changed to instance methods, the corresponding testing files were refactored as well.
For requirement 5, since a new attribute was added, we need to test if it is getting properly incremented and decremented.
For requirement 6, we need to add a test case to check if the Run Review Algorithm button is enabled to run the algorithm again
For requirement 9, a new test case was added in review_bids_helper_spec.rb that tests the changes in background color based on the number of participants and outstanding size.
More test cases will be added for testing if reviews are being assigned randomly when the student doesn't bid.

Physical Testing
We will have to run the project and check for all possible functionality that might get affected because of the refactoring done.
For requirement 5, we will have to check if the count of bidding is displayed.

= References =

*https://github.com/expertiza/expertiza/pull/2150
*https://www.youtube.com/watch?v=wxXALQNWFcc
*https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review

CSC/ECE 517 Fall 2023 - E2350. Allow reviewers to bid on what to review

2023-11-02T17:46:44Z

Ausem:

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Srilekha Gudipati (sngudipa)

=== Team Members ===
* Amulya Usem (ausem)
* Gowtham Pollam (gpollam)
* Basaveswara Mukesh Suryadevara (bsuryad)

=== Links ===
* Pull request [https://github.com/expertiza/expertiza/pull/2686]
* Github repo [https://github.com/amulyausem/expertiza]
* Deployed server [http://152.7.177.6:8080/]
Credentials : username - instructor6 password - password

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

What needs to be done
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Soultions =

=== Review_bids_others_work is a DRY violation ===

The file <code>review_bids_others_work.html.erb</code> has been refactored in order to resolve DRY violation by removing redundant code without impacting the current functionality.

[[File:Sol1.png|700px]]

=== Run_bidding algorithm should be assign_reviewers ===

<code>run_bidding_algorithm</code> was refactored to <code>assign_reviewers</code>. Accordingly, all the other instances of this were modified too.

[[File:Sol2.png|700px]]

[[File:Screenshot 2023-10-30 at 11.13.09 PM.png|700px]]

=== Currently it doesn't work if some student does not bid. In this case, the algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===

The code was modified to assign random reviews to students in case they didn't bid for any.

[[File:Screenshot 2023-10-30 at 11.17.02 PM.png|700px]]

=== Figure out why running the bidding algorithm only works on assignments with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===

Currently, it is mandatory to have a team but we can still make the team be assigned a project even if the team has only one member since there is no settings to place a minimum member cap. Although the member will have to create a team and assign a name so that the member can place a bid.

=== Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===

We have included a count variable in <code>assign_bidding</code> of controller <code>review_bids_controller.rb</code>. It helps us to keep track of the number of students bidding for reviews and is shown to the users in the view page.

[[File:Screenshot 2023-10-30 at 11.17.19 PM.png|700px]]

=== Ability to allow the algorithm to run again after running once. ===

Dependency on <code>can_choose_topic_to_review</code> attribute was removed for the visibility of the button <code>Run Review Algorithm</code> allowing the user to click and run the algorithm multiple times

[[File:Screenshot 2023-10-30 at 11.18.30 PM.png|700px]]

=== Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===

The methods in review_bid.rb are to get bidding data, to assign review topics, assign topic to reviewer and for getting individual reviewer_ids bidding data. These all are class methods. All the methods in review_bid.rb are converted into instance methods and other occurances were refactored to create an object and then call these methods.

[[File:Screenshot 2023-10-30 at 11.18.06 PM.png|700px]]

[[File:Screenshot 2023-10-30 at 11.18.17 PM.png|700px]]

=== In the previous implementation wiki, there are edge cases that are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===

More test cases for edge scenarios are to be implemented.

=== Test whether the topic changes color depending on the number of outstanding bids ===

A test case was added in <code>review_bids_helper_spec.rb</code> that test the changes in background color based on the number of participants and outstanding size.

[[File:Screenshot 2023-10-30 at 11.18.47 PM.png|700px]]

= Test Plan =

RSpec
The main task here is to make sure the functionality didn't break due to addition of new code and refactoring the existing code.

Since the methods in review_bid.rb were changed to instance methods, the corresponding testing files were refactored as well.
For requirement 5, since a new attribute was added, we need to test if it is getting properly incremented and decremented.
For requirement 6, we need to add a test case to check if the Run Review Algorithm button is enabled to run the algorithm again
For requirement 9, a new test case was added in review_bids_helper_spec.rb that tests the changes in background color based on the number of participants and outstanding size.
More test cases will be added for testing if reviews are being assigned randomly when the student doesn't bid.

Physical Testing
We will have to run the project and check for all possible functionality that might get affected because of the refactoring done.
For requirement 5, we will have to check if the count of bidding is displayed.

= References =

*https://github.com/expertiza/expertiza/pull/2150
*https://www.youtube.com/watch?v=wxXALQNWFcc
*https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review

CSC/ECE 517 Fall 2023 - E2350. Allow reviewers to bid on what to review

2023-11-02T17:46:19Z

Ausem:

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Srilekha Gudipati (sngudipa)

=== Team Members ===
* Amulya Usem (ausem)
* Gowtham Pollam (gpollam)
* Basaveswara Mukesh Suryadevara (bsuryad)

=== Links ===
* Pull request [https://github.com/expertiza/expertiza/pull/2686]
* Github repo [https://github.com/amulyausem/expertiza]
* Deployed server [http://152.7.177.6:8080/]
Credentials : username - instructor6 password - password

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

What needs to be done
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Soultions =

=== Review_bids_others_work is a DRY violation ===

The file <code>review_bids_others_work.html.erb</code> has been refactored in order to resolve DRY violation by removing redundant code without impacting the current functionality.

[[File:Sol1.png|700px]]

=== Run_bidding algorithm should be assign_reviewers ===

<code>run_bidding_algorithm</code> was refactored to <code>assign_reviewers</code>. Accordingly, all the other instances of this were modified too.

[[File:Sol2.png|700px]]

[[File:Screenshot 2023-10-30 at 11.13.09 PM.png|700px]]

=== Currently it doesn't work if some student does not bid. In this case, the algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===

The code was modified to assign random reviews to students in case they didn't bid for any.

[[File:Screenshot 2023-10-30 at 11.17.02 PM.png|700px]]

=== Figure out why running the bidding algorithm only works on assignments with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===

Currently, it is mandatory to have a team but we can still make the team be assigned a project even if the team has only one member since there is no settings to place a minimum member cap. Although the member will have to create a team and assign a name so that the member can place a bid.

=== Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===

We have included a count variable in <code>assign_bidding</code> of controller <code>review_bids_controller.rb</code>. It helps us to keep track of the number of students bidding for reviews and is shown to the users in the view page.

[[File:Screenshot 2023-10-30 at 11.17.19 PM.png|700px]]

=== Ability to allow the algorithm to run again after running once. ===

Dependency on <code>can_choose_topic_to_review</code> attribute was removed for the visibility of the button <code>Run Review Algorithm</code> allowing the user to click and run the algorithm multiple times

[[File:Screenshot 2023-10-30 at 11.18.30 PM.png|700px]]

=== Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===

The methods in review_bid.rb are to get bidding data, to assign review topics, assign topic to reviewer and for getting individual reviewer_ids bidding data. These all are class methods. All the methods in review_bid.rb are converted into instance methods and other occurances were refactored to create an object and then call these methods.

[[File:Screenshot 2023-10-30 at 11.18.06 PM.png|700px]]

[[File:Screenshot 2023-10-30 at 11.18.17 PM.png|700px]]

=== In the previous implementation wiki, there are edge cases that are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===

More test cases for edge scenarios are to be implemented.

=== Test whether the topic changes color depending on the number of outstanding bids ===

A test case was added in <code>review_bids_helper_spec.rb</code> that test the changes in background color based on the number of participants and outstanding size.

[[File:Screenshot 2023-10-30 at 11.18.47 PM.png|700px]]

== Test Plan ==

RSpec
The main task here is to make sure the functionality didn't break due to addition of new code and refactoring the existing code.

Since the methods in review_bid.rb were changed to instance methods, the corresponding testing files were refactored as well.
For requirement 5, since a new attribute was added, we need to test if it is getting properly incremented and decremented.
For requirement 6, we need to add a test case to check if the Run Review Algorithm button is enabled to run the algorithm again
For requirement 9, a new test case was added in review_bids_helper_spec.rb that tests the changes in background color based on the number of participants and outstanding size.
More test cases will be added for testing if reviews are being assigned randomly when the student doesn't bid.

Physical Testing
We will have to run the project and check for all possible functionality that might get affected because of the refactoring done.
For requirement 5, we will have to check if the count of bidding is displayed.

= References =

*https://github.com/expertiza/expertiza/pull/2150
*https://www.youtube.com/watch?v=wxXALQNWFcc
*https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review

CSC/ECE 517 Fall 2023 - E2350. Allow reviewers to bid on what to review

2023-11-01T15:44:33Z

Ausem:

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Srilekha Gudipati (sngudipa)

=== Team Members ===
* Amulya Usem (ausem)
* Gowtham Pollam (gpollam)
* Basaveswara Mukesh Suryadevara (bsuryad)

=== Links ===
* Pull request [https://github.com/expertiza/expertiza/pull/2686]
* Github repo [https://github.com/amulyausem/expertiza]
* Deployed server [http://152.7.177.6:8080/]
Credentials : username - instructor6 password - password

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

What needs to be done
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Soultions =

=== Review_bids_others_work is a DRY violation ===

The file <code>review_bids_others_work.html.erb</code> has been refactored in order to resolve DRY violation by removing redundant code without impacting the current functionality.

[[File:Sol1.png|700px]]

=== Run_bidding algorithm should be assign_reviewers ===

<code>run_bidding_algorithm</code> was refactored to <code>assign_reviewers</code>. Accordingly, all the other instances of this were modified too.

[[File:Sol2.png|700px]]

[[File:Screenshot 2023-10-30 at 11.13.09 PM.png|700px]]

=== Currently it doesn't work if some student does not bid. In this case, the algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===

The code was modified to assign random reviews to students in case they didn't bid for any.

[[File:Screenshot 2023-10-30 at 11.17.02 PM.png|700px]]

=== Figure out why running the bidding algorithm only works on assignments with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===

Currently, it is mandatory to have a team but we can still make the team be assigned a project even if the team has only one member since there is no settings to place a minimum member cap. Although the member will have to create a team and assign a name so that the member can place a bid.

=== Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===

We have included a count variable in <code>assign_bidding</code> of controller <code>review_bids_controller.rb</code>. It helps us to keep track of the number of students bidding for reviews and is shown to the users in the view page.

[[File:Screenshot 2023-10-30 at 11.17.19 PM.png|700px]]

=== Ability to allow the algorithm to run again after running once. ===

Dependency on <code>can_choose_topic_to_review</code> attribute was removed for the visibility of the button <code>Run Review Algorithm</code> allowing the user to click and run the algorithm multiple times

[[File:Screenshot 2023-10-30 at 11.18.30 PM.png|700px]]

=== Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===

All the methods in review_bid.rb are converted into instance methods and other occurances were refactored to create an object and then call these methods.

[[File:Screenshot 2023-10-30 at 11.18.06 PM.png|700px]]

[[File:Screenshot 2023-10-30 at 11.18.17 PM.png|700px]]

=== In the previous implementation wiki, there are edge cases that are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===

More test cases for edge scenarios are to be implemented.

=== Test whether the topic changes color depending on the number of outstanding bids ===

A test case was added in <code>review_bids_helper_spec.rb</code> that test the changes in background color based on the number of participants and outstanding size.

[[File:Screenshot 2023-10-30 at 11.18.47 PM.png|700px]]

= References =

*https://github.com/expertiza/expertiza/pull/2150
*https://www.youtube.com/watch?v=wxXALQNWFcc
*https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review

CSC/ECE 517 Fall 2023 - E2350. Allow reviewers to bid on what to review

2023-10-31T03:39:24Z

Ausem:

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Srilekha Gudipati (sngudipa)

=== Team Members ===
* Amulya Usem (ausem)
* Gowtham Pollam (gpollam)
* Basaveswara Mukesh Suryadevara (bsuryad)

=== Links ===
* Pull request [https://github.com/expertiza/expertiza/pull/2686]
* Github repo [https://github.com/amulyausem/expertiza]
* Deployed server [http://152.7.177.6:8080/]
Credentials : username - instructor6 password - password

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

What needs to be done
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Soultions =

=== Review_bids_others_work is a DRY violation ===

The file <code>review_bids_others_work.html.erb</code> has been refactored in order to resolve DRY violation by removing redundant code without impacting the current functionality.

[[File:Sol1.png|700px]]

=== Run_bidding algorithm should be assign_reviewers ===

<code>run_bidding_algorithm</code> was refactored to <code>assign_reviewers</code>. Accordingly, all the other instances of this were modified too.

[[File:Sol2.png|700px]]

[[File:Screenshot 2023-10-30 at 11.13.09 PM.png|700px]]

=== Currently it doesn't work if some student does not bid. In this case, the algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===

The code was modified to assign random reviews to students in case they didn't bid for any.

[[File:Screenshot 2023-10-30 at 11.18.06 PM.png|700px]]

=== Figure out why running the bidding algorithm only works on assignments with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===

Currently, it is mandatory to have a team but we can still make the team be assigned a project even if the team has only one member since there is no settings to place a minimum member cap. Although the member will have to create a team and assign a name so that the member can place a bid.

=== Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===

We have included a count variable in <code>assign_bidding</code> of controller <code>review_bids_controller.rb</code>. It helps us to keep track of the number of students bidding for reviews and is shown to the users in the view page.

[[File:Screenshot 2023-10-30 at 11.17.19 PM.png|700px]]

=== Ability to allow the algorithm to run again after running once. ===

Dependency on <code>can_choose_topic_to_review</code> attribute was removed for the visibility of the button <code>Run Review Algorithm</code> allowing the user to click and run the algorithm multiple times

[[File:Screenshot 2023-10-30 at 11.18.30 PM.png|700px]]

=== Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===

All the methods in review_bid.rb are converted into instance methods and other occurances were refactored to create an object and then call these methods.

[[File:Screenshot 2023-10-30 at 11.17.02 PM.png|700px]]

[[File:Screenshot 2023-10-30 at 11.18.17 PM.png|700px]]

=== In the previous implementation wiki, there are edge cases that are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===

More test cases for edge scenarios are to be implemented.

=== Test whether the topic changes color depending on the number of outstanding bids ===

A test case was added in <code>review_bids_helper_spec.rb</code> that test the changes in background color based on the number of participants and outstanding size.

[[File:Screenshot 2023-10-30 at 11.18.47 PM.png|700px]]

= References =

*https://github.com/expertiza/expertiza/pull/2150
*https://www.youtube.com/watch?v=wxXALQNWFcc
*https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review

CSC/ECE 517 Fall 2023 - E2350. Allow reviewers to bid on what to review

2023-10-31T03:39:00Z

Ausem:

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Srilekha Gudipati (sngudipa)

=== Team Members ===
* Amulya Usem (ausem)
* Gowtham Pollam (gpollam)
* Basaveswara Mukesh Suryadevara (bsuryad)

=== Links ===
* Pull request [https://github.com/expertiza/expertiza/pull/2686]
* Github repo [https://github.com/amulyausem/expertiza]
* Deployed server [http://152.7.177.6:8080/]
Credentials : username - instructor6 password - password

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

What needs to be done
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Soultions =

=== Review_bids_others_work is a DRY violation ===

The file <code>review_bids_others_work.html.erb</code> has been refactored in order to resolve DRY violation by removing redundant code without impacting the current functionality.

[[File:Sol1.png|700px]]

=== Run_bidding algorithm should be assign_reviewers ===

<code>run_bidding_algorithm</code> was refactored to <code>assign_reviewers</code>. Accordingly, all the other instances of this were modified too.

[[File:Sol2.png|700px]]

[[File:Screenshot 2023-10-30 at 11.13.09 PM.png|700px]]

=== Currently it doesn't work if some student does not bid. In this case, the algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===

The code was modified to assign random reviews to students in case they didn't bid for any.

[[File:Screenshot 2023-10-30 at 11.18.06 PM.png|700px]]

=== Figure out why running the bidding algorithm only works on assignments with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===

Currently, it is mandatory to have a team but we can still make the team be assigned a project even if the team has only one member since there is no settings to place a minimum member cap. Although the member will have to create a team and assign a name so that the member can place a bid.

=== Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===

We have included a count variable in <code>assign_bidding</code> of controller <code>review_bids_controller.rb</code>. It helps us to keep track of the number of students bidding for reviews and is shown to the users in the view page.

[[File:Screenshot 2023-10-30 at 11.17.19 PM.png|700px]]

=== Ability to allow the algorithm to run again after running once. ===

Dependency on <code>can_choose_topic_to_review</code> attribute was removed for the visibility of the button <code>Run Review Algorithm</code> allowing the user to click and run the algorithm multiple times

[[File:Screenshot 2023-10-30 at 11.18.30 PM.png|700px]]

=== Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===

All the methods in review_bid.rb are converted into instance methods and other occurances were refactored to create an object and then call these methods.

[[File:Screenshot 2023-10-30 at 11.17.02 PM.png|700px]]

[[File:Screenshot 2023-10-30 at 11.18.17 PM.png|700px]]

=== In the previous implementation wiki, there are edge cases that are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===

More test cases for edge scenarios are to be implemented.

=== Test whether the topic changes color depending on the number of outstanding bids ===

A test case was added in <code>review_bids_helper_spec.rb</code> that test the changes in background color based on the number of participants and outstanding size.

[[File:Screenshot 2023-10-30 at 11.18.47 PM.png|700px]]

= References =

https://github.com/expertiza/expertiza/pull/2150
https://www.youtube.com/watch?v=wxXALQNWFcc
https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review

CSC/ECE 517 Fall 2023 - E2350. Allow reviewers to bid on what to review

2023-10-31T03:38:38Z

Ausem:

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Srilekha Gudipati (sngudipa)

=== Team Members ===
* Amulya Usem (ausem)
* Gowtham Pollam (gpollam)
* Basaveswara Mukesh Suryadevara (bsuryad)

=== Links ===
* Pull request [https://github.com/expertiza/expertiza/pull/2686]
* Github repo [https://github.com/amulyausem/expertiza]
* Deployed server [http://152.7.177.6:8080/]
Credentials : username - instructor6 password - password

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

What needs to be done
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

== Soultions ==

=== Review_bids_others_work is a DRY violation ===

The file <code>review_bids_others_work.html.erb</code> has been refactored in order to resolve DRY violation by removing redundant code without impacting the current functionality.

[[File:Sol1.png|700px]]

=== Run_bidding algorithm should be assign_reviewers ===

<code>run_bidding_algorithm</code> was refactored to <code>assign_reviewers</code>. Accordingly, all the other instances of this were modified too.

[[File:Sol2.png|700px]]

[[File:Screenshot 2023-10-30 at 11.13.09 PM.png|700px]]

=== Currently it doesn't work if some student does not bid. In this case, the algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===

The code was modified to assign random reviews to students in case they didn't bid for any.

[[File:Screenshot 2023-10-30 at 11.18.06 PM.png|700px]]

=== Figure out why running the bidding algorithm only works on assignments with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===

Currently, it is mandatory to have a team but we can still make the team be assigned a project even if the team has only one member since there is no settings to place a minimum member cap. Although the member will have to create a team and assign a name so that the member can place a bid.

=== Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===

We have included a count variable in <code>assign_bidding</code> of controller <code>review_bids_controller.rb</code>. It helps us to keep track of the number of students bidding for reviews and is shown to the users in the view page.

[[File:Screenshot 2023-10-30 at 11.17.19 PM.png|700px]]

=== Ability to allow the algorithm to run again after running once. ===

Dependency on <code>can_choose_topic_to_review</code> attribute was removed for the visibility of the button <code>Run Review Algorithm</code> allowing the user to click and run the algorithm multiple times

[[File:Screenshot 2023-10-30 at 11.18.30 PM.png|700px]]

=== Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===

All the methods in review_bid.rb are converted into instance methods and other occurances were refactored to create an object and then call these methods.

[[File:Screenshot 2023-10-30 at 11.17.02 PM.png|700px]]

[[File:Screenshot 2023-10-30 at 11.18.17 PM.png|700px]]

=== In the previous implementation wiki, there are edge cases that are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===

More test cases for edge scenarios are to be implemented.

=== Test whether the topic changes color depending on the number of outstanding bids ===

A test case was added in <code>review_bids_helper_spec.rb</code> that test the changes in background color based on the number of participants and outstanding size.

[[File:Screenshot 2023-10-30 at 11.18.47 PM.png|700px]]

=== References ===

https://github.com/expertiza/expertiza/pull/2150
https://www.youtube.com/watch?v=wxXALQNWFcc
https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review

CSC/ECE 517 Fall 2023 - E2350. Allow reviewers to bid on what to review

2023-10-31T03:38:16Z

Ausem:

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Srilekha Gudipati (sngudipa)

=== Team Members ===
* Amulya Usem (ausem)
* Gowtham Pollam (gpollam)
* Basaveswara Mukesh Suryadevara (bsuryad)

=== Links ===
* Pull request [https://github.com/expertiza/expertiza/pull/2686]
* Github repo [https://github.com/amulyausem/expertiza]
* Deployed server [http://152.7.177.6:8080/]
Credentials : username - instructor6 password - password

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

What needs to be done
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

== Soultions ==

=== Review_bids_others_work is a DRY violation ===

The file <code>review_bids_others_work.html.erb</code> has been refactored in order to resolve DRY violation by removing redundant code without impacting the current functionality.

[[File:Sol1.png|700px]]

=== Run_bidding algorithm should be assign_reviewers ===

<code>run_bidding_algorithm</code> was refactored to <code>assign_reviewers</code>. Accordingly, all the other instances of this were modified too.

[[File:Sol2.png|700px]]

[[File:Screenshot 2023-10-30 at 11.13.09 PM.png|700px]]

=== Currently it doesn't work if some student does not bid. In this case, the algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===

The code was modified to assign random reviews to students in case they didn't bid for any.

[[File:Screenshot 2023-10-30 at 11.18.06 PM.png|700px]]

=== Figure out why running the bidding algorithm only works on assignments with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===

Currently, it is mandatory to have a team but we can still make the team be assigned a project even if the team has only one member since there is no settings to place a minimum member cap. Although the member will have to create a team and assign a name so that the member can place a bid.

=== Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===

We have included a count variable in <code>assign_bidding</code> of controller <code>review_bids_controller.rb</code>. It helps us to keep track of the number of students bidding for reviews and is shown to the users in the view page.

[[File:Screenshot 2023-10-30 at 11.17.19 PM.png|700px]]

=== Ability to allow the algorithm to run again after running once. ===

Dependency on <code>can_choose_topic_to_review</code> attribute was removed for the visibility of the button <code>Run Review Algorithm</code> allowing the user to click and run the algorithm multiple times

[[File:Screenshot 2023-10-30 at 11.18.30 PM.png|700px]]

=== Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===

All the methods in review_bid.rb are converted into instance methods and other occurances were refactored to create an object and then call these methods.

[[File:Screenshot 2023-10-30 at 11.17.02 PM.png|700px]]

[[File:Screenshot 2023-10-30 at 11.18.17 PM.png|700px]]

=== In the previous implementation wiki, there are edge cases that are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===

More test cases for edge scenarios are to be implemented.

=== Test whether the topic changes color depending on the number of outstanding bids ===

A test case was added in <code>review_bids_helper_spec.rb</code> that test the changes in background color based on the number of participants and outstanding size.

[[File:Screenshot 2023-10-30 at 11.18.47 PM.png|700px]]

== References ==

https://github.com/expertiza/expertiza/pull/2150
https://www.youtube.com/watch?v=wxXALQNWFcc
https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review

CSC/ECE 517 Fall 2023 - E2350. Allow reviewers to bid on what to review

2023-10-31T03:32:54Z

Ausem:

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Srilekha Gudipati (sngudipa)

=== Team Members ===
* Amulya Usem (ausem)
* Gowtham Pollam (gpollam)
* Basaveswara Mukesh Suryadevara (bsuryad)

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

What needs to be done
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

== Soultions ==

=== Review_bids_others_work is a DRY violation ===

The file <code>review_bids_others_work.html.erb</code> has been refactored in order to resolve DRY violation by removing redundant code without impacting the current functionality.

[[File:Sol1.png|700px]]

=== Run_bidding algorithm should be assign_reviewers ===

<code>run_bidding_algorithm</code> was refactored to <code>assign_reviewers</code>. Accordingly, all the other instances of this were modified too.

[[File:Sol2.png|700px]]

[[File:Screenshot 2023-10-30 at 11.13.09 PM.png|700px]]

=== Currently it doesn't work if some student does not bid. In this case, the algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===

The code was modified to assign random reviews to students in case they didn't bid for any.

[[File:Screenshot 2023-10-30 at 11.18.06 PM.png|700px]]

=== Figure out why running the bidding algorithm only works on assignments with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===

Currently, it is mandatory to have a team but we can still make the team be assigned a project even if the team has only one member since there is no settings to place a minimum member cap. Although the member will have to create a team and assign a name so that the member can place a bid.

=== Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===

We have included a count variable in <code>assign_bidding</code> of controller <code>review_bids_controller.rb</code>. It helps us to keep track of the number of students bidding for reviews and is shown to the users in the view page.

[[File:Screenshot 2023-10-30 at 11.17.19 PM.png|700px]]

=== Ability to allow the algorithm to run again after running once. ===

Dependency on <code>can_choose_topic_to_review</code> attribute was removed for the visibility of the button <code>Run Review Algorithm</code> allowing the user to click and run the algorithm multiple times

[[File:Screenshot 2023-10-30 at 11.18.30 PM.png|700px]]

=== Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===

All the methods in review_bid.rb are converted into instance methods and other occurances were refactored to create an object and then call these methods.

[[File:Screenshot 2023-10-30 at 11.17.02 PM.png|700px]]

[[File:Screenshot 2023-10-30 at 11.18.17 PM.png|700px]]

=== In the previous implementation wiki, there are edge cases that are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===

More test cases for edge scenarios are to be implemented.

=== Test whether the topic changes color depending on the number of outstanding bids ===

A test case was added in <code>review_bids_helper_spec.rb</code> that test the changes in background color based on the number of participants and outstanding size.

[[File:Screenshot 2023-10-30 at 11.18.47 PM.png|700px]]

CSC/ECE 517 Fall 2023 - E2350. Allow reviewers to bid on what to review

2023-10-31T03:32:18Z

Ausem:

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Srilekha Gudipati (sngudipa)

=== Team Members ===
* Amulya Usem (ausem)
* Gowtham Pollam (gpollam)
* Basaveswara Mukesh Suryadevara (bsuryad)

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

What needs to be done
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

== Soultions ==

=== Review_bids_others_work is a DRY violation ===

The file <code>review_bids_others_work.html.erb</code> has been refactored in order to resolve DRY violation by removing redundant code without impacting the current functionality.

[[File:Sol1.png|700px]]

=== Run_bidding algorithm should be assign_reviewers ===

<code>run_bidding_algorithm</code> was refactored to <code>assign_reviewers</code>. Accordingly, all the other instances of this were modified too.

[[File:Sol2.png|700px]]

[[File:Screenshot 2023-10-30 at 11.13.09 PM.png|700px]]

=== Currently it doesn't work if some student does not bid. In this case, the algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===

The code was modified to assign random reviews to students in case they didn't bid for any.

[[File:Screenshot 2023-10-30 at 11.18.06 PM.png|700px]]

=== Figure out why running the bidding algorithm only works on assignments with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===

Currently, it is mandatory to have a team but we can still make the team be assigned a project even if the team has only one member since there is no settings to place a minimum member cap. Although the member will have to create a team and assign a name so that the member can place a bid.

=== Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===

We have included a count variable in <code>assign_bidding</code> of controller <code>review_bids_controller.rb</code>. It helps us to keep track of the number of students bidding for reviews and is shown to the users in the view page.

[[File:Screenshot 2023-10-30 at 11.17.19 PM.png|700px]]

=== Ability to allow the algorithm to run again after running once. ===

Dependency on <code>can_choose_topic_to_review</code> attribute was removed for the visibility of the button <code>Run Review Algorithm</code> allowing the user to click and run the algorithm multiple times

[[File:Screenshot 2023-10-30 at 11.18.30 PM.png|700px]]

=== Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===

All the methods in review_bid.rb are converted into instance methods and other occurances were refactored to create an object and then call these methods.

[[File:Screenshot 2023-10-30 at 11.17.02 PM.png|700px]]

[[File:Screenshot 2023-10-30 at 11.18.17 PM.png|700px]]

=== In the previous implementation wiki, there are edge cases that are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===

More test cases for edge scenarios are to be implemented.

=== Test whether the topic changes color depending on the number of outstanding bids ===

A test case was added in <code>review_bids_helper_spec.rb</code> that test the changes in background color based on the number of participants and outstanding size.

[[File:Screenshot 2023-10-30 at 11.18.47 PM.png|700px]]

File:Screenshot 2023-10-30 at 11.18.17 PM.png

2023-10-31T03:28:12Z

Ausem:

File:Screenshot 2023-10-30 at 11.18.30 PM.png

2023-10-31T03:27:58Z

Ausem:

File:Screenshot 2023-10-30 at 11.18.47 PM.png

2023-10-31T03:27:46Z

Ausem:

CSC/ECE 517 Fall 2023 - E2350. Allow reviewers to bid on what to review

2023-10-31T03:25:34Z

Ausem: /* Soultions */

File:Screenshot 2023-10-30 at 11.17.19 PM.png

2023-10-31T03:20:30Z

Ausem: Ausem uploaded a new version of File:Screenshot 2023-10-30 at 11.17.19 PM.png

File:Screenshot 2023-10-30 at 11.17.02 PM.png

2023-10-31T03:20:16Z

Ausem:

File:Screenshot 2023-10-30 at 11.17.19 PM.png

2023-10-31T03:19:48Z

Ausem: