Expertiza_Wiki - User contributions [en]

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

2022-04-26T03:53:43Z

Kflemin3: /* Implementation */ change size of screenshot

== 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:

[[File:Reviewhistory.jpg|270px]]
[[File:Review scores imported.png|560px]] 

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]]

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

[[File:E2237_Proj4_2.png]]

 

'''Behavior Driven Development''' 
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. 
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] 
[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:52:44Z

Kflemin3: /* 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:

[[File:Reviewhistory.jpg|270px]]
[[File:Review scores imported.png|560px]] 

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]]

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

[[File:E2237_Proj4_2.png]]

 

'''Behavior Driven Development''' 
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. 
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]]

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

[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'')

File:Submission Grading History Table.jpeg

2022-04-26T03:52:05Z

Kflemin3:

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

2022-04-11T04:19:33Z

Kflemin3: attempt to simplify and clarify write-up; fixes one Useful Link

== 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.

----

The ''data flow'' for the grading history feature is shown below:

[[File:Reviewhistory.jpg]]

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

The ER table of review_scores is shown below:

[[File:Review scores imported.png]]

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

[[File:GradingHistory.png]]

=== 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]]

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

[[File:E2237_Proj4_2.png]]

 

====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-06T03:07:41Z

Kflemin3: add second photo of work to be done

== Team ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')

=== Mentor ===
*Kai Xiao (''yxiao28'')

== Topic Overview & Prior Work ==

The [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail previous team's work] 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:
 1. When a grade is assigned by an instructor, there must be an indication of the InstructorID and a timestamp of the change.
 2. 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 (NOTE: should probably remove this from here) ===

''Functional tests'' ensuring specific method calls are made were added.

;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

A ''feature test'' ensuring that correct grading history is shown in chronological order was added.

;feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.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.

== Statement of Problem ==
''There are three areas of focus for this project:''
=== System Crashes and Object Creation ===

First, 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.

Second, 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:
 a. Extract Student ID from the table, and ensure that it is shown in the header
 b. 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:
 a. From a data flow point of view
 b. From a function point of view
 c. With comment in code

== Plan and List of Work Done ==

=== General Design Goals ===
* '''''Changes to the Grading History Table: the following lines are required to be modified to complete this objective:'''''
The highlighted code here is to be removed in order to remove redundant data from the table

[[File:E2237_Proj4_1.png]]

 The data is to be moved to the header, as shown below:

[[File:E2237_Proj4_2.png]]

=== Specific Tasks Completed ===

== Initial Implementation ==

== Final Implementation ==

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
1. Verify that Student Accounts can be created and are saved to the database.
2. Verify that Assignments can be created and are saved to the database.
3. Verify that Project Bids can be created and are saved to the database.
4. Ensure that Student ID is shown in the header via RSpec, and verify via manual UI testing
5. Ensure that Assignment ID is shown in the header via RSpec, and verify via manual UI testing

=== General Testing Plan ===
=== RSpec Unit Tests ===
=== Manual UI Tests ===
''Discussion with mentor in progress to determine if UI Automation testing is in scope ''
=== Regression Testing ===
'''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project was done.'''

''Note to team: need to edit this after investigation''

 1. Investigate if this is testable using Capybara
 2. 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)
 3. Procure specific required column width, and assert that this is the value in the file (the constant)
 4. Inquire with mentor about comment requirement and conflicts
 5. Inquire with mentor regarding white space constraints
 6. Inquire why the revert is needed, what is breaking and why
 7. Ask mentor where this file is being called, and if functionality needs to be moved elsewhere.
 8. Complete Design Document to reflect these changes.

== Conclusions and Future Work ==
=== Thoughts on Comprehensive Testing and Scope ===
=== Test Plan Document (SoP) ===
=== Conclusion ===

== 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]

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

2022-04-06T03:07:01Z

Kflemin3: add first photo of work to be done

== Team ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')

=== Mentor ===
*Kai Xiao (''yxiao28'')

== Topic Overview & Prior Work ==

The [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail previous team's work] 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:
 1. When a grade is assigned by an instructor, there must be an indication of the InstructorID and a timestamp of the change.
 2. 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 (NOTE: should probably remove this from here) ===

''Functional tests'' ensuring specific method calls are made were added.

;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

A ''feature test'' ensuring that correct grading history is shown in chronological order was added.

;feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.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.

== Statement of Problem ==
''There are three areas of focus for this project:''
=== System Crashes and Object Creation ===

First, 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.

Second, 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:
 a. Extract Student ID from the table, and ensure that it is shown in the header
 b. 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:
 a. From a data flow point of view
 b. From a function point of view
 c. With comment in code

== Plan and List of Work Done ==

=== General Design Goals ===
* '''''Changes to the Grading History Table: the following lines are required to be modified to complete this objective:'''''
The highlighted code here is to be removed in order to remove redundant data from the table

[[File:E2237_Proj4_1.png]]

 The data is to be moved to the header, as shown below:

=== Specific Tasks Completed ===

== Initial Implementation ==

== Final Implementation ==

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
1. Verify that Student Accounts can be created and are saved to the database.
2. Verify that Assignments can be created and are saved to the database.
3. Verify that Project Bids can be created and are saved to the database.
4. Ensure that Student ID is shown in the header via RSpec, and verify via manual UI testing
5. Ensure that Assignment ID is shown in the header via RSpec, and verify via manual UI testing

=== General Testing Plan ===
=== RSpec Unit Tests ===
=== Manual UI Tests ===
''Discussion with mentor in progress to determine if UI Automation testing is in scope ''
=== Regression Testing ===
'''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project was done.'''

''Note to team: need to edit this after investigation''

 1. Investigate if this is testable using Capybara
 2. 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)
 3. Procure specific required column width, and assert that this is the value in the file (the constant)
 4. Inquire with mentor about comment requirement and conflicts
 5. Inquire with mentor regarding white space constraints
 6. Inquire why the revert is needed, what is breaking and why
 7. Ask mentor where this file is being called, and if functionality needs to be moved elsewhere.
 8. Complete Design Document to reflect these changes.

== Conclusions and Future Work ==
=== Thoughts on Comprehensive Testing and Scope ===
=== Test Plan Document (SoP) ===
=== Conclusion ===

== 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]

File:E2237 Proj4 2.png

2022-04-06T03:04:39Z

Kflemin3:

File:E2237 Proj4 1.png

2022-04-06T03:04:01Z

Kflemin3:

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

2022-04-06T01:14:49Z

Kflemin3: fix a missing heading

== Team ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')

=== Mentor ===
*Kai Xiao (''yxiao28'')

== Topic Overview ==

=== Prior Work ===

You can read the entirety of the [[E1934 - Grading Audit Trail|previous team's wiki write-up]] if desired.

==== 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''').

==== Modifications to Existing Files ====

;app/controllers/grades_controller.rb
: A grading history record is created for every edit to a submission's grade.
;app/controllers/review_mapping_controller.rb
: A grading history record is created for every edit to a review's grade.
;app/views/assignments/list_submissions.html.erb
: A link to access a submission's grade history is shown in the submissions table.
;app/views/reports/_review_report.html.erb
: A link to access a review's grade history is shown in the review report table.

==== Testing (NOTE: should probably remove this from here) ====

''Functional tests'' ensuring specific method calls are made were added.

;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

A ''feature test'' ensuring that correct grading history is shown in chronological order was added.

;feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.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.

=== Statement of Problem ===

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

== Plan and List of Work Done ==

=== General Design Goals ===
=== Specific Tasks Completed ===

== Initial Implementation ==

== Final Implementation ==

== Testing ==
=== Video Demonstration ===
=== Testing Goals and Test Objects ===
=== General Testing Plan ===
=== RSpec Unit Tests ===
=== Manual UI Tests ===
''Discussion with mentor in progress to determine if UI Automation testing is in scope ''
=== Regression Testing ===
'''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project was done.'''

''Note to team: need to edit this after investigation''

 1. Investigate if this is testable using Capybara
 2. 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)
 3. Procure specific required column width, and assert that this is the value in the file (the constant)
 4. Inquire with mentor about comment requirement and conflicts
 5. Inquire with mentor regarding white space constraints
 6. Inquire why the revert is needed, what is breaking and why
 7. Ask mentor where this file is being called, and if functionality needs to be moved elsewhere.
 8. Complete Design Document to reflect these changes.

== Conclusions and Future Work ==
=== Thoughts on Comprehensive Testing and Scope ===
=== Test Plan Document (SoP) ===
=== Conclusion ===

== 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]

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

2022-04-01T00:36:07Z

Kflemin3: /* Problem Statement */

== Team ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')

=== Mentor ===
*Kai Xiao (''yxiao28'')

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

== Summary of Previous Team's Work ==

You can read the entirety of the [[E1934 - Grading Audit Trail|previous team's wiki write-up]] if desired.

=== 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''').

Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

=== Modifications to Existing Files ===

;app/controllers/grades_controller.rb
: A grading history record is created for every edit to a submission's grade.
;app/controllers/review_mapping_controller.rb
: A grading history record is created for every edit to a review's grade.
;app/views/assignments/list_submissions.html.erb
: A link to access a submission's grade history is shown in the submissions table.
;app/views/reports/_review_report.html.erb
: A link to access a review's grade history is shown in the review report table.

=== Testing ===

''Functional tests'' ensuring specific method calls are made were added.

;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

A ''feature test'' ensuring that correct grading history is shown in chronological order was added.

;feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb

== Our Team's Design Proposal ==

== Test Plan ==
(in progress)
1. Investigate if this is testable using Capybara
2. 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)
3. Procure specific required column width, and assert that this is the value in the file (the constant)
4. Inquire with mentor about comment requirement and conflicts
5. Inquire with mentor regarding white space constraints
6. Inquire why the revert is needed, what is breaking and why
7.

== 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 Previous team's implementation video walkthrough]

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

2022-04-01T00:08:54Z

Kflemin3: /* Problem Statement */

== Team ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')

=== Mentor ===
*Kai Xiao (''yxiao28'')

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

== Summary of Previous Team's Work ==

You can read the entirety of the [[E1934 - Grading Audit Trail|previous team's wiki write-up]] if desired.

=== 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''').

Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

=== Modifications to Existing Files ===

;app/controllers/grades_controller.rb
: A grading history record is created for every edit to a submission's grade.
;app/controllers/review_mapping_controller.rb
: A grading history record is created for every edit to a review's grade.
;app/views/assignments/list_submissions.html.erb
: A link to access a submission's grade history is shown in the submissions table.
;app/views/reports/_review_report.html.erb
: A link to access a review's grade history is shown in the review report table.

=== Testing ===

''Functional tests'' ensuring specific method calls are made were added.

;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

A ''feature test'' ensuring that correct grading history is shown in chronological order was added.

;feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb

== Our Team's Design Proposal ==

== Test Plan ==

== 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 Previous team's implementation video walkthrough]

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

2022-03-31T23:59:01Z

Kflemin3: /* Problem Statement */

== Team ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')

=== Mentor ===
*Kai Xiao (''yxiao28'')

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

== Summary of Previous Team's Work ==

You can read the entirety of the [[E1934 - Grading Audit Trail|previous team's wiki write-up]] if desired.

=== 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''').

Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

=== Modifications to Existing Files ===

;app/controllers/grades_controller.rb
: A grading history record is created for every edit to a submission's grade.
;app/controllers/review_mapping_controller.rb
: A grading history record is created for every edit to a review's grade.
;app/views/assignments/list_submissions.html.erb
: A link to access a submission's grade history is shown in the submissions table.
;app/views/reports/_review_report.html.erb
: A link to access a review's grade history is shown in the review report table.

=== Testing ===

''Functional tests'' ensuring specific method calls are made were added.

;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

A ''feature test'' ensuring that correct grading history is shown in chronological order was added.

;feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb

== Our Team's Design Proposal ==

== 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 Previous team's implementation video walkthrough]

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

2022-03-31T23:31:22Z

Kflemin3: /* Summary of Previous Team's Work */

== Team ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')

=== Mentor ===
*Kai Xiao (''yxiao28'')

== Problem Statement ==

== Summary of Previous Team's Work ==

You can read the entirety of the [[E1934 - Grading Audit Trail|previous team's wiki write-up]] if desired.

=== 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''').

Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

=== Modifications to Existing Files ===

;app/controllers/grades_controller.rb
: A grading history record is created for every edit to a submission's grade.
;app/controllers/review_mapping_controller.rb
: A grading history record is created for every edit to a review's grade.
;app/views/assignments/list_submissions.html.erb
: A link to access a submission's grade history is shown in the submissions table.
;app/views/reports/_review_report.html.erb
: A link to access a review's grade history is shown in the review report table.

=== Testing ===

''Functional tests'' ensuring specific method calls are made were added.

;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

A ''feature test'' ensuring that correct grading history is shown in chronological order was added.

;feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb

== Our Team's Design Proposal ==

== 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 Previous team's implementation video walkthrough]

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

2022-03-31T23:30:43Z

Kflemin3: /* Modifications to Existing Files */

== Team ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')

=== Mentor ===
*Kai Xiao (''yxiao28'')

== Problem Statement ==

== Summary of Previous Team's Work ==

You can read the entirety of [[E1934 - Grading Audit Trail|previous team's wiki write-up]] if desired.

=== 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''').

Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

=== Modifications to Existing Files ===

;app/controllers/grades_controller.rb
: A grading history record is created for every edit to a submission's grade.
;app/controllers/review_mapping_controller.rb
: A grading history record is created for every edit to a review's grade.
;app/views/assignments/list_submissions.html.erb
: A link to access a submission's grade history is shown in the submissions table.
;app/views/reports/_review_report.html.erb
: A link to access a review's grade history is shown in the review report table.

=== Testing ===

''Functional tests'' ensuring specific method calls are made were added.

;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

A ''feature test'' ensuring that correct grading history is shown in chronological order was added.

;feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb

== Our Team's Design Proposal ==

== 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 Previous team's implementation video walkthrough]

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

2022-03-31T23:18:25Z

Kflemin3: /* Summary of Previous Team's Work */

== Team ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')

=== Mentor ===
*Kai Xiao (''yxiao28'')

== Problem Statement ==

== Summary of Previous Team's Work ==

You can read the entirety of [[E1934 - Grading Audit Trail|previous team's wiki write-up]] if desired.

=== 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''').

Whenever an instructor submits a new grade, or edits an existing grade, the '''grading_history_controller''' saves a new history entry to the database.

=== Modifications to Existing Files ===

=== Testing ===

''Functional tests'' ensuring specific method calls are made were added.

;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

A ''feature test'' ensuring that correct grading history is shown in chronological order was added.

;feature test handled by these two files
: spec/features/grade_histories_spec.rb
: spec/features/helpers/grade_histories_helper.rb

== Our Team's Design Proposal ==

== 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 Previous team's implementation video walkthrough]

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

2022-03-31T22:19:58Z

Kflemin3: /* Useful Links */

== Team ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')

=== Mentor ===
*Kai Xiao (''yxiao28'')

== Problem Statement ==

== Summary of Previous Team's Work ==

You can read the entirety of [[E1934 - Grading Audit Trail|previous team's wiki write-up]] if desired.

=== MVC Changes ===

=== Testing ===

== Our Team's Design Proposal ==

== 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 Previous team's implementation video walkthrough]

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

2022-03-31T22:15:26Z

Kflemin3: /* Mentor */ add bullet point for consistency

== Team ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')

=== Mentor ===
*Kai Xiao (''yxiao28'')

== Problem Statement ==

== Summary of Previous Team's Work ==

You can read the entirety of [[E1934 - Grading Audit Trail|previous team's wiki write-up]] if desired.

=== MVC Changes ===

=== Testing ===

== Our Team's Design Proposal ==

== Useful Links ==

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

2022-03-31T22:15:06Z

Kflemin3: /* Mentor */ add team mentor

== Team ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')

=== Mentor ===
Kai Xiao (''yxiao28'')

== Problem Statement ==

== Summary of Previous Team's Work ==

You can read the entirety of [[E1934 - Grading Audit Trail|previous team's wiki write-up]] if desired.

=== MVC Changes ===

=== Testing ===

== Our Team's Design Proposal ==

== Useful Links ==

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

2022-03-31T22:14:23Z

Kflemin3: /* Students */ add student team members

== Team ==
=== Students ===
*Bhuwan Bhatt (''brbhatt'')
*Soumyadeep Chatterjee (''schatte5'')
*Kelly Fleming (''kflemin3'')
*Karthik Gopala Sundaresan (''kgopala3'')

=== Mentor ===

== Problem Statement ==

== Summary of Previous Team's Work ==

You can read the entirety of [[E1934 - Grading Audit Trail|previous team's wiki write-up]] if desired.

=== MVC Changes ===

=== Testing ===

== Our Team's Design Proposal ==

== Useful Links ==

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

2022-03-31T22:10:08Z

Kflemin3: /* Summary of Previous Team's Work */ add link to relevant wiki page

== Team ==
=== Students ===
=== Mentor ===

== Problem Statement ==

== Summary of Previous Team's Work ==

You can read the entirety of [[E1934 - Grading Audit Trail|previous team's wiki write-up]] if desired.

=== MVC Changes ===

=== Testing ===

== Our Team's Design Proposal ==

== Useful Links ==

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

2022-03-31T22:08:50Z

Kflemin3: heading skeleton

== Team ==
=== Students ===
=== Mentor ===

== Problem Statement ==

== Summary of Previous Team's Work ==

=== MVC Changes ===

=== Testing ===

== Our Team's Design Proposal ==

== Useful Links ==

CSC/ECE 517 Spring 2022

2022-03-31T21:56:03Z

Kflemin3: add E2237 to list of final projects for spring 2022 semester

== OSS Projects ==

* [[CSC/ECE 517 Spring 2022 - E2200: Testing advice_controller]]
* [[CSC/ECE 517 Spring 2022 - E2203: Adding tests for courses_controller, eula_controller]]
* [[CSC/ECE 517 Spring 2022 - E2204: Adding tests for markup_styles_controller, lock_controller]]
* [[CSC/ECE 517 Spring 2022 - E2208: Testing for submission_records_controller, profile_controller]]
* [[CSC/ECE 517 Spring 2022 - E2218: Refactor response_controller]]
* [[CSC/ECE 517 Spring 2022 - E2217: Refactor questionnaires_controller]]
* [[CSC/ECE 517 Spring 2022 - E2216: Refactor late_policies_controller]]
* [[CSC/ECE 517 Spring 2022 - E2215: Refactor student_quizzes_controller]]
* [[CSC/ECE 517 Spring 2022 - E2214: Refactor teams_controller]]
* [[CSC/ECE 517 Spring 2022 - E2219: Improve assessment360_controller.rb]]
* [[CSC/ECE 517 Spring 2022 - E2211: Testing for summary_helper]]
* [[CSC/ECE 517 Spring 2022 - E2225: Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2022 - E2221: Refactor submitted content controller.rb]]
* [[CSC/ECE 517 Spring 2022 - E2206: Testing for users_controller]]
* [[CSC/ECE 517 Spring 2022 - E2207: Testing for submitted_content_controller.rb]]
* [[CSC/ECE 517 Spring 2022 - E2205: Testing for participants_controller, versions_controller]]
* [[CSC/ECE 517 Spring 2022 - E2212: Testing for hamer.rb]]
* [[CSC/ECE 517 Spring 2022 - S2200: Refactoring evaluation of SQL queries (Java/JUnit)]]
* [[CSC/ECE 517 Spring 2022 - S2222: Refactor impersonate_controller]]
* [[CSC/ECE 517 Spring 2022 - E2202- Testing for badges_controller, publishing_controller]]
*[[CSC/ECE 517 Spring 2022 - E2220: Refactor reputation_web_service_controller]]
* [[CSC/ECE 517 Spring 2022 - E2224: Refactor review_mapping_controller]]
* [[CSC/ECE 517 Spring 2022 - E2209: Testing for analytic helper.rb, join team requests helper.rb]]
* [[CSC/ECE 517 Spring 2022 - E2227: SQL Injection Fix]]
* [[CSC/ECE 517 Spring 2022 - E2223. Refactor sign up sheet controller.rb]]
* [[CSC/ECE 517 Spring 2022 - E2201: Testing for assignment_questionnaire_controller.rb]]
* [[CSC/ECE 517 Spring 2022 - E2243. Refactor student_teams functionality]]

== Final Projects ==
* [[CSC/ECE 517 Spring 2022 - E2241: Heatgrid fixes and improvements]]
* [[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail]]

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

2022-03-31T21:54:36Z

Kflemin3: create project page

== Under Construction ==

User:Kflemin3

2022-03-31T21:53:44Z

Kflemin3: make links nice

Spring 2022 CSC 517 student

worked on [[CSC/ECE_517_Spring_2022_-_E2214:_Refactor_teams_controller|E2214. Refactor teams controller]]

worked on [[CSC/ECE_517_Spring_2022_-_E2237:_Grading_audit_trail|E2237. Grading audit trail]]

feel free to contact me at '''kflemin3@ncsu.edu''' with questions about those topics

User:Kflemin3

2022-03-31T21:45:56Z

Kflemin3: create kflemin3 user page

Spring 2022 CSC 517 student

worked on [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2022_-_E2214:_Refactor_teams_controller E2214 Refactor teams_controller.rb]

worked on [http://www.example.com E2237 Grading audit trail]

you can contact me at '''kflemin3@ncsu.edu''' with questions about those topics

CSC/ECE 517 Spring 2022 - E2214: Refactor teams controller

2022-03-20T22:34:59Z

Kflemin3: /* Scope for future improvement */ fixes typo

This wiki page is for the description of changes made under E2214 OSS assignment for Spring 2022, CSC/ECE 517.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:

Instructor Login: username -> instructor6, password -> password

== Expertiza Background==

Expertiza is an educational web application created and maintained by the joint efforts of the students and the faculty at NCSU. It’s an open-source project developed on the Ruby on Rails platform and its code is available on Github. It allows students to review each other’s work and improve their work upon this feedback.

== Description of the current project ==

The following is an Expertiza based OSS project which deals primarily with the models, views, and controllers of Teams. Core to any online learning platform is the ability of students and instructors to create and delete teams. Teams_Controller primarily handles the creation, deletion, and other behaviors of course teams and assignment teams. Most of its methods are called from the instructor’s point of view in expertiza. This controller has some problems that violate some essential Rails design principles. There are a few methods in this controller that should have been in model classes. Some methods share code, which creates code repetition. Our project primarily focuses on refactoring some complex methods that involve high branching, removing redundant and dead code, modularising common functionalities, and condensing the existing bad code into a few lines to achieve the same functionality. The goal of this project is to attempt to make this part of the application easier to read and maintain.

== Files modified in current project ==

Controller, model and views were modified for this project namely: 
1. Teams Controller: teams_controller.rb 
2. Teams Model: team.rb 
3. Teams Views
* list.html.erb
* new.html.erb
* _team.html.erb
4. (Generic)Tree Display Views
* _page_footer.html.erb
* _entry_html.erb
* _folder.html.erb
* _listing.html.erb

=== Teams Controller ===

The controller contains all the methods to perform CRUD operations on the teams when seen from the instructor's point of view in the UI.

==== List of changes ====
We worked on the following work items(WIs) 
WI1 : Move allowed types list constant in list method to model as it is a best practice to keep all the constants at one place. 
WI2 : Refactor delete method. This method deletes the team and erases the records from teams_users and signed_up_teams table. 
WI3 : Refactor inherit and bequeath_all methods. Both the methods contain duplicated code with nested branching statements. 
WI4 : Introduce new methods like init_team_type, get_parent_by_id, get_parent_from_child which commonly operate on fetching team type to render UI elements accordingly. 
WI5 : Fix for a flaky test case on creating teams with the random members method.

==== Solutions Implemented and Delivered ====

1. Refactoring in the list method.
The list method contains a list of constants to check if the team_type from the session variables is a valid one or not.

Existing code snippet in teams_controller.rb:
<pre>
allowed_types = %w[Assignment Course]
session[:team_type] = params[:type] if params[:type] && allowed_types.include?(params[:type])
</pre>

We have moved the constant allowed_types to the teams model so that it can be used wherever needed in the teams_controller.rb. 
Code snippet after refactoring in team.rb:
<pre>
# Allowed types of teams -- ASSIGNMENT teams or COURSE teams
def self.allowed_types
# non-interpolated array of single-quoted strings
%w[Assignment Course]
end
</pre>

Code snippet after refactoring showing the usage in teams_controller.rb:
<pre>
session[:team_type] = params[:type] if params[:type] && Team.allowed_types.include?(params[:type])
</pre>

2. Refactor delete method.
This method contains an if block in which the condition is never satisfied. It is considered a dead code. Related piazza post: https://piazza.com/class/kxwmkrv8djq573?cid=210

So we have simply removed that if block. Below is the removed code snippet.
<pre>
if @signed_up_team == 1 && !@signUps.first.is_waitlisted # this team hold a topic
# if there is another team in waitlist, make this team hold this topic
topic_id = @signed_up_team.first.topic_id
next_wait_listed_team = SignedUpTeam.where(topic_id: topic_id, is_waitlisted: true).first
# if slot exist, then confirm the topic for this team and delete all waitlists for this team
SignUpTopic.assign_to_first_waiting_team(next_wait_listed_team) if next_wait_listed_team
end
</pre>

And also there is a statement at line 89 which we replaced with <pre>@team.destroy</pre> instead of <pre>@team.destroy if @team</pre> because we already have a nil check for this variable in line 74, so we can remove the redundant ones.

3. Refactor inherit and bequeath_all methods.
Both methods contain a piece of code in common. They also have high branching in them which makes the code readability much more difficult.
Existing Code Snippet:
<pre>
# Copies existing teams from a course down to an assignment
# The team and team members are all copied.
def inherit
assignment = Assignment.find(params[:id])
if assignment.course_id
course = Course.find(assignment.course_id)
teams = course.get_teams
if teams.empty?
flash[:note] = 'No teams were found when trying to inherit.'
else
teams.each do |team|
team.copy(assignment.id)
end
end
else
flash[:error] = 'No course was found for this assignment.'
end
redirect_to controller: 'teams', action: 'list', id: assignment.id
end
</pre>

<pre>
def bequeath_all
if session[:team_type] == 'Course'
flash[:error] = 'Invalid team type for bequeathal'
redirect_to controller: 'teams', action: 'list', id: params[:id]
return
end
assignment = Assignment.find(params[:id])
if assignment.course_id
course = Course.find(assignment.course_id)
if course.course_teams.any?
flash[:error] = 'The course already has associated teams'
redirect_to controller: 'teams', action: 'list', id: assignment.id
return
end
teams = assignment.teams
teams.each do |team|
team.copy(course.id)
end
flash[:note] = teams.length.to_s + ' teams were successfully copied to "' + course.name + '"'
else
flash[:error] = 'No course was found for this assignment.'
end
redirect_to controller: 'teams', action: 'list', id: assignment.id
end
</pre>

As a solution for this problem, we have separated the bigger functions and broken them into smaller ones as below.
Code snippet after refactoring in teams_controller.rb.
<pre>
# Copies existing teams from a course down to an assignment
# The team and team members are all copied.
def inherit
copy_teams(Team.team_operation[:inherit])
end

# Handovers all teams to the course that contains the corresponding assignment
# The team and team members are all copied.
def bequeath_all
if session[:team_type] == 'Course'
flash[:error] = 'Invalid team type for bequeath all'
redirect_to controller: 'teams', action: 'list', id: params[:id]
else
copy_teams(Team.team_operation[:bequeath])
end
end

private

# Method to abstract the functionality to copy teams.
def copy_teams(operation)
assignment = Assignment.find(params[:id])
if assignment.course_id
choose_copy_type(assignment, operation)
else
flash[:error] = 'No course was found for this assignment.'
end
redirect_to controller: 'teams', action: 'list', id: assignment.id
end

# Method to choose copy technique based on the operation type.
def choose_copy_type(assignment, operation)
course = Course.find(assignment.course_id)
if operation == Team.team_operation[:bequeath]
bequeath_copy(assignment, course)
else
inherit_copy(assignment, course)
end
end

# Method to perform a copy of assignment teams to course
def bequeath_copy(assignment, course)
teams = assignment.teams
if course.course_teams.any?
flash[:error] = 'The course already has associated teams'
else
Team.copy_content(teams, course)
flash[:note] = teams.length.to_s + ' teams were successfully copied to "' + course.name + '"'
end
end

# Method to inherit teams from course by copying
def inherit_copy(assignment, course)
teams = course.course_teams
if teams.empty?
flash[:error] = 'No teams were found when trying to inherit.'
else
Team.copy_content(teams, assignment)
flash[:note] = teams.length.to_s + ' teams were successfully copied to "' + assignment.name + '"'
end
end
</pre>

Code snippet after refactoring in team.rb.
<pre>
# copies content of one object to the another
def self.copy_content(source, destination)
source.each do |each_element|
each_element.copy(destination.id)
end
end

# enum method for team clone operations
def self.team_operation
{ inherit: 'inherit', bequeath: 'bequeath' }.freeze
end
</pre>

4. Introduce new methods like init_team_type, get_parent_by_id, get_parent_from_child which commonly operate on fetching team type to render UI elements accordingly. The significance of each method is as follows.

* init_team_type method. The purpose of this method is to provide team_type initialization as a common functionality to the methods in teams_controller.
Existing code snippet:
<pre>
session[:team_type] = params[:type] if (params[:type] && allowed_types.include?(params[:type]))
</pre>
The above line is commonly being used in multiple teams_controller.rb methods. So in order to modularize it, we have moved it to a separate method. And the if condition is no longer a one-liner because one-liner if conditions in Ruby are better suited to checking for a sole condition.
Code snippet after refactoring the teams_controller.rb:
<pre>
def init_team_type(type)
if type and Team.allowed_types.include?(type)
session[:team_type] = type
end
end
</pre>

* get_parent_id method. The purpose of this method is to improve readability and maintainability and reduce duplication (thereby reducing the risk of error!).
Existing code snippet:
<pre>
parent = Object.const_get(session[:team_type]).find(params[:id])
</pre>
Code snippet after refactoring the teams_controller.rb:
<pre>
def get_parent_by_id(id)
Object.const_get(team_type).find(id)
end
</pre>
and function call would be like
<pre>
parent = get_parent_by_id(params[:id])
</pre>

* get_parent_from_child method. The purpose of this method is to improve readability and maintainability and reduce duplication (thereby reducing the risk of error!).
Existing code snippet:
<pre>
parent = Object.const_get(session[:team_type]).find(@team.parent_id)
</pre>
Code snippet after refactoring the teams_controller.rb:
<pre>
def get_parent_from_child(child)
Object.const_get(team_type).find(child.parent_id)
end
</pre>
and function call would be like
<pre>
parent = get_parent_from_child(@team)
</pre>

5. Fix for a flaky test case due to rails environment setup configuration. Reference: https://tinyurl.com/y64bupbk.
Every time we run tests for teams_controller. There was a test case related to the create_teams method which is getting failed due to the below-attached code. 
Existing code snippet causing issue:
<pre>
undo_link('Random teams have been successfully created.')
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'Random teams have been successfully created', request)
</pre>
In order to fix that we have referred to the above-attached reference and made the following code changes. 
Code snippet after refactoring the teams_controller.rb
<pre>
message = 'Random teams have been successfully created'
undo_link(message)
# To do: Move this check to a application level commons file.
# For now this is the only usage of this check.
# If a similar use case pops up "To do" action needs to be performed.
# Fix link: https://tinyurl.com/y64bupbk
if Rails.env.development?
ExpertizaLogger.info LoggerMessage.new(controller_name, '', message, request)
end
</pre>

=== Teams Model ===

This is a model class that contains all the reusable class methods and has the necessary checks and attributes for performing checks on teams.

==== List of changes ====
We worked on the following work items(WIs) 
WI1 : Refactor randomize_all_by_parent method to modify the existing logic which contains a lot of branching. 
WI2 : Refactor assign_single_users_to_teams method. Made changes to perform an early return and modified the looping logic. 
WI3 : Refactor create_team_from_single_users method. Made changes to modify the looping logic in a better way to avoid a few extra variables.

==== Solutions Implemented and Delivered ====
1. Refactor randomize_all_by_parent method. The purpose of this block is to find teams that still need team members and users who are not in any team. In Order to achieve that, we have modified the existing logic to avoid branching and achieve the same result as follows.

Existing code snippet:
<pre>
teams_num = teams.size
i = 0
teams_num.times do
teams_users = TeamsUser.where(team_id: teams[i].id)
teams_users.each do |teams_user|
users.delete(User.find(teams_user.user_id))
end
if Team.size(teams.first.id) >= min_team_size
teams.delete(teams.first)
else
i += 1
end
end
</pre>

Code snippet after refactoring the randomize_all_by_parent method in team.rb file.
<pre>
teams.each { |team| TeamsUser.where(team_id: team.id).each { |teams_user| users.delete(User.find(teams_user.user_id)) } }
teams.reject! { |team| Team.size(team.id) >= min_team_size }
</pre>

2. Refactor assign_single_users_to_teams method. The purpose of this block is to fill the teams with users to meet the minimum number of students requirement. In this loop, once the users are empty we can simply return without any additional work which is being done in the existing logic. Instead of two break statements at lines 152 and 154, we can simply have one statement with “return” at line 152 to stop the function early. In summary, we can replace the existing block of code as shown below.

Existing code snippet:
<pre>
teams.each do |team|
curr_team_size = Team.size(team.id)
member_num_difference = min_team_size - curr_team_size
while member_num_difference > 0
team.add_member(users.first, parent.id)
users.delete(users.first)
member_num_difference -= 1
break if users.empty?
end
break if users.empty?
end
</pre>

Code snippet after refactoring the assign_single_users_to_teams method in team.rb file.
<pre>
teams.each do |team|
curr_team_size = Team.size(team.id)
member_num_difference = min_team_size - curr_team_size
member_num_difference.times do
team.add_member(users.first, parent.id)
users.delete(users.first)
return if users.empty?
end
end
</pre>

3. Refactor create_team_from_single_users method. This block works on adding single users who are not in any team by creating a new team for them. The block can be rewritten as below.

Existing code snippet:
<pre>
min_team_size.times do
break if next_team_member_index >= users.length

user = users[next_team_member_index]
team.add_member(user, parent.id)
next_team_member_index += 1
end
</pre>

Code snippet after refactoring the team.rb:
<pre>
(0..[min_team_size, users.length].min).each do |index|
user = users[index]
team.add_member(user, parent.id)
end
</pre>

=== Teams Views ===

These are the views that are rendered in the frontend when the team's related web pages are loaded.

==== List of changes ====
We worked on the following work items(WIs) 
WI1 : Move a conditional check in list.html.erb to the list method in the controller. 
WI2 : Refactor an if-else block using ternary operator in new.html.erb. 
WI3 : Refactor an if-else block using the ternary operator in _team.html.erb.

==== Solutions Implemented and Delivered ====
1. Move a conditional check used in multiple places in list.html.erb to the list method in the controller, so that it can simply be used as a boolean variable in the view. 
Existing code snippet:
<pre>
<% if session[:team_type] == 'Assignment'&& @assignment.max_team_size > 1 %>
</pre>
We moved the condition in the if-block to the list method in the controller and use it here as a boolean variable so that the code becomes short and more readable. 
Code snippet after refactoring in list.html.erb
<pre>
<% if @is_valid_assignment %>
</pre>

Code snippet after refactoring in teams_controller.rb list method.
<pre>
@is_valid_assignment = session[:team_type] == Team.allowed_types[0] && @assignment.max_team_size > 1
</pre>

2. Refactor an if-else statement using the ternary operator in new.html.erb. 
Existing code snippet:
<pre>
<% if @parent.is_a?(Course)%>
Team Size:<%= select_tag 'team_size', options_for_select(2..4), size: 1 %>
<% else %>
Team Size:<%= select_tag 'team_size', options_for_select(2..@parent.max_team_size), size: 1 %>
<% end %>
</pre>
Code snippet after refactoring new.html.erb:
<pre>
<% maxsize = @parent.is_a?(Course) ? 4 : @parent.max_team_size %>
Team Size:<%= select_tag 'team_size', options_for_select(2..maxsize), size: 1 %>
</pre>

3. Refactor an if-else statement using the ternary operator in _team.html.erb. 
Existing code snippet:
<pre>
<% if @root_node.class == AssignmentNode %>
<% modelType = ‘AssignmentTeam’ %>
<% else %>
<% modelType = ‘CourseTeam’ %>
<%end>
</pre>
Code snippet after refactoring _team.html.erb.
<pre>
<% modelType = @root_node.class == AssignmentNode ? ‘AssignmentTeam’ : ‘CourseTeam’ %>
</pre>

== Testing Details==

=== RSpec ===
* We have thoroughly tested all the test cases in teams_controller_spec.rb. And we have also fixed one of the flaky test cases which are mentioned above in one of the code changes. In addition to the unit tests, we have also made sure that there are no issues in the UI with the changes in the teams_controller.rb.
* In addition to the controller, we have also thoroughly tested the model using all the test cases in team_spec.rb. We have also verified the same in the expertiza UI.

=== UI Testing ===

'''Pre-conditions:'''
# You must be logged in using the [[CSC/ECE_517_Spring_2022_-_E2214:_Refactor_teams_controller#Peer_Review_Information|previously provided credentials]].
# You must have a course with participants. To make a new course and add its participants, follow the instructions below.
## Upon login, you will see a list of courses saved to this instructor's account.
### If you do not see this list, hover over '''Manage...''' in the navbar.
### Click on '''Courses'''.
## To create a new course, click on the '''white and blue plus button''' to the top right of the Courses table.
## Select an '''institution''', enter a '''course name''', enter a '''course directory''', enter any '''course information''', select a '''default language''', and ''uncheck'' '''Private course'''.
## Press the '''Create''' button.
## You will return to the list of courses. Find the course you just created, and click the '''Add participants''' icon, which is an ''image of a person in a blue shirt with a green plus sign''.
## Enter the '''login name''' for a student you want to add as a participant to the course into the text field, and then press '''Add'''. Add as many students as you wish.
## When you are finished, click '''Back''' to return to the Course list.
# You must have an assignment associated with the course you made or chose to use in Pre-conditions Step #2. To make a new assignment and add its participants, follow the instructions below.
## Find the course in the table and click the '''Create Assignment''' button, which is an ''image of a paper with a green plus sign''.
## Enter an '''Assignment name''', select the '''Course''' you made or chose, enter a '''Description URL''', and ''check'' the '''Has teams?''' checkbox.
## Click the '''Create''' button.
## Click the '''Save''' button.
## Click the link in the red flash message to ''add participants to the new assignment''.
### If you don't see that flash message, you may hover over '''Manage...''' in the navbar and then select '''Assignments'''.
### Locate the assignment in the table and click the '''Add participants''' icon which is an ''image of a person in a blue shirt with a green plus sign''.
## Click the link that says '''Copy participants from course'''.

'''Create Randomly-Chosen Teams:'''
# Navigate to the Courses table, and locate the course you made or chose previously.
# Click the '''Create teams''' icon, which is an ''image of three people with a green plus sign''.
# This is the ''Course Teams table''.
# Click the '''Create Team''' link.
# Keep the default value of ''2'' in the '''Team Size''' select, and press '''Create Teams'''.
# You should see some new teams populated in the Course Teams table.

'''Delete Individual Teams:'''
# Navigate to the Course Teams table.
# Click on any ''red X'' next to a team name to '''delete''' that team.
# The page should refresh and show that the deleted team no longer exists.

'''Delete All Teams:'''
# Navigate to the Course Teams table.
# Click the '''Delete All Teams''' link to delete all teams associated with the course.
# The page should refresh and show that there are no more teams associated with the course.

'''Manually Create a Team:'''
# Navigate to the Course Teams table.
# Click the '''Create Team''' link.
# Enter a '''Team Name'' into the text field and press '''Save'''.
# The Course Teams table should be shown with the new team present.
# Click the ''green plus button'' to '''Add Team Member'''.
# Enter the '''login name''' for a student you want to add to the team, and press '''Add'''.
# You can confirm this addition but pressing the ''black and white plus button'' to the left of the team's table entry. The student should be shown as a team member.

'''Inherit Teams:'''
# Ensure your course has at least one team.
# Navigate to the assignment you chose or created previously.
# Click the '''Create teams''' icon, which is an ''image of three people with a green plus sign''.
# This is the ''Assignment Teams table''.
# If the assignment already has teams, delete them.
# Click the '''Create Team''' link.
# Press the '''Inherit''' button.
# You should now see the teams from the course displayed in the Assignment Teams table.

'''Bequeath All Teams:'''
# Ensure your course has no teams.
# Navigate to the assignment you chose or created previously.
# Ensure your assignment has at least one team.
# Click '''Bequeath All Teams'''.
# Navigate to your course's Course Teams table.
# You should now see the teams from the assignment displayed in the Course Teams table.

== Scope for future improvement ==
1. The construct_table method in GradesHelper is not used anywhere. It has no reference in the project. So we feel it can be safely removed. 
2. The has_team_and_metareview? method in GradesHelper can be broken down into separate methods, one each for team and metareview. This will provide improved flexibility. It needs some analysis though, as both the entities(team & metareview) are currently checked in conjunction from all the views they are referenced from.

CSC/ECE 517 Spring 2022 - E2214: Refactor teams controller

2022-03-20T22:34:21Z

Kflemin3: detailed description of how to perform UI testing of important features affected by this refactor