CSC/ECE 517 Spring 2024 - E2414 Grading Audit Trail

Problem Statement

NC State faculty members and students use Expertiza Open-Source Website to submit assignments, grade them, form teams, and among other features. The main problem statement for project E2414 is that there is no traceability on who was the instructor that assigned or edited a grade of a submission.

Program Objectives

Grading Audit Trail must be implemented with the following information to be stored:

1. When an instructor assigns a grade, there needs to be an indication of who did it and when it was done.

2. Comments previously provided by other instructors must also be preserved.

This information needs to be stored every time an instructor edits a grade / comments and clicks the save button. The grading audit trail can probably pattern off the submission records history on Expertiza. The submission record page can be reached by logging in as instructor -> Manage -> Assignments -> View Submissions -> History. At the minimum, a grading log entry must include the instructor id, assignment id, student id, grade comment and timestamp.

Implementation

Creating GradingHistoriesController

The grading_histories_controller.rb functionality created on Ruby on Rails application serves as a critical component for managing and displaying the grading history of reviews in an educational setting. Rails ensures the integration with the model and view layers, facilitating a robust and intuitive interface for users to interact with grading data. Through the implementation of callbacks for pre-action configurations and the inclusion of authorization logic via concerns, the application effectively enforces security and role-based access control. This ensures that only authorized users such as administrators, instructors, and teaching assistants can access sensitive grading information based on their association with specific courses or assignments. The controller is adept at handling various user permissions, distinguishing between submission and review grading histories, and organizing all related entries in a user friendly manner by displaying them in reverse chronological order. This organization enhances the application's usability by allowing users to easily navigate through the grading history.

Creating Model GradingHistory

The grading_history.rb model,has been created and enhanced with a refactoring that introduces a class method assignment_for_history. This method significantly extends the model's functionality by determining the context of grading—whether it pertains to a submission or a review based on the type of grading activity. For submissions, it identifies the associated AssignmentTeam using the graded_member_id to retrieve the corresponding assignment. In the case of reviews, it uses the participant_id to find the specific AssignmentParticipant, facilitating a direct link to the reviewed assignment or activity through the ReviewGrade model. This addition underscores the model's pivotal role in not only linking grading records to instructors and assignments via belongs_to associations but also in dynamically determining the relevant assignment context based on grading type. This enhancement bolsters the model's capacity to provide a comprehensive and nuanced tracking mechanism, offering deeper insights into the historical analysis of grading actions across the platform.

Creating Model ReviewGradingHistory

The review_grading_history.rb model, inheriting from the controller, is tailored for peer review grading events, featuring protection against mass-assignment vulnerabilities and establishing a relationship with the Participant class to track review grades within the system.

Creating Model SubmissionGradingHistory

The submission_grading_history.rb model extends the controller to focus on submission-related grading records, leveraging attr_protected to enhance security and associating with the Team class to directly relate grades to submitting teams within the platform.

Creating View grading_histories

In the view for grading_histories, the _form.html employs a form builder to neatly handle both the creation and updating of grading history entries. The form is designed to alert users to any validation errors by enumerating them clearly at the top of the form, and it also provides immediate feedback. Once all validation requirements are satisfied, the form offers a straightforward 'Save' submission button, making the process of recording grading actions intuitive and efficient.

The index.html view for grading_histories has been created to enhance performance and readability. It presents a grade history in a striped table format, centered around a dynamic header that adapts to display grading information pertinent to submissions or reviews. The created and refactored code uses conditional logic to efficiently handle potential nil records, ensuring that the display adapts gracefully in the absence of grading data. When available, the table populates with comprehensive details such as the instructor's full name, grade, comments, and the precise timestamp of grading—presented in an orderly fashion.

Creating Spec Feature GradeHistories

Our feature spec grade_histories_spec.rb employs the GradeHistoriesHelperSpec module to ensure that the grading audit trail behaves as intended. The spec is structured to set up the testing environment with assignment_setup and make_submission before each test case. In the first scenario, the spec verifies the visibility of the grade history for a given submission, simulating an instructor's interaction with the grading interface. It tests the workflow of assigning a grade and commenting on a submission, and then it ensures that these details appear correctly on the grading history page. The second scenario checks that the grade history entries are presented in reverse chronological order. It mimics the instructor grading a submission twice, adding comments each time. After saving these grades, the spec confirms that the most recent comment appears first on the grading history page. By using capybara's page and table methods, the spec can navigate through the web pages and verify the content and order of the grading entries on the page. These tests collectively ensure that the grade audit trail feature is not only functioning correctly but also displaying the grading information in an orderly and expected manner, which is crucial for maintaining transparency and accountability in the grading process.

Creating Spec Helper GradeHistories

The grade_histories_helper_spec.rb module is designed to provide a scaffold for feature tests related to grade histories. It consists of setup procedures that lay the groundwork for a consistent and controlled testing environment. The assignment_setup method within the module encapsulates the creation of an assignment with predefined characteristics, a list of participants, various deadline types, and corresponding deadline rights. This method simulates the environment needed for an assignment's lifecycle, including submission and review processes. Moreover, the helper includes a make_submission method, automating the steps a student would take to submit a link to their work. This encompasses navigating to the assignment page, entering the submission details, and executing the submission action. The combination of these methods in the spec helper allows for a seamless transition into actual test scenarios, ensuring that each feature test for grading histories can run in an environment that closely mimics the real application state. This leads to more reliable test outcomes and a robust verification process for the grading audit trail functionality within the application.

Updating Grades Controller

We introduced important functionalities to improve grading transparency and history tracking on the grades_controller.rb. An addition to the save_grade_and_comment_for_submission method is the creation of a GradingHistory record each time a submission is graded. This record stores vital information, including the instructor's ID, assignment ID, the type of graded item ('Submission'), the graded team's ID, along with the given grade and accompanying comment. This development is a significant stride in grading auditability, as it ensures every grading action is logged and traceable within the system. The method also encapsulates error handling to alert users in the event of a failure in saving the grade and comment, thereby maintaining a user-friendly interface.

Updating Review Mapping Controller

We integrated a robust suite of methods to facilitate peer review assignments and management within our educational platform on the review_mapping_controller.rb. The introduction of dynamic reviewer assignments allows for flexible peer evaluation processes, aligning with the evolving needs of academic settings. The calibration feature provides a mechanism for instructors to gauge the quality of reviews, ensuring that the assessment process is both fair and consistent. One the most important improvements is the inclusion of grading history records for reviews. With this feature, the grading process for reviewers is not just a transitory evaluation but a documented history, contributing to transparent and traceable assessment practices. This aspect of the enhancement not only adds depth to the instructor's oversight capabilities but also enriches the feedback loop for students. The controller now supports more organized review policies, checking for outstanding reviews and allowing assignments to adhere strictly to the configured review limits. These checks prevent over-assignment of reviews, thereby maintaining a balanced workload among participants and ensuring the quality of peer assessments. The enhanced error handling and user feedback mechanisms contribute to a smoother user experience by providing clearer guidance and actionable insights during exception scenarios, such as attempting to delete a review mapping in progress or assigning a self-review.

Updating Review Grade Model

The review_grade.rb model was updated with the find_graded_member method contribute to deepening the contextual understanding of review grades within the system. This method introduces the ability to directly associate a graded review with its corresponding assignment through the participant's parent relationship. By encapsulating this logic within the model, the system design adheres more closely to the principles of object-oriented programming, promoting encapsulation and cohesion. This change has a more intuitive and maintainable approach to accessing assignment details from a review grade instance. The find_graded_member method abstracts the complexity of traversing associated records, thereby simplifying external calls and enhancing code readability.

Updating Views Assignment List Submissions

The new code added for the assignments/list_submissions.html.erb fil introduces additional functionality for displaying submission history and grading history. This would provide instructors and TAs with direct links to view the history of submissions and the grading actions performed, which contributes to a more informative and interactive user experience.This change reflects a focus on usability, by offering a more granular view of each team's progress and assessment over time. The addition of links like "Submission History" and "Grading History" would be helpful for users who need to track changes, reviews, and grades over the course of an assignment. It simplifies the workflow for instructors and TAs, consolidating relevant historical data in a single, accessible location. It is also important to note the thoughtful design decision to separate "Submission History" from "Grading History," recognizing that users might be interested in these two aspects independently.