Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-05-01T02:42:53Z

Schatte5: /* Useful Links */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--'''every other spec file mentioned above crashes'''.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

=== Code and Documentation Goals ===

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:
* data flow
* functions
* code comments

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|345px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
[[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]<br>
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts.

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

== Implementation ==

The following is a code snippet of the new view only, the grading history view. Other changes can be seen from the Pull Request linked at the end.

*/app/views/grading_histories/index.html.erb
<pre>
<% record = @grading_histories[0]
if record == nil
receiver = ""
assignment = ""
else
if record.grading_type == "Submission"
receiver = "of " + Team.where(id: record.grade_receiver_id).pluck(:name).first
assignment = "for the submission " + Assignment.where(id: record.assignment_id).pluck(:name).first
else
receiver = "of " + User.where(id: record.grade_receiver_id).pluck(:fullname).first
assignment = "for review in " + Assignment.where(id: record.assignment_id).pluck(:name).first
end

end
%>
<h1 class="center">Grade History <%= receiver %> <%= assignment %></h1>

<table style="border-collapse:collapse; table-layout:fixed; width:1500px;">
<thead>
<tr>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Instructor</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Grade</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Comment</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Graded At</th>
</tr>


<tbody>
<% @grading_histories.each do |record| %>
<tr>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= User.where(id: record.instructor_id).pluck(:fullname).first %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.grade %></td>
<td style="padding:10px; border:solid 1.5px black; width:60px; word-wrap:break-word;"><%= record.comment %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.created_at %></td>
</tr>
<% end %>
</tbody>
</table>
</pre>

*Screenshot of the Grading History Table

[[File:Submission_Grading_History_Table.jpeg|1000px]]

The student ID and the Assignment ID have been moved to the header in accordance with the DRY principle. The redundant fields present in the table have also been removed.
We have created a factory for testing grading histories controller and included tests for grading_histories_controller, grades_controller and review_mapping_controller.

== Testing ==
=== Video Demonstration ===

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]<br>
[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Assignments can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''

*Factory
<pre>
#Used for Grading Histories Controller Spec
factory :grading_history, class: GradingHistory do
id 1
instructor_id 6
assignment_id 1
grading_type 'Submission'
grade_receiver_id 1
grade 100
comment 'Good work!'
end
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>

*Grading Histories
<pre>
Scenario: Grading History creation
Given: A team exists for a particular assignment and has a submission
When: An instructor assigns a grade for that submission
Then: The grading history entry is created
</pre>

*Review Mapping
<pre>
Scenario: Save Reviewer Grade and Comment
Given: A student has given a review for a submission
When: An instructor assigns a grade for the review
Then: The assigned grade and the accompanying comment are saved
</pre>

*Grade
<pre>
Scenario: Save Grade and Comment for Submission
Given: A team has made a submission for an assignment
When: An instructor assigns a grade for the submission
Then: The assigned grade and the accompanying comment are saved
</pre>

=== Manual UI Tests ===
*Student ID in header
<pre>
Scenario: Student ID/Team ID (Receiver_ID) in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Receiver ID appears in the header, not in any table columns
</pre>

*Assignment Name in header
<pre>
Scenario: Assignment Name in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment Name appears in the header, not in any table columns
</pre>

*Color change after Grade is assigned to a submission
<pre>
Scenario: Team_ID Color changes from blue to brown when grade is assigned
Logged in as an Instructor of Course/Admin or TA assigned to Course
On Assignment page, click on Etc->View Submissions
All submissions for assignment are shown
Team name is blue, and grade is not assigned
Click on "Assign Grade" under team name
Instructor/TA assigns grade, save successfully
Back to submissions list, team name is now brown
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* '''TA Grade Editing Problems:''' The current version of beta branch has an issue wherein grades that have already been assigned cannot be changed by any TAs. This issue has been brought to the attention of the Expertiza team.

=== Conclusion ===
* '''Functionality:''' The functionality regarding grading changes/trails has been demonstrably completed; Instructors can change grades for their assignment submissions, and the changes are reflected in the enw created Grading History Table.
* '''Appearance:''' The requested layout of the Grading History table, with the student/teamID & the assignmentID at the header, along with the instructorID in it's own column on the left, is done, and is shown in the screenshots in this document.
* '''Testing:''' Tests have been added into Expertiza that ensure that the positive flows work as intended. More tests need to be added for completeness, as stated below.
* '''Future Work:''' More testing is required - with so many, more time & work is needed to add tests that ensure comprehensive coverage.

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]

[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

[https://www.youtube.com/watch?v=YmXsANRlB5Q Updated RSpec Demo]

[https://github.com/expertiza/expertiza/pull/2407 Pull Request]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-05-01T02:42:08Z

Schatte5: /* Useful Links */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--'''every other spec file mentioned above crashes'''.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

=== Code and Documentation Goals ===

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:
* data flow
* functions
* code comments

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|345px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
[[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]<br>
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts.

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

== Implementation ==

The following is a code snippet of the new view only, the grading history view. Other changes can be seen from the Pull Request linked at the end.

*/app/views/grading_histories/index.html.erb
<pre>
<% record = @grading_histories[0]
if record == nil
receiver = ""
assignment = ""
else
if record.grading_type == "Submission"
receiver = "of " + Team.where(id: record.grade_receiver_id).pluck(:name).first
assignment = "for the submission " + Assignment.where(id: record.assignment_id).pluck(:name).first
else
receiver = "of " + User.where(id: record.grade_receiver_id).pluck(:fullname).first
assignment = "for review in " + Assignment.where(id: record.assignment_id).pluck(:name).first
end

end
%>
<h1 class="center">Grade History <%= receiver %> <%= assignment %></h1>

<table style="border-collapse:collapse; table-layout:fixed; width:1500px;">
<thead>
<tr>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Instructor</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Grade</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Comment</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Graded At</th>
</tr>


<tbody>
<% @grading_histories.each do |record| %>
<tr>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= User.where(id: record.instructor_id).pluck(:fullname).first %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.grade %></td>
<td style="padding:10px; border:solid 1.5px black; width:60px; word-wrap:break-word;"><%= record.comment %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.created_at %></td>
</tr>
<% end %>
</tbody>
</table>
</pre>

*Screenshot of the Grading History Table

[[File:Submission_Grading_History_Table.jpeg|1000px]]

The student ID and the Assignment ID have been moved to the header in accordance with the DRY principle. The redundant fields present in the table have also been removed.
We have created a factory for testing grading histories controller and included tests for grading_histories_controller, grades_controller and review_mapping_controller.

== Testing ==
=== Video Demonstration ===

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]<br>
[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Assignments can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''

*Factory
<pre>
#Used for Grading Histories Controller Spec
factory :grading_history, class: GradingHistory do
id 1
instructor_id 6
assignment_id 1
grading_type 'Submission'
grade_receiver_id 1
grade 100
comment 'Good work!'
end
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>

*Grading Histories
<pre>
Scenario: Grading History creation
Given: A team exists for a particular assignment and has a submission
When: An instructor assigns a grade for that submission
Then: The grading history entry is created
</pre>

*Review Mapping
<pre>
Scenario: Save Reviewer Grade and Comment
Given: A student has given a review for a submission
When: An instructor assigns a grade for the review
Then: The assigned grade and the accompanying comment are saved
</pre>

*Grade
<pre>
Scenario: Save Grade and Comment for Submission
Given: A team has made a submission for an assignment
When: An instructor assigns a grade for the submission
Then: The assigned grade and the accompanying comment are saved
</pre>

=== Manual UI Tests ===
*Student ID in header
<pre>
Scenario: Student ID/Team ID (Receiver_ID) in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Receiver ID appears in the header, not in any table columns
</pre>

*Assignment Name in header
<pre>
Scenario: Assignment Name in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment Name appears in the header, not in any table columns
</pre>

*Color change after Grade is assigned to a submission
<pre>
Scenario: Team_ID Color changes from blue to brown when grade is assigned
Logged in as an Instructor of Course/Admin or TA assigned to Course
On Assignment page, click on Etc->View Submissions
All submissions for assignment are shown
Team name is blue, and grade is not assigned
Click on "Assign Grade" under team name
Instructor/TA assigns grade, save successfully
Back to submissions list, team name is now brown
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* '''TA Grade Editing Problems:''' The current version of beta branch has an issue wherein grades that have already been assigned cannot be changed by any TAs. This issue has been brought to the attention of the Expertiza team.

=== Conclusion ===
* '''Functionality:''' The functionality regarding grading changes/trails has been demonstrably completed; Instructors can change grades for their assignment submissions, and the changes are reflected in the enw created Grading History Table.
* '''Appearance:''' The requested layout of the Grading History table, with the student/teamID & the assignmentID at the header, along with the instructorID in it's own column on the left, is done, and is shown in the screenshots in this document.
* '''Testing:''' Tests have been added into Expertiza that ensure that the positive flows work as intended. More tests need to be added for completeness, as stated below.
* '''Future Work:''' More testing is required - with so many, more time & work is needed to add tests that ensure comprehensive coverage.

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]

[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

[https://github.com/expertiza/expertiza/pull/2407 Pull Request]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-28T20:09:20Z

Schatte5: /* Conclusion */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--'''every other spec file mentioned above crashes'''.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

=== Code and Documentation Goals ===

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:
* data flow
* functions
* code comments

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|345px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
[[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]<br>
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts.

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

== Implementation ==

The following is a code snippet of the new view only, the grading history view. Other changes can be seen from the Pull Request linked at the end.

*/app/views/grading_histories/index.html.erb
<pre>
<% record = @grading_histories[0]
if record == nil
receiver = ""
assignment = ""
else
if record.grading_type == "Submission"
receiver = "of " + Team.where(id: record.grade_receiver_id).pluck(:name).first
assignment = "for the submission " + Assignment.where(id: record.assignment_id).pluck(:name).first
else
receiver = "of " + User.where(id: record.grade_receiver_id).pluck(:fullname).first
assignment = "for review in " + Assignment.where(id: record.assignment_id).pluck(:name).first
end

end
%>
<h1 class="center">Grade History <%= receiver %> <%= assignment %></h1>

<table style="border-collapse:collapse; table-layout:fixed; width:1500px;">
<thead>
<tr>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Instructor</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Grade</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Comment</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Graded At</th>
</tr>


<tbody>
<% @grading_histories.each do |record| %>
<tr>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= User.where(id: record.instructor_id).pluck(:fullname).first %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.grade %></td>
<td style="padding:10px; border:solid 1.5px black; width:60px; word-wrap:break-word;"><%= record.comment %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.created_at %></td>
</tr>
<% end %>
</tbody>
</table>
</pre>

*Screenshot of the Grading History Table

[[File:Submission_Grading_History_Table.jpeg|1000px]]

The student ID and the Assignment ID have been moved to the header in accordance with the DRY principle. The redundant fields present in the table have also been removed.
We have created a factory for testing grading histories controller and included tests for grading_histories_controller, grades_controller and review_mapping_controller.

== Testing ==
=== Video Demonstration ===

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]<br>
[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Assignments can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''

*Factory
<pre>
#Used for Grading Histories Controller Spec
factory :grading_history, class: GradingHistory do
id 1
instructor_id 6
assignment_id 1
grading_type 'Submission'
grade_receiver_id 1
grade 100
comment 'Good work!'
end
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>

*Grading Histories
<pre>
Scenario: Grading History creation
Given: A team exists for a particular assignment and has a submission
When: An instructor assigns a grade for that submission
Then: The grading history entry is created
</pre>

*Review Mapping
<pre>
Scenario: Save Reviewer Grade and Comment
Given: A student has given a review for a submission
When: An instructor assigns a grade for the review
Then: The assigned grade and the accompanying comment are saved
</pre>

*Grade
<pre>
Scenario: Save Grade and Comment for Submission
Given: A team has made a submission for an assignment
When: An instructor assigns a grade for the submission
Then: The assigned grade and the accompanying comment are saved
</pre>

=== Manual UI Tests ===
*Student ID in header
<pre>
Scenario: Student ID/Team ID (Receiver_ID) in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Receiver ID appears in the header, not in any table columns
</pre>

*Assignment Name in header
<pre>
Scenario: Assignment Name in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment Name appears in the header, not in any table columns
</pre>

*Color change after Grade is assigned to a submission
<pre>
Scenario: Team_ID Color changes from blue to brown when grade is assigned
Logged in as an Instructor of Course/Admin or TA assigned to Course
On Assignment page, click on Etc->View Submissions
All submissions for assignment are shown
Team name is blue, and grade is not assigned
Click on "Assign Grade" under team name
Instructor/TA assigns grade, save successfully
Back to submissions list, team name is now brown
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* '''TA Grade Editing Problems:''' The current version of beta branch has an issue wherein grades that have already been assigned cannot be changed by any TAs. This issue has been brought to the attention of the Expertiza team.

=== Conclusion ===
* '''Functionality:''' The functionality regarding grading changes/trails has been demonstrably completed; Instructors can change grades for their assignment submissions, and the changes are reflected in the enw created Grading History Table.
* '''Appearance:''' The requested layout of the Grading History table, with the student/teamID & the assignmentID at the header, along with the instructorID in it's own column on the left, is done, and is shown in the screenshots in this document.
* '''Testing:''' Tests have been added into Expertiza that ensure that the positive flows work as intended. More tests need to be added for completeness, as stated below.
* '''Future Work:''' More testing is required - with so many, more time & work is needed to add tests that ensure comprehensive coverage.

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]

[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

[https://github.com/expertiza/expertiza/pull/2399 Pull Request]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-28T19:57:40Z

Schatte5: /* Manual UI Tests */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--'''every other spec file mentioned above crashes'''.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

=== Code and Documentation Goals ===

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:
* data flow
* functions
* code comments

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|345px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
[[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]<br>
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts.

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

== Implementation ==

The following is a code snippet of the new view only, the grading history view. Other changes can be seen from the Pull Request linked at the end.

*/app/views/grading_histories/index.html.erb
<pre>
<% record = @grading_histories[0]
if record == nil
receiver = ""
assignment = ""
else
if record.grading_type == "Submission"
receiver = "of " + Team.where(id: record.grade_receiver_id).pluck(:name).first
assignment = "for the submission " + Assignment.where(id: record.assignment_id).pluck(:name).first
else
receiver = "of " + User.where(id: record.grade_receiver_id).pluck(:fullname).first
assignment = "for review in " + Assignment.where(id: record.assignment_id).pluck(:name).first
end

end
%>
<h1 class="center">Grade History <%= receiver %> <%= assignment %></h1>

<table style="border-collapse:collapse; table-layout:fixed; width:1500px;">
<thead>
<tr>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Instructor</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Grade</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Comment</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Graded At</th>
</tr>


<tbody>
<% @grading_histories.each do |record| %>
<tr>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= User.where(id: record.instructor_id).pluck(:fullname).first %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.grade %></td>
<td style="padding:10px; border:solid 1.5px black; width:60px; word-wrap:break-word;"><%= record.comment %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.created_at %></td>
</tr>
<% end %>
</tbody>
</table>
</pre>

*Screenshot of the Grading History Table

[[File:Submission_Grading_History_Table.jpeg|1000px]]

The student ID and the Assignment ID have been moved to the header in accordance with the DRY principle. The redundant fields present in the table have also been removed.
We have created a factory for testing grading histories controller and included tests for grading_histories_controller, grades_controller and review_mapping_controller.

== Testing ==
=== Video Demonstration ===

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]<br>
[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Assignments can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''

*Factory
<pre>
#Used for Grading Histories Controller Spec
factory :grading_history, class: GradingHistory do
id 1
instructor_id 6
assignment_id 1
grading_type 'Submission'
grade_receiver_id 1
grade 100
comment 'Good work!'
end
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>

*Grading Histories
<pre>
Scenario: Grading History creation
Given: A team exists for a particular assignment and has a submission
When: An instructor assigns a grade for that submission
Then: The grading history entry is created
</pre>

*Review Mapping
<pre>
Scenario: Save Reviewer Grade and Comment
Given: A student has given a review for a submission
When: An instructor assigns a grade for the review
Then: The assigned grade and the accompanying comment are saved
</pre>

*Grade
<pre>
Scenario: Save Grade and Comment for Submission
Given: A team has made a submission for an assignment
When: An instructor assigns a grade for the submission
Then: The assigned grade and the accompanying comment are saved
</pre>

=== Manual UI Tests ===
*Student ID in header
<pre>
Scenario: Student ID/Team ID (Receiver_ID) in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Receiver ID appears in the header, not in any table columns
</pre>

*Assignment Name in header
<pre>
Scenario: Assignment Name in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment Name appears in the header, not in any table columns
</pre>

*Color change after Grade is assigned to a submission
<pre>
Scenario: Team_ID Color changes from blue to brown when grade is assigned
Logged in as an Instructor of Course/Admin or TA assigned to Course
On Assignment page, click on Etc->View Submissions
All submissions for assignment are shown
Team name is blue, and grade is not assigned
Click on "Assign Grade" under team name
Instructor/TA assigns grade, save successfully
Back to submissions list, team name is now brown
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* '''TA Grade Editing Problems:''' The current version of beta branch has an issue wherein grades that have already been assigned cannot be changed by any TAs. This issue has been brought to the attention of the Expertiza team.

=== Conclusion ===
* '''Functionality:''' The functionality regarding grading changes/trails has been demonstrably completed; Instructors can change grades for their assignment submissions, and the changes are reflected in the enw created Grading History Table.
* '''Appearance:''' The requested layout of the Grading History table, with the student/teamID & the assignmentID at the header, along with the instructorID in it's own column on the left, is done, and is shown in the screenshots in this document.
* '''Testing:''' Tests have been added into Expertiza that ensure that the positive flows work as intended. More tests need to be added for completeness, as stated below.
* '''Future Work:''' More testing is required - with over 650 changes, more work is needed to add tests that ensure comprehensive coverage.

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]

[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

[https://github.com/expertiza/expertiza/pull/2399 Pull Request]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-28T19:53:24Z

Schatte5: /* Manual UI Tests */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--'''every other spec file mentioned above crashes'''.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

=== Code and Documentation Goals ===

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:
* data flow
* functions
* code comments

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|345px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
[[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]<br>
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts.

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

== Implementation ==

The following is a code snippet of the new view only, the grading history view. Other changes can be seen from the Pull Request linked at the end.

*/app/views/grading_histories/index.html.erb
<pre>
<% record = @grading_histories[0]
if record == nil
receiver = ""
assignment = ""
else
if record.grading_type == "Submission"
receiver = "of " + Team.where(id: record.grade_receiver_id).pluck(:name).first
assignment = "for the submission " + Assignment.where(id: record.assignment_id).pluck(:name).first
else
receiver = "of " + User.where(id: record.grade_receiver_id).pluck(:fullname).first
assignment = "for review in " + Assignment.where(id: record.assignment_id).pluck(:name).first
end

end
%>
<h1 class="center">Grade History <%= receiver %> <%= assignment %></h1>

<table style="border-collapse:collapse; table-layout:fixed; width:1500px;">
<thead>
<tr>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Instructor</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Grade</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Comment</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Graded At</th>
</tr>


<tbody>
<% @grading_histories.each do |record| %>
<tr>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= User.where(id: record.instructor_id).pluck(:fullname).first %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.grade %></td>
<td style="padding:10px; border:solid 1.5px black; width:60px; word-wrap:break-word;"><%= record.comment %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.created_at %></td>
</tr>
<% end %>
</tbody>
</table>
</pre>

*Screenshot of the Grading History Table

[[File:Submission_Grading_History_Table.jpeg|1000px]]

The student ID and the Assignment ID have been moved to the header in accordance with the DRY principle. The redundant fields present in the table have also been removed.
We have created a factory for testing grading histories controller and included tests for grading_histories_controller, grades_controller and review_mapping_controller.

== Testing ==
=== Video Demonstration ===

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]<br>
[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Assignments can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''

*Factory
<pre>
#Used for Grading Histories Controller Spec
factory :grading_history, class: GradingHistory do
id 1
instructor_id 6
assignment_id 1
grading_type 'Submission'
grade_receiver_id 1
grade 100
comment 'Good work!'
end
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>

*Grading Histories
<pre>
Scenario: Grading History creation
Given: A team exists for a particular assignment and has a submission
When: An instructor assigns a grade for that submission
Then: The grading history entry is created
</pre>

*Review Mapping
<pre>
Scenario: Save Reviewer Grade and Comment
Given: A student has given a review for a submission
When: An instructor assigns a grade for the review
Then: The assigned grade and the accompanying comment are saved
</pre>

*Grade
<pre>
Scenario: Save Grade and Comment for Submission
Given: A team has made a submission for an assignment
When: An instructor assigns a grade for the submission
Then: The assigned grade and the accompanying comment are saved
</pre>

=== Manual UI Tests ===
*Student ID in header
<pre>
Scenario: Student ID/Team ID (Receiver_ID) in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Receiver ID appears in the header, not in any table columns
</pre>

*Assignment Name in header
<pre>
Scenario: Assignment Name in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment Name appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* '''TA Grade Editing Problems:''' The current version of beta branch has an issue wherein grades that have already been assigned cannot be changed by any TAs. This issue has been brought to the attention of the Expertiza team.

=== Conclusion ===
* '''Functionality:''' The functionality regarding grading changes/trails has been demonstrably completed; Instructors can change grades for their assignment submissions, and the changes are reflected in the enw created Grading History Table.
* '''Appearance:''' The requested layout of the Grading History table, with the student/teamID & the assignmentID at the header, along with the instructorID in it's own column on the left, is done, and is shown in the screenshots in this document.
* '''Testing:''' Tests have been added into Expertiza that ensure that the positive flows work as intended. More tests need to be added for completeness, as stated below.
* '''Future Work:''' More testing is required - with over 650 changes, more work is needed to add tests that ensure comprehensive coverage.

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]

[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

[https://github.com/expertiza/expertiza/pull/2399 Pull Request]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-28T19:52:58Z

Schatte5: /* Manual UI Tests */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--'''every other spec file mentioned above crashes'''.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

=== Code and Documentation Goals ===

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:
* data flow
* functions
* code comments

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|345px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
[[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]<br>
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts.

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

== Implementation ==

The following is a code snippet of the new view only, the grading history view. Other changes can be seen from the Pull Request linked at the end.

*/app/views/grading_histories/index.html.erb
<pre>
<% record = @grading_histories[0]
if record == nil
receiver = ""
assignment = ""
else
if record.grading_type == "Submission"
receiver = "of " + Team.where(id: record.grade_receiver_id).pluck(:name).first
assignment = "for the submission " + Assignment.where(id: record.assignment_id).pluck(:name).first
else
receiver = "of " + User.where(id: record.grade_receiver_id).pluck(:fullname).first
assignment = "for review in " + Assignment.where(id: record.assignment_id).pluck(:name).first
end

end
%>
<h1 class="center">Grade History <%= receiver %> <%= assignment %></h1>

<table style="border-collapse:collapse; table-layout:fixed; width:1500px;">
<thead>
<tr>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Instructor</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Grade</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Comment</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Graded At</th>
</tr>


<tbody>
<% @grading_histories.each do |record| %>
<tr>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= User.where(id: record.instructor_id).pluck(:fullname).first %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.grade %></td>
<td style="padding:10px; border:solid 1.5px black; width:60px; word-wrap:break-word;"><%= record.comment %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.created_at %></td>
</tr>
<% end %>
</tbody>
</table>
</pre>

*Screenshot of the Grading History Table

[[File:Submission_Grading_History_Table.jpeg|1000px]]

The student ID and the Assignment ID have been moved to the header in accordance with the DRY principle. The redundant fields present in the table have also been removed.
We have created a factory for testing grading histories controller and included tests for grading_histories_controller, grades_controller and review_mapping_controller.

== Testing ==
=== Video Demonstration ===

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]<br>
[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Assignments can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''

*Factory
<pre>
#Used for Grading Histories Controller Spec
factory :grading_history, class: GradingHistory do
id 1
instructor_id 6
assignment_id 1
grading_type 'Submission'
grade_receiver_id 1
grade 100
comment 'Good work!'
end
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>

*Grading Histories
<pre>
Scenario: Grading History creation
Given: A team exists for a particular assignment and has a submission
When: An instructor assigns a grade for that submission
Then: The grading history entry is created
</pre>

*Review Mapping
<pre>
Scenario: Save Reviewer Grade and Comment
Given: A student has given a review for a submission
When: An instructor assigns a grade for the review
Then: The assigned grade and the accompanying comment are saved
</pre>

*Grade
<pre>
Scenario: Save Grade and Comment for Submission
Given: A team has made a submission for an assignment
When: An instructor assigns a grade for the submission
Then: The assigned grade and the accompanying comment are saved
</pre>

=== Manual UI Tests ===
*Student ID in header
<pre>
Scenario: Student ID/Team ID (Receiver_ID) in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Receiver ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* '''TA Grade Editing Problems:''' The current version of beta branch has an issue wherein grades that have already been assigned cannot be changed by any TAs. This issue has been brought to the attention of the Expertiza team.

=== Conclusion ===
* '''Functionality:''' The functionality regarding grading changes/trails has been demonstrably completed; Instructors can change grades for their assignment submissions, and the changes are reflected in the enw created Grading History Table.
* '''Appearance:''' The requested layout of the Grading History table, with the student/teamID & the assignmentID at the header, along with the instructorID in it's own column on the left, is done, and is shown in the screenshots in this document.
* '''Testing:''' Tests have been added into Expertiza that ensure that the positive flows work as intended. More tests need to be added for completeness, as stated below.
* '''Future Work:''' More testing is required - with over 650 changes, more work is needed to add tests that ensure comprehensive coverage.

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]

[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

[https://github.com/expertiza/expertiza/pull/2399 Pull Request]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-28T19:52:28Z

Schatte5: /* Manual UI Tests */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--'''every other spec file mentioned above crashes'''.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

=== Code and Documentation Goals ===

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:
* data flow
* functions
* code comments

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|345px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
[[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]<br>
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts.

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

== Implementation ==

The following is a code snippet of the new view only, the grading history view. Other changes can be seen from the Pull Request linked at the end.

*/app/views/grading_histories/index.html.erb
<pre>
<% record = @grading_histories[0]
if record == nil
receiver = ""
assignment = ""
else
if record.grading_type == "Submission"
receiver = "of " + Team.where(id: record.grade_receiver_id).pluck(:name).first
assignment = "for the submission " + Assignment.where(id: record.assignment_id).pluck(:name).first
else
receiver = "of " + User.where(id: record.grade_receiver_id).pluck(:fullname).first
assignment = "for review in " + Assignment.where(id: record.assignment_id).pluck(:name).first
end

end
%>
<h1 class="center">Grade History <%= receiver %> <%= assignment %></h1>

<table style="border-collapse:collapse; table-layout:fixed; width:1500px;">
<thead>
<tr>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Instructor</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Grade</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Comment</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Graded At</th>
</tr>


<tbody>
<% @grading_histories.each do |record| %>
<tr>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= User.where(id: record.instructor_id).pluck(:fullname).first %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.grade %></td>
<td style="padding:10px; border:solid 1.5px black; width:60px; word-wrap:break-word;"><%= record.comment %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.created_at %></td>
</tr>
<% end %>
</tbody>
</table>
</pre>

*Screenshot of the Grading History Table

[[File:Submission_Grading_History_Table.jpeg|1000px]]

The student ID and the Assignment ID have been moved to the header in accordance with the DRY principle. The redundant fields present in the table have also been removed.
We have created a factory for testing grading histories controller and included tests for grading_histories_controller, grades_controller and review_mapping_controller.

== Testing ==
=== Video Demonstration ===

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]<br>
[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Assignments can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''

*Factory
<pre>
#Used for Grading Histories Controller Spec
factory :grading_history, class: GradingHistory do
id 1
instructor_id 6
assignment_id 1
grading_type 'Submission'
grade_receiver_id 1
grade 100
comment 'Good work!'
end
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>

*Grading Histories
<pre>
Scenario: Grading History creation
Given: A team exists for a particular assignment and has a submission
When: An instructor assigns a grade for that submission
Then: The grading history entry is created
</pre>

*Review Mapping
<pre>
Scenario: Save Reviewer Grade and Comment
Given: A student has given a review for a submission
When: An instructor assigns a grade for the review
Then: The assigned grade and the accompanying comment are saved
</pre>

*Grade
<pre>
Scenario: Save Grade and Comment for Submission
Given: A team has made a submission for an assignment
When: An instructor assigns a grade for the submission
Then: The assigned grade and the accompanying comment are saved
</pre>

=== Manual UI Tests ===
*Student ID in header
<pre>
Scenario: Student ID/Team ID (Receiver_ID) in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* '''TA Grade Editing Problems:''' The current version of beta branch has an issue wherein grades that have already been assigned cannot be changed by any TAs. This issue has been brought to the attention of the Expertiza team.

=== Conclusion ===
* '''Functionality:''' The functionality regarding grading changes/trails has been demonstrably completed; Instructors can change grades for their assignment submissions, and the changes are reflected in the enw created Grading History Table.
* '''Appearance:''' The requested layout of the Grading History table, with the student/teamID & the assignmentID at the header, along with the instructorID in it's own column on the left, is done, and is shown in the screenshots in this document.
* '''Testing:''' Tests have been added into Expertiza that ensure that the positive flows work as intended. More tests need to be added for completeness, as stated below.
* '''Future Work:''' More testing is required - with over 650 changes, more work is needed to add tests that ensure comprehensive coverage.

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]

[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

[https://github.com/expertiza/expertiza/pull/2399 Pull Request]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-28T19:51:47Z

Schatte5: /* Manual UI Tests */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--'''every other spec file mentioned above crashes'''.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

=== Code and Documentation Goals ===

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:
* data flow
* functions
* code comments

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|345px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
[[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]<br>
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts.

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

== Implementation ==

The following is a code snippet of the new view only, the grading history view. Other changes can be seen from the Pull Request linked at the end.

*/app/views/grading_histories/index.html.erb
<pre>
<% record = @grading_histories[0]
if record == nil
receiver = ""
assignment = ""
else
if record.grading_type == "Submission"
receiver = "of " + Team.where(id: record.grade_receiver_id).pluck(:name).first
assignment = "for the submission " + Assignment.where(id: record.assignment_id).pluck(:name).first
else
receiver = "of " + User.where(id: record.grade_receiver_id).pluck(:fullname).first
assignment = "for review in " + Assignment.where(id: record.assignment_id).pluck(:name).first
end

end
%>
<h1 class="center">Grade History <%= receiver %> <%= assignment %></h1>

<table style="border-collapse:collapse; table-layout:fixed; width:1500px;">
<thead>
<tr>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Instructor</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Grade</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Comment</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Graded At</th>
</tr>


<tbody>
<% @grading_histories.each do |record| %>
<tr>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= User.where(id: record.instructor_id).pluck(:fullname).first %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.grade %></td>
<td style="padding:10px; border:solid 1.5px black; width:60px; word-wrap:break-word;"><%= record.comment %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.created_at %></td>
</tr>
<% end %>
</tbody>
</table>
</pre>

*Screenshot of the Grading History Table

[[File:Submission_Grading_History_Table.jpeg|1000px]]

The student ID and the Assignment ID have been moved to the header in accordance with the DRY principle. The redundant fields present in the table have also been removed.
We have created a factory for testing grading histories controller and included tests for grading_histories_controller, grades_controller and review_mapping_controller.

== Testing ==
=== Video Demonstration ===

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]<br>
[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Assignments can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''

*Factory
<pre>
#Used for Grading Histories Controller Spec
factory :grading_history, class: GradingHistory do
id 1
instructor_id 6
assignment_id 1
grading_type 'Submission'
grade_receiver_id 1
grade 100
comment 'Good work!'
end
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>

*Grading Histories
<pre>
Scenario: Grading History creation
Given: A team exists for a particular assignment and has a submission
When: An instructor assigns a grade for that submission
Then: The grading history entry is created
</pre>

*Review Mapping
<pre>
Scenario: Save Reviewer Grade and Comment
Given: A student has given a review for a submission
When: An instructor assigns a grade for the review
Then: The assigned grade and the accompanying comment are saved
</pre>

*Grade
<pre>
Scenario: Save Grade and Comment for Submission
Given: A team has made a submission for an assignment
When: An instructor assigns a grade for the submission
Then: The assigned grade and the accompanying comment are saved
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID/Team ID (Receiver_ID) in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* '''TA Grade Editing Problems:''' The current version of beta branch has an issue wherein grades that have already been assigned cannot be changed by any TAs. This issue has been brought to the attention of the Expertiza team.

=== Conclusion ===
* '''Functionality:''' The functionality regarding grading changes/trails has been demonstrably completed; Instructors can change grades for their assignment submissions, and the changes are reflected in the enw created Grading History Table.
* '''Appearance:''' The requested layout of the Grading History table, with the student/teamID & the assignmentID at the header, along with the instructorID in it's own column on the left, is done, and is shown in the screenshots in this document.
* '''Testing:''' Tests have been added into Expertiza that ensure that the positive flows work as intended. More tests need to be added for completeness, as stated below.
* '''Future Work:''' More testing is required - with over 650 changes, more work is needed to add tests that ensure comprehensive coverage.

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]

[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

[https://github.com/expertiza/expertiza/pull/2399 Pull Request]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-28T19:43:11Z

Schatte5: /* Planned and Completed Work */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--'''every other spec file mentioned above crashes'''.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

=== Code and Documentation Goals ===

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:
* data flow
* functions
* code comments

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|345px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
[[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]<br>
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts.

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

== Implementation ==

The following is a code snippet of the new view only, the grading history view. Other changes can be seen from the Pull Request linked at the end.

*/app/views/grading_histories/index.html.erb
<pre>
<% record = @grading_histories[0]
if record == nil
receiver = ""
assignment = ""
else
if record.grading_type == "Submission"
receiver = "of " + Team.where(id: record.grade_receiver_id).pluck(:name).first
assignment = "for the submission " + Assignment.where(id: record.assignment_id).pluck(:name).first
else
receiver = "of " + User.where(id: record.grade_receiver_id).pluck(:fullname).first
assignment = "for review in " + Assignment.where(id: record.assignment_id).pluck(:name).first
end

end
%>
<h1 class="center">Grade History <%= receiver %> <%= assignment %></h1>

<table style="border-collapse:collapse; table-layout:fixed; width:1500px;">
<thead>
<tr>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Instructor</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Grade</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Comment</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Graded At</th>
</tr>


<tbody>
<% @grading_histories.each do |record| %>
<tr>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= User.where(id: record.instructor_id).pluck(:fullname).first %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.grade %></td>
<td style="padding:10px; border:solid 1.5px black; width:60px; word-wrap:break-word;"><%= record.comment %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.created_at %></td>
</tr>
<% end %>
</tbody>
</table>
</pre>

*Screenshot of the Grading History Table

[[File:Submission_Grading_History_Table.jpeg|1000px]]

The student ID and the Assignment ID have been moved to the header in accordance with the DRY principle. The redundant fields present in the table have also been removed.
We have created a factory for testing grading histories controller and included tests for grading_histories_controller, grades_controller and review_mapping_controller.

== Testing ==
=== Video Demonstration ===

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]<br>
[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Assignments can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''

*Factory
<pre>
#Used for Grading Histories Controller Spec
factory :grading_history, class: GradingHistory do
id 1
instructor_id 6
assignment_id 1
grading_type 'Submission'
grade_receiver_id 1
grade 100
comment 'Good work!'
end
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>

*Grading Histories
<pre>
Scenario: Grading History creation
Given: A team exists for a particular assignment and has a submission
When: An instructor assigns a grade for that submission
Then: The grading history entry is created
</pre>

*Review Mapping
<pre>
Scenario: Save Reviewer Grade and Comment
Given: A student has given a review for a submission
When: An instructor assigns a grade for the review
Then: The assigned grade and the accompanying comment are saved
</pre>

*Grade
<pre>
Scenario: Save Grade and Comment for Submission
Given: A team has made a submission for an assignment
When: An instructor assigns a grade for the submission
Then: The assigned grade and the accompanying comment are saved
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* '''TA Grade Editing Problems:''' The current version of beta branch has an issue wherein grades that have already been assigned cannot be changed by any TAs. This issue has been brought to the attention of the Expertiza team.

=== Conclusion ===
* '''Functionality:''' The functionality regarding grading changes/trails has been demonstrably completed; Instructors can change grades for their assignment submissions, and the changes are reflected in the enw created Grading History Table.
* '''Appearance:''' The requested layout of the Grading History table, with the student/teamID & the assignmentID at the header, along with the instructorID in it's own column on the left, is done, and is shown in the screenshots in this document.
* '''Testing:''' Tests have been added into Expertiza that ensure that the positive flows work as intended. More tests need to be added for completeness, as stated below.
* '''Future Work:''' More testing is required - with over 650 changes, more work is needed to add tests that ensure comprehensive coverage.

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]

[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

[https://github.com/expertiza/expertiza/pull/2399 Pull Request]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-28T19:42:56Z

Schatte5: /* Changes to the Grading History Table */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--'''every other spec file mentioned above crashes'''.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

=== Code and Documentation Goals ===

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:
* data flow
* functions
* code comments

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|345px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
[[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts.

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

== Implementation ==

The following is a code snippet of the new view only, the grading history view. Other changes can be seen from the Pull Request linked at the end.

*/app/views/grading_histories/index.html.erb
<pre>
<% record = @grading_histories[0]
if record == nil
receiver = ""
assignment = ""
else
if record.grading_type == "Submission"
receiver = "of " + Team.where(id: record.grade_receiver_id).pluck(:name).first
assignment = "for the submission " + Assignment.where(id: record.assignment_id).pluck(:name).first
else
receiver = "of " + User.where(id: record.grade_receiver_id).pluck(:fullname).first
assignment = "for review in " + Assignment.where(id: record.assignment_id).pluck(:name).first
end

end
%>
<h1 class="center">Grade History <%= receiver %> <%= assignment %></h1>

<table style="border-collapse:collapse; table-layout:fixed; width:1500px;">
<thead>
<tr>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Instructor</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Grade</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Comment</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Graded At</th>
</tr>


<tbody>
<% @grading_histories.each do |record| %>
<tr>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= User.where(id: record.instructor_id).pluck(:fullname).first %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.grade %></td>
<td style="padding:10px; border:solid 1.5px black; width:60px; word-wrap:break-word;"><%= record.comment %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.created_at %></td>
</tr>
<% end %>
</tbody>
</table>
</pre>

*Screenshot of the Grading History Table

[[File:Submission_Grading_History_Table.jpeg|1000px]]

The student ID and the Assignment ID have been moved to the header in accordance with the DRY principle. The redundant fields present in the table have also been removed.
We have created a factory for testing grading histories controller and included tests for grading_histories_controller, grades_controller and review_mapping_controller.

== Testing ==
=== Video Demonstration ===

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]<br>
[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Assignments can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''

*Factory
<pre>
#Used for Grading Histories Controller Spec
factory :grading_history, class: GradingHistory do
id 1
instructor_id 6
assignment_id 1
grading_type 'Submission'
grade_receiver_id 1
grade 100
comment 'Good work!'
end
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>

*Grading Histories
<pre>
Scenario: Grading History creation
Given: A team exists for a particular assignment and has a submission
When: An instructor assigns a grade for that submission
Then: The grading history entry is created
</pre>

*Review Mapping
<pre>
Scenario: Save Reviewer Grade and Comment
Given: A student has given a review for a submission
When: An instructor assigns a grade for the review
Then: The assigned grade and the accompanying comment are saved
</pre>

*Grade
<pre>
Scenario: Save Grade and Comment for Submission
Given: A team has made a submission for an assignment
When: An instructor assigns a grade for the submission
Then: The assigned grade and the accompanying comment are saved
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* '''TA Grade Editing Problems:''' The current version of beta branch has an issue wherein grades that have already been assigned cannot be changed by any TAs. This issue has been brought to the attention of the Expertiza team.

=== Conclusion ===
* '''Functionality:''' The functionality regarding grading changes/trails has been demonstrably completed; Instructors can change grades for their assignment submissions, and the changes are reflected in the enw created Grading History Table.
* '''Appearance:''' The requested layout of the Grading History table, with the student/teamID & the assignmentID at the header, along with the instructorID in it's own column on the left, is done, and is shown in the screenshots in this document.
* '''Testing:''' Tests have been added into Expertiza that ensure that the positive flows work as intended. More tests need to be added for completeness, as stated below.
* '''Future Work:''' More testing is required - with over 650 changes, more work is needed to add tests that ensure comprehensive coverage.

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]

[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

[https://github.com/expertiza/expertiza/pull/2399 Pull Request]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-26T03:59:50Z

Schatte5: /* Conclusion */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--'''every other spec file mentioned above crashes'''.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

=== Code and Documentation Goals ===

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:
* data flow
* functions
* code comments

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|345px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts. [[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

== Implementation ==

The following is a code snippet of the new view only, the grading history view. Other changes can be seen from the Pull Request linked at the end.

*/app/views/grading_histories/index.html.erb
<pre>
<% record = @grading_histories[0]
if record == nil
receiver = ""
assignment = ""
else
if record.grading_type == "Submission"
receiver = "of " + Team.where(id: record.grade_receiver_id).pluck(:name).first
assignment = "for the submission " + Assignment.where(id: record.assignment_id).pluck(:name).first
else
receiver = "of " + User.where(id: record.grade_receiver_id).pluck(:fullname).first
assignment = "for review in " + Assignment.where(id: record.assignment_id).pluck(:name).first
end

end
%>
<h1 class="center">Grade History <%= receiver %> <%= assignment %></h1>

<table style="border-collapse:collapse; table-layout:fixed; width:1500px;">
<thead>
<tr>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Instructor</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Grade</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Comment</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Graded At</th>
</tr>


<tbody>
<% @grading_histories.each do |record| %>
<tr>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= User.where(id: record.instructor_id).pluck(:fullname).first %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.grade %></td>
<td style="padding:10px; border:solid 1.5px black; width:60px; word-wrap:break-word;"><%= record.comment %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.created_at %></td>
</tr>
<% end %>
</tbody>
</table>
</pre>

*Screenshot of the Grading History Table

[[File:Submission_Grading_History_Table.jpeg|1000px]]

The student ID and the Assignment ID have been moved to the header in accordance with the DRY principle. The redundant fields present in the table have also been removed.
We have created a factory for testing grading histories controller and included tests for grading_histories_controller, grades_controller and review_mapping_controller.

== Testing ==
=== Video Demonstration ===

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]<br>
[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Assignments can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''

*Factory
<pre>
#Used for Grading Histories Controller Spec
factory :grading_history, class: GradingHistory do
id 1
instructor_id 6
assignment_id 1
grading_type 'Submission'
grade_receiver_id 1
grade 100
comment 'Good work!'
end
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>

*Grading Histories
<pre>
Scenario: Grading History creation
Given: A team exists for a particular assignment and has a submission
When: An instructor assigns a grade for that submission
Then: The grading history entry is created
</pre>

*Review Mapping
<pre>
Scenario: Save Reviewer Grade and Comment
Given: A student has given a review for a submission
When: An instructor assigns a grade for the review
Then: The assigned grade and the accompanying comment are saved
</pre>

*Grade
<pre>
Scenario: Save Grade and Comment for Submission
Given: A team has made a submission for an assignment
When: An instructor assigns a grade for the submission
Then: The assigned grade and the accompanying comment are saved
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* '''TA Grade Editing Problems:''' The current version of beta branch has an issue wherein grades that have already been assigned cannot be changed by any TAs. This issue has been brought to the attention of the Expertiza team.

=== Conclusion ===
* '''Functionality:''' The functionality regarding grading changes/trails has been demonstrably completed; Instructors can change grades for their assignment submissions, and the changes are reflected in the enw created Grading History Table.
* '''Appearance:''' The requested layout of the Grading History table, with the student/teamID & the assignmentID at the header, along with the instructorID in it's own column on the left, is done, and is shown in the screenshots in this document.
* '''Testing:''' Tests have been added into Expertiza that ensure that the positive flows work as intended. More tests need to be added for completeness, as stated below.
* '''Future Work:''' More testing is required - with over 650 changes, more work is needed to add tests that ensure comprehensive coverage.

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]

[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

[https://github.com/expertiza/expertiza/pull/2399 Pull Request]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-26T03:59:35Z

Schatte5: /* Comprehensive Testing and Scope */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--'''every other spec file mentioned above crashes'''.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

=== Code and Documentation Goals ===

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:
* data flow
* functions
* code comments

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|345px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts. [[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

== Implementation ==

The following is a code snippet of the new view only, the grading history view. Other changes can be seen from the Pull Request linked at the end.

*/app/views/grading_histories/index.html.erb
<pre>
<% record = @grading_histories[0]
if record == nil
receiver = ""
assignment = ""
else
if record.grading_type == "Submission"
receiver = "of " + Team.where(id: record.grade_receiver_id).pluck(:name).first
assignment = "for the submission " + Assignment.where(id: record.assignment_id).pluck(:name).first
else
receiver = "of " + User.where(id: record.grade_receiver_id).pluck(:fullname).first
assignment = "for review in " + Assignment.where(id: record.assignment_id).pluck(:name).first
end

end
%>
<h1 class="center">Grade History <%= receiver %> <%= assignment %></h1>

<table style="border-collapse:collapse; table-layout:fixed; width:1500px;">
<thead>
<tr>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Instructor</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Grade</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Comment</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Graded At</th>
</tr>


<tbody>
<% @grading_histories.each do |record| %>
<tr>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= User.where(id: record.instructor_id).pluck(:fullname).first %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.grade %></td>
<td style="padding:10px; border:solid 1.5px black; width:60px; word-wrap:break-word;"><%= record.comment %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.created_at %></td>
</tr>
<% end %>
</tbody>
</table>
</pre>

*Screenshot of the Grading History Table

[[File:Submission_Grading_History_Table.jpeg|1000px]]

The student ID and the Assignment ID have been moved to the header in accordance with the DRY principle. The redundant fields present in the table have also been removed.
We have created a factory for testing grading histories controller and included tests for grading_histories_controller, grades_controller and review_mapping_controller.

== Testing ==
=== Video Demonstration ===

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]<br>
[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Assignments can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''

*Factory
<pre>
#Used for Grading Histories Controller Spec
factory :grading_history, class: GradingHistory do
id 1
instructor_id 6
assignment_id 1
grading_type 'Submission'
grade_receiver_id 1
grade 100
comment 'Good work!'
end
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>

*Grading Histories
<pre>
Scenario: Grading History creation
Given: A team exists for a particular assignment and has a submission
When: An instructor assigns a grade for that submission
Then: The grading history entry is created
</pre>

*Review Mapping
<pre>
Scenario: Save Reviewer Grade and Comment
Given: A student has given a review for a submission
When: An instructor assigns a grade for the review
Then: The assigned grade and the accompanying comment are saved
</pre>

*Grade
<pre>
Scenario: Save Grade and Comment for Submission
Given: A team has made a submission for an assignment
When: An instructor assigns a grade for the submission
Then: The assigned grade and the accompanying comment are saved
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* '''TA Grade Editing Problems:''' The current version of beta branch has an issue wherein grades that have already been assigned cannot be changed by any TAs. This issue has been brought to the attention of the Expertiza team.

=== Conclusion ===
* '''Functionality''' The functionality regarding grading changes/trails has been demonstrably completed; Instructors can change grades for their assignment submissions, and the changes are reflected in the enw created Grading History Table.
* '''Appearance''' The requested layout of the Grading History table, with the student/teamID & the assignmentID at the header, along with the instructorID in it's own column on the left, is done, and is shown in the screenshots in this document.
* '''Testing''' Tests have been added into Expertiza that ensure that the positive flows work as intended. More tests need to be added for completeness, as stated below.
* '''Future Work''' More testing is required - with over 650 changes, more work is needed to add tests that ensure comprehensive coverage.

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]

[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

[https://github.com/expertiza/expertiza/pull/2399 Pull Request]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-26T03:58:49Z

Schatte5: /* Implementation */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--'''every other spec file mentioned above crashes'''.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

=== Code and Documentation Goals ===

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:
* data flow
* functions
* code comments

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|345px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts. [[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

== Implementation ==

The following is a code snippet of the new view only, the grading history view. Other changes can be seen from the Pull Request linked at the end.

*/app/views/grading_histories/index.html.erb
<pre>
<% record = @grading_histories[0]
if record == nil
receiver = ""
assignment = ""
else
if record.grading_type == "Submission"
receiver = "of " + Team.where(id: record.grade_receiver_id).pluck(:name).first
assignment = "for the submission " + Assignment.where(id: record.assignment_id).pluck(:name).first
else
receiver = "of " + User.where(id: record.grade_receiver_id).pluck(:fullname).first
assignment = "for review in " + Assignment.where(id: record.assignment_id).pluck(:name).first
end

end
%>
<h1 class="center">Grade History <%= receiver %> <%= assignment %></h1>

<table style="border-collapse:collapse; table-layout:fixed; width:1500px;">
<thead>
<tr>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Instructor</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Grade</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Comment</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Graded At</th>
</tr>


<tbody>
<% @grading_histories.each do |record| %>
<tr>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= User.where(id: record.instructor_id).pluck(:fullname).first %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.grade %></td>
<td style="padding:10px; border:solid 1.5px black; width:60px; word-wrap:break-word;"><%= record.comment %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.created_at %></td>
</tr>
<% end %>
</tbody>
</table>
</pre>

*Screenshot of the Grading History Table

[[File:Submission_Grading_History_Table.jpeg|1000px]]

== Testing ==
=== Video Demonstration ===

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]<br>
[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Assignments can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''

*Factory
<pre>
#Used for Grading Histories Controller Spec
factory :grading_history, class: GradingHistory do
id 1
instructor_id 6
assignment_id 1
grading_type 'Submission'
grade_receiver_id 1
grade 100
comment 'Good work!'
end
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>

*Grading Histories
<pre>
Scenario: Grading History creation
Given: A team exists for a particular assignment and has a submission
When: An instructor assigns a grade for that submission
Then: The grading history entry is created
</pre>

*Review Mapping
<pre>
Scenario: Save Reviewer Grade and Comment
Given: A student has given a review for a submission
When: An instructor assigns a grade for the review
Then: The assigned grade and the accompanying comment are saved
</pre>

*Grade
<pre>
Scenario: Save Grade and Comment for Submission
Given: A team has made a submission for an assignment
When: An instructor assigns a grade for the submission
Then: The assigned grade and the accompanying comment are saved
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* '''TA Grade Editing Problems''' The current version of beta branch has an issue wherein grades that have already been assigned cannot be changed by any TAs. This issue has been brought to the attention of the Expertiza team.

=== Conclusion ===
* '''Functionality''' The functionality regarding grading changes/trails has been demonstrably completed; Instructors can change grades for their assignment submissions, and the changes are reflected in the enw created Grading History Table.
* '''Appearance''' The requested layout of the Grading History table, with the student/teamID & the assignmentID at the header, along with the instructorID in it's own column on the left, is done, and is shown in the screenshots in this document.
* '''Testing''' Tests have been added into Expertiza that ensure that the positive flows work as intended. More tests need to be added for completeness, as stated below.
* '''Future Work''' More testing is required - with over 650 changes, more work is needed to add tests that ensure comprehensive coverage.

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]

[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

[https://github.com/expertiza/expertiza/pull/2399 Pull Request]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-26T03:57:09Z

Schatte5: /* Conclusions and Future Work */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--'''every other spec file mentioned above crashes'''.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

=== Code and Documentation Goals ===

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:
* data flow
* functions
* code comments

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|345px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts. [[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

== Implementation ==

*/app/views/grading_histories/index.html.erb
<pre>
<% record = @grading_histories[0]
if record == nil
receiver = ""
assignment = ""
else
if record.grading_type == "Submission"
receiver = "of " + Team.where(id: record.grade_receiver_id).pluck(:name).first
assignment = "for the submission " + Assignment.where(id: record.assignment_id).pluck(:name).first
else
receiver = "of " + User.where(id: record.grade_receiver_id).pluck(:fullname).first
assignment = "for review in " + Assignment.where(id: record.assignment_id).pluck(:name).first
end

end
%>
<h1 class="center">Grade History <%= receiver %> <%= assignment %></h1>

<table style="border-collapse:collapse; table-layout:fixed; width:1500px;">
<thead>
<tr>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Instructor</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Grade</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Comment</th>
<th style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;">Graded At</th>
</tr>


<tbody>
<% @grading_histories.each do |record| %>
<tr>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= User.where(id: record.instructor_id).pluck(:fullname).first %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.grade %></td>
<td style="padding:10px; border:solid 1.5px black; width:60px; word-wrap:break-word;"><%= record.comment %></td>
<td style="padding:10px; border:solid 1.5px black; width:50px; word-wrap:break-word;"><%= record.created_at %></td>
</tr>
<% end %>
</tbody>
</table>
</pre>

*Screenshot of the Grading History Table

[[File:Submission_Grading_History_Table.jpeg|1000px]]

== Testing ==
=== Video Demonstration ===

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]<br>
[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Assignments can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''

*Factory
<pre>
#Used for Grading Histories Controller Spec
factory :grading_history, class: GradingHistory do
id 1
instructor_id 6
assignment_id 1
grading_type 'Submission'
grade_receiver_id 1
grade 100
comment 'Good work!'
end
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>

*Grading Histories
<pre>
Scenario: Grading History creation
Given: A team exists for a particular assignment and has a submission
When: An instructor assigns a grade for that submission
Then: The grading history entry is created
</pre>

*Review Mapping
<pre>
Scenario: Save Reviewer Grade and Comment
Given: A student has given a review for a submission
When: An instructor assigns a grade for the review
Then: The assigned grade and the accompanying comment are saved
</pre>

*Grade
<pre>
Scenario: Save Grade and Comment for Submission
Given: A team has made a submission for an assignment
When: An instructor assigns a grade for the submission
Then: The assigned grade and the accompanying comment are saved
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* '''TA Grade Editing Problems''' The current version of beta branch has an issue wherein grades that have already been assigned cannot be changed by any TAs. This issue has been brought to the attention of the Expertiza team.

=== Conclusion ===
* '''Functionality''' The functionality regarding grading changes/trails has been demonstrably completed; Instructors can change grades for their assignment submissions, and the changes are reflected in the enw created Grading History Table.
* '''Appearance''' The requested layout of the Grading History table, with the student/teamID & the assignmentID at the header, along with the instructorID in it's own column on the left, is done, and is shown in the screenshots in this document.
* '''Testing''' Tests have been added into Expertiza that ensure that the positive flows work as intended. More tests need to be added for completeness, as stated below.
* '''Future Work''' More testing is required - with over 650 changes, more work is needed to add tests that ensure comprehensive coverage.

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]

[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

[https://github.com/expertiza/expertiza/pull/2399 Pull Request]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-26T03:43:50Z

Schatte5: /* Issues with Existing Tests */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--'''every other spec file mentioned above crashes'''.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

=== Code and Documentation Goals ===

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:
* data flow
* functions
* code comments

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|345px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts. [[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]<br>
[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Assignments can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''

*Factory
<pre>
#Used for Grading Histories Controller Spec
factory :grading_history, class: GradingHistory do
id 1
instructor_id 6
assignment_id 1
grading_type 'Submission'
grade_receiver_id 1
grade 100
comment 'Good work!'
end
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>

*Grading Histories
<pre>
Scenario: Grading History creation
Given: A team exists for a particular assignment and has a submission
When: An instructor assigns a grade for that submission
Then: The grading history entry is created
</pre>

*Review Mapping
<pre>
Scenario: Save Reviewer Grade and Comment
Given: A student has given a review for a submission
When: An instructor assigns a grade for the review
Then: The assigned grade and the accompanying comment are saved
</pre>

*Grade
<pre>
Scenario: Save Grade and Comment for Submission
Given: A team has made a submission for an assignment
When: An instructor assigns a grade for the submission
Then: The assigned grade and the accompanying comment are saved
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* ''will be added for final submission''

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]

[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

[https://github.com/expertiza/expertiza/pull/2399 Pull Request]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-26T03:42:54Z

Schatte5: /* Problem Statement */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--every other spec file mentioned above crashes.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

=== Code and Documentation Goals ===

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:
* data flow
* functions
* code comments

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|345px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts. [[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]<br>
[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Assignments can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''

*Factory
<pre>
#Used for Grading Histories Controller Spec
factory :grading_history, class: GradingHistory do
id 1
instructor_id 6
assignment_id 1
grading_type 'Submission'
grade_receiver_id 1
grade 100
comment 'Good work!'
end
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>

*Grading Histories
<pre>
Scenario: Grading History creation
Given: A team exists for a particular assignment and has a submission
When: An instructor assigns a grade for that submission
Then: The grading history entry is created
</pre>

*Review Mapping
<pre>
Scenario: Save Reviewer Grade and Comment
Given: A student has given a review for a submission
When: An instructor assigns a grade for the review
Then: The assigned grade and the accompanying comment are saved
</pre>

*Grade
<pre>
Scenario: Save Grade and Comment for Submission
Given: A team has made a submission for an assignment
When: An instructor assigns a grade for the submission
Then: The assigned grade and the accompanying comment are saved
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* ''will be added for final submission''

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]

[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

[https://github.com/expertiza/expertiza/pull/2399 Pull Request]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-26T03:42:35Z

Schatte5: /* Data Flow and Functionality */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--every other spec file mentioned above crashes.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|345px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts. [[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]<br>
[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Assignments can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''

*Factory
<pre>
#Used for Grading Histories Controller Spec
factory :grading_history, class: GradingHistory do
id 1
instructor_id 6
assignment_id 1
grading_type 'Submission'
grade_receiver_id 1
grade 100
comment 'Good work!'
end
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>

*Grading Histories
<pre>
Scenario: Grading History creation
Given: A team exists for a particular assignment and has a submission
When: An instructor assigns a grade for that submission
Then: The grading history entry is created
</pre>

*Review Mapping
<pre>
Scenario: Save Reviewer Grade and Comment
Given: A student has given a review for a submission
When: An instructor assigns a grade for the review
Then: The assigned grade and the accompanying comment are saved
</pre>

*Grade
<pre>
Scenario: Save Grade and Comment for Submission
Given: A team has made a submission for an assignment
When: An instructor assigns a grade for the submission
Then: The assigned grade and the accompanying comment are saved
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* ''will be added for final submission''

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]

[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

[https://github.com/expertiza/expertiza/pull/2399 Pull Request]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-26T03:42:15Z

Schatte5: /* Planned and Completed Work */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--every other spec file mentioned above crashes.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|345px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

=== Code and Documentation Goals ===

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:
* data flow
* functions
* code comments

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts. [[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]<br>
[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Assignments can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''

*Factory
<pre>
#Used for Grading Histories Controller Spec
factory :grading_history, class: GradingHistory do
id 1
instructor_id 6
assignment_id 1
grading_type 'Submission'
grade_receiver_id 1
grade 100
comment 'Good work!'
end
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>

*Grading Histories
<pre>
Scenario: Grading History creation
Given: A team exists for a particular assignment and has a submission
When: An instructor assigns a grade for that submission
Then: The grading history entry is created
</pre>

*Review Mapping
<pre>
Scenario: Save Reviewer Grade and Comment
Given: A student has given a review for a submission
When: An instructor assigns a grade for the review
Then: The assigned grade and the accompanying comment are saved
</pre>

*Grade
<pre>
Scenario: Save Grade and Comment for Submission
Given: A team has made a submission for an assignment
When: An instructor assigns a grade for the submission
Then: The assigned grade and the accompanying comment are saved
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* ''will be added for final submission''

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]

[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

[https://github.com/expertiza/expertiza/pull/2399 Pull Request]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-26T03:40:18Z

Schatte5: /* Video Demonstration */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--every other spec file mentioned above crashes.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|345px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

=== Code and Documentation Goals ===

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:
* data flow
* functions
* code comments

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts. [[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

=== Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]<br>
[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Assignments can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''

*Factory
<pre>
#Used for Grading Histories Controller Spec
factory :grading_history, class: GradingHistory do
id 1
instructor_id 6
assignment_id 1
grading_type 'Submission'
grade_receiver_id 1
grade 100
comment 'Good work!'
end
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>

*Grading Histories
<pre>
Scenario: Grading History creation
Given: A team exists for a particular assignment and has a submission
When: An instructor assigns a grade for that submission
Then: The grading history entry is created
</pre>

*Review Mapping
<pre>
Scenario: Save Reviewer Grade and Comment
Given: A student has given a review for a submission
When: An instructor assigns a grade for the review
Then: The assigned grade and the accompanying comment are saved
</pre>

*Grade
<pre>
Scenario: Save Grade and Comment for Submission
Given: A team has made a submission for an assignment
When: An instructor assigns a grade for the submission
Then: The assigned grade and the accompanying comment are saved
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* ''will be added for final submission''

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]

[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

[https://github.com/expertiza/expertiza/pull/2399 Pull Request]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-26T03:40:05Z

Schatte5: /* Video Demonstration */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--every other spec file mentioned above crashes.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|345px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

=== Code and Documentation Goals ===

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:
* data flow
* functions
* code comments

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts. [[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

=== Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]<br>
[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Assignments can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''

*Factory
<pre>
#Used for Grading Histories Controller Spec
factory :grading_history, class: GradingHistory do
id 1
instructor_id 6
assignment_id 1
grading_type 'Submission'
grade_receiver_id 1
grade 100
comment 'Good work!'
end
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>

*Grading Histories
<pre>
Scenario: Grading History creation
Given: A team exists for a particular assignment and has a submission
When: An instructor assigns a grade for that submission
Then: The grading history entry is created
</pre>

*Review Mapping
<pre>
Scenario: Save Reviewer Grade and Comment
Given: A student has given a review for a submission
When: An instructor assigns a grade for the review
Then: The assigned grade and the accompanying comment are saved
</pre>

*Grade
<pre>
Scenario: Save Grade and Comment for Submission
Given: A team has made a submission for an assignment
When: An instructor assigns a grade for the submission
Then: The assigned grade and the accompanying comment are saved
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* ''will be added for final submission''

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]

[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

[https://github.com/expertiza/expertiza/pull/2399 Pull Request]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-26T03:39:34Z

Schatte5: /* Video Demonstration */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--every other spec file mentioned above crashes.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|345px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

=== Code and Documentation Goals ===

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:
* data flow
* functions
* code comments

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts. [[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

=== Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]
[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Assignments can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''

*Factory
<pre>
#Used for Grading Histories Controller Spec
factory :grading_history, class: GradingHistory do
id 1
instructor_id 6
assignment_id 1
grading_type 'Submission'
grade_receiver_id 1
grade 100
comment 'Good work!'
end
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>

*Grading Histories
<pre>
Scenario: Grading History creation
Given: A team exists for a particular assignment and has a submission
When: An instructor assigns a grade for that submission
Then: The grading history entry is created
</pre>

*Review Mapping
<pre>
Scenario: Save Reviewer Grade and Comment
Given: A student has given a review for a submission
When: An instructor assigns a grade for the review
Then: The assigned grade and the accompanying comment are saved
</pre>

*Grade
<pre>
Scenario: Save Grade and Comment for Submission
Given: A team has made a submission for an assignment
When: An instructor assigns a grade for the submission
Then: The assigned grade and the accompanying comment are saved
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* ''will be added for final submission''

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]

[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

[https://github.com/expertiza/expertiza/pull/2399 Pull Request]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-26T02:46:55Z

Schatte5: /* Useful Links */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--every other spec file mentioned above crashes.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely Student Accounts, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|345px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

=== Code and Documentation Goals ===

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:
* data flow
* functions
* code comments

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts. [[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

=== Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Student Accounts can be created and are saved to the database.
# Verify that Assignments can be created and are saved to the database.
# Verify that Project Bids can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''
*Student Account
<pre>
Scenario: Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student account with all the necessary fields
Then: Account is saved in the database

Scenario: Duplicate Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts with all the necessary fields
Then: Student already exists message is shown

Scenario: Account Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts without all the necessary fields
Then: Message to input fields is shown
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>
*Project Bids
<pre>
Scenario: Project Bid creation
Given: Logged in as a Student
When: Complete Project Bid for open Project
Then: Project Bid is saved in the database

Scenario: Duplicate Project Bid
Given: Logged in as a Student
When: Click on bid for open Project
Then Message stating already selected shown
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* ''will be added for final submission''

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

[https://youtu.be/ItrCCEY1jR8 Live Demo: Functionality]

[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-26T02:39:14Z

Schatte5: /* Useful Links */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--every other spec file mentioned above crashes.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely Student Accounts, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|345px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

=== Code and Documentation Goals ===

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:
* data flow
* functions
* code comments

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts. [[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

=== Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Student Accounts can be created and are saved to the database.
# Verify that Assignments can be created and are saved to the database.
# Verify that Project Bids can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''
*Student Account
<pre>
Scenario: Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student account with all the necessary fields
Then: Account is saved in the database

Scenario: Duplicate Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts with all the necessary fields
Then: Student already exists message is shown

Scenario: Account Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts without all the necessary fields
Then: Message to input fields is shown
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>
*Project Bids
<pre>
Scenario: Project Bid creation
Given: Logged in as a Student
When: Complete Project Bid for open Project
Then: Project Bid is saved in the database

Scenario: Duplicate Project Bid
Given: Logged in as a Student
When: Click on bid for open Project
Then Message stating already selected shown
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* ''will be added for final submission''

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

[https://youtu.be/9x59twFwwC0 RSpec Test Demo]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

User:Schatte5

2022-04-25T06:54:52Z

Schatte5: Created page with "Spring 2022 ECE517 Student. Email expertiza support in case of any questions that aren't answered in the wiki."

Spring 2022 ECE517 Student.
Email expertiza support in case of any questions that aren't answered in the wiki.

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-12T01:22:58Z

Schatte5: /* New Data Flow */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--every other spec file mentioned above crashes.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely Student Accounts, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|345px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

=== Code and Documentation Goals ===

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:
* data flow
* functions
* code comments

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts. [[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

=== Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Student Accounts can be created and are saved to the database.
# Verify that Assignments can be created and are saved to the database.
# Verify that Project Bids can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''
*Student Account
<pre>
Scenario: Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student account with all the necessary fields
Then: Account is saved in the database

Scenario: Duplicate Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts with all the necessary fields
Then: Student already exists message is shown

Scenario: Account Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts without all the necessary fields
Then: Message to input fields is shown
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>
*Project Bids
<pre>
Scenario: Project Bid creation
Given: Logged in as a Student
When: Complete Project Bid for open Project
Then: Project Bid is saved in the database

Scenario: Duplicate Project Bid
Given: Logged in as a Student
When: Click on bid for open Project
Then Message stating already selected shown
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* ''will be added for final submission''

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-12T01:22:48Z

Schatte5: /* New Data Flow */

== Topic Overview & Prior Work (E2158) ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information on the previous team's work with this feature.

'''A summary of the desired functionality is presented below:'''

Any instructor can assign or edit a grade freely.

There should be a way to track which instructor assigned or edited a grade, along with any comments they wrote justifying that grade.

These things must be recorded in the grading audit trail any time an instructor assigns or edits a grade and its comments:
* id of the instructor
* timestamp
Additionally, any comments written by other instructors should be preserved.

=== Overview of Major Changes By Previous Team ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').
**Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''grading_histories/index.html.erb''').

=== Files Modified By Previous Team ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing By Previous Team ===

''Functional tests'' were added.
<pre>
functional tests added to these files
: spec/controllers/review_mapping_controller_spec.rb
: spec/models/grading_history.rb
: spec/controllers/grading_history_controller.rb
</pre>
A ''feature test'' ensuring that a submission's grading history is shown completely, and in chronological order, was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
Only review_mapping_controller_spec.rb runs successfully--every other spec file mentioned above crashes.

== Problem Statement ==

''There are '''three areas of focus''' for our team's project (E2237):''
=== System Crashes and Object Creation ===

# We must ensure that the unit tests no longer crash, and that they pass with appropriate coverage.
# We must ensure that the creation of testing objects, namely Student Accounts, Assignments, and Project Bids, does not cause crashing.

=== Changes to Grading History View ===

The grading history table in the view is earmarked for certain changes:
# '''Student ID''' is a redundant field--move it to the page header.
# '''Assignment ID''' is a redundant field--move it to the page header.

==Data Flow and Functionality==
===Old Data Flow===
The existing ''data flow'' for the grading history feature for reviews is shown below:

<span style="position:relative;left:0px;top:0px">[[File:Reviewhistory.jpg|270px]]</span>
<span style="position:relative;left:125px;top:0px">[[File:Review scores imported.png|560px]] </span>

The related ''table'' from the database is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores].

===New Data Flow===

The latest ''flow'' for the Grading History functionality is shown below:

[[File:kai_diagram1.jpg|3450px]]

The primary function of this change is to DRY out the current implementation. The flow shown below tracks the tables where grades and comments(that comprise grading history) are recorded into already existing tables. The newly created table '''grading_history''' is linked to the '''teams''' table from which comments and grades are drawn. This table then displays these values, thereby completing the functionality when the user clicks on display history. The '''grading_history''' table contains the team id and instructor_name

[[File:Kai_new_flow 3.jpg|650px]]

=== Code and Documentation Goals ===

We must explain changes made to files with diagrams and justifications.

Explanations will be provided from these perspectives:
* data flow
* functions
* code comments

== Planned and Completed Work ==

=== General Design Goals ===
====Changes to the Grading History Table====

The images below reference grading history view issues mentioned above in the ''Problem Statement''.

To DRY the code, we will remove the redundant table data boxed below...

[[File:E2237_Proj4_1.png]]

<br> ...and we'll move it to the page header:

[[File:E2237_Proj4_2.png]]

<br>

'''Behavior Driven Development'''<br>
Due to the nature of the functionalities that we will be implementing, we will be following a BDD methodology - Our primary intention with this is to focus our refactoring, development and database design efforts to ensure that end-user functionality is implemented fully.<br>
In order to demonstrate this, we have provided our tests ahead of time and will be using them to guide our development efforts. [[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail#RSpec Unit Tests|BDD Scenarios]]

====System Stability: Strategies====
''The source of crashing issues is currently unknown.'' To debug this, we will pursue the following:
* Refactor the specs and controllers
** Ensure DRY principle is followed
** Improve readability and maintainability
** Add code comments as needed
* Ensure testing objects do not cause crashes

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

=== Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Student Accounts can be created and are saved to the database.
# Verify that Assignments can be created and are saved to the database.
# Verify that Project Bids can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''
*Student Account
<pre>
Scenario: Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student account with all the necessary fields
Then: Account is saved in the database

Scenario: Duplicate Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts with all the necessary fields
Then: Student already exists message is shown

Scenario: Account Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts without all the necessary fields
Then: Message to input fields is shown
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>
*Project Bids
<pre>
Scenario: Project Bid creation
Given: Logged in as a Student
When: Complete Project Bid for open Project
Then: Project Bid is saved in the database

Scenario: Duplicate Project Bid
Given: Logged in as a Student
When: Click on bid for open Project
Then Message stating already selected shown
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* ''will be added for final submission''

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/2164 Previous team's Expertiza GitHub pull request]

[[CSC/ECE 517 Fall 2021 - E2158. Grading audit trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-12T00:35:37Z

Schatte5: /* Old Data Flow */

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-12T00:35:25Z

Schatte5: /* Old Data Flow */

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-12T00:35:12Z

Schatte5: /* Data Flow and Functionality */

File:Kai new flow 3.jpg

2022-04-12T00:32:32Z

Schatte5:

File:Kai new flow 2.jpg

2022-04-12T00:30:13Z

Schatte5:

File:Kai new flow.jpg

2022-04-12T00:29:19Z

Schatte5:

File:Kai diagram1.jpg

2022-04-12T00:26:59Z

Schatte5:

File:Kai diagram.jpg

2022-04-12T00:24:06Z

Schatte5: phd level diagram, exclusive access

phd level diagram, exclusive access

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-07T21:24:40Z

Schatte5: /* Changes to Grading History Table */

== Topic Overview & Prior Work ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information regarding this feature.
'''A summary of the desired functionality is presented below:'''

After an instructor assigns a grade to an assignment, there should be a way to track who gave the grade. Any instructor can assign/edit a grade freely; a grading audit trail must be created and the following information needs to be stored:
* When a grade is assigned by an instructor, there must be an indication of the InstructorID and a timestamp of the change.
* Comments previously provided by other instructors must be preserved.
*This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

=== Overview of Major Changes ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb'''). Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''index_html.erb''').

=== Files Involved ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing ===

As per E2158, - ''Functional tests'' ensuring specific method calls are made were added.
<pre>
functional tests added to these files
: spec/controllers/grades_controller_spec.rb
: spec/controllers/review_mapping_controller_spec.rb
: spec/controllers/grading_histories_controller_test.rb
</pre>
Additionally, a ''feature test'' ensuring that correct grading history is shown in chronological order was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
# Running these tests causes failures - in fact, only the Spec files for review_mapping_controller runs.
# As per E2158, running all tests leads to the simulation crashing

== Statement of Problem ==

''There are '''three areas of focus''' for this project:''
=== System Crashes and Object Creation ===

#The work done by the previous team results in the system crashing when the tests are being executed; as a result, automated unit testing does not succeed. Our goal in this regard is to ensure that the tests are successfully executed for all test cases, with the appropriate outcome and coverage reports visible to the user.
#Testing efforts to this point have used static, pre-created objects; this is due to issues with object creation. Our goal in this aspect is to ensure that the creation of new test objects, namely Student Accounts, Assignments, and Project Bids is successful.

=== Changes to Grading History Table ===

The grading history table is earmarked for certain changes:
# Extract Student ID from the table, and ensure that it is shown in the header.
# Extract Assignment ID from the table, and ensure that it is shown in the header

The data flow for this feature is shown below:

[[File:Reviewhistory.jpg]]

The related table from databases is [https://expertiza.csc.ncsu.edu/index.php/Review_scores review_scores]. The ER table of review_scores is shown as below.

[[File:Review scores imported.png]]

The latest flow for the Grading History functionality is shown below:
[[File:GradingHistory.png]]

=== Code and Documentation Goals ===

Reasoning and data flow structures/UML diagrams should be added that detail the changes that have been made, as well as any comments on why certain files needed to be modified.
These will be completed from these perspectives:
# From a data flow point of view
# From a function point of view
# With comment in code

== Plan and List of Work Done ==

=== General Design Goals ===
====Changes to the Grading History Table====

The outlined code here is to be removed as these fields are redundant.
We will perform the following to DRY the implementation:

[[File:E2237_Proj4_1.png]]

<br> The data is to be moved to the header, as shown below:

[[File:E2237_Proj4_2.png]]

<br>

====System Stability: Strategies====
''The source of this issue is currently unknown.'' Therefore, we will pursue the following to debug this:
# Refactoring: We will explore refactoring both the test cases and the controllers (mentioned in section 2.2) to enforce the DRY principle where needed, and comment the code to enhance readability & maintainability
# Test data: Currently, there is an existing issue with the test methodology - testing is all being done using pre-existing, static data. This will be fixed as a result of our work on Object Creation.
<br>

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

=== Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Student Accounts can be created and are saved to the database.
# Verify that Assignments can be created and are saved to the database.
# Verify that Project Bids can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''
*Student Account
<pre>
Scenario: Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student account with all the necessary fields
Then: Account is saved in the database

Scenario: Duplicate Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts with all the necessary fields
Then: Student already exists message is shown

Scenario: Account Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts without all the necessary fields
Then: Message to input fields is shown
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>
*Project Bids
<pre>
Scenario: Project Bid creation
Given: Logged in as a Student
When: Complete Project Bid for open Project
Then: Project Bid is saved in the database

Scenario: Duplicate Project Bid
Given: Logged in as a Student
When: Click on bid for open Project
Then Message stating already selected shown
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* ''will be added for final submission''

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/1441 Previous team's Expertiza GitHub pull request]

[[E1934 - Grading Audit Trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-07T21:21:35Z

Schatte5: /* Changes to Grading History Table */

== Topic Overview & Prior Work ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information regarding this feature.
'''A summary of the desired functionality is presented below:'''

After an instructor assigns a grade to an assignment, there should be a way to track who gave the grade. Any instructor can assign/edit a grade freely; a grading audit trail must be created and the following information needs to be stored:
* When a grade is assigned by an instructor, there must be an indication of the InstructorID and a timestamp of the change.
* Comments previously provided by other instructors must be preserved.
*This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

=== Overview of Major Changes ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb'''). Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''index_html.erb''').

=== Files Involved ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing ===

As per E2158, - ''Functional tests'' ensuring specific method calls are made were added.
<pre>
functional tests added to these files
: spec/controllers/grades_controller_spec.rb
: spec/controllers/review_mapping_controller_spec.rb
: spec/controllers/grading_histories_controller_test.rb
</pre>
Additionally, a ''feature test'' ensuring that correct grading history is shown in chronological order was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
# Running these tests causes failures - in fact, only the Spec files for review_mapping_controller runs.
# As per E2158, running all tests leads to the simulation crashing

== Statement of Problem ==

''There are '''three areas of focus''' for this project:''
=== System Crashes and Object Creation ===

#The work done by the previous team results in the system crashing when the tests are being executed; as a result, automated unit testing does not succeed. Our goal in this regard is to ensure that the tests are successfully executed for all test cases, with the appropriate outcome and coverage reports visible to the user.
#Testing efforts to this point have used static, pre-created objects; this is due to issues with object creation. Our goal in this aspect is to ensure that the creation of new test objects, namely Student Accounts, Assignments, and Project Bids is successful.

=== Changes to Grading History Table ===

The grading history table is earmarked for certain changes:
# Extract Student ID from the table, and ensure that it is shown in the header.
# Extract Assignment ID from the table, and ensure that it is shown in the header

The data flow for this feature is shown below:

[[File:Reviewhistory.jpg]]

The latest flow for the Grading History functionality is shown below:
[[File:GradingHistory.png]]

=== Code and Documentation Goals ===

Reasoning and data flow structures/UML diagrams should be added that detail the changes that have been made, as well as any comments on why certain files needed to be modified.
These will be completed from these perspectives:
# From a data flow point of view
# From a function point of view
# With comment in code

== Plan and List of Work Done ==

=== General Design Goals ===
====Changes to the Grading History Table====

The outlined code here is to be removed as these fields are redundant.
We will perform the following to DRY the implementation:

[[File:E2237_Proj4_1.png]]

<br> The data is to be moved to the header, as shown below:

[[File:E2237_Proj4_2.png]]

<br>

====System Stability: Strategies====
''The source of this issue is currently unknown.'' Therefore, we will pursue the following to debug this:
# Refactoring: We will explore refactoring both the test cases and the controllers (mentioned in section 2.2) to enforce the DRY principle where needed, and comment the code to enhance readability & maintainability
# Test data: Currently, there is an existing issue with the test methodology - testing is all being done using pre-existing, static data. This will be fixed as a result of our work on Object Creation.
<br>

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

=== Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Student Accounts can be created and are saved to the database.
# Verify that Assignments can be created and are saved to the database.
# Verify that Project Bids can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''
*Student Account
<pre>
Scenario: Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student account with all the necessary fields
Then: Account is saved in the database

Scenario: Duplicate Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts with all the necessary fields
Then: Student already exists message is shown

Scenario: Account Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts without all the necessary fields
Then: Message to input fields is shown
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>
*Project Bids
<pre>
Scenario: Project Bid creation
Given: Logged in as a Student
When: Complete Project Bid for open Project
Then: Project Bid is saved in the database

Scenario: Duplicate Project Bid
Given: Logged in as a Student
When: Click on bid for open Project
Then Message stating already selected shown
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* ''will be added for final submission''

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/1441 Previous team's Expertiza GitHub pull request]

[[E1934 - Grading Audit Trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-07T21:21:17Z

Schatte5: /* Changes to the Grading History Table */

== Topic Overview & Prior Work ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information regarding this feature.
'''A summary of the desired functionality is presented below:'''

After an instructor assigns a grade to an assignment, there should be a way to track who gave the grade. Any instructor can assign/edit a grade freely; a grading audit trail must be created and the following information needs to be stored:
* When a grade is assigned by an instructor, there must be an indication of the InstructorID and a timestamp of the change.
* Comments previously provided by other instructors must be preserved.
*This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

=== Overview of Major Changes ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb'''). Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''index_html.erb''').

=== Files Involved ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing ===

As per E2158, - ''Functional tests'' ensuring specific method calls are made were added.
<pre>
functional tests added to these files
: spec/controllers/grades_controller_spec.rb
: spec/controllers/review_mapping_controller_spec.rb
: spec/controllers/grading_histories_controller_test.rb
</pre>
Additionally, a ''feature test'' ensuring that correct grading history is shown in chronological order was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
# Running these tests causes failures - in fact, only the Spec files for review_mapping_controller runs.
# As per E2158, running all tests leads to the simulation crashing

== Statement of Problem ==

''There are '''three areas of focus''' for this project:''
=== System Crashes and Object Creation ===

#The work done by the previous team results in the system crashing when the tests are being executed; as a result, automated unit testing does not succeed. Our goal in this regard is to ensure that the tests are successfully executed for all test cases, with the appropriate outcome and coverage reports visible to the user.
#Testing efforts to this point have used static, pre-created objects; this is due to issues with object creation. Our goal in this aspect is to ensure that the creation of new test objects, namely Student Accounts, Assignments, and Project Bids is successful.

=== Changes to Grading History Table ===

The grading history table is earmarked for certain changes:
# Extract Student ID from the table, and ensure that it is shown in the header.
# Extract Assignment ID from the table, and ensure that it is shown in the header

=== Code and Documentation Goals ===

Reasoning and data flow structures/UML diagrams should be added that detail the changes that have been made, as well as any comments on why certain files needed to be modified.
These will be completed from these perspectives:
# From a data flow point of view
# From a function point of view
# With comment in code

== Plan and List of Work Done ==

=== General Design Goals ===
====Changes to the Grading History Table====

The outlined code here is to be removed as these fields are redundant.
We will perform the following to DRY the implementation:

[[File:E2237_Proj4_1.png]]

<br> The data is to be moved to the header, as shown below:

[[File:E2237_Proj4_2.png]]

<br>

====System Stability: Strategies====
''The source of this issue is currently unknown.'' Therefore, we will pursue the following to debug this:
# Refactoring: We will explore refactoring both the test cases and the controllers (mentioned in section 2.2) to enforce the DRY principle where needed, and comment the code to enhance readability & maintainability
# Test data: Currently, there is an existing issue with the test methodology - testing is all being done using pre-existing, static data. This will be fixed as a result of our work on Object Creation.
<br>

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

=== Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Student Accounts can be created and are saved to the database.
# Verify that Assignments can be created and are saved to the database.
# Verify that Project Bids can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''
*Student Account
<pre>
Scenario: Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student account with all the necessary fields
Then: Account is saved in the database

Scenario: Duplicate Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts with all the necessary fields
Then: Student already exists message is shown

Scenario: Account Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts without all the necessary fields
Then: Message to input fields is shown
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>
*Project Bids
<pre>
Scenario: Project Bid creation
Given: Logged in as a Student
When: Complete Project Bid for open Project
Then: Project Bid is saved in the database

Scenario: Duplicate Project Bid
Given: Logged in as a Student
When: Click on bid for open Project
Then Message stating already selected shown
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* ''will be added for final submission''

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/1441 Previous team's Expertiza GitHub pull request]

[[E1934 - Grading Audit Trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-07T21:19:32Z

Schatte5: /* Changes to the Grading History Table */

== Topic Overview & Prior Work ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information regarding this feature.
'''A summary of the desired functionality is presented below:'''

After an instructor assigns a grade to an assignment, there should be a way to track who gave the grade. Any instructor can assign/edit a grade freely; a grading audit trail must be created and the following information needs to be stored:
* When a grade is assigned by an instructor, there must be an indication of the InstructorID and a timestamp of the change.
* Comments previously provided by other instructors must be preserved.
*This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

=== Overview of Major Changes ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb'''). Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''index_html.erb''').

=== Files Involved ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing ===

As per E2158, - ''Functional tests'' ensuring specific method calls are made were added.
<pre>
functional tests added to these files
: spec/controllers/grades_controller_spec.rb
: spec/controllers/review_mapping_controller_spec.rb
: spec/controllers/grading_histories_controller_test.rb
</pre>
Additionally, a ''feature test'' ensuring that correct grading history is shown in chronological order was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
# Running these tests causes failures - in fact, only the Spec files for review_mapping_controller runs.
# As per E2158, running all tests leads to the simulation crashing

== Statement of Problem ==

''There are '''three areas of focus''' for this project:''
=== System Crashes and Object Creation ===

#The work done by the previous team results in the system crashing when the tests are being executed; as a result, automated unit testing does not succeed. Our goal in this regard is to ensure that the tests are successfully executed for all test cases, with the appropriate outcome and coverage reports visible to the user.
#Testing efforts to this point have used static, pre-created objects; this is due to issues with object creation. Our goal in this aspect is to ensure that the creation of new test objects, namely Student Accounts, Assignments, and Project Bids is successful.

=== Changes to Grading History Table ===

The grading history table is earmarked for certain changes:
# Extract Student ID from the table, and ensure that it is shown in the header.
# Extract Assignment ID from the table, and ensure that it is shown in the header

=== Code and Documentation Goals ===

Reasoning and data flow structures/UML diagrams should be added that detail the changes that have been made, as well as any comments on why certain files needed to be modified.
These will be completed from these perspectives:
# From a data flow point of view
# From a function point of view
# With comment in code

== Plan and List of Work Done ==

=== General Design Goals ===
====Changes to the Grading History Table====
The data flow for this feature is shown below:

[[File:Reviewhistory.jpg]]

The latest flow for the Grading History functionality is shown below:
[[File:GradingHistory.png]]
<br>

The outlined code here is to be removed as these fields are redundant.
We will perform the following to DRY the implementation:

[[File:E2237_Proj4_1.png]]

<br> The data is to be moved to the header, as shown below:

[[File:E2237_Proj4_2.png]]

<br>

====System Stability: Strategies====
''The source of this issue is currently unknown.'' Therefore, we will pursue the following to debug this:
# Refactoring: We will explore refactoring both the test cases and the controllers (mentioned in section 2.2) to enforce the DRY principle where needed, and comment the code to enhance readability & maintainability
# Test data: Currently, there is an existing issue with the test methodology - testing is all being done using pre-existing, static data. This will be fixed as a result of our work on Object Creation.
<br>

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

=== Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Student Accounts can be created and are saved to the database.
# Verify that Assignments can be created and are saved to the database.
# Verify that Project Bids can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''
*Student Account
<pre>
Scenario: Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student account with all the necessary fields
Then: Account is saved in the database

Scenario: Duplicate Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts with all the necessary fields
Then: Student already exists message is shown

Scenario: Account Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts without all the necessary fields
Then: Message to input fields is shown
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>
*Project Bids
<pre>
Scenario: Project Bid creation
Given: Logged in as a Student
When: Complete Project Bid for open Project
Then: Project Bid is saved in the database

Scenario: Duplicate Project Bid
Given: Logged in as a Student
When: Click on bid for open Project
Then Message stating already selected shown
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* ''will be added for final submission''

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/1441 Previous team's Expertiza GitHub pull request]

[[E1934 - Grading Audit Trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-07T21:19:22Z

Schatte5: /* Changes to the Grading History Table */

== Topic Overview & Prior Work ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information regarding this feature.
'''A summary of the desired functionality is presented below:'''

After an instructor assigns a grade to an assignment, there should be a way to track who gave the grade. Any instructor can assign/edit a grade freely; a grading audit trail must be created and the following information needs to be stored:
* When a grade is assigned by an instructor, there must be an indication of the InstructorID and a timestamp of the change.
* Comments previously provided by other instructors must be preserved.
*This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

=== Overview of Major Changes ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb'''). Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''index_html.erb''').

=== Files Involved ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing ===

As per E2158, - ''Functional tests'' ensuring specific method calls are made were added.
<pre>
functional tests added to these files
: spec/controllers/grades_controller_spec.rb
: spec/controllers/review_mapping_controller_spec.rb
: spec/controllers/grading_histories_controller_test.rb
</pre>
Additionally, a ''feature test'' ensuring that correct grading history is shown in chronological order was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
# Running these tests causes failures - in fact, only the Spec files for review_mapping_controller runs.
# As per E2158, running all tests leads to the simulation crashing

== Statement of Problem ==

''There are '''three areas of focus''' for this project:''
=== System Crashes and Object Creation ===

#The work done by the previous team results in the system crashing when the tests are being executed; as a result, automated unit testing does not succeed. Our goal in this regard is to ensure that the tests are successfully executed for all test cases, with the appropriate outcome and coverage reports visible to the user.
#Testing efforts to this point have used static, pre-created objects; this is due to issues with object creation. Our goal in this aspect is to ensure that the creation of new test objects, namely Student Accounts, Assignments, and Project Bids is successful.

=== Changes to Grading History Table ===

The grading history table is earmarked for certain changes:
# Extract Student ID from the table, and ensure that it is shown in the header.
# Extract Assignment ID from the table, and ensure that it is shown in the header

=== Code and Documentation Goals ===

Reasoning and data flow structures/UML diagrams should be added that detail the changes that have been made, as well as any comments on why certain files needed to be modified.
These will be completed from these perspectives:
# From a data flow point of view
# From a function point of view
# With comment in code

== Plan and List of Work Done ==

=== General Design Goals ===
====Changes to the Grading History Table====
The data flow for this feature is shown below:

[[File:Reviewhistory.jpg]]
The latest flow for the Grading History functionality is shown below:
[[File:GradingHistory.png]]
<br>

The outlined code here is to be removed as these fields are redundant.
We will perform the following to DRY the implementation:

[[File:E2237_Proj4_1.png]]

<br> The data is to be moved to the header, as shown below:

[[File:E2237_Proj4_2.png]]

<br>

====System Stability: Strategies====
''The source of this issue is currently unknown.'' Therefore, we will pursue the following to debug this:
# Refactoring: We will explore refactoring both the test cases and the controllers (mentioned in section 2.2) to enforce the DRY principle where needed, and comment the code to enhance readability & maintainability
# Test data: Currently, there is an existing issue with the test methodology - testing is all being done using pre-existing, static data. This will be fixed as a result of our work on Object Creation.
<br>

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

=== Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Student Accounts can be created and are saved to the database.
# Verify that Assignments can be created and are saved to the database.
# Verify that Project Bids can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''
*Student Account
<pre>
Scenario: Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student account with all the necessary fields
Then: Account is saved in the database

Scenario: Duplicate Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts with all the necessary fields
Then: Student already exists message is shown

Scenario: Account Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts without all the necessary fields
Then: Message to input fields is shown
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>
*Project Bids
<pre>
Scenario: Project Bid creation
Given: Logged in as a Student
When: Complete Project Bid for open Project
Then: Project Bid is saved in the database

Scenario: Duplicate Project Bid
Given: Logged in as a Student
When: Click on bid for open Project
Then Message stating already selected shown
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* ''will be added for final submission''

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/1441 Previous team's Expertiza GitHub pull request]

[[E1934 - Grading Audit Trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-07T21:17:44Z

Schatte5: /* Changes to the Grading History Table */

== Topic Overview & Prior Work ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information regarding this feature.
'''A summary of the desired functionality is presented below:'''

After an instructor assigns a grade to an assignment, there should be a way to track who gave the grade. Any instructor can assign/edit a grade freely; a grading audit trail must be created and the following information needs to be stored:
* When a grade is assigned by an instructor, there must be an indication of the InstructorID and a timestamp of the change.
* Comments previously provided by other instructors must be preserved.
*This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

=== Overview of Major Changes ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb'''). Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''index_html.erb''').

=== Files Involved ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing ===

As per E2158, - ''Functional tests'' ensuring specific method calls are made were added.
<pre>
functional tests added to these files
: spec/controllers/grades_controller_spec.rb
: spec/controllers/review_mapping_controller_spec.rb
: spec/controllers/grading_histories_controller_test.rb
</pre>
Additionally, a ''feature test'' ensuring that correct grading history is shown in chronological order was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
# Running these tests causes failures - in fact, only the Spec files for review_mapping_controller runs.
# As per E2158, running all tests leads to the simulation crashing

== Statement of Problem ==

''There are '''three areas of focus''' for this project:''
=== System Crashes and Object Creation ===

#The work done by the previous team results in the system crashing when the tests are being executed; as a result, automated unit testing does not succeed. Our goal in this regard is to ensure that the tests are successfully executed for all test cases, with the appropriate outcome and coverage reports visible to the user.
#Testing efforts to this point have used static, pre-created objects; this is due to issues with object creation. Our goal in this aspect is to ensure that the creation of new test objects, namely Student Accounts, Assignments, and Project Bids is successful.

=== Changes to Grading History Table ===

The grading history table is earmarked for certain changes:
# Extract Student ID from the table, and ensure that it is shown in the header.
# Extract Assignment ID from the table, and ensure that it is shown in the header

=== Code and Documentation Goals ===

Reasoning and data flow structures/UML diagrams should be added that detail the changes that have been made, as well as any comments on why certain files needed to be modified.
These will be completed from these perspectives:
# From a data flow point of view
# From a function point of view
# With comment in code

== Plan and List of Work Done ==

=== General Design Goals ===
====Changes to the Grading History Table====
The data flow for this feature is shown below:
[[File:Reviewhistory.jpg]]
<br>

The outlined code here is to be removed as these fields are redundant.
We will perform the following to DRY the implementation:

[[File:E2237_Proj4_1.png]]

<br> The data is to be moved to the header, as shown below:

[[File:E2237_Proj4_2.png]]

<br>

====System Stability: Strategies====
''The source of this issue is currently unknown.'' Therefore, we will pursue the following to debug this:
# Refactoring: We will explore refactoring both the test cases and the controllers (mentioned in section 2.2) to enforce the DRY principle where needed, and comment the code to enhance readability & maintainability
# Test data: Currently, there is an existing issue with the test methodology - testing is all being done using pre-existing, static data. This will be fixed as a result of our work on Object Creation.
<br>

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

=== Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Student Accounts can be created and are saved to the database.
# Verify that Assignments can be created and are saved to the database.
# Verify that Project Bids can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''
*Student Account
<pre>
Scenario: Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student account with all the necessary fields
Then: Account is saved in the database

Scenario: Duplicate Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts with all the necessary fields
Then: Student already exists message is shown

Scenario: Account Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts without all the necessary fields
Then: Message to input fields is shown
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>
*Project Bids
<pre>
Scenario: Project Bid creation
Given: Logged in as a Student
When: Complete Project Bid for open Project
Then: Project Bid is saved in the database

Scenario: Duplicate Project Bid
Given: Logged in as a Student
When: Click on bid for open Project
Then Message stating already selected shown
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* ''will be added for final submission''

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/1441 Previous team's Expertiza GitHub pull request]

[[E1934 - Grading Audit Trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-07T21:16:57Z

Schatte5: /* System Stability: Strategies */

== Topic Overview & Prior Work ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information regarding this feature.
'''A summary of the desired functionality is presented below:'''

After an instructor assigns a grade to an assignment, there should be a way to track who gave the grade. Any instructor can assign/edit a grade freely; a grading audit trail must be created and the following information needs to be stored:
* When a grade is assigned by an instructor, there must be an indication of the InstructorID and a timestamp of the change.
* Comments previously provided by other instructors must be preserved.
*This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

=== Overview of Major Changes ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb'''). Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''index_html.erb''').

=== Files Involved ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing ===

As per E2158, - ''Functional tests'' ensuring specific method calls are made were added.
<pre>
functional tests added to these files
: spec/controllers/grades_controller_spec.rb
: spec/controllers/review_mapping_controller_spec.rb
: spec/controllers/grading_histories_controller_test.rb
</pre>
Additionally, a ''feature test'' ensuring that correct grading history is shown in chronological order was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
# Running these tests causes failures - in fact, only the Spec files for review_mapping_controller runs.
# As per E2158, running all tests leads to the simulation crashing

== Statement of Problem ==

''There are '''three areas of focus''' for this project:''
=== System Crashes and Object Creation ===

#The work done by the previous team results in the system crashing when the tests are being executed; as a result, automated unit testing does not succeed. Our goal in this regard is to ensure that the tests are successfully executed for all test cases, with the appropriate outcome and coverage reports visible to the user.
#Testing efforts to this point have used static, pre-created objects; this is due to issues with object creation. Our goal in this aspect is to ensure that the creation of new test objects, namely Student Accounts, Assignments, and Project Bids is successful.

=== Changes to Grading History Table ===

The grading history table is earmarked for certain changes:
# Extract Student ID from the table, and ensure that it is shown in the header.
# Extract Assignment ID from the table, and ensure that it is shown in the header

=== Code and Documentation Goals ===

Reasoning and data flow structures/UML diagrams should be added that detail the changes that have been made, as well as any comments on why certain files needed to be modified.
These will be completed from these perspectives:
# From a data flow point of view
# From a function point of view
# With comment in code

== Plan and List of Work Done ==

=== General Design Goals ===
====Changes to the Grading History Table====
The outlined code here is to be removed as these fields are redundant.
We will perform the following to DRY the implementation:

[[File:E2237_Proj4_1.png]]

<br> The data is to be moved to the header, as shown below:

[[File:E2237_Proj4_2.png]]

<br>

====System Stability: Strategies====
''The source of this issue is currently unknown.'' Therefore, we will pursue the following to debug this:
# Refactoring: We will explore refactoring both the test cases and the controllers (mentioned in section 2.2) to enforce the DRY principle where needed, and comment the code to enhance readability & maintainability
# Test data: Currently, there is an existing issue with the test methodology - testing is all being done using pre-existing, static data. This will be fixed as a result of our work on Object Creation.
<br>

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

=== Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Student Accounts can be created and are saved to the database.
# Verify that Assignments can be created and are saved to the database.
# Verify that Project Bids can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''
*Student Account
<pre>
Scenario: Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student account with all the necessary fields
Then: Account is saved in the database

Scenario: Duplicate Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts with all the necessary fields
Then: Student already exists message is shown

Scenario: Account Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts without all the necessary fields
Then: Message to input fields is shown
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>
*Project Bids
<pre>
Scenario: Project Bid creation
Given: Logged in as a Student
When: Complete Project Bid for open Project
Then: Project Bid is saved in the database

Scenario: Duplicate Project Bid
Given: Logged in as a Student
When: Click on bid for open Project
Then Message stating already selected shown
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* ''will be added for final submission''

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/1441 Previous team's Expertiza GitHub pull request]

[[E1934 - Grading Audit Trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-07T21:15:01Z

Schatte5: /* System Stability: Strategies */

== Topic Overview & Prior Work ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information regarding this feature.
'''A summary of the desired functionality is presented below:'''

After an instructor assigns a grade to an assignment, there should be a way to track who gave the grade. Any instructor can assign/edit a grade freely; a grading audit trail must be created and the following information needs to be stored:
* When a grade is assigned by an instructor, there must be an indication of the InstructorID and a timestamp of the change.
* Comments previously provided by other instructors must be preserved.
*This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

=== Overview of Major Changes ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb'''). Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''index_html.erb''').

=== Files Involved ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing ===

As per E2158, - ''Functional tests'' ensuring specific method calls are made were added.
<pre>
functional tests added to these files
: spec/controllers/grades_controller_spec.rb
: spec/controllers/review_mapping_controller_spec.rb
: spec/controllers/grading_histories_controller_test.rb
</pre>
Additionally, a ''feature test'' ensuring that correct grading history is shown in chronological order was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
# Running these tests causes failures - in fact, only the Spec files for review_mapping_controller runs.
# As per E2158, running all tests leads to the simulation crashing

== Statement of Problem ==

''There are '''three areas of focus''' for this project:''
=== System Crashes and Object Creation ===

#The work done by the previous team results in the system crashing when the tests are being executed; as a result, automated unit testing does not succeed. Our goal in this regard is to ensure that the tests are successfully executed for all test cases, with the appropriate outcome and coverage reports visible to the user.
#Testing efforts to this point have used static, pre-created objects; this is due to issues with object creation. Our goal in this aspect is to ensure that the creation of new test objects, namely Student Accounts, Assignments, and Project Bids is successful.

=== Changes to Grading History Table ===

The grading history table is earmarked for certain changes:
# Extract Student ID from the table, and ensure that it is shown in the header.
# Extract Assignment ID from the table, and ensure that it is shown in the header

=== Code and Documentation Goals ===

Reasoning and data flow structures/UML diagrams should be added that detail the changes that have been made, as well as any comments on why certain files needed to be modified.
These will be completed from these perspectives:
# From a data flow point of view
# From a function point of view
# With comment in code

== Plan and List of Work Done ==

=== General Design Goals ===
====Changes to the Grading History Table====
The outlined code here is to be removed as these fields are redundant.
We will perform the following to DRY the implementation:

[[File:E2237_Proj4_1.png]]

<br> The data is to be moved to the header, as shown below:

[[File:E2237_Proj4_2.png]]

<br>

====System Stability: Strategies====
''The source of this issue is currently unknown.'' Therefore, we will pursue the following to debug this:
# Refactoring: We will explore refactoring both the test cases and the controllers (mentioned in section 2.2) to enforce the DRY principle where needed, and comment the code to enhance readability & maintainability
# Test data: Currently, there is an existing issue with the test methodology - testing is all being done using pre-existing, static data. This will be fixed as a result of our work on Object Creation.
<br>
The data flow that we will be working on is shown below:

[[File:Reviewhistory.jpg]]

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

=== Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Student Accounts can be created and are saved to the database.
# Verify that Assignments can be created and are saved to the database.
# Verify that Project Bids can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''
*Student Account
<pre>
Scenario: Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student account with all the necessary fields
Then: Account is saved in the database

Scenario: Duplicate Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts with all the necessary fields
Then: Student already exists message is shown

Scenario: Account Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts without all the necessary fields
Then: Message to input fields is shown
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>
*Project Bids
<pre>
Scenario: Project Bid creation
Given: Logged in as a Student
When: Complete Project Bid for open Project
Then: Project Bid is saved in the database

Scenario: Duplicate Project Bid
Given: Logged in as a Student
When: Click on bid for open Project
Then Message stating already selected shown
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* ''will be added for final submission''

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/1441 Previous team's Expertiza GitHub pull request]

[[E1934 - Grading Audit Trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-07T21:14:48Z

Schatte5: /* System Stability: Strategies */

== Topic Overview & Prior Work ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information regarding this feature.
'''A summary of the desired functionality is presented below:'''

After an instructor assigns a grade to an assignment, there should be a way to track who gave the grade. Any instructor can assign/edit a grade freely; a grading audit trail must be created and the following information needs to be stored:
* When a grade is assigned by an instructor, there must be an indication of the InstructorID and a timestamp of the change.
* Comments previously provided by other instructors must be preserved.
*This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

=== Overview of Major Changes ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb'''). Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''index_html.erb''').

=== Files Involved ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing ===

As per E2158, - ''Functional tests'' ensuring specific method calls are made were added.
<pre>
functional tests added to these files
: spec/controllers/grades_controller_spec.rb
: spec/controllers/review_mapping_controller_spec.rb
: spec/controllers/grading_histories_controller_test.rb
</pre>
Additionally, a ''feature test'' ensuring that correct grading history is shown in chronological order was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
# Running these tests causes failures - in fact, only the Spec files for review_mapping_controller runs.
# As per E2158, running all tests leads to the simulation crashing

== Statement of Problem ==

''There are '''three areas of focus''' for this project:''
=== System Crashes and Object Creation ===

#The work done by the previous team results in the system crashing when the tests are being executed; as a result, automated unit testing does not succeed. Our goal in this regard is to ensure that the tests are successfully executed for all test cases, with the appropriate outcome and coverage reports visible to the user.
#Testing efforts to this point have used static, pre-created objects; this is due to issues with object creation. Our goal in this aspect is to ensure that the creation of new test objects, namely Student Accounts, Assignments, and Project Bids is successful.

=== Changes to Grading History Table ===

The grading history table is earmarked for certain changes:
# Extract Student ID from the table, and ensure that it is shown in the header.
# Extract Assignment ID from the table, and ensure that it is shown in the header

=== Code and Documentation Goals ===

Reasoning and data flow structures/UML diagrams should be added that detail the changes that have been made, as well as any comments on why certain files needed to be modified.
These will be completed from these perspectives:
# From a data flow point of view
# From a function point of view
# With comment in code

== Plan and List of Work Done ==

=== General Design Goals ===
====Changes to the Grading History Table====
The outlined code here is to be removed as these fields are redundant.
We will perform the following to DRY the implementation:

[[File:E2237_Proj4_1.png]]

<br> The data is to be moved to the header, as shown below:

[[File:E2237_Proj4_2.png]]

<br>

====System Stability: Strategies====
''The source of this issue is currently unknown.'' Therefore, we will pursue the following to debug this:
# Refactoring: We will explore refactoring both the test cases and the controllers (mentioned in section 2.2) to enforce the DRY principle where needed, and comment the code to enhance readability & maintainability
# Test data: Currently, there is an existing issue with the test methodology - testing is all being done using pre-existing, static data. This will be fixed as a result of our work on Object Creation.
<br>
The data flow that we will be working on is shown below:
[[File:Reviewhistory.jpg]]

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

=== Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Student Accounts can be created and are saved to the database.
# Verify that Assignments can be created and are saved to the database.
# Verify that Project Bids can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''
*Student Account
<pre>
Scenario: Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student account with all the necessary fields
Then: Account is saved in the database

Scenario: Duplicate Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts with all the necessary fields
Then: Student already exists message is shown

Scenario: Account Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts without all the necessary fields
Then: Message to input fields is shown
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>
*Project Bids
<pre>
Scenario: Project Bid creation
Given: Logged in as a Student
When: Complete Project Bid for open Project
Then: Project Bid is saved in the database

Scenario: Duplicate Project Bid
Given: Logged in as a Student
When: Click on bid for open Project
Then Message stating already selected shown
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* ''will be added for final submission''

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/1441 Previous team's Expertiza GitHub pull request]

[[E1934 - Grading Audit Trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

File:Reviewhistory.jpg

2022-04-07T21:13:28Z

Schatte5:

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-07T20:47:39Z

Schatte5: /* Changes to the Grading History Table */

== Topic Overview & Prior Work ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information regarding this feature.
'''A summary of the desired functionality is presented below:'''

After an instructor assigns a grade to an assignment, there should be a way to track who gave the grade. Any instructor can assign/edit a grade freely; a grading audit trail must be created and the following information needs to be stored:
* When a grade is assigned by an instructor, there must be an indication of the InstructorID and a timestamp of the change.
* Comments previously provided by other instructors must be preserved.
*This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

=== Overview of Major Changes ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb'''). Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''index_html.erb''').

=== Files Involved ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing ===

As per E2158, - ''Functional tests'' ensuring specific method calls are made were added.
<pre>
functional tests added to these files
: spec/controllers/grades_controller_spec.rb
: spec/controllers/review_mapping_controller_spec.rb
: spec/controllers/grading_histories_controller_test.rb
</pre>
Additionally, a ''feature test'' ensuring that correct grading history is shown in chronological order was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
==== Issues with Existing Tests ====
# Running these tests causes failures - in fact, only the Spec files for review_mapping_controller runs.
# As per E2158, running all tests leads to the simulation crashing

== Statement of Problem ==

''There are '''three areas of focus''' for this project:''
=== System Crashes and Object Creation ===

#The work done by the previous team results in the system crashing when the tests are being executed; as a result, automated unit testing does not succeed. Our goal in this regard is to ensure that the tests are successfully executed for all test cases, with the appropriate outcome and coverage reports visible to the user.
#Testing efforts to this point have used static, pre-created objects; this is due to issues with object creation. Our goal in this aspect is to ensure that the creation of new test objects, namely Student Accounts, Assignments, and Project Bids is successful.

=== Changes to Grading History Table ===

The grading history table is earmarked for certain changes:
# Extract Student ID from the table, and ensure that it is shown in the header.
# Extract Assignment ID from the table, and ensure that it is shown in the header

=== Code and Documentation Goals ===

Reasoning and data flow structures/UML diagrams should be added that detail the changes that have been made, as well as any comments on why certain files needed to be modified.
These will be completed from these perspectives:
# From a data flow point of view
# From a function point of view
# With comment in code

== Plan and List of Work Done ==

=== General Design Goals ===
====Changes to the Grading History Table====
The outlined code here is to be removed as these fields are redundant.
We will perform the following to DRY the implementation:

[[File:E2237_Proj4_1.png]]

<br> The data is to be moved to the header, as shown below:

[[File:E2237_Proj4_2.png]]

<br>

====System Stability: Strategies====
''The source of this issue is currently unknown.'' Therefore, we will pursue the following to debug this:
# Refactoring: We will explore refactoring both the test cases and the controllers (mentioned in section 2.2) to enforce the DRY principle where needed, and comment the code to enhance readability & maintainability
# Test data: Currently, there is an existing issue with the test methodology - testing is all being done using pre-existing, static data. This will be fixed as a result of our work on Object Creation.

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

=== Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Student Accounts can be created and are saved to the database.
# Verify that Assignments can be created and are saved to the database.
# Verify that Project Bids can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''
*Student Account
<pre>
Scenario: Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student account with all the necessary fields
Then: Account is saved in the database

Scenario: Duplicate Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts with all the necessary fields
Then: Student already exists message is shown

Scenario: Account Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts without all the necessary fields
Then: Message to input fields is shown
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>
*Project Bids
<pre>
Scenario: Project Bid creation
Given: Logged in as a Student
When: Complete Project Bid for open Project
Then: Project Bid is saved in the database

Scenario: Duplicate Project Bid
Given: Logged in as a Student
When: Click on bid for open Project
Then Message stating already selected shown
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* ''will be added for final submission''

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/1441 Previous team's Expertiza GitHub pull request]

[[E1934 - Grading Audit Trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-06T04:38:17Z

Schatte5: /* Changes to the Grading History Table */

== Topic Overview & Prior Work ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information regarding this feature.
'''A summary of the desired functionality is presented below:'''

After an instructor assigns a grade to an assignment, there should be a way to track who gave the grade. Any instructor can assign/edit a grade freely; a grading audit trail must be created and the following information needs to be stored:
* When a grade is assigned by an instructor, there must be an indication of the InstructorID and a timestamp of the change.
* Comments previously provided by other instructors must be preserved.
*This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

=== Overview of Major Changes ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''index_html.erb''').

=== Files Involved ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing ===

As per E2158, - ''Functional tests'' ensuring specific method calls are made were added.
<pre>
functional tests added to these files
: spec/controllers/grades_controller_spec.rb
: spec/controllers/review_mapping_controller_spec.rb
: spec/controllers/grading_histories_controller_test.rb
</pre>
Additionally, a ''feature test'' ensuring that correct grading history is shown in chronological order was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.
==== Issues with Existing Tests ====
# Running these tests causes failures - in fact, only the Spec files for review_mapping_controller runs.
# As per E2158, running all tests leads to the simulation crashing

== Statement of Problem ==

''There are '''three areas of focus''' for this project:''
=== System Crashes and Object Creation ===

#The work done by the previous team results in the system crashing when the tests are being executed; as a result, automated unit testing does not succeed. Our goal in this regard is to ensure that the tests are successfully executed for all test cases, with the appropriate outcome and coverage reports visible to the user.
#Testing efforts to this point have used static, pre-created objects; this is due to issues with object creation. Our goal in this aspect is to ensure that the creation of new test objects, namely Student Accounts, Assignments, and Project Bids is successful.

=== Changes to Grading History Table ===

The grading history table is earmarked for certain changes:
# Extract Student ID from the table, and ensure that it is shown in the header.
# Extract Assignment ID from the table, and ensure that it is shown in the header

=== Code and Documentation Goals ===

Add reasonings and data flow structures/UML diagrams that detail the changes that have been made, as well as any comments on why certain files needed to be modified.
These will be completed from these perspectives:
# From a data flow point of view
# From a function point of view
# With comment in code

== Plan and List of Work Done ==

=== General Design Goals ===
====Changes to the Grading History Table====
The outlined code here is to be removed in order to remove redundant data from the table

[[File:E2237_Proj4_1.png]]

<br> The data is to be moved to the header, as shown below:

[[File:E2237_Proj4_2.png]]

<br>

====System Stability: Strategies====
''The source of this issue is currently unknown.'' Therefore, we will pursue the following to debug this:
# Refactoring: We will explore refactoring both the test cases and the controllers (mentioned in section 2.2) to enforce the DRY principle where needed, and comment the code to enhance readability & maintainability
# Test data: Currently, there is an existing issue with the test methodology - testing is all being done using pre-existing, static data. This will be fixed as a result of our work on Object Creation.

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

=== Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Student Accounts can be created and are saved to the database.
# Verify that Assignments can be created and are saved to the database.
# Verify that Project Bids can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''
*Student Account
<pre>
Scenario: Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student account with all the necessary fields
Then: Account is saved in the database

Scenario: Duplicate Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts with all the necessary fields
Then: Student already exists message is shown

Scenario: Account Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts without all the necessary fields
Then: Message to input fields is shown
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>
*Project Bids
<pre>
Scenario: Project Bid creation
Given: Logged in as a Student
When: Complete Project Bid for open Project
Then: Project Bid is saved in the database

Scenario: Duplicate Project Bid
Given: Logged in as a Student
When: Click on bid for open Project
Then Message stating already selected shown
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* ''will be added for final submission''

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/1441 Previous team's Expertiza GitHub pull request]

[[E1934 - Grading Audit Trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-06T04:36:27Z

Schatte5: /* Manual UI Tests */

== Topic Overview & Prior Work ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information regarding this feature.
'''A summary of the desired functionality is presented below:'''

After an instructor assigns a grade to an assignment, there should be a way to track who gave the grade. Any instructor can assign/edit a grade freely; a grading audit trail must be created and the following information needs to be stored:
* When a grade is assigned by an instructor, there must be an indication of the InstructorID and a timestamp of the change.
* Comments previously provided by other instructors must be preserved.
*This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

=== Overview of Major Changes ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''index_html.erb''').

=== Files Involved ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing ===

As per E2158, - ''Functional tests'' ensuring specific method calls are made were added.
<pre>
functional tests added to these files
: spec/controllers/grades_controller_spec.rb
: spec/controllers/review_mapping_controller_spec.rb
: spec/controllers/grading_histories_controller_test.rb
</pre>
Additionally, a ''feature test'' ensuring that correct grading history is shown in chronological order was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.
==== Issues with Existing Tests ====
# Running these tests causes failures - in fact, only the Spec files for review_mapping_controller runs.
# As per E2158, running all tests leads to the simulation crashing

== Statement of Problem ==

''There are '''three areas of focus''' for this project:''
=== System Crashes and Object Creation ===

#The work done by the previous team results in the system crashing when the tests are being executed; as a result, automated unit testing does not succeed. Our goal in this regard is to ensure that the tests are successfully executed for all test cases, with the appropriate outcome and coverage reports visible to the user.
#Testing efforts to this point have used static, pre-created objects; this is due to issues with object creation. Our goal in this aspect is to ensure that the creation of new test objects, namely Student Accounts, Assignments, and Project Bids is successful.

=== Changes to Grading History Table ===

The grading history table is earmarked for certain changes:
# Extract Student ID from the table, and ensure that it is shown in the header.
# Extract Assignment ID from the table, and ensure that it is shown in the header

=== Code and Documentation Goals ===

Add reasonings and data flow structures/UML diagrams that detail the changes that have been made, as well as any comments on why certain files needed to be modified.
These will be completed from these perspectives:
# From a data flow point of view
# From a function point of view
# With comment in code

== Plan and List of Work Done ==

=== General Design Goals ===
====Changes to the Grading History Table====
The highlighted code here is to be removed in order to remove redundant data from the table

[[File:E2237_Proj4_1.png]]

<br> The data is to be moved to the header, as shown below:

[[File:E2237_Proj4_2.png]]

<br>
====System Stability: Strategies====
''The source of this issue is currently unknown.'' Therefore, we will pursue the following to debug this:
# Refactoring: We will explore refactoring both the test cases and the controllers (mentioned in section 2.2) to enforce the DRY principle where needed, and comment the code to enhance readability & maintainability
# Test data: Currently, there is an existing issue with the test methodology - testing is all being done using pre-existing, static data. This will be fixed as a result of our work on Object Creation.

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

=== Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Student Accounts can be created and are saved to the database.
# Verify that Assignments can be created and are saved to the database.
# Verify that Project Bids can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''
*Student Account
<pre>
Scenario: Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student account with all the necessary fields
Then: Account is saved in the database

Scenario: Duplicate Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts with all the necessary fields
Then: Student already exists message is shown

Scenario: Account Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts without all the necessary fields
Then: Message to input fields is shown
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>
*Project Bids
<pre>
Scenario: Project Bid creation
Given: Logged in as a Student
When: Complete Project Bid for open Project
Then: Project Bid is saved in the database

Scenario: Duplicate Project Bid
Given: Logged in as a Student
When: Click on bid for open Project
Then Message stating already selected shown
</pre>

=== Manual UI Tests ===
''Note: Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* ''will be added for final submission''

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/1441 Previous team's Expertiza GitHub pull request]

[[E1934 - Grading Audit Trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-06T04:36:12Z

Schatte5: /* Comprehensive Testing and Scope */

== Topic Overview & Prior Work ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information regarding this feature.
'''A summary of the desired functionality is presented below:'''

After an instructor assigns a grade to an assignment, there should be a way to track who gave the grade. Any instructor can assign/edit a grade freely; a grading audit trail must be created and the following information needs to be stored:
* When a grade is assigned by an instructor, there must be an indication of the InstructorID and a timestamp of the change.
* Comments previously provided by other instructors must be preserved.
*This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

=== Overview of Major Changes ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''index_html.erb''').

=== Files Involved ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing ===

As per E2158, - ''Functional tests'' ensuring specific method calls are made were added.
<pre>
functional tests added to these files
: spec/controllers/grades_controller_spec.rb
: spec/controllers/review_mapping_controller_spec.rb
: spec/controllers/grading_histories_controller_test.rb
</pre>
Additionally, a ''feature test'' ensuring that correct grading history is shown in chronological order was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.
==== Issues with Existing Tests ====
# Running these tests causes failures - in fact, only the Spec files for review_mapping_controller runs.
# As per E2158, running all tests leads to the simulation crashing

== Statement of Problem ==

''There are '''three areas of focus''' for this project:''
=== System Crashes and Object Creation ===

#The work done by the previous team results in the system crashing when the tests are being executed; as a result, automated unit testing does not succeed. Our goal in this regard is to ensure that the tests are successfully executed for all test cases, with the appropriate outcome and coverage reports visible to the user.
#Testing efforts to this point have used static, pre-created objects; this is due to issues with object creation. Our goal in this aspect is to ensure that the creation of new test objects, namely Student Accounts, Assignments, and Project Bids is successful.

=== Changes to Grading History Table ===

The grading history table is earmarked for certain changes:
# Extract Student ID from the table, and ensure that it is shown in the header.
# Extract Assignment ID from the table, and ensure that it is shown in the header

=== Code and Documentation Goals ===

Add reasonings and data flow structures/UML diagrams that detail the changes that have been made, as well as any comments on why certain files needed to be modified.
These will be completed from these perspectives:
# From a data flow point of view
# From a function point of view
# With comment in code

== Plan and List of Work Done ==

=== General Design Goals ===
====Changes to the Grading History Table====
The highlighted code here is to be removed in order to remove redundant data from the table

[[File:E2237_Proj4_1.png]]

<br> The data is to be moved to the header, as shown below:

[[File:E2237_Proj4_2.png]]

<br>
====System Stability: Strategies====
''The source of this issue is currently unknown.'' Therefore, we will pursue the following to debug this:
# Refactoring: We will explore refactoring both the test cases and the controllers (mentioned in section 2.2) to enforce the DRY principle where needed, and comment the code to enhance readability & maintainability
# Test data: Currently, there is an existing issue with the test methodology - testing is all being done using pre-existing, static data. This will be fixed as a result of our work on Object Creation.

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

=== Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Student Accounts can be created and are saved to the database.
# Verify that Assignments can be created and are saved to the database.
# Verify that Project Bids can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''
*Student Account
<pre>
Scenario: Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student account with all the necessary fields
Then: Account is saved in the database

Scenario: Duplicate Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts with all the necessary fields
Then: Student already exists message is shown

Scenario: Account Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts without all the necessary fields
Then: Message to input fields is shown
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>
*Project Bids
<pre>
Scenario: Project Bid creation
Given: Logged in as a Student
When: Complete Project Bid for open Project
Then: Project Bid is saved in the database

Scenario: Duplicate Project Bid
Given: Logged in as a Student
When: Click on bid for open Project
Then Message stating already selected shown
</pre>

=== Manual UI Tests ===
''Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.
* ''will be added for final submission''

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/1441 Previous team's Expertiza GitHub pull request]

[[E1934 - Grading Audit Trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-06T04:35:52Z

Schatte5: /* Thoughts on Comprehensive Testing and Scope */

== Topic Overview & Prior Work ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information regarding this feature.
'''A summary of the desired functionality is presented below:'''

After an instructor assigns a grade to an assignment, there should be a way to track who gave the grade. Any instructor can assign/edit a grade freely; a grading audit trail must be created and the following information needs to be stored:
* When a grade is assigned by an instructor, there must be an indication of the InstructorID and a timestamp of the change.
* Comments previously provided by other instructors must be preserved.
*This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

=== Overview of Major Changes ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''index_html.erb''').

=== Files Involved ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing ===

As per E2158, - ''Functional tests'' ensuring specific method calls are made were added.
<pre>
functional tests added to these files
: spec/controllers/grades_controller_spec.rb
: spec/controllers/review_mapping_controller_spec.rb
: spec/controllers/grading_histories_controller_test.rb
</pre>
Additionally, a ''feature test'' ensuring that correct grading history is shown in chronological order was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.
==== Issues with Existing Tests ====
# Running these tests causes failures - in fact, only the Spec files for review_mapping_controller runs.
# As per E2158, running all tests leads to the simulation crashing

== Statement of Problem ==

''There are '''three areas of focus''' for this project:''
=== System Crashes and Object Creation ===

#The work done by the previous team results in the system crashing when the tests are being executed; as a result, automated unit testing does not succeed. Our goal in this regard is to ensure that the tests are successfully executed for all test cases, with the appropriate outcome and coverage reports visible to the user.
#Testing efforts to this point have used static, pre-created objects; this is due to issues with object creation. Our goal in this aspect is to ensure that the creation of new test objects, namely Student Accounts, Assignments, and Project Bids is successful.

=== Changes to Grading History Table ===

The grading history table is earmarked for certain changes:
# Extract Student ID from the table, and ensure that it is shown in the header.
# Extract Assignment ID from the table, and ensure that it is shown in the header

=== Code and Documentation Goals ===

Add reasonings and data flow structures/UML diagrams that detail the changes that have been made, as well as any comments on why certain files needed to be modified.
These will be completed from these perspectives:
# From a data flow point of view
# From a function point of view
# With comment in code

== Plan and List of Work Done ==

=== General Design Goals ===
====Changes to the Grading History Table====
The highlighted code here is to be removed in order to remove redundant data from the table

[[File:E2237_Proj4_1.png]]

<br> The data is to be moved to the header, as shown below:

[[File:E2237_Proj4_2.png]]

<br>
====System Stability: Strategies====
''The source of this issue is currently unknown.'' Therefore, we will pursue the following to debug this:
# Refactoring: We will explore refactoring both the test cases and the controllers (mentioned in section 2.2) to enforce the DRY principle where needed, and comment the code to enhance readability & maintainability
# Test data: Currently, there is an existing issue with the test methodology - testing is all being done using pre-existing, static data. This will be fixed as a result of our work on Object Creation.

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

=== Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Student Accounts can be created and are saved to the database.
# Verify that Assignments can be created and are saved to the database.
# Verify that Project Bids can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''
*Student Account
<pre>
Scenario: Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student account with all the necessary fields
Then: Account is saved in the database

Scenario: Duplicate Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts with all the necessary fields
Then: Student already exists message is shown

Scenario: Account Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts without all the necessary fields
Then: Message to input fields is shown
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>
*Project Bids
<pre>
Scenario: Project Bid creation
Given: Logged in as a Student
When: Complete Project Bid for open Project
Then: Project Bid is saved in the database

Scenario: Duplicate Project Bid
Given: Logged in as a Student
When: Click on bid for open Project
Then Message stating already selected shown
</pre>

=== Manual UI Tests ===
''Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage.

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/1441 Previous team's Expertiza GitHub pull request]

[[E1934 - Grading Audit Trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')

CSC/ECE 517 Spring 2022 - E2237: Grading audit trail

2022-04-06T04:35:18Z

Schatte5: /* Thoughts on Comprehensive Testing and Scope */

== Topic Overview & Prior Work ==
=== Feature Overview ===

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail E2158] contains detailed information regarding this feature.
'''A summary of the desired functionality is presented below:'''

After an instructor assigns a grade to an assignment, there should be a way to track who gave the grade. Any instructor can assign/edit a grade freely; a grading audit trail must be created and the following information needs to be stored:
* When a grade is assigned by an instructor, there must be an indication of the InstructorID and a timestamp of the change.
* Comments previously provided by other instructors must be preserved.
*This information needs to be stored every time an instructor edits a grade/comment and clicks the save button.

=== Overview of Major Changes ===

*A new table was added to the database ('''grading_history'''), along with the corresponding model ('''grading_history.rb''') and controller ('''grading_history_controller.rb''').

*Two models for specific types of histories were added: '''review_grading_history.rb''', and '''submission_grading_history.rb'''.

*A view for displaying the grading history of a particular assignment or review was added ('''index_html.erb''').

=== Files Involved ===
* \app\controllers\grades_controller.rb
* \app\controllers\grading_histories_controller.rb
* \app\controllers\review_mapping_controller.rb
* \app\helpers\grading_histories_helper.rb
* \app\models\grading_history.rb
* \app\models\review_grading_history.rb
* \app\models\submission_grading_history.rb
* \app\views\assignments\list_submissions.html.erb
* \app\views\grading_histories\index.html.erb
* \app\views\reports\_review_report.html.erb
* \config\routes.rb
* \app\views\assignments\list_submissions.html.erb

=== Testing ===

As per E2158, - ''Functional tests'' ensuring specific method calls are made were added.
<pre>
functional tests added to these files
: spec/controllers/grades_controller_spec.rb
: spec/controllers/review_mapping_controller_spec.rb
: spec/controllers/grading_histories_controller_test.rb
</pre>
Additionally, a ''feature test'' ensuring that correct grading history is shown in chronological order was added.
<pre>
feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb
</pre>
Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.
==== Issues with Existing Tests ====
# Running these tests causes failures - in fact, only the Spec files for review_mapping_controller runs.
# As per E2158, running all tests leads to the simulation crashing

== Statement of Problem ==

''There are '''three areas of focus''' for this project:''
=== System Crashes and Object Creation ===

#The work done by the previous team results in the system crashing when the tests are being executed; as a result, automated unit testing does not succeed. Our goal in this regard is to ensure that the tests are successfully executed for all test cases, with the appropriate outcome and coverage reports visible to the user.
#Testing efforts to this point have used static, pre-created objects; this is due to issues with object creation. Our goal in this aspect is to ensure that the creation of new test objects, namely Student Accounts, Assignments, and Project Bids is successful.

=== Changes to Grading History Table ===

The grading history table is earmarked for certain changes:
# Extract Student ID from the table, and ensure that it is shown in the header.
# Extract Assignment ID from the table, and ensure that it is shown in the header

=== Code and Documentation Goals ===

Add reasonings and data flow structures/UML diagrams that detail the changes that have been made, as well as any comments on why certain files needed to be modified.
These will be completed from these perspectives:
# From a data flow point of view
# From a function point of view
# With comment in code

== Plan and List of Work Done ==

=== General Design Goals ===
====Changes to the Grading History Table====
The highlighted code here is to be removed in order to remove redundant data from the table

[[File:E2237_Proj4_1.png]]

<br> The data is to be moved to the header, as shown below:

[[File:E2237_Proj4_2.png]]

<br>
====System Stability: Strategies====
''The source of this issue is currently unknown.'' Therefore, we will pursue the following to debug this:
# Refactoring: We will explore refactoring both the test cases and the controllers (mentioned in section 2.2) to enforce the DRY principle where needed, and comment the code to enhance readability & maintainability
# Test data: Currently, there is an existing issue with the test methodology - testing is all being done using pre-existing, static data. This will be fixed as a result of our work on Object Creation.

====Documentation====
# Changes to any files will be documented on this page; the programmatical reasoning behind the changes shall be explained, and will be in accordance with the DRY principle.
# Any changes to the overall program logic and data flow will be illustrated with UML diagrams in this document, along with the reasoning for any such changes.
# A pull request of the fixed code, fully commented, will be provided in this document.

=== Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
''will be added for the final submission''

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
# Verify that Student Accounts can be created and are saved to the database.
# Verify that Assignments can be created and are saved to the database.
# Verify that Project Bids can be created and are saved to the database.
# Ensure that Student ID is shown in the header, and verify via manual UI testing
# Ensure that Assignment ID is shown in the header, and verify via manual UI testing
# Finally, verify that tests can be run without crashing the system.

=== RSpec Unit Tests ===
'''''Test cases provided here, will add RSpec code blocks for the final submission'''''
*Student Account
<pre>
Scenario: Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student account with all the necessary fields
Then: Account is saved in the database

Scenario: Duplicate Account Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts with all the necessary fields
Then: Student already exists message is shown

Scenario: Account Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create student accounts without all the necessary fields
Then: Message to input fields is shown
</pre>

*Assignments
<pre>
Scenario: Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment is saved in the database

Scenario: Duplicate Assignment Creation with all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment with all the necessary fields
Then: Assignment already exists message is shown

Scenario: Assignment Creation without all fields
Given: Logged in as an Instructor/Admin
When: Create Assignment without all the necessary fields
Then: Message to input fields is shown
</pre>
*Project Bids
<pre>
Scenario: Project Bid creation
Given: Logged in as a Student
When: Complete Project Bid for open Project
Then: Project Bid is saved in the database

Scenario: Duplicate Project Bid
Given: Logged in as a Student
When: Click on bid for open Project
Then Message stating already selected shown
</pre>

=== Manual UI Tests ===
''Discussion with mentor in progress to determine if UI Automation testing is in scope ''
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

*Assignment ID in header
<pre>
Scenario: Assignment ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Assignment ID appears in the header, not in any table columns
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that ''
''old test cases still pass.''

# Get the specific format requirement for the title, and assert that it's there. Ensure that this doesn't appear anywhere else (possible via ensuring count is 1)
# Procure specific required column width, and assert that this is the value in the file (the constant)

== Conclusions and Future Work ==
=== Thoughts on Comprehensive Testing and Scope ===
* '''Initial Thoughts:''' Current code coverage cannot be determined due to a combination of missing tests and simulation crashes. This will need to be fixed to enable monitoring of regular metrics, and adding comprehensive tests that target full code coverage. The extent of this project's responsibilities in either situation must be established for the final submission.

=== Conclusion ===
''will be added for final submission''

== Useful Links ==
[https://github.com/expertiza/expertiza/pull/1441 Previous team's Expertiza GitHub pull request]

[[E1934 - Grading Audit Trail|Previous team's wiki write-up]]

[https://www.youtube.com/watch?v=yyxX_kRYxLc E1934 implementation video walkthrough]

== Contributors ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')
=== Mentor ===
*Kai Xiao (''yxiao28'')