CSC/ECE 517 Fall 2024 - E2450. Refactor assignments controller.rb

About Controller

The `AssignmentsController` handles actions related to managing assignments.Key functionalities include initializing a new assignment in the `new` action and creating assignments through the `create` action, with validations to prevent duplicate names and directory paths. If creation succeeds, it redirects appropriately; otherwise, it renders the form with errors. This controller ensures smooth assignment management by enforcing proper validations and access control throughout the process.

Functionality of assignments_controller

The `AssignmentsController` handles the management of assignments by providing actions for creating and initializing them while ensuring access control. It uses `before_action` callbacks to enforce authorization, ensuring only permitted users can interact with assignment-related features. The `new` action initializes a blank assignment object for form rendering, facilitating the creation of new assignments. Additionally, the `create` action is responsible for processing form submissions, validating input, and saving the assignment if it meets the criteria. This controller ensures that all assignment operations are secure, properly initialized, and follow the required business logic.

Problem Statement

The `assignments_controller` presents difficulties due to its large size, intricate structure, and absence of comments, making it challenging for developers to grasp its functionality. To address these issues, a thorough refactor is advised, breaking down lengthy methods into smaller, more manageable sections. This strategy would modularize complex logic, assigning specific tasks to individual parts within the controller’s responsibilities. Furthermore, the refactor should aim to remove redundant code by consolidating repetitive sections into reusable functions or utilities, enhancing code quality and reducing the risk of errors. By restructuring the controller and improving its documentation, developers can better understand its operations, making maintenance, debugging, and future updates more straightforward.

Tasks

1. Refactor create method

2. Refactor edit method

3. Refactor update method

4. Refactor delete method: New models for subclasses will be implemented to streamline organization and simplify management.

5. Reposition methods

6. Enhance Comments

7. Expand Test Coverage

Phase 1

1. Clarify and Refactor exist_assignment variable.
2. Clarify aq Parameter Naming in list_unassigned_rubrics & remove_existing_questionnaire.
3. Fixing the Github required checks.
4. Refactor Variable Naming for Clarity.
5. Review path Method Location.
6. Refactor Authorization Checks.
7. Simplify Array Usage in Create Method.
8. Refactor Method Names with 'Check'.
9. Refactor query_participants_and_alert Method.

Test Cases

1. To do

Implementation

 === Refactor query_participants_and_alert Method ===
   ==== What ====
     The method `query_participants_and_alert` was refactored to improve readability and maintainability by splitting it into two distinct methods.

   ==== Why ====
     The method was initially complex, with inline logic that reduced readability.

   ==== How ====
     The inline check for participants was moved to a new method `missing_participants?` in `assignment.rb`, which now simply checks if participants are blank. The alerting functionality was moved to a new `alert_missing_participants` method. This method generates a flash error message and adds a link to help the user add participants if they are missing.

 === Clarify and Refactor Variable Naming for Clarity ===
   ==== a. `find_existing_assignment` Renamed to `assignment_by_name` ====
     ===== What =====
       Renamed `find_existing_assignment` to `assignment_by_name`.

     ===== Why =====
       The original name was verbose and inconsistent with Ruby conventions.

     ===== How =====
       Renamed `find_existing_assignment` to `assignment_by_name` to more accurately describe the purpose of the variable.

   ==== b. `exist_assignment` Renamed to `assignment_created` ====
     ===== What =====
       Renamed `exist_assignment` to `assignment_created`.

     ===== Why =====
       The original name was ambiguous and could lead to confusion.

     ===== How =====
       Renamed `exist_assignment` to `assignment_created` to clearly indicate that the variable tracks the creation status of an assignment.

   ==== c. `aq` Parameter Renamed to `assignment_questionnaire` ====
     ===== What =====
       Renamed `aq` parameter to `assignment_questionnaire`.

     ===== Why =====
       The `aq` parameter used in loops lacked descriptive power, making it harder for developers to interpret its purpose.

     ===== How =====
       Renamed `aq` to `assignment_questionnaire` to better indicate the parameter’s context in assignment questionnaire iterations.

 === Refactor Authorization Checks ===
   ==== What ====
     Centralized privilege-checking logic by using helper methods from the `AuthorizationHelper` module.

   ==== Why ====
     Direct role checks created redundant code, as privilege-checking logic was scattered and duplicated.

   ==== How ====
     Replaced direct role checks with calls to `current_user_has_instructor_privileges?` and `current_user_has_ta_privileges?`, enhancing maintainability and aligning with DRY principles.

 === Simplify Array Usage in Create Method ===
   ==== What ====
     Reduced complexity by removing unnecessary arrays in the `check` method.

   ==== Why ====
     The `check` method was generic and not expressive enough for its validation purposes, and `ques_array` and `due_array` added unnecessary complexity.

   ==== How ====
     Renamed `check` to `validate`, making the method’s purpose clearer and aligning with common naming conventions. Removed `ques_array` and `due_array`, opting to directly traverse data structures where possible.

Team

Mentor

• Ameya Vaichalkar

Members

• Avleen Mehal
• Daksh Pratap Singh
• Abhinav Sharma

References

1. Expertiza