CSC/ECE 517 Spring 2024 - E2443 Reimplement grades controller

From Expertiza_Wiki
Jump to navigation Jump to search

Expertiza

Expertiza is an open-source web application built on Ruby on Rails that enables instructors to create customized assignments with topic lists for students to choose from. It facilitates team formation, allowing students to collaborate on assignments and projects. Expertiza supports peer review processes where students can provide feedback on each other's submissions across various document formats, including URLs and wiki pages. This freely available platform provides a flexible and comprehensive solution for managing assignments, teamwork, and peer evaluations.

Introduction

We're refactoring the grades_controller.rb in Expertiza, enhancing its codebase to adhere to DRY and design principles, improving readability, and reducing redundancy. Our focus includes thorough rswag testing of the grades_controller method and demonstrating Swagger UI integration.

Problem Statement

The reimplementation project entails:

  1. Refactoring Grades Controller: Enhancing code clarity, optimizing loops, and adding comments for unclear lines of code to improve maintainability and readability.
  2. Removing Redundant Methods: Identifying and eliminating unused methods in the controller to reduce complexity and streamline functionality.
  3. CRUD Operations: Implementing CRUD operations (Create, Read, Update, Delete) in the controller for efficient data management.
  4. Adherence to DRY Principle: Ensuring that the reimplementation follows the Don't Repeat Yourself (DRY) principle to avoid duplication and improve code efficiency.
  5. Testing with RSwag: Writing comprehensive tests using RSwag for each controller method to ensure functionality and integration with Swagger UI, followed by a video demonstration showcasing the Swagger UI integration and functionality of the reimplemented controller.

Class UML Diagram

UML Diagram

Plan for Reimplementation of GradesController

Code Clarity:

Existing methods such as view, view_my_scores, and view_team will undergo refinement to improve clarity and readability. This includes adding inline comments within complex methods to provide better understanding. Additionally, loops within make_chart will be streamlined for improved performance, while conditional statements within action_allowed? will be simplified for easier comprehension.

Authorization Logic:

Authorization logic within controller actions will be refined to simplify the process and improve error handling. This involves extracting authorization concerns into separate methods like student_privileges_allowed?, ta_privileges_allowed?, etc. Furthermore, error messages within action_allowed? will be enhanced to provide clearer feedback to users in case of access denial.

View Method Optimization:

In view methods like view, view_my_scores, and view_team, efforts will be made to streamline code and reduce dependencies. This includes optimizing database queries to improve performance and removing redundant code to enhance maintainability.

Edit and Update Actions:

Edit and update actions such as edit and update will be enhanced to adhere to RESTful conventions. Specifically, parameter handling will be simplified to ensure consistency and robust error handling will be implemented to gracefully handle invalid input.

Chart Generation Optimization:

Chart generation methods will be optimized to improve efficiency and scalability. This includes implementing caching mechanisms for precomputed data within make_chart to enhance responsiveness. Additionally, exploration of client-side rendering using JavaScript libraries like Chart.js will be considered to further improve performance.

Self-Review Logic Enhancement:

Self-review logic within self_review_finished? will undergo validation to ensure accuracy and effectiveness. This includes refining edge cases where self-review completion may not be accurately detected and enhancing user guidance for a smoother experience.

Redirection Logic Improvement:

Redirection logic within redirect_when_disallowed will be improved to simplify and consolidate redirection processes. This involves enhancing error handling to provide clearer feedback to users and optimizing redirection logic to minimize unnecessary redirects.

Comprehensive Testing with RSwag:

Comprehensive testing with RSwag will be conducted to validate API endpoints and ensure thorough test coverage. This includes writing tests for each controller method, covering both positive and negative test cases, and integrating automated testing into the CI pipeline for consistency and reliability.

Reimplementation of GradesController

Implementation of APIs

In the context of the project "E2443. Reimplement grades_controller" for the Expertiza platform, the modifications made to the routes.rb file for the GradesController are intended to streamline and enhance the existing functionality related to grading. These routing configurations play a critical role in structuring how grade-related requests are processed and responded to within the application.

The specific routes added under the grades resource leverage a nested structure to facilitate clear and organized handling of various grade-related actions, ensuring that each action pertains directly to individual grade entities identified by :id, being the participant ID.

Breakdown of Routes

  • View Team (:id/view_team) - This endpoint retrieves detailed information about the team associated with a specific assignment participant. It is crucial for scenarios where assessments or grades are team-based. The API fetches the participant's team and provides comprehensive details, including the team members and their contributions to assignments. This functionality supports collaborative assessments and enhances transparency in team-based grading.

 def view_team
   participant = AssignmentParticipant.find(params[:id])
   assignment = participant.assignment
   team = participant.team
   questionnaires = assignment.questionnaires
   questions = retrieve_questions(questionnaires, assignment.id)
   pscore = participant_scores(participant, questions)

   render json: { participant:, assignment:, team:, questions:, pscore:}
 end

  • View Grade Details (:id/view) - This endpoint allows for viewing all relevant details of an assignment for a particular participant. It aggregates data such as related questionnaires, questions, and scores, providing a holistic view of the grading criteria and results. This function is particularly valuable for providing a comprehensive breakdown of scores across different review rounds, assisting in a deeper understanding of how grades were allocated.

 def view
   assignment = Assignment.find(params[:id])
   questionnaires = assignment.questionnaires
   if assignment.num_review_rounds > 1
     questions = retrieve_questions questionnaires, assignment.id
   else
     questions = {}
     questionnaires.each do |questionnaire|
       questions[questionnaire.symbol] = questionnaire.questions
     end
   end
   scores = review_grades(assignment, questions)
   num_reviewers_assigned_scores = scores[:teams].length
   averages = vector(scores)
   avg_of_avg = mean(averages)
   render json: { scores:, averages:, avg_of_avg:, num_reviewers_assigned_scores: }
 end

  • View Scores (:id/view_scores) - This API endpoint is designed to show scores for a specific assignment participant. It provides detailed insights into how participants are performing in the ongoing assignments and the various stages of assignment completion. This is essential for tracking academic progress and identifying areas where students may need additional support or recognition.

 def view_scores
   participant = AssignmentParticipant.find(params[:id])
   assignment = participant.assignment
   # questionnaires = assignment.questionnaires
   # questions = retrieve_questions questionnaires, assignment.id
   # pscore = participant_scores(participant, questions)
   topic_id = SignedUpTeam.topic_id(participant.assignment.id, participant.user_id)
   stage = assignment.current_stage(topic_id)

   render json: { participant: }
 end

  • Update Grade (:id/update) - This endpoint enables updating the grade for a participant. It accepts a new grade value and updates the participant’s record if the new grade differs from the existing one. This API is crucial for situations where grades need to be revised or corrected, ensuring that grading remains dynamic and reflective of actual student performance and any subsequent reviews or reassessments.

  • Show Grade (:id) - This endpoint provides a detailed view of a participant's assignment by fetching and displaying all relevant information such as the assignment details, participant info, related questions, and scores. This function is a vital read operation that allows instructors and students to access complete information on a participant's performance in a specific assignment.

  • Action Allowed (:id/action_allowed) - This endpoint checks if a particular action is allowed for the current user, based on the user’s role and the specific action they intend to perform (like viewing scores). It ensures that operations are conducted within established permissions, enhancing security and role-based access control within the application. This is critical for maintaining the integrity of the grading process and ensuring that only authorized actions are executed.

  • Save Grade and Comment (:id/save_grade_and_comment_for_submission) - This API allows for the saving of grades and comments for a specific submission. It is designed to capture both quantitative and qualitative feedback, storing this information securely and making it accessible for review. This endpoint is particularly important for providing feedback that is integral to educational environments, fostering a constructive and informative feedback loop.

These routes collectively support the essential CRUD operations needed for managing grades within the Expertiza system. By carefully defining these routes, the project ensures that grade management is handled in a structured and efficient manner, thereby reducing redundancy and enhancing the overall system architecture. This reimplementation fosters better scalability and easier maintenance, adhering to improved software design principles and practices.

Implementation of Spec file

The specification file for the Grades API provides comprehensive testing scenarios for various endpoints within the Api::V1::GradesController. This document is crafted using RSpec, a popular testing framework for Ruby applications, and employs the Swagger tool to describe and document the API endpoints. The focus is on ensuring that the controller behaves as expected across different use cases, adhering to both functional and non-functional requirements. Here is a detailed explanation of the test cases outlined in the specification:

Testing Framework and Tools

  • RSpec is utilized for writing and executing the test cases, providing a DSL (Domain-Specific Language) that is readable and expressive.
  • Swagger helps in documenting the API, which not only serves for testing but also acts as a live documentation for developers and users of the API.

Endpoints and Test Scenarios

  • GET /api/v1/grades/{id}/view - This endpoint tests the functionality to view detailed grade information for a specific ID.The test ensures that upon receiving a valid ID, the system returns a 200 status code indicating a successful operation.
  • GET /api/v1/grades/{id}/view_team - Tests the ability to retrieve team details associated with a specific grade.A 200 status code response is expected when valid data is provided, confirming the correct retrieval of team information.
  • GET /api/v1/grades/{id}/view_scores - Focuses on viewing scores for a specific grade.The test confirms that the endpoint returns a 200 status when executed with a correct ID, displaying the scores accurately.
  • PUT /api/v1/grades/{id}/update - Tests the grade update functionality. This endpoint expects a JSON body with grade details.Two scenarios are tested: successful grade update (200 status) and failure due to missing required attributes (422 status), ensuring robust error handling and data validation.
  • GET /api/v1/grades/{id} - Simple retrieval of grade details. The test verifies that the endpoint fetches and returns the correct grade information, indicated by a 200 success status.
  • GET /api/v1/grades/{id}/action_allowed - Checks if a certain action is permissible for a given grade ID. It tests for both allowed (200 status) and not allowed scenarios (403 status), important for validating access control mechanisms.
  • PUT /api/v1/grades/{id}/save_grade_and_comment_for_submission - This test ensures that grades and comments can be successfully saved for a submission. The parameters are passed via query strings, and the test checks for a successful save operation (200 status).

Importance of These Tests

The specified tests are essential for maintaining the integrity and reliability of the Grades API. They ensure that:

  • The API responds correctly under various conditions.
  • Data integrity is maintained with correct inputs and handling of incorrect or partial inputs.
  • Security and access control measures are effective, particularly in verifying user permissions.

This meticulous testing setup reflects a commitment to quality and robustness in the software development lifecycle, crucial for applications like Expertiza that are used in educational settings. These tests contribute directly to the project's aim of enhancing maintainability, readability, and adherence to the DRY principle within the grades_controller.

Swagger File Implementation

The Swagger file uses YAML format to describe the HTTP routes, parameters, and responses for the API. Each path is clearly defined with required parameters and expected responses, facilitating automatic documentation generation and client code generation.

GET /grades/{id}/view_team

Summary: Retrieve team details associated with a specific grade.

Response 200: Indicates successful retrieval of the team details. Parameter: id (integer, required) - the unique identifier for a grade.

GET /grades/{id}/view

Summary: Fetch comprehensive details about a specific grade.

Response 200: Successful operation, returning complete grade details.

GET /grades/{id}/view_scores

Summary: Obtain scoring details for a specific grade.

Response 200: Successful retrieval of score data.

PUT /grades/{id}/update

Summary: Update details of a specific grade.

Response 200: Confirmation of successful update.

GET /grades/{id}

Summary: Access detailed information about a specific grade.

Response 200: Successful operation, showing detailed grade data.

GET /grades/{id}/action_allowed

Summary: Check permissions for performing certain actions on a grade.

Response 200: Successful verification of allowed actions.

POST /grades/{id}/save_grade_and_comment_for_submission

Summary: Save a grade along with a comment for a specific submission.

Response 200: Successfully saved the grade and comment.

Importance and Usage

  • Standardization and Documentation: Swagger files like this one help in standardizing API practices across development teams, providing a consistent and predictable interface. It ensures that all team members, including backend and frontend developers, understand the API’s functionality and constraints without diving into the codebase.
  • Client SDK Generation: Tools such as Swagger Codegen can utilize this file to automatically generate client libraries in various programming languages, which can accelerate development and integration efforts.
  • Interactive API Documentation: Swagger UI can render this file into interactive API documentation that allows developers to perform live API calls for testing purposes, greatly enhancing the developer experience and easing troubleshooting and testing.

The careful organization and detailed descriptions in the Swagger file are critical for maintaining the robustness and reliability of the API, aligning with best practices in API design and documentation. This approach supports the project's goal to improve maintainability and readability of the grades_controller, ensuring that the API is both accessible and functional.

Implementation of Helper Files

The recently implemented helper modules—AssignmentHelper, AuthorizationHelper, GradesHelper, PenaltyHelper, and StudentTaskHelper—serve as foundational components that augment the functionality of the Expertiza system. Each module encapsulates specific, reusable logic that interfaces with various aspects of the system, promoting a modular, maintainable, and DRY codebase. Here’s a comprehensive breakdown of each helper module:

AssignmentHelper

This module provides utility functions tailored to manage and manipulate course and assignment data:

  • course_options: Generates a list of courses available to the user based on their role, such as teaching assistants seeing only their courses, while administrators can view all courses.
  • questionnaire_options: Filters questionnaires based on visibility and association with the instructor, allowing users to select questionnaires relevant to their role.
  • review_strategy_options and due_date: These functions assist in setting up review strategies for assignments and managing due dates respectively, essential for assignment creation and editing.

AuthorizationHelper

Focused on security, this module determines the access level of users within the system:

  • current_user_has_..._privileges? methods check the user’s role against required privileges, ensuring actions are permitted before proceeding.
  • current_user_is_assignment_participant? and similar methods validate user participation in specific contexts, crucial for enforcing role-based actions within assignments.

GradesHelper

This module aids in the handling and display of grades and related functionalities:

  • accordion_title and score_vector: These functions manage the display of structured data, such as grouping related responses under a common header in the UI.
  • vector and mean: Utilized for statistical calculations to derive insights from grade data, supporting detailed analytical features like average scores.

PenaltyHelper

Manages the calculation of penalties based on assignment deadlines and submission timelines:

  • calculate_penalty and its associated methods (calculate_submission_penalty, calculate_review_penalty, etc.) assess penalties for late submissions and incomplete reviews, ensuring students are graded fairly based on timeliness and compliance with deadlines.

StudentTaskHelper

Enhances the student interaction with tasks and reviews:

  • get_review_grade_info and get_awarded_badges: Provide visual feedback and recognition for students’ efforts, which are crucial for motivation and engagement.
  • check_reviewable_topics and unsubmitted_self_review?: These functions check for reviewable topics and monitor the submission status of self-reviews, critical for maintaining the integrity and progression of peer reviews.

Integration and Impact

The integration of these helper modules significantly enhances the system's robustness by segregating responsibilities into distinct, manageable components. This approach not only simplifies the main application logic but also enhances code readability and maintenance—core aims of the project. By refining the backend architecture through these helpers, the system can more easily adapt to new requirements and facilitate smoother updates and enhancements.

Incorporating these modules into the Expertiza platform effectively addresses key project objectives, including adherence to DRY principles, improved maintainability, and ensuring a scalable architecture that can handle the evolving needs of educational environments. These improvements directly contribute to a more stable, efficient, and user-friendly grading system.

Implementation of Migration files

These migration files represent changes to the database schema in a Ruby on Rails application using ActiveRecord. Let's go through each migration file and explain its purpose:

  • CreateDeadlineTypes: This migration creates a table called deadline_types with a name column. It also inserts some initial data into this table.
  • CreateLatePolicies: This migration creates a table called late_policies with columns for penalty period, penalty per unit, whether the penalty is expressed as a percentage, and maximum penalty. It also inserts initial data into this table and adds an index on the penalty_period_in_minutes column.
  • CreateDueDates: This migration creates a table called due_dates with columns for due date, deadline type ID, assignment ID, late policy ID, and flags for submission, review, resubmission, rereview, and review of review permissions. It adds foreign key constraints to reference other tables and indexes on various columns.
  • ChangeAssignmentIdInDueDatesTableToParentId: This migration renames the assignment_id column in the due_dates table to parent_id and removes the foreign key constraint on it. This seems to be part of a restructuring where assignment_id is renamed to parent_id in several tables.
  • CreateTeams: This migration creates a table called teams with a name column and an assignment_id column, which references the assignments table. It adds a foreign key constraint on the assignment_id column.
  • ChangeAssignmentIdInParticipantsTableToParentId: This migration renames the assignment_id column in the participants table to parent_id and removes the foreign key constraint on it.
  • ChangeAssignmentIdInTeamsTableToParentId: This migration renames the assignment_id column in the teams table to parent_id and removes the foreign key constraint on it.
  • AddUsedInRoundToAssignmentQuestionnaires: This migration adds a column called used_in_round to the assignment_questionnaires table.
  • UpdateParticipants: This migration adds columns for grade, comments_to_student, and private_instructor_comments to the participants table.
  • CreateTeamsUsers: This migration creates a join table called teams_users to establish a many-to-many relationship between teams and users. It adds foreign key constraints for both team_id and user_id.

Use of Design and Dry Principles

In the provided GradesController code, several design principles and DRY (Don't Repeat Yourself) principles have been applied to ensure a clean and maintainable codebase. Let's break down the implementation and discuss how these principles are reflected:

Modularization and Inclusion of Concerns

The controller includes several modules like Scoring, PenaltyHelper, StudentTaskHelper, AssignmentHelper, GradesHelper, and AuthorizationHelper. This modularization helps in organizing related functionalities into separate files, promoting better code organization and reusability. Each module encapsulates related methods and concerns, promoting separation of concerns and making the codebase more modular.

Single Responsibility Principle (SRP)

Methods within the controller have clear and specific responsibilities. For example, view, view_scores, view_team, edit, show, update, and save_grade_and_comment_for_submission methods handle specific actions related to grading, viewing, and updating grades. This adherence to SRP makes the code easier to understand, test, and maintain as each method focuses on a single task.

Conditional Handling with Case Statements

The action_allowed method utilizes a case statement to handle different actions based on the parameters received. This approach makes the code more readable and maintainable compared to using multiple nested if-else statements. Each case in the statement handles a specific action, improving code organization and readability.

Code Reuse and DRY Principle

Common functionalities are abstracted into helper modules (GradesHelper, PenaltyHelper, etc.) and included where needed. For example, methods like participant_scores, calculate_penalty, retrieve_questions, etc., are reused across different controller actions. By extracting shared functionalities into helper modules, the code adheres to the DRY principle, reducing redundancy and promoting code reuse.

Comments and Documentation

The code includes comments explaining the purpose of methods, API endpoints, and complex logic. Comments are used judiciously to provide clarity where necessary. While comments are helpful, they should ideally focus on explaining why certain decisions were made or complex logic was implemented rather than simply restating what the code does.

Private Methods for Encapsulation

Private methods like set_assignment, list_questions, and self_review_finished? encapsulate internal implementation details and are not accessible outside the controller. This encapsulation hides complexity and promotes cleaner interfaces.

Error Handling

Error handling is implemented using rescue_from for ActiveRecord::RecordNotFound and StandardError. This ensures graceful handling of exceptions and provides meaningful error responses to clients. Overall, the GradesController demonstrates good adherence to design principles like SRP, modularity, DRY, encapsulation, and error handling. The code is well-structured, readable, and follows best practices for building maintainable Rails applications.

Design Principles

Single Responsibility Principle (SRP):

  • Each action in the GradesController will be responsible for a specific task related to managing grades.
  • Actions will be refactored to separate concerns such as data retrieval, computation, and view rendering.
  • For example, the `view` action will focus solely on retrieving grading data and rendering the grading report.

Don't Repeat Yourself (DRY) Principle:

  • Code duplication in the GradesController will be eliminated by extracting common functionality into helper methods or modules.
  • Repetitive logic, such as retrieving questions or calculating penalties, will be refactored to promote code reusability and maintainability.

Encapsulation:

  • Data and behavior within the GradesController will be encapsulated within appropriate methods and classes to minimize dependencies.
  • Access to instance variables and controller actions will be limited, promoting encapsulation and separation of concerns.

Dependency Inversion Principle (DIP):

  • The GradesController will depend on abstractions, interfaces, or higher-level modules instead of concrete implementations.
  • Dependency injection or inversion of control will be used to decouple the controller from specific database or service implementations.

Testing with RSwag:

Integration Testing:

  • Integration tests using RSwag will be written to verify the behavior of each controller action, including `view`, `view_my_scores`, and `view_team`.
  • CRUD operations (Create, Read, Update, Delete) will be tested to ensure proper data management and interaction with the database.

Swagger UI Integration:

  • RSwag will be integrated with Swagger UI to provide a user-friendly interface for interacting with API endpoints.
  • Swagger UI will accurately reflect the API documentation and allow users to test endpoints interactively.

Parameter Validation:

  • Endpoint parameters, such as assignment IDs and participant IDs, will be tested with various input values to ensure proper handling and error reporting.
  • Input parameters such as IDs, query parameters, and request bodies will be validated to ensure data integrity.

Error Handling:

  • Error handling scenarios, including validation errors, resource not found, unauthorized access, and server errors, will be tested.
  • Error responses will contain appropriate status codes, error messages, and error details as per the API contract.

Security Testing:

  • API endpoints will be assessed for vulnerabilities such as SQL injection, cross-site scripting (XSS), and sensitive data exposure.
  • Authentication and authorization mechanisms will be evaluated for effectiveness to ensure secure access to grading functionalities.

Performance Testing:

  • Performance of API endpoints under various load conditions will be evaluated using tools like JMeter or Gatling.
  • Response times, throughput, and resource utilization will be measured to identify performance bottlenecks and optimize critical paths.

Documentation Verification:

  • API documentation generated by RSwag will be validated to accurately reflect implemented endpoints, parameters, and responses.
  • Documentation will be kept up-to-date and aligned with the behavior of API endpoints.

By following these design principles and testing strategies, the reimplementation of the GradesController will result in a well-designed, maintainable, and thoroughly tested component, meeting project requirements effectively.

Initial Attempt in re-implementation

The initial implementation of the grades_controller in the API namespace enhances the code structure, readability, and maintainability through a series of thoughtful improvements. These changes align with the principles of modularity, reusability, and clarity, ensuring the controller's effectiveness in handling grading-related tasks within the application.

One significant improvement is the organization of controller actions, each serving a specific purpose and adhering to RESTful conventions. Actions such as `view`, `view_my_scores`, `view_team`, `edit`, `update`, and `save_grade_and_comment_for_submission` are clearly defined and encapsulate distinct functionalities. This structured approach enhances code readability and makes it easier to understand the controller's responsibilities at a glance. 

     def view
       @assignment = Assignment.find(params[:id])
       @scores = review_grades(@assignment, retrieve_questions(@assignment.questionnaires, @assignment.id))
       render json: grading_report_data(@assignment, @scores)
     end
 
     def view_my_scores
       @questions = retrieve_questions(@participant.assignment.questionnaires, @participant.assignment.id)
       @pscore = participant_scores(@participant, @questions)
       make_chart
       @summary = prepare_feedback_summary
       render json: my_scores_data
     end
 
     def view_team
       @assignment = @participant.assignment
       @team = @participant.team
       @team_id = @team.id
       @questions = retrieve_questions(@assignment.questionnaires, @assignment.id)
       @pscore = participant_scores(@participant, @questions)
       @penalties = calculate_penalty(@participant.id)
       @vmlist = populate_view_models
       @current_role_name = current_role_name
       render json: team_view_data
     end
 
     def edit
       @questions = list_questions(@participant.assignment)
       @scores = participant_scores(@participant, @questions)
       render json: edit_data
     end
 
     def update
       if @participant.update(participant_params)
         render json: @participant
       else
         render json: @participant.errors, status: :unprocessable_entity
       end
     end
 
     def save_grade_and_comment_for_submission
       if @participant.team.update(grade_for_submission: params[:grade_for_submission], comment_for_submission: params[:comment_for_submission])
         render json: { success: true }
       else
         render json: { success: false, errors: @participant.team.errors.full_messages }, status: :unprocessable_entity
       end
     end

Furthermore, the controller leverages `before_action` callbacks to set the participant before executing certain actions, reducing redundancy and promoting DRY (Don't Repeat Yourself) principles.

class GradesController < ApplicationController 

   before_action :set_participant, only: [:view_my_scores, :view_team, :edit, :update, :save_grade_and_comment_for_submission]

By defining the `set_participant` method as a callback for actions that require participant data, the controller avoids repetitive code and ensures consistency in handling participant-related tasks across different actions. 

   def set_participant
       @participant = AssignmentParticipant.find(params[:id])
   end

The use of private helper methods encapsulates logic that is specific to each action, promoting code reuse and modularity. These methods, such as `grading_report_data`, `my_scores_data`, `team_view_data`, `edit_data`, `prepare_feedback_summary`, and `populate_view_models`, encapsulate data preparation and processing tasks, keeping the controller actions focused and concise. 

     def grading_report_data(assignment, scores)
       {
         assignment: assignment,
         scores: scores,
         num_reviewers_assigned_scores: scores[:teams].length,
         average_chart: bar_chart(vector(scores)),
         avg_of_avg: mean(vector(scores)),
         penalties: penalties(assignment.id),
         show_reputation: false
       }
     end
 
     def my_scores_data
       {
         participant: @participant,
         questions: @questions,
         pscore: @pscore,
         summary: @summary,
         avg_scores_by_round: @summary.avg_scores_by_round,
         avg_scores_by_criterion: @summary.avg_scores_by_criterion
       }
     end
 
     def team_view_data
       {
         participant: @participant,
         assignment: @assignment,
         team: @team,
         team_id: @team_id,
         questions: @questions,
         pscore: @pscore,
         penalties: @penalties,
         vmlist: @vmlist,
         current_role_name: @current_role_name
       }
     end
 
     def edit_data
       {
         participant: @participant,
         questions: @questions,
         scores: @scores
       }
     end
 
     def prepare_feedback_summary
       summary_ws_url = WEBSERVICE_CONFIG['summary_webservice_url']
       sum = SummaryHelper::Summary.new.summarize_reviews_by_reviewee(@questions, @participant.assignment, @team_id, summary_ws_url, session)
       sum.summary
     end
 
     def populate_view_models
       vmlist = []
       counter_for_same_rubric = 0
       if @assignment.vary_by_topic?
         topic_id = SignedUpTeam.topic_id_by_team_id(@team_id)
         topic_specific_questionnaire = AssignmentQuestionnaire.where(assignment_id: @assignment.id, topic_id: topic_id).first.questionnaire
         vmlist << populate_view_model(topic_specific_questionnaire)
       end
       @assignment.questionnaires.each do |questionnaire|
         @round = nil
         next if @assignment.vary_by_topic? && questionnaire.type == 'ReviewQuestionnaire'
 
         if @assignment.varying_rubrics_by_round? && questionnaire.type == 'ReviewQuestionnaire'
           questionnaires = AssignmentQuestionnaire.where(assignment_id: @assignment.id, questionnaire_id: questionnaire.id)
           if questionnaires.count > 1
             @round = questionnaires[counter_for_same_rubric].used_in_round
             counter_for_same_rubric += 1
           else
             @round = questionnaires[0].used_in_round
             counter_for_same_rubric = 0
           end
         end
         vmlist << populate_view_model(questionnaire)
       end
       vmlist
     end

Additionally, the controller follows strong parameter conventions by using the `participant_params` method to permit specific attributes for participant updates. This helps mitigate security risks associated with mass assignment vulnerabilities and ensures that only permitted attributes can be modified through API requests. 

     def participant_params
       params.require(:participant).permit(:grade, :other_params)
     end

Team

Mentor
  • Kashika Malick
Members
  • Sravya Yepuri (syepuri@ncsu.edu)
  • Hasini Chenchala (hchench@ncsu.edu)
  • Chirag Hegde (chegde@ncsu.edu)
Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2443_Reimplement_grades_controller&oldid=156674"