Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2023 - E2329. Grading audit trail(Project 4)

2023-04-25T02:18:25Z

Sbuddai: /* Output */

== Team Introduction ==

=== Team Members ===

Sarika Vishwanatham (svishwa2@ncsu.edu)

Chetana Chunduru (cchetan2@ncsu.edu)

Shreya Buddaiahgari (sbuddai@ncsu.edu)

=== Mentor ===

Krishna Saurabh Vankadaru (kvankad@ncsu.edu)

== Problem Description ==
There is no way to determine who graded an assignment after the instructor awarded it a grade. The following data must be recorded and kept in a grading audit trail:

1. The identity of the person who assigned the grade and the time it was completed must be stated.

2. Previous feedback from other instructors must also be kept.
Every time an instructor modifies a grade or comment and presses the save button, this data must be saved.

There are now two places where grading audit trails need to be added:

1. Check your grade: Log in as the instructor, click Manage, then click Assignments. Review Report View

2. Log in as the instructor and select Manage from the Assignments menu. Check out the entries

== Prior Work ==

In the system, the team built a database called grading history that includes information about the instructor, the assignment, the grade type, the student, the grade, the comment, and the timestamp.

They developed a model, a controller, and a view for the "Review Grade" and the "Submission Grade" using the MVC design.

:Model - grading history.rb has a set of properties that includes the following: timestamp, comment, grade type, instructor ID, and assignment ID.

:Controller - grading history controller.rb. E ach time a review grade or submission grade is saved, a new entry is added to the database

:View - index_html.erb.shows the grade history for the current submission or review. A submission record in the system is an existent illustration of this.

Also, they changed the grades controller so that grading history controller.rb will call a function to produce an entry that is saved to the database each time a grade is submitted or amended.The review report error is fixed which wasn't previously generated due some issue. 'Grading_history' table is created and added to database. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.Included comprehensive test cases and comments for thorough testing and documentation purposes.

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

== Design Strategy ==

Although the project is four years old and the merge requests were never merged, the earlier revisions of the project fully satisfied all of the functional requirements of the "grading audit trail" feature. As a result, the changes are obsolete and interfere with the newest Expertiza's ability to create.

1. Improving the separation of concerns

2. Cleaning up the grading audit trail code

3. Make the grading audit trail feature read-only

4. Display history in reverse chronological order

5. CSS - Change px to %

6. Fixture of grading history button in review report

7. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.

8. Included comprehensive test cases and comments for thorough testing and documentation purposes.

== Planned Work ==

===1. Improving the separation of concerns===

The goal here is to move the code snippet from views, which contains some business logic for displaying grading history data, out of the view file and into the controller.
For example, we could find business logic in “app/views/grading_histories/index.html.erb”. To fix this, In the controller action that renders the index.html.erb view, we retrieve the @grading_histories collection and process it to extract the relevant data needed to display on the view. We create a new instance variable, say @grading_history_info, and assign it a hash object containing the extracted data. Then, pass this @grading_history_info variable to the view as part of the render call, so that it's available to the view template. In the index.html.erb view, replace the business logic code snippet with code that accesses the relevant data from the @grading_history_info hash and uses it to populate the view.
By doing this, you have effectively separated the business logic from the view, making it easier to maintain and test each component independently.
Some of the potential benefits of this approach include:

• Improved readability and maintainability of the view code, since it no longer contains complex business logic.

• Improved testability of the business logic code, since it can be tested in isolation from the view.

• Reduced coupling between the view and the controller, since the controller now provides the view with the data it needs, rather than the view fetching it directly from the database.

===2. Cleaning up the grading audit trail code===

Some examples of the types of code that might be redundant or unnecessary code in a project are:

• Commented-out code that is no longer needed

• Unused variables or functions

• Code that's been duplicated or replaced by newer code

• Code that's no longer being executed or has been deprecated

• Code that's no longer compatible with the current system configuration or dependencies

By cleaning up redundant or unnecessary code, we can make the project codebase more efficient, easier to maintain, and less error-prone.

===3. Make the grading audit trail feature read-only===

When a grade is assigned by an instructor, the grading audit trail shows who did it and when it was done. It also includes comments previously provided by other instructors. This information will be stored every time an instructor edits a grade/comment and clicks the save button.

By making the grading audit trail read-only, you can help ensure the integrity of the grading history and record any changes to grades or comments. This can be particularly important in academic settings, where grading data must be accurate and reliable for record-keeping purposes.

===4. Display history in reverse chronological order===

The proposed design change aims to modify the grading audit trail feature to display the grading history in reverse chronological order, with the most recent entries appearing first.

By displaying the grading audit trail in reverse chronological order, instructors can quickly and easily see the most recent changes made to a student's submission, without having to scroll through potentially large amounts of data. This can be particularly useful for identifying recent trends or patterns in a student's work, or for quickly reviewing recent changes made by multiple instructors.
This change can also improve the usability of the feature, as users will be able to quickly find the information, they need without having to manually sort or filter the data themselves.

===5. CSS - Change px to %===

Change the CSS properties like border-width from px units to a percentage value that fits your design needs. For example, you could use 0.1em or 0.5%. This will make the border scale proportionally to the size of the container.

Avoid using fixed width or height values in your CSS code. Instead, use relative values such as percentages or em units to allow your design to adapt to different screen sizes and resolutions. For example, if you want to set the width of the container to 80% of the screen width, you can use width: 80%;.

We can also consider using CSS Grid or Flexbox to create layouts that are more flexible and adaptable. These layout systems allow us to create complex designs that can adapt to different screen sizes and resolutions without the need for fixed width or height values.

6. Fixture of grading history button in review report

7. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.

8. Included comprehensive test cases and comments for thorough testing and documentation purposes.

== Flow Diagram ==

[[File:Grading flow diagram.png]]

[[File:Flow diagram grading.png]]

== Output ==

Assignments Page:

[[File:Assignments proj3.jpeg|1000px]]

Submissions Page:

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

Grading Histories Page:

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

Review Report Page:

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

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

Grading History for Review Report:

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

== Testing Plan ==

Functional testing:

1. Test SubmissionGradeHistory.create: call a submission grade when changed.
spec/controllers/grades_controller_spec.rb

The test cases are defined to check whether the controller action save_grade_and_comment_for_submission can save the grade and comment for a submission, and then redirect to the grades#view_team page with no errors and to check whether the same controller action can catch an error that might occur when saving the grade and comment for a submission, and then raises that error.

[[File:GradesController.png|1000px]]

2. Test ReviewGradeHistory.create: call a submission grade when changed.
spec/controllers/review_mapping_controller_spec.rb

This test case is to ensure that the review grades and comments are saved and that the correct page is redirected to after the action is completed.

[[File:Reviewscontroller.png|1000px]]

3. Test GradeHistory.where: called when grading history button is clicked.
spec/controllers/grading_histories_controller_test.rb

The create test is checking whether the grading history object can be successfully created with valid parameters. It sets up an instance of the grading_history object using the FactoryBot gem and checks whether the expected values for the attributes of the object are returned.

The index test is checking whether the index action of the controller properly handles requests to show grading histories for a particular participant. It sets up an instance of the instructor object and a session object with the instructor user. It then allows the GradingHistory model to receive a create method call with certain arguments and checks whether a GET request to the index action with the appropriate parameters and session redirects to the correct page.

[[File:Screenshot 2023-04-24 a PM.png|1000px]]

=='''Reference'''==
[https://expertiza.ncsu.edu/ Expertiza]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/E1869_GRADING_AUDIT_TRAIL Previous Project Documentation]

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation Expertiza Documentation]

[https://github.com/expertiza/expertiza Expertiza Github]

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2305._Grading_audit_trail]

CSC/ECE 517 Spring 2023 - E2329. Grading audit trail(Project 4)

2023-04-25T02:17:58Z

Sbuddai: /* Output */

CSC/ECE 517 Spring 2023 - E2329. Grading audit trail(Project 4)

2023-04-25T02:16:58Z

Sbuddai:

== Team Introduction ==

=== Team Members ===

Sarika Vishwanatham (svishwa2@ncsu.edu)

Chetana Chunduru (cchetan2@ncsu.edu)

Shreya Buddaiahgari (sbuddai@ncsu.edu)

=== Mentor ===

Krishna Saurabh Vankadaru (kvankad@ncsu.edu)

== Problem Description ==
There is no way to determine who graded an assignment after the instructor awarded it a grade. The following data must be recorded and kept in a grading audit trail:

1. The identity of the person who assigned the grade and the time it was completed must be stated.

2. Previous feedback from other instructors must also be kept.
Every time an instructor modifies a grade or comment and presses the save button, this data must be saved.

There are now two places where grading audit trails need to be added:

1. Check your grade: Log in as the instructor, click Manage, then click Assignments. Review Report View

2. Log in as the instructor and select Manage from the Assignments menu. Check out the entries

== Prior Work ==

In the system, the team built a database called grading history that includes information about the instructor, the assignment, the grade type, the student, the grade, the comment, and the timestamp.

They developed a model, a controller, and a view for the "Review Grade" and the "Submission Grade" using the MVC design.

:Model - grading history.rb has a set of properties that includes the following: timestamp, comment, grade type, instructor ID, and assignment ID.

:Controller - grading history controller.rb. E ach time a review grade or submission grade is saved, a new entry is added to the database

:View - index_html.erb.shows the grade history for the current submission or review. A submission record in the system is an existent illustration of this.

Also, they changed the grades controller so that grading history controller.rb will call a function to produce an entry that is saved to the database each time a grade is submitted or amended.The review report error is fixed which wasn't previously generated due some issue. 'Grading_history' table is created and added to database. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.Included comprehensive test cases and comments for thorough testing and documentation purposes.

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

== Design Strategy ==

Although the project is four years old and the merge requests were never merged, the earlier revisions of the project fully satisfied all of the functional requirements of the "grading audit trail" feature. As a result, the changes are obsolete and interfere with the newest Expertiza's ability to create.

1. Improving the separation of concerns

2. Cleaning up the grading audit trail code

3. Make the grading audit trail feature read-only

4. Display history in reverse chronological order

5. CSS - Change px to %

6. Fixture of grading history button in review report

7. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.

8. Included comprehensive test cases and comments for thorough testing and documentation purposes.

== Planned Work ==

===1. Improving the separation of concerns===

The goal here is to move the code snippet from views, which contains some business logic for displaying grading history data, out of the view file and into the controller.
For example, we could find business logic in “app/views/grading_histories/index.html.erb”. To fix this, In the controller action that renders the index.html.erb view, we retrieve the @grading_histories collection and process it to extract the relevant data needed to display on the view. We create a new instance variable, say @grading_history_info, and assign it a hash object containing the extracted data. Then, pass this @grading_history_info variable to the view as part of the render call, so that it's available to the view template. In the index.html.erb view, replace the business logic code snippet with code that accesses the relevant data from the @grading_history_info hash and uses it to populate the view.
By doing this, you have effectively separated the business logic from the view, making it easier to maintain and test each component independently.
Some of the potential benefits of this approach include:

• Improved readability and maintainability of the view code, since it no longer contains complex business logic.

• Improved testability of the business logic code, since it can be tested in isolation from the view.

• Reduced coupling between the view and the controller, since the controller now provides the view with the data it needs, rather than the view fetching it directly from the database.

===2. Cleaning up the grading audit trail code===

Some examples of the types of code that might be redundant or unnecessary code in a project are:

• Commented-out code that is no longer needed

• Unused variables or functions

• Code that's been duplicated or replaced by newer code

• Code that's no longer being executed or has been deprecated

• Code that's no longer compatible with the current system configuration or dependencies

By cleaning up redundant or unnecessary code, we can make the project codebase more efficient, easier to maintain, and less error-prone.

===3. Make the grading audit trail feature read-only===

When a grade is assigned by an instructor, the grading audit trail shows who did it and when it was done. It also includes comments previously provided by other instructors. This information will be stored every time an instructor edits a grade/comment and clicks the save button.

By making the grading audit trail read-only, you can help ensure the integrity of the grading history and record any changes to grades or comments. This can be particularly important in academic settings, where grading data must be accurate and reliable for record-keeping purposes.

===4. Display history in reverse chronological order===

The proposed design change aims to modify the grading audit trail feature to display the grading history in reverse chronological order, with the most recent entries appearing first.

By displaying the grading audit trail in reverse chronological order, instructors can quickly and easily see the most recent changes made to a student's submission, without having to scroll through potentially large amounts of data. This can be particularly useful for identifying recent trends or patterns in a student's work, or for quickly reviewing recent changes made by multiple instructors.
This change can also improve the usability of the feature, as users will be able to quickly find the information, they need without having to manually sort or filter the data themselves.

===5. CSS - Change px to %===

Change the CSS properties like border-width from px units to a percentage value that fits your design needs. For example, you could use 0.1em or 0.5%. This will make the border scale proportionally to the size of the container.

Avoid using fixed width or height values in your CSS code. Instead, use relative values such as percentages or em units to allow your design to adapt to different screen sizes and resolutions. For example, if you want to set the width of the container to 80% of the screen width, you can use width: 80%;.

We can also consider using CSS Grid or Flexbox to create layouts that are more flexible and adaptable. These layout systems allow us to create complex designs that can adapt to different screen sizes and resolutions without the need for fixed width or height values.

6. Fixture of grading history button in review report

7. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.

8. Included comprehensive test cases and comments for thorough testing and documentation purposes.

== Flow Diagram ==

[[File:Grading flow diagram.png]]

[[File:Flow diagram grading.png]]

== Output ==

Assignments Page:

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

Submissions Page:

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

Grading Histories Page:

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

Review Report Page:

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

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

Grading History for Review Report:

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

== Testing Plan ==

Functional testing:

1. Test SubmissionGradeHistory.create: call a submission grade when changed.
spec/controllers/grades_controller_spec.rb

The test cases are defined to check whether the controller action save_grade_and_comment_for_submission can save the grade and comment for a submission, and then redirect to the grades#view_team page with no errors and to check whether the same controller action can catch an error that might occur when saving the grade and comment for a submission, and then raises that error.

[[File:GradesController.png|1000px]]

2. Test ReviewGradeHistory.create: call a submission grade when changed.
spec/controllers/review_mapping_controller_spec.rb

This test case is to ensure that the review grades and comments are saved and that the correct page is redirected to after the action is completed.

[[File:Reviewscontroller.png|1000px]]

3. Test GradeHistory.where: called when grading history button is clicked.
spec/controllers/grading_histories_controller_test.rb

The create test is checking whether the grading history object can be successfully created with valid parameters. It sets up an instance of the grading_history object using the FactoryBot gem and checks whether the expected values for the attributes of the object are returned.

The index test is checking whether the index action of the controller properly handles requests to show grading histories for a particular participant. It sets up an instance of the instructor object and a session object with the instructor user. It then allows the GradingHistory model to receive a create method call with certain arguments and checks whether a GET request to the index action with the appropriate parameters and session redirects to the correct page.

[[File:Screenshot 2023-04-24 a PM.png|1000px]]

=='''Reference'''==
[https://expertiza.ncsu.edu/ Expertiza]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/E1869_GRADING_AUDIT_TRAIL Previous Project Documentation]

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation Expertiza Documentation]

[https://github.com/expertiza/expertiza Expertiza Github]

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2305._Grading_audit_trail]

CSC/ECE 517 Spring 2023 - E2329. Grading audit trail(Project 4)

2023-04-25T02:15:53Z

Sbuddai:

== Team Introduction ==

=== Team Members ===

Sarika Vishwanatham (svishwa2@ncsu.edu)

Chetana Chunduru (cchetan2@ncsu.edu)

Shreya Buddaiahgari (sbuddai@ncsu.edu)

=== Mentor ===

Krishna Saurabh Vankadaru (kvankad@ncsu.edu)

== Problem Description ==
There is no way to determine who graded an assignment after the instructor awarded it a grade. The following data must be recorded and kept in a grading audit trail:

1. The identity of the person who assigned the grade and the time it was completed must be stated.

2. Previous feedback from other instructors must also be kept.
Every time an instructor modifies a grade or comment and presses the save button, this data must be saved.

There are now two places where grading audit trails need to be added:

1. Check your grade: Log in as the instructor, click Manage, then click Assignments. Review Report View

2. Log in as the instructor and select Manage from the Assignments menu. Check out the entries

== Prior Work ==

In the system, the team built a database called grading history that includes information about the instructor, the assignment, the grade type, the student, the grade, the comment, and the timestamp.

They developed a model, a controller, and a view for the "Review Grade" and the "Submission Grade" using the MVC design.

:Model - grading history.rb has a set of properties that includes the following: timestamp, comment, grade type, instructor ID, and assignment ID.

:Controller - grading history controller.rb. E ach time a review grade or submission grade is saved, a new entry is added to the database

:View - index_html.erb.shows the grade history for the current submission or review. A submission record in the system is an existent illustration of this.

Also, they changed the grades controller so that grading history controller.rb will call a function to produce an entry that is saved to the database each time a grade is submitted or amended.The review report error is fixed which wasn't previously generated due some issue. 'Grading_history' table is created and added to database. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.Included comprehensive test cases and comments for thorough testing and documentation purposes.

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

== Design Strategy ==

Although the project is four years old and the merge requests were never merged, the earlier revisions of the project fully satisfied all of the functional requirements of the "grading audit trail" feature. As a result, the changes are obsolete and interfere with the newest Expertiza's ability to create.

1. Improving the separation of concerns

2. Cleaning up the grading audit trail code

3. Make the grading audit trail feature read-only

4. Display history in reverse chronological order

5. CSS - Change px to %

6. Fixture of grading history button in review report

7. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.

8. Included comprehensive test cases and comments for thorough testing and documentation purposes.

== Planned Work ==

===1. Improving the separation of concerns===

The goal here is to move the code snippet from views, which contains some business logic for displaying grading history data, out of the view file and into the controller.
For example, we could find business logic in “app/views/grading_histories/index.html.erb”. To fix this, In the controller action that renders the index.html.erb view, we retrieve the @grading_histories collection and process it to extract the relevant data needed to display on the view. We create a new instance variable, say @grading_history_info, and assign it a hash object containing the extracted data. Then, pass this @grading_history_info variable to the view as part of the render call, so that it's available to the view template. In the index.html.erb view, replace the business logic code snippet with code that accesses the relevant data from the @grading_history_info hash and uses it to populate the view.
By doing this, you have effectively separated the business logic from the view, making it easier to maintain and test each component independently.
Some of the potential benefits of this approach include:

• Improved readability and maintainability of the view code, since it no longer contains complex business logic.

• Improved testability of the business logic code, since it can be tested in isolation from the view.

• Reduced coupling between the view and the controller, since the controller now provides the view with the data it needs, rather than the view fetching it directly from the database.

===2. Cleaning up the grading audit trail code===

Some examples of the types of code that might be redundant or unnecessary code in a project are:

• Commented-out code that is no longer needed

• Unused variables or functions

• Code that's been duplicated or replaced by newer code

• Code that's no longer being executed or has been deprecated

• Code that's no longer compatible with the current system configuration or dependencies

By cleaning up redundant or unnecessary code, we can make the project codebase more efficient, easier to maintain, and less error-prone.

===3. Make the grading audit trail feature read-only===

When a grade is assigned by an instructor, the grading audit trail shows who did it and when it was done. It also includes comments previously provided by other instructors. This information will be stored every time an instructor edits a grade/comment and clicks the save button.

By making the grading audit trail read-only, you can help ensure the integrity of the grading history and record any changes to grades or comments. This can be particularly important in academic settings, where grading data must be accurate and reliable for record-keeping purposes.

===4. Display history in reverse chronological order===

The proposed design change aims to modify the grading audit trail feature to display the grading history in reverse chronological order, with the most recent entries appearing first.

By displaying the grading audit trail in reverse chronological order, instructors can quickly and easily see the most recent changes made to a student's submission, without having to scroll through potentially large amounts of data. This can be particularly useful for identifying recent trends or patterns in a student's work, or for quickly reviewing recent changes made by multiple instructors.
This change can also improve the usability of the feature, as users will be able to quickly find the information, they need without having to manually sort or filter the data themselves.

===5. CSS - Change px to %===

Change the CSS properties like border-width from px units to a percentage value that fits your design needs. For example, you could use 0.1em or 0.5%. This will make the border scale proportionally to the size of the container.

Avoid using fixed width or height values in your CSS code. Instead, use relative values such as percentages or em units to allow your design to adapt to different screen sizes and resolutions. For example, if you want to set the width of the container to 80% of the screen width, you can use width: 80%;.

We can also consider using CSS Grid or Flexbox to create layouts that are more flexible and adaptable. These layout systems allow us to create complex designs that can adapt to different screen sizes and resolutions without the need for fixed width or height values.

6. Fixture of grading history button in review report

7. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.

8. Included comprehensive test cases and comments for thorough testing and documentation purposes.

== Flow Diagram ==

[[File:Grading flow diagram.png]]

[[File:Flow diagram grading.png]]

== Output ==

Assignments Page:

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

Submissions Page:

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

Grading Histories Page:

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

Review Report Page:

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

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

Grading History for Review Report:

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

== Testing Plan ==

Functional testing:

1. Test SubmissionGradeHistory.create: call a submission grade when changed.
spec/controllers/grades_controller_spec.rb

The test cases are defined to check whether the controller action save_grade_and_comment_for_submission can save the grade and comment for a submission, and then redirect to the grades#view_team page with no errors and to check whether the same controller action can catch an error that might occur when saving the grade and comment for a submission, and then raises that error.

[[File:GradesController.png|1000px]]

2. Test ReviewGradeHistory.create: call a submission grade when changed.
spec/controllers/review_mapping_controller_spec.rb

This test case is to ensure that the review grades and comments are saved and that the correct page is redirected to after the action is completed.

[[File:Reviewscontroller.png|1000px]]

3. Test GradeHistory.where: called when grading history button is clicked.
spec/controllers/grading_histories_controller_test.rb

The create test is checking whether the grading history object can be successfully created with valid parameters. It sets up an instance of the grading_history object using the FactoryBot gem and checks whether the expected values for the attributes of the object are returned.

The index test is checking whether the index action of the controller properly handles requests to show grading histories for a particular participant. It sets up an instance of the instructor object and a session object with the instructor user. It then allows the GradingHistory model to receive a create method call with certain arguments and checks whether a GET request to the index action with the appropriate parameters and session redirects to the correct page.

[[File:Screenshot 2023-04-24 a PM.png|1000px]]

=='''Reference'''==
[https://expertiza.ncsu.edu/ Expertiza]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/E1869_GRADING_AUDIT_TRAIL Previous Project Documentation]

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation Expertiza Documentation]

[https://github.com/expertiza/expertiza Expertiza Github]

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2305._Grading_audit_trail]

File:GradingHistoryFromReviewReport.jpeg

2023-04-25T02:10:30Z

Sbuddai:

File:ReviewReportOutput2.jpeg

2023-04-25T02:10:04Z

Sbuddai:

File:ReviewReportOutput.jpeg

2023-04-25T02:08:56Z

Sbuddai:

File:GradingHistoryOutput.jpeg

2023-04-25T02:08:17Z

Sbuddai:

File:SubmissionsPage.jpeg

2023-04-25T02:07:32Z

Sbuddai:

CSC/ECE 517 Spring 2023 - E2329. Grading audit trail(Project 4)

2023-04-25T02:04:16Z

Sbuddai: /* Testing Plan */

== Team Introduction ==

=== Team Members ===

Sarika Vishwanatham (svishwa2@ncsu.edu)

Chetana Chunduru (cchetan2@ncsu.edu)

Shreya Buddaiahgari (sbuddai@ncsu.edu)

=== Mentor ===

Krishna Saurabh Vankadaru (kvankad@ncsu.edu)

== Problem Description ==
There is no way to determine who graded an assignment after the instructor awarded it a grade. The following data must be recorded and kept in a grading audit trail:

1. The identity of the person who assigned the grade and the time it was completed must be stated.

2. Previous feedback from other instructors must also be kept.
Every time an instructor modifies a grade or comment and presses the save button, this data must be saved.

There are now two places where grading audit trails need to be added:

1. Check your grade: Log in as the instructor, click Manage, then click Assignments. Review Report View

2. Log in as the instructor and select Manage from the Assignments menu. Check out the entries

== Prior Work ==

In the system, the team built a database called grading history that includes information about the instructor, the assignment, the grade type, the student, the grade, the comment, and the timestamp.

They developed a model, a controller, and a view for the "Review Grade" and the "Submission Grade" using the MVC design.

:Model - grading history.rb has a set of properties that includes the following: timestamp, comment, grade type, instructor ID, and assignment ID.

:Controller - grading history controller.rb. E ach time a review grade or submission grade is saved, a new entry is added to the database

:View - index_html.erb.shows the grade history for the current submission or review. A submission record in the system is an existent illustration of this.

Also, they changed the grades controller so that grading history controller.rb will call a function to produce an entry that is saved to the database each time a grade is submitted or amended.The review report error is fixed which wasn't previously generated due some issue. 'Grading_history' table is created and added to database. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.Included comprehensive test cases and comments for thorough testing and documentation purposes.

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

== Design Strategy ==

Although the project is four years old and the merge requests were never merged, the earlier revisions of the project fully satisfied all of the functional requirements of the "grading audit trail" feature. As a result, the changes are obsolete and interfere with the newest Expertiza's ability to create.

1. Improving the separation of concerns

2. Cleaning up the grading audit trail code

3. Make the grading audit trail feature read-only

4. Display history in reverse chronological order

5. CSS - Change px to %

6. Fixture of grading history button in review report

7. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.

8. Included comprehensive test cases and comments for thorough testing and documentation purposes.

== Planned Work ==

===1. Improving the separation of concerns===

The goal here is to move the code snippet from views, which contains some business logic for displaying grading history data, out of the view file and into the controller.
For example, we could find business logic in “app/views/grading_histories/index.html.erb”. To fix this, In the controller action that renders the index.html.erb view, we retrieve the @grading_histories collection and process it to extract the relevant data needed to display on the view. We create a new instance variable, say @grading_history_info, and assign it a hash object containing the extracted data. Then, pass this @grading_history_info variable to the view as part of the render call, so that it's available to the view template. In the index.html.erb view, replace the business logic code snippet with code that accesses the relevant data from the @grading_history_info hash and uses it to populate the view.
By doing this, you have effectively separated the business logic from the view, making it easier to maintain and test each component independently.
Some of the potential benefits of this approach include:

• Improved readability and maintainability of the view code, since it no longer contains complex business logic.

• Improved testability of the business logic code, since it can be tested in isolation from the view.

• Reduced coupling between the view and the controller, since the controller now provides the view with the data it needs, rather than the view fetching it directly from the database.

===2. Cleaning up the grading audit trail code===

Some examples of the types of code that might be redundant or unnecessary code in a project are:

• Commented-out code that is no longer needed

• Unused variables or functions

• Code that's been duplicated or replaced by newer code

• Code that's no longer being executed or has been deprecated

• Code that's no longer compatible with the current system configuration or dependencies

By cleaning up redundant or unnecessary code, we can make the project codebase more efficient, easier to maintain, and less error-prone.

===3. Make the grading audit trail feature read-only===

When a grade is assigned by an instructor, the grading audit trail shows who did it and when it was done. It also includes comments previously provided by other instructors. This information will be stored every time an instructor edits a grade/comment and clicks the save button.

By making the grading audit trail read-only, you can help ensure the integrity of the grading history and record any changes to grades or comments. This can be particularly important in academic settings, where grading data must be accurate and reliable for record-keeping purposes.

===4. Display history in reverse chronological order===

The proposed design change aims to modify the grading audit trail feature to display the grading history in reverse chronological order, with the most recent entries appearing first.

By displaying the grading audit trail in reverse chronological order, instructors can quickly and easily see the most recent changes made to a student's submission, without having to scroll through potentially large amounts of data. This can be particularly useful for identifying recent trends or patterns in a student's work, or for quickly reviewing recent changes made by multiple instructors.
This change can also improve the usability of the feature, as users will be able to quickly find the information, they need without having to manually sort or filter the data themselves.

===5. CSS - Change px to %===

Change the CSS properties like border-width from px units to a percentage value that fits your design needs. For example, you could use 0.1em or 0.5%. This will make the border scale proportionally to the size of the container.

Avoid using fixed width or height values in your CSS code. Instead, use relative values such as percentages or em units to allow your design to adapt to different screen sizes and resolutions. For example, if you want to set the width of the container to 80% of the screen width, you can use width: 80%;.

We can also consider using CSS Grid or Flexbox to create layouts that are more flexible and adaptable. These layout systems allow us to create complex designs that can adapt to different screen sizes and resolutions without the need for fixed width or height values.

6. Fixture of grading history button in review report

7. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.

8. Included comprehensive test cases and comments for thorough testing and documentation purposes.

== Flow Diagram ==

[[File:Grading flow diagram.png]]

[[File:Flow diagram grading.png]]

== Testing Plan ==

Functional testing:

1. Test SubmissionGradeHistory.create: call a submission grade when changed.
spec/controllers/grades_controller_spec.rb

The test cases are defined to check whether the controller action save_grade_and_comment_for_submission can save the grade and comment for a submission, and then redirect to the grades#view_team page with no errors and to check whether the same controller action can catch an error that might occur when saving the grade and comment for a submission, and then raises that error.

[[File:GradesController.png|1000px]]

2. Test ReviewGradeHistory.create: call a submission grade when changed.
spec/controllers/review_mapping_controller_spec.rb

This test case is to ensure that the review grades and comments are saved and that the correct page is redirected to after the action is completed.

[[File:Reviewscontroller.png|1000px]]

3. Test GradeHistory.where: called when grading history button is clicked.
spec/controllers/grading_histories_controller_test.rb

The create test is checking whether the grading history object can be successfully created with valid parameters. It sets up an instance of the grading_history object using the FactoryBot gem and checks whether the expected values for the attributes of the object are returned.

The index test is checking whether the index action of the controller properly handles requests to show grading histories for a particular participant. It sets up an instance of the instructor object and a session object with the instructor user. It then allows the GradingHistory model to receive a create method call with certain arguments and checks whether a GET request to the index action with the appropriate parameters and session redirects to the correct page.

[[File:Screenshot 2023-04-24 a PM.png|1000px]]

=='''Reference'''==
[https://expertiza.ncsu.edu/ Expertiza]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/E1869_GRADING_AUDIT_TRAIL Previous Project Documentation]

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation Expertiza Documentation]

[https://github.com/expertiza/expertiza Expertiza Github]

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2305._Grading_audit_trail]

File:Screenshot 2023-04-24 a PM.png

2023-04-25T02:01:10Z

Sbuddai:

File:GradingHistoriesTest.png

2023-04-25T01:51:18Z

Sbuddai:

File:Assignments proj3.jpeg

2023-04-25T01:40:13Z

Sbuddai:

CSC/ECE 517 Spring 2023 - E2329. Grading audit trail(Project 4)

2023-04-25T01:27:28Z

Sbuddai: /* Testing Plan */

== Team Introduction ==

=== Team Members ===

Sarika Vishwanatham (svishwa2@ncsu.edu)

Chetana Chunduru (cchetan2@ncsu.edu)

Shreya Buddaiahgari (sbuddai@ncsu.edu)

=== Mentor ===

Krishna Saurabh Vankadaru (kvankad@ncsu.edu)

== Problem Description ==
There is no way to determine who graded an assignment after the instructor awarded it a grade. The following data must be recorded and kept in a grading audit trail:

1. The identity of the person who assigned the grade and the time it was completed must be stated.

2. Previous feedback from other instructors must also be kept.
Every time an instructor modifies a grade or comment and presses the save button, this data must be saved.

There are now two places where grading audit trails need to be added:

1. Check your grade: Log in as the instructor, click Manage, then click Assignments. Review Report View

2. Log in as the instructor and select Manage from the Assignments menu. Check out the entries

== Prior Work ==

In the system, the team built a database called grading history that includes information about the instructor, the assignment, the grade type, the student, the grade, the comment, and the timestamp.

They developed a model, a controller, and a view for the "Review Grade" and the "Submission Grade" using the MVC design.

:Model - grading history.rb has a set of properties that includes the following: timestamp, comment, grade type, instructor ID, and assignment ID.

:Controller - grading history controller.rb. E ach time a review grade or submission grade is saved, a new entry is added to the database

:View - index_html.erb.shows the grade history for the current submission or review. A submission record in the system is an existent illustration of this.

Also, they changed the grades controller so that grading history controller.rb will call a function to produce an entry that is saved to the database each time a grade is submitted or amended.The review report error is fixed which wasn't previously generated due some issue. 'Grading_history' table is created and added to database. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.Included comprehensive test cases and comments for thorough testing and documentation purposes.

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

== Design Strategy ==

Although the project is four years old and the merge requests were never merged, the earlier revisions of the project fully satisfied all of the functional requirements of the "grading audit trail" feature. As a result, the changes are obsolete and interfere with the newest Expertiza's ability to create.

1. Improving the separation of concerns

2. Cleaning up the grading audit trail code

3. Make the grading audit trail feature read-only

4. Display history in reverse chronological order

5. CSS - Change px to %

6. Fixture of grading history button in review report

7. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.

8. Included comprehensive test cases and comments for thorough testing and documentation purposes.

== Planned Work ==

===1. Improving the separation of concerns===

The goal here is to move the code snippet from views, which contains some business logic for displaying grading history data, out of the view file and into the controller.
For example, we could find business logic in “app/views/grading_histories/index.html.erb”. To fix this, In the controller action that renders the index.html.erb view, we retrieve the @grading_histories collection and process it to extract the relevant data needed to display on the view. We create a new instance variable, say @grading_history_info, and assign it a hash object containing the extracted data. Then, pass this @grading_history_info variable to the view as part of the render call, so that it's available to the view template. In the index.html.erb view, replace the business logic code snippet with code that accesses the relevant data from the @grading_history_info hash and uses it to populate the view.
By doing this, you have effectively separated the business logic from the view, making it easier to maintain and test each component independently.
Some of the potential benefits of this approach include:

• Improved readability and maintainability of the view code, since it no longer contains complex business logic.

• Improved testability of the business logic code, since it can be tested in isolation from the view.

• Reduced coupling between the view and the controller, since the controller now provides the view with the data it needs, rather than the view fetching it directly from the database.

===2. Cleaning up the grading audit trail code===

Some examples of the types of code that might be redundant or unnecessary code in a project are:

• Commented-out code that is no longer needed

• Unused variables or functions

• Code that's been duplicated or replaced by newer code

• Code that's no longer being executed or has been deprecated

• Code that's no longer compatible with the current system configuration or dependencies

By cleaning up redundant or unnecessary code, we can make the project codebase more efficient, easier to maintain, and less error-prone.

===3. Make the grading audit trail feature read-only===

When a grade is assigned by an instructor, the grading audit trail shows who did it and when it was done. It also includes comments previously provided by other instructors. This information will be stored every time an instructor edits a grade/comment and clicks the save button.

By making the grading audit trail read-only, you can help ensure the integrity of the grading history and record any changes to grades or comments. This can be particularly important in academic settings, where grading data must be accurate and reliable for record-keeping purposes.

===4. Display history in reverse chronological order===

The proposed design change aims to modify the grading audit trail feature to display the grading history in reverse chronological order, with the most recent entries appearing first.

By displaying the grading audit trail in reverse chronological order, instructors can quickly and easily see the most recent changes made to a student's submission, without having to scroll through potentially large amounts of data. This can be particularly useful for identifying recent trends or patterns in a student's work, or for quickly reviewing recent changes made by multiple instructors.
This change can also improve the usability of the feature, as users will be able to quickly find the information, they need without having to manually sort or filter the data themselves.

===5. CSS - Change px to %===

Change the CSS properties like border-width from px units to a percentage value that fits your design needs. For example, you could use 0.1em or 0.5%. This will make the border scale proportionally to the size of the container.

Avoid using fixed width or height values in your CSS code. Instead, use relative values such as percentages or em units to allow your design to adapt to different screen sizes and resolutions. For example, if you want to set the width of the container to 80% of the screen width, you can use width: 80%;.

We can also consider using CSS Grid or Flexbox to create layouts that are more flexible and adaptable. These layout systems allow us to create complex designs that can adapt to different screen sizes and resolutions without the need for fixed width or height values.

6. Fixture of grading history button in review report

7. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.

8. Included comprehensive test cases and comments for thorough testing and documentation purposes.

== Flow Diagram ==

[[File:Grading flow diagram.png]]

[[File:Flow diagram grading.png]]

== Testing Plan ==

Functional testing:

1. Test SubmissionGradeHistory.create: call a submission grade when changed.
spec/controllers/grades_controller_spec.rb

The test cases are defined to check whether the controller action save_grade_and_comment_for_submission can save the grade and comment for a submission, and then redirect to the grades#view_team page with no errors and to check whether the same controller action can catch an error that might occur when saving the grade and comment for a submission, and then raises that error.

[[File:GradesController.png]]

2. Test ReviewGradeHistory.create: call a submission grade when changed.
spec/controllers/review_mapping_controller_spec.rb

This test case is to ensure that the review grades and comments are saved and that the correct page is redirected to after the action is completed.

[[File:Reviewscontroller.png]]

3. Test GradeHistory.where: called when grading history button is clicked.
spec/controllers/grading_histories_controller_test.rb

The create test is checking whether the grading history object can be successfully created with valid parameters. It sets up an instance of the grading_history object using the FactoryBot gem and checks whether the expected values for the attributes of the object are returned.

The index test is checking whether the index action of the controller properly handles requests to show grading histories for a particular participant. It sets up an instance of the instructor object and a session object with the instructor user. It then allows the GradingHistory model to receive a create method call with certain arguments and checks whether a GET request to the index action with the appropriate parameters and session redirects to the correct page.

[[File:GradingHistories.png]]

=='''Reference'''==
[https://expertiza.ncsu.edu/ Expertiza]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/E1869_GRADING_AUDIT_TRAIL Previous Project Documentation]

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation Expertiza Documentation]

[https://github.com/expertiza/expertiza Expertiza Github]

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2305._Grading_audit_trail]

File:Reviewscontroller.png

2023-04-25T01:25:50Z

Sbuddai:

File:GradesController.png

2023-04-25T01:24:53Z

Sbuddai:

File:GradingHistories.png

2023-04-25T01:23:49Z

Sbuddai:

CSC/ECE 517 Spring 2023 - E2329. Grading audit trail(Project 4)

2023-04-25T01:04:57Z

Sbuddai: /* Testing Plan */

== Team Introduction ==

=== Team Members ===

Sarika Vishwanatham (svishwa2@ncsu.edu)

Chetana Chunduru (cchetan2@ncsu.edu)

Shreya Buddaiahgari (sbuddai@ncsu.edu)

=== Mentor ===

Krishna Saurabh Vankadaru (kvankad@ncsu.edu)

== Problem Description ==
There is no way to determine who graded an assignment after the instructor awarded it a grade. The following data must be recorded and kept in a grading audit trail:

1. The identity of the person who assigned the grade and the time it was completed must be stated.

2. Previous feedback from other instructors must also be kept.
Every time an instructor modifies a grade or comment and presses the save button, this data must be saved.

There are now two places where grading audit trails need to be added:

1. Check your grade: Log in as the instructor, click Manage, then click Assignments. Review Report View

2. Log in as the instructor and select Manage from the Assignments menu. Check out the entries

== Prior Work ==

In the system, the team built a database called grading history that includes information about the instructor, the assignment, the grade type, the student, the grade, the comment, and the timestamp.

They developed a model, a controller, and a view for the "Review Grade" and the "Submission Grade" using the MVC design.

:Model - grading history.rb has a set of properties that includes the following: timestamp, comment, grade type, instructor ID, and assignment ID.

:Controller - grading history controller.rb. E ach time a review grade or submission grade is saved, a new entry is added to the database

:View - index_html.erb.shows the grade history for the current submission or review. A submission record in the system is an existent illustration of this.

Also, they changed the grades controller so that grading history controller.rb will call a function to produce an entry that is saved to the database each time a grade is submitted or amended.The review report error is fixed which wasn't previously generated due some issue. 'Grading_history' table is created and added to database. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.Included comprehensive test cases and comments for thorough testing and documentation purposes.

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

== Design Strategy ==

Although the project is four years old and the merge requests were never merged, the earlier revisions of the project fully satisfied all of the functional requirements of the "grading audit trail" feature. As a result, the changes are obsolete and interfere with the newest Expertiza's ability to create.

1. Improving the separation of concerns

2. Cleaning up the grading audit trail code

3. Make the grading audit trail feature read-only

4. Display history in reverse chronological order

5. CSS - Change px to %

6. Fixture of grading history button in review report

7. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.

8. Included comprehensive test cases and comments for thorough testing and documentation purposes.

== Planned Work ==

===1. Improving the separation of concerns===

The goal here is to move the code snippet from views, which contains some business logic for displaying grading history data, out of the view file and into the controller.
For example, we could find business logic in “app/views/grading_histories/index.html.erb”. To fix this, In the controller action that renders the index.html.erb view, we retrieve the @grading_histories collection and process it to extract the relevant data needed to display on the view. We create a new instance variable, say @grading_history_info, and assign it a hash object containing the extracted data. Then, pass this @grading_history_info variable to the view as part of the render call, so that it's available to the view template. In the index.html.erb view, replace the business logic code snippet with code that accesses the relevant data from the @grading_history_info hash and uses it to populate the view.
By doing this, you have effectively separated the business logic from the view, making it easier to maintain and test each component independently.
Some of the potential benefits of this approach include:

• Improved readability and maintainability of the view code, since it no longer contains complex business logic.

• Improved testability of the business logic code, since it can be tested in isolation from the view.

• Reduced coupling between the view and the controller, since the controller now provides the view with the data it needs, rather than the view fetching it directly from the database.

===2. Cleaning up the grading audit trail code===

Some examples of the types of code that might be redundant or unnecessary code in a project are:

• Commented-out code that is no longer needed

• Unused variables or functions

• Code that's been duplicated or replaced by newer code

• Code that's no longer being executed or has been deprecated

• Code that's no longer compatible with the current system configuration or dependencies

By cleaning up redundant or unnecessary code, we can make the project codebase more efficient, easier to maintain, and less error-prone.

===3. Make the grading audit trail feature read-only===

When a grade is assigned by an instructor, the grading audit trail shows who did it and when it was done. It also includes comments previously provided by other instructors. This information will be stored every time an instructor edits a grade/comment and clicks the save button.

By making the grading audit trail read-only, you can help ensure the integrity of the grading history and record any changes to grades or comments. This can be particularly important in academic settings, where grading data must be accurate and reliable for record-keeping purposes.

===4. Display history in reverse chronological order===

The proposed design change aims to modify the grading audit trail feature to display the grading history in reverse chronological order, with the most recent entries appearing first.

By displaying the grading audit trail in reverse chronological order, instructors can quickly and easily see the most recent changes made to a student's submission, without having to scroll through potentially large amounts of data. This can be particularly useful for identifying recent trends or patterns in a student's work, or for quickly reviewing recent changes made by multiple instructors.
This change can also improve the usability of the feature, as users will be able to quickly find the information, they need without having to manually sort or filter the data themselves.

===5. CSS - Change px to %===

Change the CSS properties like border-width from px units to a percentage value that fits your design needs. For example, you could use 0.1em or 0.5%. This will make the border scale proportionally to the size of the container.

Avoid using fixed width or height values in your CSS code. Instead, use relative values such as percentages or em units to allow your design to adapt to different screen sizes and resolutions. For example, if you want to set the width of the container to 80% of the screen width, you can use width: 80%;.

We can also consider using CSS Grid or Flexbox to create layouts that are more flexible and adaptable. These layout systems allow us to create complex designs that can adapt to different screen sizes and resolutions without the need for fixed width or height values.

6. Fixture of grading history button in review report

7. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.

8. Included comprehensive test cases and comments for thorough testing and documentation purposes.

== Flow Diagram ==

[[File:Grading flow diagram.png]]

[[File:Flow diagram grading.png]]

== Testing Plan ==

Functional testing:

1. Test SubmissionGradeHistory.create: call a submission grade when changed.
spec/controllers/grades_controller_spec.rb

The test cases are defined to check whether the controller action save_grade_and_comment_for_submission can save the grade and comment for a submission, and then redirect to the grades#view_team page with no errors and to check whether the same controller action can catch an error that might occur when saving the grade and comment for a submission, and then raises that error.

2. Test ReviewGradeHistory.create: call a submission grade when changed.
spec/controllers/review_mapping_controller_spec.rb

This test case is to ensure that the review grades and comments are saved and that the correct page is redirected to after the action is completed.

3. Test GradeHistory.where: called when grading history button is clicked.
spec/controllers/grading_histories_controller_test.rb

The create test is checking whether the grading history object can be successfully created with valid parameters. It sets up an instance of the grading_history object using the FactoryBot gem and checks whether the expected values for the attributes of the object are returned.

The index test is checking whether the index action of the controller properly handles requests to show grading histories for a particular participant. It sets up an instance of the instructor object and a session object with the instructor user. It then allows the GradingHistory model to receive a create method call with certain arguments and checks whether a GET request to the index action with the appropriate parameters and session redirects to the correct page.

=='''Reference'''==
[https://expertiza.ncsu.edu/ Expertiza]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/E1869_GRADING_AUDIT_TRAIL Previous Project Documentation]

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation Expertiza Documentation]

[https://github.com/expertiza/expertiza Expertiza Github]

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2305._Grading_audit_trail]

CSC/ECE 517 Spring 2023 - E2329. Grading audit trail(Project 4)

2023-04-13T01:24:19Z

Sbuddai: /* Flow Diagram */

== Team Introduction ==

=== Team Members ===

Sarika Vishwanatham (svishwa2@ncsu.edu)

Chetana Chunduru (cchetan2@ncsu.edu)

Shreya Buddaiahgari (sbuddai@ncsu.edu)

=== Mentor ===

Krishna Saurabh Vankadaru (kvankad@ncsu.edu)

== Problem Description ==
There is no way to determine who graded an assignment after the instructor awarded it a grade. The following data must be recorded and kept in a grading audit trail:

1. The identity of the person who assigned the grade and the time it was completed must be stated.

2. Previous feedback from other instructors must also be kept.
Every time an instructor modifies a grade or comment and presses the save button, this data must be saved.

There are now two places where grading audit trails need to be added:

1. Check your grade: Log in as the instructor, click Manage, then click Assignments. Review Report View

2. Log in as the instructor and select Manage from the Assignments menu. Check out the entries

== Prior Work ==

In the system, the team built a database called grading history that includes information about the instructor, the assignment, the grade type, the student, the grade, the comment, and the timestamp.

They developed a model, a controller, and a view for the "Review Grade" and the "Submission Grade" using the MVC design.

:Model - grading history.rb has a set of properties that includes the following: timestamp, comment, grade type, instructor ID, and assignment ID.

:Controller - grading history controller.rb. E ach time a review grade or submission grade is saved, a new entry is added to the database

:View - index_html.erb.shows the grade history for the current submission or review. A submission record in the system is an existent illustration of this.

Also, they changed the grades controller so that grading history controller.rb will call a function to produce an entry that is saved to the database each time a grade is submitted or amended.The review report error is fixed which wasn't previously generated due some issue. 'Grading_history' table is created and added to database. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.Included comprehensive test cases and comments for thorough testing and documentation purposes.

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

== Design Strategy ==

Although the project is four years old and the merge requests were never merged, the earlier revisions of the project fully satisfied all of the functional requirements of the "grading audit trail" feature. As a result, the changes are obsolete and interfere with the newest Expertiza's ability to create.

1. Improving the separation of concerns

2. Cleaning up the grading audit trail code

3. Make the grading audit trail feature read-only

4. Display history in reverse chronological order

5. CSS - Change px to %

6. Fixture of grading history button in review report

7. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.

8. Included comprehensive test cases and comments for thorough testing and documentation purposes.

== Planned Work ==

===1. Improving the separation of concerns===

The goal here is to move the code snippet from views, which contains some business logic for displaying grading history data, out of the view file and into the controller.
For example, we could find business logic in “app/views/grading_histories/index.html.erb”. To fix this, In the controller action that renders the index.html.erb view, we retrieve the @grading_histories collection and process it to extract the relevant data needed to display on the view. We create a new instance variable, say @grading_history_info, and assign it a hash object containing the extracted data. Then, pass this @grading_history_info variable to the view as part of the render call, so that it's available to the view template. In the index.html.erb view, replace the business logic code snippet with code that accesses the relevant data from the @grading_history_info hash and uses it to populate the view.
By doing this, you have effectively separated the business logic from the view, making it easier to maintain and test each component independently.
Some of the potential benefits of this approach include:

• Improved readability and maintainability of the view code, since it no longer contains complex business logic.

• Improved testability of the business logic code, since it can be tested in isolation from the view.

• Reduced coupling between the view and the controller, since the controller now provides the view with the data it needs, rather than the view fetching it directly from the database.

===2. Cleaning up the grading audit trail code===

Some examples of the types of code that might be redundant or unnecessary code in a project are:

• Commented-out code that is no longer needed

• Unused variables or functions

• Code that's been duplicated or replaced by newer code

• Code that's no longer being executed or has been deprecated

• Code that's no longer compatible with the current system configuration or dependencies

By cleaning up redundant or unnecessary code, we can make the project codebase more efficient, easier to maintain, and less error-prone.

===3. Make the grading audit trail feature read-only===

When a grade is assigned by an instructor, the grading audit trail shows who did it and when it was done. It also includes comments previously provided by other instructors. This information will be stored every time an instructor edits a grade/comment and clicks the save button.

By making the grading audit trail read-only, you can help ensure the integrity of the grading history and record any changes to grades or comments. This can be particularly important in academic settings, where grading data must be accurate and reliable for record-keeping purposes.

===4. Display history in reverse chronological order===

The proposed design change aims to modify the grading audit trail feature to display the grading history in reverse chronological order, with the most recent entries appearing first.

By displaying the grading audit trail in reverse chronological order, instructors can quickly and easily see the most recent changes made to a student's submission, without having to scroll through potentially large amounts of data. This can be particularly useful for identifying recent trends or patterns in a student's work, or for quickly reviewing recent changes made by multiple instructors.
This change can also improve the usability of the feature, as users will be able to quickly find the information, they need without having to manually sort or filter the data themselves.

===5. CSS - Change px to %===

Change the CSS properties like border-width from px units to a percentage value that fits your design needs. For example, you could use 0.1em or 0.5%. This will make the border scale proportionally to the size of the container.

Avoid using fixed width or height values in your CSS code. Instead, use relative values such as percentages or em units to allow your design to adapt to different screen sizes and resolutions. For example, if you want to set the width of the container to 80% of the screen width, you can use width: 80%;.

We can also consider using CSS Grid or Flexbox to create layouts that are more flexible and adaptable. These layout systems allow us to create complex designs that can adapt to different screen sizes and resolutions without the need for fixed width or height values.

6. Fixture of grading history button in review report

7. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.

8. Included comprehensive test cases and comments for thorough testing and documentation purposes.

== Flow Diagram ==

[[File:Grading flow diagram.png]]

[[File:Flow diagram grading.png]]

== Testing Plan ==

Functional testing:

1. Test SubmissionGradeHistory.create: call a submission grade when changed.
spec/controllers/grades_controller_spec.rb

2. Test ReviewGradeHistory.create: call a submission grade when changed.
spec/controllers/review_mapping_controller_spec.rb

3. Test GradeHistory.where: called when grading history button is clicked.
spec/controllers/grading_histories_controller_test.rb

Feature Testing:

1. Test the grading history: visible and shown in chronological order?
spec/features/grade_histories_spec.rb
spec/features/helpers/grade_histories_helper.rb

=='''Reference'''==
[https://expertiza.ncsu.edu/ Expertiza]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/E1869_GRADING_AUDIT_TRAIL Previous Project Documentation]

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation Expertiza Documentation]

[https://github.com/expertiza/expertiza Expertiza Github]

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2305._Grading_audit_trail]

CSC/ECE 517 Spring 2023 - E2329. Grading audit trail(Project 4)

2023-04-13T01:23:53Z

Sbuddai:

== Team Introduction ==

=== Team Members ===

Sarika Vishwanatham (svishwa2@ncsu.edu)

Chetana Chunduru (cchetan2@ncsu.edu)

Shreya Buddaiahgari (sbuddai@ncsu.edu)

=== Mentor ===

Krishna Saurabh Vankadaru (kvankad@ncsu.edu)

== Problem Description ==
There is no way to determine who graded an assignment after the instructor awarded it a grade. The following data must be recorded and kept in a grading audit trail:

1. The identity of the person who assigned the grade and the time it was completed must be stated.

2. Previous feedback from other instructors must also be kept.
Every time an instructor modifies a grade or comment and presses the save button, this data must be saved.

There are now two places where grading audit trails need to be added:

1. Check your grade: Log in as the instructor, click Manage, then click Assignments. Review Report View

2. Log in as the instructor and select Manage from the Assignments menu. Check out the entries

== Prior Work ==

In the system, the team built a database called grading history that includes information about the instructor, the assignment, the grade type, the student, the grade, the comment, and the timestamp.

They developed a model, a controller, and a view for the "Review Grade" and the "Submission Grade" using the MVC design.

:Model - grading history.rb has a set of properties that includes the following: timestamp, comment, grade type, instructor ID, and assignment ID.

:Controller - grading history controller.rb. E ach time a review grade or submission grade is saved, a new entry is added to the database

:View - index_html.erb.shows the grade history for the current submission or review. A submission record in the system is an existent illustration of this.

Also, they changed the grades controller so that grading history controller.rb will call a function to produce an entry that is saved to the database each time a grade is submitted or amended.The review report error is fixed which wasn't previously generated due some issue. 'Grading_history' table is created and added to database. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.Included comprehensive test cases and comments for thorough testing and documentation purposes.

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

== Design Strategy ==

Although the project is four years old and the merge requests were never merged, the earlier revisions of the project fully satisfied all of the functional requirements of the "grading audit trail" feature. As a result, the changes are obsolete and interfere with the newest Expertiza's ability to create.

1. Improving the separation of concerns

2. Cleaning up the grading audit trail code

3. Make the grading audit trail feature read-only

4. Display history in reverse chronological order

5. CSS - Change px to %

6. Fixture of grading history button in review report

7. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.

8. Included comprehensive test cases and comments for thorough testing and documentation purposes.

== Planned Work ==

===1. Improving the separation of concerns===

The goal here is to move the code snippet from views, which contains some business logic for displaying grading history data, out of the view file and into the controller.
For example, we could find business logic in “app/views/grading_histories/index.html.erb”. To fix this, In the controller action that renders the index.html.erb view, we retrieve the @grading_histories collection and process it to extract the relevant data needed to display on the view. We create a new instance variable, say @grading_history_info, and assign it a hash object containing the extracted data. Then, pass this @grading_history_info variable to the view as part of the render call, so that it's available to the view template. In the index.html.erb view, replace the business logic code snippet with code that accesses the relevant data from the @grading_history_info hash and uses it to populate the view.
By doing this, you have effectively separated the business logic from the view, making it easier to maintain and test each component independently.
Some of the potential benefits of this approach include:

• Improved readability and maintainability of the view code, since it no longer contains complex business logic.

• Improved testability of the business logic code, since it can be tested in isolation from the view.

• Reduced coupling between the view and the controller, since the controller now provides the view with the data it needs, rather than the view fetching it directly from the database.

===2. Cleaning up the grading audit trail code===

Some examples of the types of code that might be redundant or unnecessary code in a project are:

• Commented-out code that is no longer needed

• Unused variables or functions

• Code that's been duplicated or replaced by newer code

• Code that's no longer being executed or has been deprecated

• Code that's no longer compatible with the current system configuration or dependencies

By cleaning up redundant or unnecessary code, we can make the project codebase more efficient, easier to maintain, and less error-prone.

===3. Make the grading audit trail feature read-only===

When a grade is assigned by an instructor, the grading audit trail shows who did it and when it was done. It also includes comments previously provided by other instructors. This information will be stored every time an instructor edits a grade/comment and clicks the save button.

By making the grading audit trail read-only, you can help ensure the integrity of the grading history and record any changes to grades or comments. This can be particularly important in academic settings, where grading data must be accurate and reliable for record-keeping purposes.

===4. Display history in reverse chronological order===

The proposed design change aims to modify the grading audit trail feature to display the grading history in reverse chronological order, with the most recent entries appearing first.

By displaying the grading audit trail in reverse chronological order, instructors can quickly and easily see the most recent changes made to a student's submission, without having to scroll through potentially large amounts of data. This can be particularly useful for identifying recent trends or patterns in a student's work, or for quickly reviewing recent changes made by multiple instructors.
This change can also improve the usability of the feature, as users will be able to quickly find the information, they need without having to manually sort or filter the data themselves.

===5. CSS - Change px to %===

Change the CSS properties like border-width from px units to a percentage value that fits your design needs. For example, you could use 0.1em or 0.5%. This will make the border scale proportionally to the size of the container.

Avoid using fixed width or height values in your CSS code. Instead, use relative values such as percentages or em units to allow your design to adapt to different screen sizes and resolutions. For example, if you want to set the width of the container to 80% of the screen width, you can use width: 80%;.

We can also consider using CSS Grid or Flexbox to create layouts that are more flexible and adaptable. These layout systems allow us to create complex designs that can adapt to different screen sizes and resolutions without the need for fixed width or height values.

6. Fixture of grading history button in review report

7. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.

8. Included comprehensive test cases and comments for thorough testing and documentation purposes.

== Flow Diagram ==

[[File:Grading flow diagram.png]]

[[File:Flow diagram grading.png]]

== Testing Plan ==

Functional testing:

1. Test SubmissionGradeHistory.create: call a submission grade when changed.
spec/controllers/grades_controller_spec.rb

2. Test ReviewGradeHistory.create: call a submission grade when changed.
spec/controllers/review_mapping_controller_spec.rb

3. Test GradeHistory.where: called when grading history button is clicked.
spec/controllers/grading_histories_controller_test.rb

Feature Testing:

1. Test the grading history: visible and shown in chronological order?
spec/features/grade_histories_spec.rb
spec/features/helpers/grade_histories_helper.rb

=='''Reference'''==
[https://expertiza.ncsu.edu/ Expertiza]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/E1869_GRADING_AUDIT_TRAIL Previous Project Documentation]

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation Expertiza Documentation]

[https://github.com/expertiza/expertiza Expertiza Github]

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2305._Grading_audit_trail]

File:Flow diagram grading.png

2023-04-13T01:23:08Z

Sbuddai:

CSC/ECE 517 Spring 2023 - E2329. Grading audit trail(Project 4)

2023-04-13T00:44:06Z

Sbuddai:

== Team Introduction ==

=== Team Members ===

Sarika Vishwanatham (svishwa2@ncsu.edu)

Chetana Chunduru (cchetan2@ncsu.edu)

Shreya Buddaiahgari (sbuddai@ncsu.edu)

=== Mentor ===

Krishna Saurabh Vankadaru (kvankad@ncsu.edu)

== Problem Description ==
There is no way to determine who graded an assignment after the instructor awarded it a grade. The following data must be recorded and kept in a grading audit trail:

1. The identity of the person who assigned the grade and the time it was completed must be stated.

2. Previous feedback from other instructors must also be kept.
Every time an instructor modifies a grade or comment and presses the save button, this data must be saved.

There are now two places where grading audit trails need to be added:

1. Check your grade: Log in as the instructor, click Manage, then click Assignments. Review Report View

2. Log in as the instructor and select Manage from the Assignments menu. Check out the entries

== Prior Work ==

In the system, the team built a database called grading history that includes information about the instructor, the assignment, the grade type, the student, the grade, the comment, and the timestamp.

They developed a model, a controller, and a view for the "Review Grade" and the "Submission Grade" using the MVC design.

:Model - grading history.rb has a set of properties that includes the following: timestamp, comment, grade type, instructor ID, and assignment ID.

:Controller - grading history controller.rb. E ach time a review grade or submission grade is saved, a new entry is added to the database

:View - index_html.erb.shows the grade history for the current submission or review. A submission record in the system is an existent illustration of this.

Also, they changed the grades controller so that grading history controller.rb will call a function to produce an entry that is saved to the database each time a grade is submitted or amended.The review report error is fixed which wasn't previously generated due some issue. 'Grading_history' table is created and added to database. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.Included comprehensive test cases and comments for thorough testing and documentation purposes.

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

== Design Strategy ==

Although the project is four years old and the merge requests were never merged, the earlier revisions of the project fully satisfied all of the functional requirements of the "grading audit trail" feature. As a result, the changes are obsolete and interfere with the newest Expertiza's ability to create.

1. Improving the separation of concerns

2. Cleaning up the grading audit trail code

3. Make the grading audit trail feature read-only

4. Display history in reverse chronological order

5. CSS - Change px to %

6. Fixture of grading history button in review report

7. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.

8. Included comprehensive test cases and comments for thorough testing and documentation purposes.

== Planned Work ==

===1. Improving the separation of concerns===

The goal here is to move the code snippet from views, which contains some business logic for displaying grading history data, out of the view file and into the controller.
For example, we could find business logic in “app/views/grading_histories/index.html.erb”. To fix this, In the controller action that renders the index.html.erb view, we retrieve the @grading_histories collection and process it to extract the relevant data needed to display on the view. We create a new instance variable, say @grading_history_info, and assign it a hash object containing the extracted data. Then, pass this @grading_history_info variable to the view as part of the render call, so that it's available to the view template. In the index.html.erb view, replace the business logic code snippet with code that accesses the relevant data from the @grading_history_info hash and uses it to populate the view.
By doing this, you have effectively separated the business logic from the view, making it easier to maintain and test each component independently.
Some of the potential benefits of this approach include:

• Improved readability and maintainability of the view code, since it no longer contains complex business logic.

• Improved testability of the business logic code, since it can be tested in isolation from the view.

• Reduced coupling between the view and the controller, since the controller now provides the view with the data it needs, rather than the view fetching it directly from the database.

===2. Cleaning up the grading audit trail code===

Some examples of the types of code that might be redundant or unnecessary code in a project are:

• Commented-out code that is no longer needed

• Unused variables or functions

• Code that's been duplicated or replaced by newer code

• Code that's no longer being executed or has been deprecated

• Code that's no longer compatible with the current system configuration or dependencies

By cleaning up redundant or unnecessary code, we can make the project codebase more efficient, easier to maintain, and less error-prone.

===3. Make the grading audit trail feature read-only===

When a grade is assigned by an instructor, the grading audit trail shows who did it and when it was done. It also includes comments previously provided by other instructors. This information will be stored every time an instructor edits a grade/comment and clicks the save button.

By making the grading audit trail read-only, you can help ensure the integrity of the grading history and record any changes to grades or comments. This can be particularly important in academic settings, where grading data must be accurate and reliable for record-keeping purposes.

===4. Display history in reverse chronological order===

The proposed design change aims to modify the grading audit trail feature to display the grading history in reverse chronological order, with the most recent entries appearing first.

By displaying the grading audit trail in reverse chronological order, instructors can quickly and easily see the most recent changes made to a student's submission, without having to scroll through potentially large amounts of data. This can be particularly useful for identifying recent trends or patterns in a student's work, or for quickly reviewing recent changes made by multiple instructors.
This change can also improve the usability of the feature, as users will be able to quickly find the information, they need without having to manually sort or filter the data themselves.

===5. CSS - Change px to %===

Change the CSS properties like border-width from px units to a percentage value that fits your design needs. For example, you could use 0.1em or 0.5%. This will make the border scale proportionally to the size of the container.

Avoid using fixed width or height values in your CSS code. Instead, use relative values such as percentages or em units to allow your design to adapt to different screen sizes and resolutions. For example, if you want to set the width of the container to 80% of the screen width, you can use width: 80%;.

We can also consider using CSS Grid or Flexbox to create layouts that are more flexible and adaptable. These layout systems allow us to create complex designs that can adapt to different screen sizes and resolutions without the need for fixed width or height values.

6. Fixture of grading history button in review report

7. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.

8. Included comprehensive test cases and comments for thorough testing and documentation purposes.

== Flow Diagram ==

[[File:Grading flow diagram.png]]

== Testing Plan ==

Functional testing:

1. Test SubmissionGradeHistory.create: call a submission grade when changed.
spec/controllers/grades_controller_spec.rb

2. Test ReviewGradeHistory.create: call a submission grade when changed.
spec/controllers/review_mapping_controller_spec.rb

3. Test GradeHistory.where: called when grading history button is clicked.
spec/controllers/grading_histories_controller_test.rb

Feature Testing:

1. Test the grading history: visible and shown in chronological order?
spec/features/grade_histories_spec.rb
spec/features/helpers/grade_histories_helper.rb

=='''Reference'''==
[https://expertiza.ncsu.edu/ Expertiza]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/E1869_GRADING_AUDIT_TRAIL Previous Project Documentation]

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation Expertiza Documentation]

[https://github.com/expertiza/expertiza Expertiza Github]

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2305._Grading_audit_trail]

File:Grading flow diagram.png

2023-04-13T00:42:03Z

Sbuddai:

CSC/ECE 517 Spring 2023 - E2329. Grading audit trail(Project 4)

2023-04-08T01:19:22Z

Sbuddai: /* Design Strategy */

== Team Introduction ==

=== Team Members ===

Sarika Vishwanatham (svishwa2@ncsu.edu)

Chetana Chunduru (cchetan2@ncsu.edu)

Shreya Buddaiahgari (sbuddai@ncsu.edu)

=== Mentor ===

Krishna Saurabh Vankadaru (kvankad@ncsu.edu)

== Problem Description ==
There is no way to determine who graded an assignment after the instructor awarded it a grade. The following data must be recorded and kept in a grading audit trail:

1. The identity of the person who assigned the grade and the time it was completed must be stated.

2. Previous feedback from other instructors must also be kept.
Every time an instructor modifies a grade or comment and presses the save button, this data must be saved.

There are now two places where grading audit trails need to be added:

1. Check your grade: Log in as the instructor, click Manage, then click Assignments. Review Report View

2. Log in as the instructor and select Manage from the Assignments menu. Check out the entries

== Prior Work ==

In the system, the team built a database called grading history that includes information about the instructor, the assignment, the grade type, the student, the grade, the comment, and the timestamp.

They developed a model, a controller, and a view for the "Review Grade" and the "Submission Grade" using the MVC design.

:Model - grading history.rb has a set of properties that includes the following: timestamp, comment, grade type, instructor ID, and assignment ID.

:Controller - grading history controller.rb. E ach time a review grade or submission grade is saved, a new entry is added to the database

:View - index_html.erb.shows the grade history for the current submission or review. A submission record in the system is an existent illustration of this.

Also, they changed the grades controller so that grading history controller.rb will call a function to produce an entry that is saved to the database each time a grade is submitted or amended.The review report error is fixed which wasn't previously generated due some issue. 'Grading_history' table is created and added to database. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.Included comprehensive test cases and comments for thorough testing and documentation purposes.

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

== Design Strategy ==

Although the project is four years old and the merge requests were never merged, the earlier revisions of the project fully satisfied all of the functional requirements of the "grading audit trail" feature. As a result, the changes are obsolete and interfere with the newest Expertiza's ability to create.

1. Improving the separation of concerns

2. Cleaning up the grading audit trail code

3. Make the grading audit trail feature read-only

4. Display history in reverse chronological order

5. CSS - Change px to %

6. Fixture of grading history button in review report

7. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.

8. Included comprehensive test cases and comments for thorough testing and documentation purposes.

== Planned Work ==

===1. Improving the separation of concerns===

The goal here is to move the code snippet from views, which contains some business logic for displaying grading history data, out of the view file and into the controller.
For example, we could find business logic in “app/views/grading_histories/index.html.erb”. To fix this, In the controller action that renders the index.html.erb view, we retrieve the @grading_histories collection and process it to extract the relevant data needed to display on the view. We create a new instance variable, say @grading_history_info, and assign it a hash object containing the extracted data. Then, pass this @grading_history_info variable to the view as part of the render call, so that it's available to the view template. In the index.html.erb view, replace the business logic code snippet with code that accesses the relevant data from the @grading_history_info hash and uses it to populate the view.
By doing this, you have effectively separated the business logic from the view, making it easier to maintain and test each component independently.
Some of the potential benefits of this approach include:

• Improved readability and maintainability of the view code, since it no longer contains complex business logic.

• Improved testability of the business logic code, since it can be tested in isolation from the view.

• Reduced coupling between the view and the controller, since the controller now provides the view with the data it needs, rather than the view fetching it directly from the database.

===2. Cleaning up the grading audit trail code===

Some examples of the types of code that might be redundant or unnecessary code in a project are:

• Commented-out code that is no longer needed

• Unused variables or functions

• Code that's been duplicated or replaced by newer code

• Code that's no longer being executed or has been deprecated

• Code that's no longer compatible with the current system configuration or dependencies

By cleaning up redundant or unnecessary code, we can make the project codebase more efficient, easier to maintain, and less error-prone.

===3. Make the grading audit trail feature read-only===

When a grade is assigned by an instructor, the grading audit trail shows who did it and when it was done. It also includes comments previously provided by other instructors. This information will be stored every time an instructor edits a grade/comment and clicks the save button.

By making the grading audit trail read-only, you can help ensure the integrity of the grading history and record any changes to grades or comments. This can be particularly important in academic settings, where grading data must be accurate and reliable for record-keeping purposes.

===4. Display history in reverse chronological order===

The proposed design change aims to modify the grading audit trail feature to display the grading history in reverse chronological order, with the most recent entries appearing first.

By displaying the grading audit trail in reverse chronological order, instructors can quickly and easily see the most recent changes made to a student's submission, without having to scroll through potentially large amounts of data. This can be particularly useful for identifying recent trends or patterns in a student's work, or for quickly reviewing recent changes made by multiple instructors.
This change can also improve the usability of the feature, as users will be able to quickly find the information, they need without having to manually sort or filter the data themselves.

===5. CSS - Change px to %===

Change the CSS properties like border-width from px units to a percentage value that fits your design needs. For example, you could use 0.1em or 0.5%. This will make the border scale proportionally to the size of the container.

Avoid using fixed width or height values in your CSS code. Instead, use relative values such as percentages or em units to allow your design to adapt to different screen sizes and resolutions. For example, if you want to set the width of the container to 80% of the screen width, you can use width: 80%;.

We can also consider using CSS Grid or Flexbox to create layouts that are more flexible and adaptable. These layout systems allow us to create complex designs that can adapt to different screen sizes and resolutions without the need for fixed width or height values.

6. Fixture of grading history button in review report

7. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.

8. Included comprehensive test cases and comments for thorough testing and documentation purposes.

== Testing Plan ==

Functional testing:

1. Test SubmissionGradeHistory.create: call a submission grade when changed.
spec/controllers/grades_controller_spec.rb

2. Test ReviewGradeHistory.create: call a submission grade when changed.
spec/controllers/review_mapping_controller_spec.rb

3. Test GradeHistory.where: called when grading history button is clicked.
spec/controllers/grading_histories_controller_test.rb

Feature Testing:

1. Test the grading history: visible and shown in chronological order?
spec/features/grade_histories_spec.rb
spec/features/helpers/grade_histories_helper.rb

=='''Reference'''==
[https://expertiza.ncsu.edu/ Expertiza]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/E1869_GRADING_AUDIT_TRAIL Previous Project Documentation]

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation Expertiza Documentation]

[https://github.com/expertiza/expertiza Expertiza Github]

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2305._Grading_audit_trail]

CSC/ECE 517 Spring 2023 - E2329. Grading audit trail(Project 4)

2023-04-08T01:19:01Z

Sbuddai: /* Planned Work */

== Team Introduction ==

=== Team Members ===

Sarika Vishwanatham (svishwa2@ncsu.edu)

Chetana Chunduru (cchetan2@ncsu.edu)

Shreya Buddaiahgari (sbuddai@ncsu.edu)

=== Mentor ===

Krishna Saurabh Vankadaru (kvankad@ncsu.edu)

== Problem Description ==
There is no way to determine who graded an assignment after the instructor awarded it a grade. The following data must be recorded and kept in a grading audit trail:

1. The identity of the person who assigned the grade and the time it was completed must be stated.

2. Previous feedback from other instructors must also be kept.
Every time an instructor modifies a grade or comment and presses the save button, this data must be saved.

There are now two places where grading audit trails need to be added:

1. Check your grade: Log in as the instructor, click Manage, then click Assignments. Review Report View

2. Log in as the instructor and select Manage from the Assignments menu. Check out the entries

== Prior Work ==

In the system, the team built a database called grading history that includes information about the instructor, the assignment, the grade type, the student, the grade, the comment, and the timestamp.

They developed a model, a controller, and a view for the "Review Grade" and the "Submission Grade" using the MVC design.

:Model - grading history.rb has a set of properties that includes the following: timestamp, comment, grade type, instructor ID, and assignment ID.

:Controller - grading history controller.rb. E ach time a review grade or submission grade is saved, a new entry is added to the database

:View - index_html.erb.shows the grade history for the current submission or review. A submission record in the system is an existent illustration of this.

Also, they changed the grades controller so that grading history controller.rb will call a function to produce an entry that is saved to the database each time a grade is submitted or amended.The review report error is fixed which wasn't previously generated due some issue. 'Grading_history' table is created and added to database. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.Included comprehensive test cases and comments for thorough testing and documentation purposes.

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

== Design Strategy ==

Although the project is four years old and the merge requests were never merged, the earlier revisions of the project fully satisfied all of the functional requirements of the "grading audit trail" feature. As a result, the changes are obsolete and interfere with the newest Expertiza's ability to create.

1. Improving the separation of concerns

2. Cleaning up the grading audit trail code

3. Make the grading audit trail feature read-only

4. Display history in reverse chronological order

5. CSS - Change px to %

6. Fixture of grading history button in review report

== Planned Work ==

===1. Improving the separation of concerns===

The goal here is to move the code snippet from views, which contains some business logic for displaying grading history data, out of the view file and into the controller.
For example, we could find business logic in “app/views/grading_histories/index.html.erb”. To fix this, In the controller action that renders the index.html.erb view, we retrieve the @grading_histories collection and process it to extract the relevant data needed to display on the view. We create a new instance variable, say @grading_history_info, and assign it a hash object containing the extracted data. Then, pass this @grading_history_info variable to the view as part of the render call, so that it's available to the view template. In the index.html.erb view, replace the business logic code snippet with code that accesses the relevant data from the @grading_history_info hash and uses it to populate the view.
By doing this, you have effectively separated the business logic from the view, making it easier to maintain and test each component independently.
Some of the potential benefits of this approach include:

• Improved readability and maintainability of the view code, since it no longer contains complex business logic.

• Improved testability of the business logic code, since it can be tested in isolation from the view.

• Reduced coupling between the view and the controller, since the controller now provides the view with the data it needs, rather than the view fetching it directly from the database.

===2. Cleaning up the grading audit trail code===

Some examples of the types of code that might be redundant or unnecessary code in a project are:

• Commented-out code that is no longer needed

• Unused variables or functions

• Code that's been duplicated or replaced by newer code

• Code that's no longer being executed or has been deprecated

• Code that's no longer compatible with the current system configuration or dependencies

By cleaning up redundant or unnecessary code, we can make the project codebase more efficient, easier to maintain, and less error-prone.

===3. Make the grading audit trail feature read-only===

When a grade is assigned by an instructor, the grading audit trail shows who did it and when it was done. It also includes comments previously provided by other instructors. This information will be stored every time an instructor edits a grade/comment and clicks the save button.

By making the grading audit trail read-only, you can help ensure the integrity of the grading history and record any changes to grades or comments. This can be particularly important in academic settings, where grading data must be accurate and reliable for record-keeping purposes.

===4. Display history in reverse chronological order===

The proposed design change aims to modify the grading audit trail feature to display the grading history in reverse chronological order, with the most recent entries appearing first.

By displaying the grading audit trail in reverse chronological order, instructors can quickly and easily see the most recent changes made to a student's submission, without having to scroll through potentially large amounts of data. This can be particularly useful for identifying recent trends or patterns in a student's work, or for quickly reviewing recent changes made by multiple instructors.
This change can also improve the usability of the feature, as users will be able to quickly find the information, they need without having to manually sort or filter the data themselves.

===5. CSS - Change px to %===

Change the CSS properties like border-width from px units to a percentage value that fits your design needs. For example, you could use 0.1em or 0.5%. This will make the border scale proportionally to the size of the container.

Avoid using fixed width or height values in your CSS code. Instead, use relative values such as percentages or em units to allow your design to adapt to different screen sizes and resolutions. For example, if you want to set the width of the container to 80% of the screen width, you can use width: 80%;.

We can also consider using CSS Grid or Flexbox to create layouts that are more flexible and adaptable. These layout systems allow us to create complex designs that can adapt to different screen sizes and resolutions without the need for fixed width or height values.

6. Fixture of grading history button in review report

7. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.

8. Included comprehensive test cases and comments for thorough testing and documentation purposes.

== Testing Plan ==

Functional testing:

1. Test SubmissionGradeHistory.create: call a submission grade when changed.
spec/controllers/grades_controller_spec.rb

2. Test ReviewGradeHistory.create: call a submission grade when changed.
spec/controllers/review_mapping_controller_spec.rb

3. Test GradeHistory.where: called when grading history button is clicked.
spec/controllers/grading_histories_controller_test.rb

Feature Testing:

1. Test the grading history: visible and shown in chronological order?
spec/features/grade_histories_spec.rb
spec/features/helpers/grade_histories_helper.rb

=='''Reference'''==
[https://expertiza.ncsu.edu/ Expertiza]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/E1869_GRADING_AUDIT_TRAIL Previous Project Documentation]

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation Expertiza Documentation]

[https://github.com/expertiza/expertiza Expertiza Github]

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2305._Grading_audit_trail]

CSC/ECE 517 Spring 2023

2023-04-08T00:24:16Z

Sbuddai: /* OSS Projects */

== OSS Projects ==
[[CSC/ECE 517 Spring_2023 -E2306. Refactor user_controller.rb, user.rb and its child classes]]

[[CSC/ECE 517 Spring_2023 - E2320. Reimplement the Question hierarchy]]

[[CSC/ECE 517 Spring_2023 - E2312 + E2313. Reimplement response.rb and responses_controller.rb]]

[[CSC/ECE 517 Spring_2023 - NTNX-1. Support provisioning MongoDb via NDB Kubernetes Operator]]

[[CSC/ECE 517 Spring_2023 - E2316. Reimplement sign_up_sheet_controller.rb]]

[[CSC/ECE 517 Spring_2023 - E2315. Reimplement signed_up_team.rb, sign_up_topic.rb, sign_up_sheet.rb]]

[[CSC/ECE 517 Spring_2023 - E2340. Reimplement signed_up_team.rb, sign_up_topic.rb, sign_up_sheet.rb (Project 4)]]

[[CSC/ECE 517 Spring_2023 - E2323. Refactor DueDate functionality from assignment.rb]]

[[CSC/ECE 517 Spring 2023 - E2317: Reimplement participant.rb]]

[[CSC/ECE 517 Spring 2023 - E2314. Reimplement the response map hierarchy]]

[[CSC/ECE 517 Spring 2023- NTNX-4. Extend NDB operator provision postregresql aws]]

[[CSC/ECE 517 Spring 2023 - E2321. Reimplement QuestionnairesController and QuestionsController]]

[[CSC/ECE 517 Spring 2023 - E2305. Grading audit trail]]

[[CSC/ECE 517 Spring 2023 - E2329. Grading audit trail(Project 4)]]

[[CSC/ECE 517 Spring 2023 - E2309. Refactor Node model and its subclasses]]

[[CSC/ECE 517 Spring 2023 - NTNX-2. Support provisioning mySQL databases via NDB Kubernetes Operator]]

[[CSC/ECE 517 Spring 2023 - E2300. Refactor E1858. Github metrics integration]]

[[CSC/ECE 517 Sping 2023 - E2322: Refactor Questionnaire View to display Bookmark Rating]]

[[CSC/ECE 517 Spring 2023 - NTNX-3. Refactor models to keep profiles (software, compute, network, etc) as optional and use default if not specified]]

[[CSC/ECE_517_Spring_2023_-_E2301._Refactor_review_maping_helper]]

[[CSC/ECE_517_Spring_2023_-_E2337._Reimplement_node_hierarchy]]

[[CSC/ECE_517_Spring_2023_-E2339._Reimplement signed_up_teams_controller and sign_up_topics_controller.rb]]

[[CSC/ECE_517_Spring_2023_-_E2320._Reimplement the Question Hierarchy]]

[[CSC/ECE_517_Spring_2023 - E2341. UI for Participants.rb]]

CSC/ECE 517 Spring 2023 - E2329. Grading audit trail(Project 4)

2023-04-08T00:22:58Z

Sbuddai: /* Planned Work */

== Team Introduction ==

=== Team Members ===

Sarika Vishwanatham (svishwa2@ncsu.edu)

Chetana Chunduru (cchetan2@ncsu.edu)

Shreya Buddaiahgari (sbuddai@ncsu.edu)

=== Mentor ===

Krishna Saurabh Vankadaru (kvankad@ncsu.edu)

== Problem Description ==
There is no way to determine who graded an assignment after the instructor awarded it a grade. The following data must be recorded and kept in a grading audit trail:

1. The identity of the person who assigned the grade and the time it was completed must be stated.

2. Previous feedback from other instructors must also be kept.
Every time an instructor modifies a grade or comment and presses the save button, this data must be saved.

There are now two places where grading audit trails need to be added:

1. Check your grade: Log in as the instructor, click Manage, then click Assignments. Review Report View

2. Log in as the instructor and select Manage from the Assignments menu. Check out the entries

== Prior Work ==

In the system, the team built a database called grading history that includes information about the instructor, the assignment, the grade type, the student, the grade, the comment, and the timestamp.

They developed a model, a controller, and a view for the "Review Grade" and the "Submission Grade" using the MVC design.

:Model - grading history.rb has a set of properties that includes the following: timestamp, comment, grade type, instructor ID, and assignment ID.

:Controller - grading history controller.rb. E ach time a review grade or submission grade is saved, a new entry is added to the database

:View - index_html.erb.shows the grade history for the current submission or review. A submission record in the system is an existent illustration of this.

Also, they changed the grades controller so that grading history controller.rb will call a function to produce an entry that is saved to the database each time a grade is submitted or amended.The review report error is fixed which wasn't previously generated due some issue. 'Grading_history' table is created and added to database. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.Included comprehensive test cases and comments for thorough testing and documentation purposes.

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

== Design Strategy ==

Although the project is four years old and the merge requests were never merged, the earlier revisions of the project fully satisfied all of the functional requirements of the "grading audit trail" feature. As a result, the changes are obsolete and interfere with the newest Expertiza's ability to create.

1. Improving the separation of concerns

2. Cleaning up the grading audit trail code

3. Make the grading audit trail feature read-only

4. Display history in reverse chronological order

5. CSS - Change px to %

6. Fixture of grading history button in review report

== Planned Work ==

===1. Improving the separation of concerns===

The goal here is to move the code snippet from views, which contains some business logic for displaying grading history data, out of the view file and into the controller.
For example, we could find business logic in “app/views/grading_histories/index.html.erb”. To fix this, In the controller action that renders the index.html.erb view, we retrieve the @grading_histories collection and process it to extract the relevant data needed to display on the view. We create a new instance variable, say @grading_history_info, and assign it a hash object containing the extracted data. Then, pass this @grading_history_info variable to the view as part of the render call, so that it's available to the view template. In the index.html.erb view, replace the business logic code snippet with code that accesses the relevant data from the @grading_history_info hash and uses it to populate the view.
By doing this, you have effectively separated the business logic from the view, making it easier to maintain and test each component independently.
Some of the potential benefits of this approach include:

• Improved readability and maintainability of the view code, since it no longer contains complex business logic.

• Improved testability of the business logic code, since it can be tested in isolation from the view.

• Reduced coupling between the view and the controller, since the controller now provides the view with the data it needs, rather than the view fetching it directly from the database.

===2. Cleaning up the grading audit trail code===

Some examples of the types of code that might be redundant or unnecessary code in a project are:

• Commented-out code that is no longer needed

• Unused variables or functions

• Code that's been duplicated or replaced by newer code

• Code that's no longer being executed or has been deprecated

• Code that's no longer compatible with the current system configuration or dependencies

By cleaning up redundant or unnecessary code, we can make the project codebase more efficient, easier to maintain, and less error-prone.

===3. Make the grading audit trail feature read-only===

When a grade is assigned by an instructor, the grading audit trail shows who did it and when it was done. It also includes comments previously provided by other instructors. This information will be stored every time an instructor edits a grade/comment and clicks the save button.

By making the grading audit trail read-only, you can help ensure the integrity of the grading history and record any changes to grades or comments. This can be particularly important in academic settings, where grading data must be accurate and reliable for record-keeping purposes.

===4. Display history in reverse chronological order===

The proposed design change aims to modify the grading audit trail feature to display the grading history in reverse chronological order, with the most recent entries appearing first.

By displaying the grading audit trail in reverse chronological order, instructors can quickly and easily see the most recent changes made to a student's submission, without having to scroll through potentially large amounts of data. This can be particularly useful for identifying recent trends or patterns in a student's work, or for quickly reviewing recent changes made by multiple instructors.
This change can also improve the usability of the feature, as users will be able to quickly find the information, they need without having to manually sort or filter the data themselves.

===5. CSS - Change px to %===

Change the CSS properties like border-width from px units to a percentage value that fits your design needs. For example, you could use 0.1em or 0.5%. This will make the border scale proportionally to the size of the container.

Avoid using fixed width or height values in your CSS code. Instead, use relative values such as percentages or em units to allow your design to adapt to different screen sizes and resolutions. For example, if you want to set the width of the container to 80% of the screen width, you can use width: 80%;.

We can also consider using CSS Grid or Flexbox to create layouts that are more flexible and adaptable. These layout systems allow us to create complex designs that can adapt to different screen sizes and resolutions without the need for fixed width or height values.

6. Fixture of grading history button in review report

== Testing Plan ==

Functional testing:

1. Test SubmissionGradeHistory.create: call a submission grade when changed.
spec/controllers/grades_controller_spec.rb

2. Test ReviewGradeHistory.create: call a submission grade when changed.
spec/controllers/review_mapping_controller_spec.rb

3. Test GradeHistory.where: called when grading history button is clicked.
spec/controllers/grading_histories_controller_test.rb

Feature Testing:

1. Test the grading history: visible and shown in chronological order?
spec/features/grade_histories_spec.rb
spec/features/helpers/grade_histories_helper.rb

=='''Reference'''==
[https://expertiza.ncsu.edu/ Expertiza]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/E1869_GRADING_AUDIT_TRAIL Previous Project Documentation]

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation Expertiza Documentation]

[https://github.com/expertiza/expertiza Expertiza Github]

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2305._Grading_audit_trail]

CSC/ECE 517 Spring 2023 - E2329. Grading audit trail(Project 4)

2023-04-08T00:17:16Z

Sbuddai:

== Team Introduction ==

=== Team Members ===

Sarika Vishwanatham (svishwa2@ncsu.edu)

Chetana Chunduru (cchetan2@ncsu.edu)

Shreya Buddaiahgari (sbuddai@ncsu.edu)

=== Mentor ===

Krishna Saurabh Vankadaru (kvankad@ncsu.edu)

== Problem Description ==
There is no way to determine who graded an assignment after the instructor awarded it a grade. The following data must be recorded and kept in a grading audit trail:

1. The identity of the person who assigned the grade and the time it was completed must be stated.

2. Previous feedback from other instructors must also be kept.
Every time an instructor modifies a grade or comment and presses the save button, this data must be saved.

There are now two places where grading audit trails need to be added:

1. Check your grade: Log in as the instructor, click Manage, then click Assignments. Review Report View

2. Log in as the instructor and select Manage from the Assignments menu. Check out the entries

== Prior Work ==

In the system, the team built a database called grading history that includes information about the instructor, the assignment, the grade type, the student, the grade, the comment, and the timestamp.

They developed a model, a controller, and a view for the "Review Grade" and the "Submission Grade" using the MVC design.

:Model - grading history.rb has a set of properties that includes the following: timestamp, comment, grade type, instructor ID, and assignment ID.

:Controller - grading history controller.rb. E ach time a review grade or submission grade is saved, a new entry is added to the database

:View - index_html.erb.shows the grade history for the current submission or review. A submission record in the system is an existent illustration of this.

Also, they changed the grades controller so that grading history controller.rb will call a function to produce an entry that is saved to the database each time a grade is submitted or amended.The review report error is fixed which wasn't previously generated due some issue. 'Grading_history' table is created and added to database. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.Included comprehensive test cases and comments for thorough testing and documentation purposes.

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

== Design Strategy ==

Although the project is four years old and the merge requests were never merged, the earlier revisions of the project fully satisfied all of the functional requirements of the "grading audit trail" feature. As a result, the changes are obsolete and interfere with the newest Expertiza's ability to create.

1. Improving the separation of concerns

2. Cleaning up the grading audit trail code

3. Make the grading audit trail feature read-only

4. Display history in reverse chronological order

5. CSS - Change px to %

6. Fixture of grading history button in review report

== Planned Work ==

1. Improving the separation of concerns

The goal here is to move the code snippet from views, which contains some business logic for displaying grading history data, out of the view file and into the controller.
For example, we could find business logic in “app/views/grading_histories/index.html.erb”. To fix this, In the controller action that renders the index.html.erb view, we retrieve the @grading_histories collection and process it to extract the relevant data needed to display on the view. We create a new instance variable, say @grading_history_info, and assign it a hash object containing the extracted data. Then, pass this @grading_history_info variable to the view as part of the render call, so that it's available to the view template. In the index.html.erb view, replace the business logic code snippet with code that accesses the relevant data from the @grading_history_info hash and uses it to populate the view.
By doing this, you have effectively separated the business logic from the view, making it easier to maintain and test each component independently.
Some of the potential benefits of this approach include:

• Improved readability and maintainability of the view code, since it no longer contains complex business logic.

• Improved testability of the business logic code, since it can be tested in isolation from the view.

• Reduced coupling between the view and the controller, since the controller now provides the view with the data it needs, rather than the view fetching it directly from the database.

2. Cleaning up the grading audit trail code

Some examples of the types of code that might be redundant or unnecessary code in a project are:

• Commented-out code that is no longer needed

• Unused variables or functions

• Code that's been duplicated or replaced by newer code

• Code that's no longer being executed or has been deprecated

• Code that's no longer compatible with the current system configuration or dependencies

By cleaning up redundant or unnecessary code, we can make the project codebase more efficient, easier to maintain, and less error-prone.

3. Make the grading audit trail feature read-only

When a grade is assigned by an instructor, the grading audit trail shows who did it and when it was done. It also includes comments previously provided by other instructors. This information will be stored every time an instructor edits a grade/comment and clicks the save button.

By making the grading audit trail read-only, you can help ensure the integrity of the grading history and record any changes to grades or comments. This can be particularly important in academic settings, where grading data must be accurate and reliable for record-keeping purposes.

4. Display history in reverse chronological order

The proposed design change aims to modify the grading audit trail feature to display the grading history in reverse chronological order, with the most recent entries appearing first.

By displaying the grading audit trail in reverse chronological order, instructors can quickly and easily see the most recent changes made to a student's submission, without having to scroll through potentially large amounts of data. This can be particularly useful for identifying recent trends or patterns in a student's work, or for quickly reviewing recent changes made by multiple instructors.
This change can also improve the usability of the feature, as users will be able to quickly find the information, they need without having to manually sort or filter the data themselves.

5. CSS - Change px to %

Change the CSS properties like border-width from px units to a percentage value that fits your design needs. For example, you could use 0.1em or 0.5%. This will make the border scale proportionally to the size of the container.

Avoid using fixed width or height values in your CSS code. Instead, use relative values such as percentages or em units to allow your design to adapt to different screen sizes and resolutions. For example, if you want to set the width of the container to 80% of the screen width, you can use width: 80%;.

We can also consider using CSS Grid or Flexbox to create layouts that are more flexible and adaptable. These layout systems allow us to create complex designs that can adapt to different screen sizes and resolutions without the need for fixed width or height values.

6. Fixture of grading history button in review report

== Testing Plan ==

Functional testing:

1. Test SubmissionGradeHistory.create: call a submission grade when changed.
spec/controllers/grades_controller_spec.rb

2. Test ReviewGradeHistory.create: call a submission grade when changed.
spec/controllers/review_mapping_controller_spec.rb

3. Test GradeHistory.where: called when grading history button is clicked.
spec/controllers/grading_histories_controller_test.rb

Feature Testing:

1. Test the grading history: visible and shown in chronological order?
spec/features/grade_histories_spec.rb
spec/features/helpers/grade_histories_helper.rb

=='''Reference'''==
[https://expertiza.ncsu.edu/ Expertiza]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/E1869_GRADING_AUDIT_TRAIL Previous Project Documentation]

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation Expertiza Documentation]

[https://github.com/expertiza/expertiza Expertiza Github]

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2305._Grading_audit_trail]

CSC/ECE 517 Spring 2023 - E2329. Grading audit trail(Project 4)

2023-04-08T00:09:05Z

Sbuddai:

== Team Introduction ==

=== Team Members ===

Sarika Vishwanatham (svishwa2@ncsu.edu)

Chetana Chunduru (cchetan2@ncsu.edu)

Shreya Buddaiahgari (sbuddai@ncsu.edu)

=== Mentor ===

Krishna Saurabh Vankadaru (kvankad@ncsu.edu)

== Problem Description ==
There is no way to determine who graded an assignment after the instructor awarded it a grade. The following data must be recorded and kept in a grading audit trail:

1. The identity of the person who assigned the grade and the time it was completed must be stated.

2. Previous feedback from other instructors must also be kept.
Every time an instructor modifies a grade or comment and presses the save button, this data must be saved.

There are now two places where grading audit trails need to be added:

1. Check your grade: Log in as the instructor, click Manage, then click Assignments. Review Report View

2. Log in as the instructor and select Manage from the Assignments menu. Check out the entries

== Prior Work ==

In the system, the team built a database called grading history that includes information about the instructor, the assignment, the grade type, the student, the grade, the comment, and the timestamp.

They developed a model, a controller, and a view for the "Review Grade" and the "Submission Grade" using the MVC design.

:Model - grading history.rb has a set of properties that includes the following: timestamp, comment, grade type, instructor ID, and assignment ID.

:Controller - grading history controller.rb. E ach time a review grade or submission grade is saved, a new entry is added to the database

:View - index_html.erb.shows the grade history for the current submission or review. A submission record in the system is an existent illustration of this.

Also, they changed the grades controller so that grading history controller.rb will call a function to produce an entry that is saved to the database each time a grade is submitted or amended.The review report error is fixed which wasn't previously generated due some issue. 'Grading_history' table is created and added to database. GUI has been enhanced to ensure compatibility and smooth functioning with the latest version of Expertiza.Included comprehensive test cases and comments for thorough testing and documentation purposes.

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

== Design Strategy ==

Although the project is four years old and the merge requests were never merged, the earlier revisions of the project fully satisfied all of the functional requirements of the "grading audit trail" feature. As a result, the changes are obsolete and interfere with the newest Expertiza's ability to create.

1. Improving the separation of concerns
2. Cleaning up the grading audit trail code
3. Make the grading audit trail feature read-only
4. Display history in reverse chronological order
5. CSS - Change px to %
6. Fixture of grading history button in review report

== Planned Work ==

1. Improving the separation of concerns

The goal here is to move the code snippet from views, which contains some business logic for displaying grading history data, out of the view file and into the controller.
For example, we could find business logic in “app/views/grading_histories/index.html.erb”. To fix this, In the controller action that renders the index.html.erb view, we retrieve the @grading_histories collection and process it to extract the relevant data needed to display on the view. We create a new instance variable, say @grading_history_info, and assign it a hash object containing the extracted data. Then, pass this @grading_history_info variable to the view as part of the render call, so that it's available to the view template. In the index.html.erb view, replace the business logic code snippet with code that accesses the relevant data from the @grading_history_info hash and uses it to populate the view.
By doing this, you have effectively separated the business logic from the view, making it easier to maintain and test each component independently.
Some of the potential benefits of this approach include:
• Improved readability and maintainability of the view code, since it no longer contains complex business logic.
• Improved testability of the business logic code, since it can be tested in isolation from the view.
• Reduced coupling between the view and the controller, since the controller now provides the view with the data it needs, rather than the view fetching it directly from the database.

2. Cleaning up the grading audit trail code

Some examples of the types of code that might be redundant or unnecessary code in a project are:
• Commented-out code that is no longer needed
• Unused variables or functions
• Code that's been duplicated or replaced by newer code
• Code that's no longer being executed or has been deprecated
• Code that's no longer compatible with the current system configuration or dependencies
By cleaning up redundant or unnecessary code, we can make the project codebase more efficient, easier to maintain, and less error-prone.

3. Make the grading audit trail feature read-only

When a grade is assigned by an instructor, the grading audit trail shows who did it and when it was done. It also includes comments previously provided by other instructors. This information will be stored every time an instructor edits a grade/comment and clicks the save button.
By making the grading audit trail read-only, you can help ensure the integrity of the grading history and record any changes to grades or comments. This can be particularly important in academic settings, where grading data must be accurate and reliable for record-keeping purposes.

4. Display history in reverse chronological order

The proposed design change aims to modify the grading audit trail feature to display the grading history in reverse chronological order, with the most recent entries appearing first.
By displaying the grading audit trail in reverse chronological order, instructors can quickly and easily see the most recent changes made to a student's submission, without having to scroll through potentially large amounts of data. This can be particularly useful for identifying recent trends or patterns in a student's work, or for quickly reviewing recent changes made by multiple instructors.
This change can also improve the usability of the feature, as users will be able to quickly find the information, they need without having to manually sort or filter the data themselves.

5. CSS - Change px to %

Change the CSS properties like border-width from px units to a percentage value that fits your design needs. For example, you could use 0.1em or 0.5%. This will make the border scale proportionally to the size of the container.
Avoid using fixed width or height values in your CSS code. Instead, use relative values such as percentages or em units to allow your design to adapt to different screen sizes and resolutions. For example, if you want to set the width of the container to 80% of the screen width, you can use width: 80%;.
We can also consider using CSS Grid or Flexbox to create layouts that are more flexible and adaptable. These layout systems allow us to create complex designs that can adapt to different screen sizes and resolutions without the need for fixed width or height values.

6. Fixture of grading history button in review report

== Testing Plan ==

Functional testing:

1. Test SubmissionGradeHistory.create: call a submission grade when changed.
spec/controllers/grades_controller_spec.rb

2. Test ReviewGradeHistory.create: call a submission grade when changed.
spec/controllers/review_mapping_controller_spec.rb

3. Test GradeHistory.where: called when grading history button is clicked.
spec/controllers/grading_histories_controller_test.rb

Feature Testing:

1. Test the grading history: visible and shown in chronological order?
spec/features/grade_histories_spec.rb
spec/features/helpers/grade_histories_helper.rb

=='''Reference'''==
[https://expertiza.ncsu.edu/ Expertiza]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/E1869_GRADING_AUDIT_TRAIL Previous Project Documentation]

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation Expertiza Documentation]

[https://github.com/expertiza/expertiza Expertiza Github]

[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2023_-_E2305._Grading_audit_trail]

CSC/ECE 517 Spring 2023 - E2329. Grading audit trail(Project 4)

2023-04-07T21:44:35Z

Sbuddai: Created page with "== Team Introduction == === Team Members === Sarika Vishwanatham (svishwa2@ncsu.edu) Chetana Chunduru (cchetan2@ncsu.edu) Shreya Buddaiahgari (sbuddai@ncsu.edu) === Mento..."

CSC/ECE 517 Spring 2023 - E2305. Grading audit trail

2023-03-29T07:35:26Z

Sbuddai:

CSC/ECE 517 Spring 2023 - E2305. Grading audit trail

2023-03-25T20:56:42Z

Sbuddai: /* Team Introduction */

CSC/ECE 517 Spring 2023 - E2305. Grading audit trail

2023-03-25T20:56:22Z

Sbuddai:

== Team Introduction ==

=== Team Member ===

Sarika Vishwanatham (svishwa2@ncsu.edu)

Chetana Chunduru (cchetan2@ncsu.edu)

Shreya Buddaiahgari (sbuddai@ncsu.edu)

=== Mentor ===

Krishna Saurabh Vankadaru (kvankad@ncsu.edu)

== Problem Description ==
There is no way to determine who graded an assignment after the instructor awarded it a grade. The following data must be recorded and kept in a grading audit trail:

1. The identity of the person who assigned the grade and the time it was completed must be stated.

2. Previous feedback from other instructors must also be kept.
Every time an instructor modifies a grade or comment and presses the save button, this data must be saved.

There are now two places where grading audit trails need to be added:

1. Check your grade: Log in as the instructor, click Manage, then click Assignments. Review Report View

2. Log in as the instructor and select Manage from the Assignments menu. Check out the entries

== Prior Work ==

In the system, the team built a database called grading history that includes information about the instructor, the assignment, the grade type, the student, the grade, the comment, and the timestamp.

They developed a model, a controller, and a view for the "Review Grade" and the "Submission Grade" using the MVC design.

:Model - grading history.rb has a set of properties that includes the following: timestamp, comment, grade type, instructor ID, and assignment ID.

:Controller - grading history controller.rb. E ach time a review grade or submission grade is saved, a new entry is added to the database

:View - index_html.erb.shows the grade history for the current submission or review. A submission record in the system is an existent illustration of this.

Also, they changed the grades controller so that grading history controller.rb will call a function to produce an entry that is saved to the database each time a grade is submitted or amended.

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

https://www.youtube.com/watch?v=yyxX_kRYxLc

== General Design Plan ==

Although the project is four years old and the merge requests were never merged, the earlier revisions of the project fully satisfied all of the functional requirements of the "grading audit trail" feature. As a result, the changes are obsolete and interfere with the newest Expertiza's ability to create.

1. Review report was not generated previously due to an error, the issue fixture is taken care.

2. The table which was previously added to the database was not visible, now the table is added again ('''grading_history''')

2. To correct build errors, manually cherry-pick and refine the changes from earlier iterations.

3. Make GUI clean so that it works well with the most recent Expertiza.

4. Provide test cases and 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]]

 

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

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

====Documentation====

# Changes to any files will be documented on this page; the programmatically 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 ==

=== Files added ===

1. grading_history table is created

[[File:WhatsApp Image 2023-03-25 at 4.29.57 PM.jpeg]]

=== Files Modified ===

*app/config/routes.rb

[[File:WhatsApp Image 2023-03-25 at 4.29.57 PM (2).jpeg]]

[[File:WhatsApp Image 2023-03-25 at 4.29.57 PM (3).jpeg]]

*app/controllers/review_mapping_controller.rb
'''

Creates a Grading History Record for every Review grade edited by the instructor for a Student.
'''

* app/views/assignments/list_submissions.html.erb
'''
Add code to support view changes for Grade Record
'''

* app/views/reports/_review_report.html.erb
'''
Add code to support view changes for Grade Record
'''

=== Expected View ===
 
[[File:WhatsApp Image 2023-03-23 at 7.46.59 PM.jpeg]]
 
 
[[File:WhatsApp Image 2023-03-23 at 8.54.40 PM.jpeg]]
 
 
[[File:WhatsApp Image 2023-03-23 at 7.45.43 PM.jpeg]]
 
 
[[File:WhatsApp Image 2023-03-23 at 7.43.59 PM.jpeg]]
 

=='''Reference'''==
[https://expertiza.ncsu.edu/ Expertiza]

[http://wiki.expertiza.ncsu.edu/index.php/CSC/E1869_GRADING_AUDIT_TRAIL Previous Project Documentation]

[https://youtu.be/yyxX_kRYxLc Screencast]

[http://wiki.expertiza.ncsu.edu/index.php/Main_Page Expertiza_wiki]

[http://wiki.expertiza.ncsu.edu/index.php/Expertiza_documentation Expertiza Documentation]

[https://github.com/expertiza/expertiza Expertiza Github]

File:WhatsApp Image 2023-03-23 at 7.43.59 PM.jpeg

2023-03-25T20:55:48Z

Sbuddai: summary report

summary report

File:WhatsApp Image 2023-03-23 at 7.45.43 PM.jpeg

2023-03-25T20:55:16Z

Sbuddai: review report

review report

File:WhatsApp Image 2023-03-23 at 8.54.40 PM.jpeg

2023-03-25T20:54:52Z

Sbuddai: submission record

submission record

File:WhatsApp Image 2023-03-23 at 7.46.59 PM.jpeg

2023-03-25T20:54:17Z

Sbuddai: Grading history

Grading history

CSC/ECE 517 Spring 2023 - E2305. Grading audit trail

2023-03-25T20:50:56Z

Sbuddai:

== Team Introduction ==

=== Team Member ===

Sarika Vishwanatham (svishwa2@ncsu.edu)

Chetana Chunduru (cchetan2@ncsu.edu)

Shreya Buddaiahgari (sbuddai@ncsu.edu)

=== Mentor ===

Krishna Saurabh Vankadaru (kvankad@ncsu.edu)

== Problem Description ==
There is no way to determine who graded an assignment after the instructor awarded it a grade. The following data must be recorded and kept in a grading audit trail:

1. The identity of the person who assigned the grade and the time it was completed must be stated.

2. Previous feedback from other instructors must also be kept.
Every time an instructor modifies a grade or comment and presses the save button, this data must be saved.

There are now two places where grading audit trails need to be added:

1. Check your grade: Log in as the instructor, click Manage, then click Assignments. Review Report View

2. Log in as the instructor and select Manage from the Assignments menu. Check out the entries

== Prior Work ==

In the system, the team built a database called grading history that includes information about the instructor, the assignment, the grade type, the student, the grade, the comment, and the timestamp.

They developed a model, a controller, and a view for the "Review Grade" and the "Submission Grade" using the MVC design.

:Model - grading history.rb has a set of properties that includes the following: timestamp, comment, grade type, instructor ID, and assignment ID.

:Controller - grading history controller.rb. E ach time a review grade or submission grade is saved, a new entry is added to the database

:View - index_html.erb.shows the grade history for the current submission or review. A submission record in the system is an existent illustration of this.

Also, they changed the grades controller so that grading history controller.rb will call a function to produce an entry that is saved to the database each time a grade is submitted or amended.

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

https://www.youtube.com/watch?v=yyxX_kRYxLc

== General Design Plan ==

Although the project is four years old and the merge requests were never merged, the earlier revisions of the project fully satisfied all of the functional requirements of the "grading audit trail" feature. As a result, the changes are obsolete and interfere with the newest Expertiza's ability to create.

1. Review report was not generated previously due to an error, the issue fixture is taken care.

2. The table which was previously added to the database was not visible, now the table is added again ('''grading_history''')

2. To correct build errors, manually cherry-pick and refine the changes from earlier iterations.

3. Make GUI clean so that it works well with the most recent Expertiza.

4. Provide test cases and 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]]

 

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

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

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

== Implementation ==

=== Files added ===

1. grading_history table is created

[[File:WhatsApp Image 2023-03-25 at 4.29.57 PM.jpeg]]

=== Files Modified ===

*app/config/routes.rb

[[File:WhatsApp Image 2023-03-25 at 4.29.57 PM (2).jpeg]]

[[File:WhatsApp Image 2023-03-25 at 4.29.57 PM (3).jpeg]]

*app/controllers/grades_controller.rb

*app/controllers/review_mapping_controller.rb
'''

Creates a Grading History Record for every Review grade edited by the instructor for a Student.
'''

* app/views/assignments/list_submissions.html.erb
'''
Add code to support view changes for Grade Record
'''

* app/views/reports/_review_report.html.erb
'''
Add code to support view changes for Grade Record
'''

File:WhatsApp Image 2023-03-25 at 4.29.57 PM (3).jpeg

2023-03-25T20:48:50Z

Sbuddai: config file

config file

File:WhatsApp Image 2023-03-25 at 4.29.57 PM (2).jpeg

2023-03-25T20:48:05Z

Sbuddai: config file

config file

CSC/ECE 517 Spring 2023 - E2305. Grading audit trail

2023-03-25T20:43:02Z

Sbuddai:

== Team Introduction ==

=== Team Member ===

Sarika Vishwanatham (svishwa2@ncsu.edu)

Chetana Chunduru (cchetan2@ncsu.edu)

Shreya Buddaiahgari (sbuddai@ncsu.edu)

=== Mentor ===

Krishna Saurabh Vankadaru (kvankad@ncsu.edu)

== Problem Description ==
There is no way to determine who graded an assignment after the instructor awarded it a grade. The following data must be recorded and kept in a grading audit trail:

1. The identity of the person who assigned the grade and the time it was completed must be stated.

2. Previous feedback from other instructors must also be kept.
Every time an instructor modifies a grade or comment and presses the save button, this data must be saved.

There are now two places where grading audit trails need to be added:

1. Check your grade: Log in as the instructor, click Manage, then click Assignments. Review Report View

2. Log in as the instructor and select Manage from the Assignments menu. Check out the entries

== Prior Work ==

In the system, the team built a database called grading history that includes information about the instructor, the assignment, the grade type, the student, the grade, the comment, and the timestamp.

They developed a model, a controller, and a view for the "Review Grade" and the "Submission Grade" using the MVC design.

:Model - grading history.rb has a set of properties that includes the following: timestamp, comment, grade type, instructor ID, and assignment ID.

:Controller - grading history controller.rb. E ach time a review grade or submission grade is saved, a new entry is added to the database

:View - index_html.erb.shows the grade history for the current submission or review. A submission record in the system is an existent illustration of this.

Also, they changed the grades controller so that grading history controller.rb will call a function to produce an entry that is saved to the database each time a grade is submitted or amended.

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

https://www.youtube.com/watch?v=yyxX_kRYxLc

== General Design Plan ==

Although the project is four years old and the merge requests were never merged, the earlier revisions of the project fully satisfied all of the functional requirements of the "grading audit trail" feature. As a result, the changes are obsolete and interfere with the newest Expertiza's ability to create.

1. Review report was not generated previously due to an error, the issue fixture is taken care.

2. The table which was previously added to the database was not visible, now the table is added again ('''grading_history''')

2. To correct build errors, manually cherry-pick and refine the changes from earlier iterations.

3. Make GUI clean so that it works well with the most recent Expertiza.

4. Provide test cases and 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]]

 

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

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

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

== Implementation ==

=== Files added ===

1. grading_history table is created

[[File:WhatsApp Image 2023-03-25 at 4.29.57 PM.jpeg]]

File:WhatsApp Image 2023-03-25 at 4.29.57 PM.jpeg

2023-03-25T20:42:23Z

Sbuddai: Grading history table

Grading history table

CSC/ECE 517 Spring 2023

2023-03-22T20:51:32Z

Sbuddai:

CSC/ECE 517 Spring 2023 - E2305. Grading audit trail

2023-03-22T20:50:27Z

Sbuddai:

CSC/ECE 517 Spring 2023 - E2305. Grading audit trail

2023-03-22T19:59:17Z

Sbuddai: CSC/ECE 517 Spring 2023 - E2305. Grading audit trail

CSC/ECE 517 Spring 2023 - E2305. Grading audit trail