Expertiza_Wiki - User contributions [en]

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

2024-11-12T16:32:23Z

Asharm67: /* Phase 2 */

== 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''' ===
# Clarify and Refactor exist_assignment variable.
# Clarify aq Parameter Naming in list_unassigned_rubrics & remove_existing_questionnaire.
# Fixing the Github required checks.
# Refactor Variable Naming for Clarity.
# Review path Method Location.
# Refactor Authorization Checks.
# Simplify Array Usage in Create Method.
# Refactor Method Names with 'Check'.
# Refactor query_participants_and_alert Method.

=== '''Phase 2''' ===
Current Status
We have successfully completed the following refactoring and functionality improvements:
1. Refactor query_participants_and_alert Method
Refactored query_participants_and_alert by splitting it into missing_participants? and alert_missing_participants for improved readability and maintainability.
The new missing_participants? method checks if participants are blank, while alert_missing_participants generates a flash error message with a link to add missing participants.
2. Clarify and Refactor Variable Naming for Clarity
a. Renamed find_existing_assignment to assignment_by_name for consistency with Ruby conventions.
b. Renamed exist_assignment to assignment_created to clearly indicate it tracks assignment creation status.
c. Renamed the aq parameter to assignment_questionnaire for clarity in assignment questionnaire iterations.
3. Refactor Authorization Checks
Centralized privilege-checking logic by replacing direct role checks with helper methods current_user_has_instructor_privileges? and current_user_has_ta_privileges?, enhancing maintainability and aligning with DRY principles.
4. Simplify Array Usage in create Method
Simplified the check method by renaming it to validate and removing unnecessary arrays (ques_array and due_array). Direct data structure traversal is now used, reducing complexity and enhancing clarity.
These changes have been implemented and tested to ensure they meet the requirements for clarity, functionality, and performance.

Issues and Plan of Action For Phase 2

1. Assess Method Placement for Assignment Name Check
Current Issue: The method that checks if an assignment name is already in use currently resides in the controller. This placement may violate the separation of concerns principle, as it could be more fitting for a model or service object to handle this validation.
Plan: Analyze the current functionality of the assignment name check and determine if it involves complex logic that could be encapsulated within a service object or model. If it's a simple validation, move it to the model; for more complex operations, implement a service object to streamline the controller and enhance reusability across the application.
2. Simplify path_warning_and_answer_tag Method
Current Issue: The path_warning_and_answer_tag method has a verbose name and may be performing multiple tasks, making it hard to read and maintain.
Plan: Rename path_warning_and_answer_tag to a clear, action-oriented name and refactor the method by breaking it into smaller, single-purpose methods. Each new method should encapsulate one logical part of the process, improving readability, modularity, and simplifying future maintenance.
3. Evaluate Bookmarking Functionality
Current Issue: Bookmarking assignments and managing badges may not be logically consistent within the current context, creating ambiguity about where and how these features should be implemented.
Plan: Review the current use cases for bookmarking and badge handling to establish if these features align with the current controller or model. If they serve a broader purpose or require more context-specific handling, consider relocating them to a dedicated module or service. Create a detailed design proposal for implementing and managing these features effectively.
4. Move Assignment Management Methods to Model
Current Issue: The methods remove_assignment_from_course and place_assignment_in_course are currently in the controller, but they deal with assignment management, which may belong more appropriately in the model.
Plan: Move remove_assignment_from_course and place_assignment_in_course to the assignment model to adhere to the principle of separating concerns. Adjust the controller to call these model methods, keeping the controller focused on handling HTTP requests while the model manages data-related logic.
5. Reassess Delayed Mailer Methods
Current Issue: The delayed_mailer and delete_delayed_mailer methods reside in the controller but may not need to be there, especially if they are used for background email processes that can be managed elsewhere.
Plan: Evaluate the purpose and functionality of these delayed mailer methods. If they are intended to manage background processes, consider relocating them to a service object or a background job manager to enhance modularity. Ensure the new placement supports asynchronous processing while reducing the controller’s load.
6. Addressing Code Climate Issues
Current Issue: Code climate flags include high complexity and excessive line count
Plan: Refactor by:
Splitting complex logic into smaller helper methods
Reducing nested conditionals and loops
Improving readability through concise naming and streamlined code
These adjustments will enhance maintainability and meet Code Climate’s metrics for complexity and line limits.
7. Remove HTML Markup Code From the Controller
Current Issue: There is HTML markup code present in the controller, especially in Flash messages
Plan: Evaluate the current controller to identify HTML markup in Flash messages and remove it, adhering to MVC principles. Refactor the controller to pass raw, clean data (without HTML) to the view. In the view, update Flash message rendering to handle HTML formatting using Rails helpers like raw or sanitize for security. Test thoroughly to ensure functionality and proper display across browsers. Finally, update documentation and request a code review before deploying the changes.

== Test Cases ==
All of the required checks for tests are passing. This is shown in the image below. The previously written test cases were not changed, just modified the cases to incorporate our refactoring.

[[File:Screenshot_2024-11-01_at_12.30.05_AM.png|700px]]

== 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 ==
#[https://expertiza.ncsu.edu/ Expertiza]

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

2024-11-12T16:32:10Z

Asharm67: /* Phase 2 */

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

2024-11-12T16:27:13Z

Asharm67: /* Phase 2 */

== 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''' ===
# Clarify and Refactor exist_assignment variable.
# Clarify aq Parameter Naming in list_unassigned_rubrics & remove_existing_questionnaire.
# Fixing the Github required checks.
# Refactor Variable Naming for Clarity.
# Review path Method Location.
# Refactor Authorization Checks.
# Simplify Array Usage in Create Method.
# Refactor Method Names with 'Check'.
# Refactor query_participants_and_alert Method.

=== '''Phase 2''' ===
1. Assess Method Placement for Assignment Name Check
Current Issue: The method that checks if an assignment name is already in use currently resides in the controller. This placement may violate the separation of concerns principle, as it could be more fitting for a model or service object to handle this validation.
Plan: Analyze the current functionality of the assignment name check and determine if it involves complex logic that could be encapsulated within a service object or model. If it's a simple validation, move it to the model; for more complex operations, implement a service object to streamline the controller and enhance reusability across the application.
2. Simplify path_warning_and_answer_tag Method
Current Issue: The path_warning_and_answer_tag method has a verbose name and may be performing multiple tasks, making it hard to read and maintain.
Plan: Rename path_warning_and_answer_tag to a clear, action-oriented name and refactor the method by breaking it into smaller, single-purpose methods. Each new method should encapsulate one logical part of the process, improving readability, modularity, and simplifying future maintenance.
3. Evaluate Bookmarking Functionality
Current Issue: Bookmarking assignments and managing badges may not be logically consistent within the current context, creating ambiguity about where and how these features should be implemented.
Plan: Review the current use cases for bookmarking and badge handling to establish if these features align with the current controller or model. If they serve a broader purpose or require more context-specific handling, consider relocating them to a dedicated module or service. Create a detailed design proposal for implementing and managing these features effectively.
4. Move Assignment Management Methods to Model
Current Issue: The methods remove_assignment_from_course and place_assignment_in_course are currently in the controller, but they deal with assignment management, which may belong more appropriately in the model.
Plan: Move remove_assignment_from_course and place_assignment_in_course to the assignment model to adhere to the principle of separating concerns. Adjust the controller to call these model methods, keeping the controller focused on handling HTTP requests while the model manages data-related logic.
5. Reassess Delayed Mailer Methods
Current Issue: The delayed_mailer and delete_delayed_mailer methods reside in the controller but may not need to be there, especially if they are used for background email processes that can be managed elsewhere.
Plan: Evaluate the purpose and functionality of these delayed mailer methods. If they are intended to manage background processes, consider relocating them to a service object or a background job manager to enhance modularity. Ensure the new placement supports asynchronous processing while reducing the controller’s load.
6. Addressing Code Climate Issues
Current Issue: Code climate flags include high complexity and excessive line count
Plan: Refactor by:
Splitting complex logic into smaller helper methods
Reducing nested conditionals and loops
Improving readability through concise naming and streamlined code
These adjustments will enhance maintainability and meet Code Climate’s metrics for complexity and line limits.
7. Remove HTML Markup Code From the Controller
Current Issue: There is HTML markup code present in the controller, especially in Flash messages
Plan: Evaluate the current controller to identify HTML markup in Flash messages and remove it, adhering to MVC principles. Refactor the controller to pass raw, clean data (without HTML) to the view. In the view, update Flash message rendering to handle HTML formatting using Rails helpers like raw or sanitize for security. Test thoroughly to ensure functionality and proper display across browsers. Finally, update documentation and request a code review before deploying the changes.

== Test Cases ==
All of the required checks for tests are passing. This is shown in the image below. The previously written test cases were not changed, just modified the cases to incorporate our refactoring.

[[File:Screenshot_2024-11-01_at_12.30.05_AM.png|700px]]

== 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 ==
#[https://expertiza.ncsu.edu/ Expertiza]

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

2024-11-12T16:24:20Z

Asharm67: /* Tasks */

== 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''' ===
# Clarify and Refactor exist_assignment variable.
# Clarify aq Parameter Naming in list_unassigned_rubrics & remove_existing_questionnaire.
# Fixing the Github required checks.
# Refactor Variable Naming for Clarity.
# Review path Method Location.
# Refactor Authorization Checks.
# Simplify Array Usage in Create Method.
# Refactor Method Names with 'Check'.
# Refactor query_participants_and_alert Method.

=== '''Phase 2''' ===
# Assess Method Placement for Assignment Name Check
Current Issue: The method that checks if an assignment name is already in use currently resides in the controller. This placement may violate the separation of concerns principle, as it could be more fitting for a model or service object to handle this validation.
Plan: Analyze the current functionality of the assignment name check and determine if it involves complex logic that could be encapsulated within a service object or model. If it's a simple validation, move it to the model; for more complex operations, implement a service object to streamline the controller and enhance reusability across the application.
# Simplify path_warning_and_answer_tag Method
Current Issue: The path_warning_and_answer_tag method has a verbose name and may be performing multiple tasks, making it hard to read and maintain.
Plan: Rename path_warning_and_answer_tag to a clear, action-oriented name and refactor the method by breaking it into smaller, single-purpose methods. Each new method should encapsulate one logical part of the process, improving readability, modularity, and simplifying future maintenance.
# Evaluate Bookmarking Functionality
Current Issue: Bookmarking assignments and managing badges may not be logically consistent within the current context, creating ambiguity about where and how these features should be implemented.
Plan: Review the current use cases for bookmarking and badge handling to establish if these features align with the current controller or model. If they serve a broader purpose or require more context-specific handling, consider relocating them to a dedicated module or service. Create a detailed design proposal for implementing and managing these features effectively.
# Move Assignment Management Methods to Model
Current Issue: The methods remove_assignment_from_course and place_assignment_in_course are currently in the controller, but they deal with assignment management, which may belong more appropriately in the model.
Plan: Move remove_assignment_from_course and place_assignment_in_course to the assignment model to adhere to the principle of separating concerns. Adjust the controller to call these model methods, keeping the controller focused on handling HTTP requests while the model manages data-related logic.
# Reassess Delayed Mailer Methods
Current Issue: The delayed_mailer and delete_delayed_mailer methods reside in the controller but may not need to be there, especially if they are used for background email processes that can be managed elsewhere.
Plan: Evaluate the purpose and functionality of these delayed mailer methods. If they are intended to manage background processes, consider relocating them to a service object or a background job manager to enhance modularity. Ensure the new placement supports asynchronous processing while reducing the controller’s load.
# Addressing Code Climate Issues
Current Issue: Code climate flags include high complexity and excessive line count
Plan: Refactor by:
Splitting complex logic into smaller helper methods
Reducing nested conditionals and loops
Improving readability through concise naming and streamlined code
These adjustments will enhance maintainability and meet Code Climate’s metrics for complexity and line limits.
# Remove HTML Markup Code From the Controller
Current Issue: There is HTML markup code present in the controller, especially in Flash messages
Plan: Evaluate the current controller to identify HTML markup in Flash messages and remove it, adhering to MVC principles. Refactor the controller to pass raw, clean data (without HTML) to the view. In the view, update Flash message rendering to handle HTML formatting using Rails helpers like raw or sanitize for security. Test thoroughly to ensure functionality and proper display across browsers. Finally, update documentation and request a code review before deploying the changes.

== Test Cases ==
All of the required checks for tests are passing. This is shown in the image below. The previously written test cases were not changed, just modified the cases to incorporate our refactoring.

[[File:Screenshot_2024-11-01_at_12.30.05_AM.png|700px]]

== 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 ==
#[https://expertiza.ncsu.edu/ Expertiza]

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

2024-11-12T16:22:42Z

Asharm67: /* Tasks */

== 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''' ===
# Clarify and Refactor exist_assignment variable.
# Clarify aq Parameter Naming in list_unassigned_rubrics & remove_existing_questionnaire.
# Fixing the Github required checks.
# Refactor Variable Naming for Clarity.
# Review path Method Location.
# Refactor Authorization Checks.
# Simplify Array Usage in Create Method.
# Refactor Method Names with 'Check'.
# Refactor query_participants_and_alert Method.

=== '''Phase 2''' ===
1. Assess Method Placement for Assignment Name Check
Current Issue: The method that checks if an assignment name is already in use currently resides in the controller. This placement may violate the separation of concerns principle, as it could be more fitting for a model or service object to handle this validation.
Plan: Analyze the current functionality of the assignment name check and determine if it involves complex logic that could be encapsulated within a service object or model. If it's a simple validation, move it to the model; for more complex operations, implement a service object to streamline the controller and enhance reusability across the application.
2. Simplify path_warning_and_answer_tag Method
Current Issue: The path_warning_and_answer_tag method has a verbose name and may be performing multiple tasks, making it hard to read and maintain.
Plan: Rename path_warning_and_answer_tag to a clear, action-oriented name and refactor the method by breaking it into smaller, single-purpose methods. Each new method should encapsulate one logical part of the process, improving readability, modularity, and simplifying future maintenance.
3. Evaluate Bookmarking Functionality
Current Issue: Bookmarking assignments and managing badges may not be logically consistent within the current context, creating ambiguity about where and how these features should be implemented.
Plan: Review the current use cases for bookmarking and badge handling to establish if these features align with the current controller or model. If they serve a broader purpose or require more context-specific handling, consider relocating them to a dedicated module or service. Create a detailed design proposal for implementing and managing these features effectively.
4. Move Assignment Management Methods to Model
Current Issue: The methods remove_assignment_from_course and place_assignment_in_course are currently in the controller, but they deal with assignment management, which may belong more appropriately in the model.
Plan: Move remove_assignment_from_course and place_assignment_in_course to the assignment model to adhere to the principle of separating concerns. Adjust the controller to call these model methods, keeping the controller focused on handling HTTP requests while the model manages data-related logic.
5. Reassess Delayed Mailer Methods
Current Issue: The delayed_mailer and delete_delayed_mailer methods reside in the controller but may not need to be there, especially if they are used for background email processes that can be managed elsewhere.
Plan: Evaluate the purpose and functionality of these delayed mailer methods. If they are intended to manage background processes, consider relocating them to a service object or a background job manager to enhance modularity. Ensure the new placement supports asynchronous processing while reducing the controller’s load.
6. Addressing Code Climate Issues
Current Issue: Code climate flags include high complexity and excessive line count
Plan: Refactor by:
Splitting complex logic into smaller helper methods
Reducing nested conditionals and loops
Improving readability through concise naming and streamlined code
These adjustments will enhance maintainability and meet Code Climate’s metrics for complexity and line limits.
7. Remove HTML Markup Code From Controller
Current Issue: There is HTML markup code present in the controller, especially in Flash messages
Plan: Evaluate the current controller to identify HTML markup in Flash messages and remove it, adhering to MVC principles. Refactor the controller to pass raw, clean data (without HTML) to the view. In the view, update Flash message rendering to handle HTML formatting using Rails helpers like raw or sanitize for security. Test thoroughly to ensure functionality and proper display across browsers. Finally, update documentation and request a code review before deploying the changes.

== Test Cases ==
All of the required checks for tests are passing. This is shown in the image below. The previously written test cases were not changed, just modified the cases to incorporate our refactoring.

[[File:Screenshot_2024-11-01_at_12.30.05_AM.png|700px]]

== 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 ==
#[https://expertiza.ncsu.edu/ Expertiza]

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

2024-10-30T02:33:29Z

Asharm67:

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

2024-10-30T02:32:50Z

Asharm67: /* Clarify and Refactor exist_assignment variable. */

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

2024-10-30T02:32:22Z

Asharm67: /* Tasks */

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

2024-10-30T02:30:20Z

Asharm67: Created page with "== 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..."

CSC/ECE 517 Fall 2024

2024-10-30T01:39:16Z

Asharm67:

* [[CSC/ECE 517 Fall 2024 - E2450. Refactor assignments_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2452. Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2453. Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Fall 2024 - E2454. Refactor student_task.rb]]
* [[CSC/ECE 517 Fall 2024 - E2456. Refactor teams_user.rb]]
* [[CSC/ECE 517 Fall 2024 - E2455. Refactor sign_up_sheet_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2458. User management and users table]]
* [[CSC/ECE 517 Fall 2024 - E2459. View for results of bidding]]
* [[CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management]]
* [[CSC/ECE 517 Fall 2024 - E2461. UI for Courses]]
* [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2024_-_E2462._UI_for_Questionnaires CSC/ECE 517 Fall 2024 - E2462. UI for Questionnaire.rb]
* [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2024_-_E2463_Implement_Front_End_for_Student_Task_List CSC/ECE 517 Fall 2024 - E2463. UI for Student Task List]
* [[CSC/ECE 517 Fall 2024 - E2464 UI for Project Topics (was: Sign_up_Topics)]]
* [[CSC/ECE 517 Fall 2024 - E2465. UI for Institutions and Notification]]
* [[CSC/ECE 517 Fall 2024 - E2466. UI for Impersonate User]]
* [[CSC/ECE 517 Fall 2024 - E2467. UI for View Submissions]]
* [[CSC/ECE 517 Fall 2024 - E2468. Reimplement due_date]]
* [[CSC/ECE 517 Fall 2024 - E2469. Reimplement grades/view_team]]
* [[CSC/ECE 517 Fall 2024 - E2470. Reimplement grades_controller]]
* [[CSC/ECE 517 Fall 2024 - E2471. Reimplement logger]]
* [[CSC/ECE 517 Fall 2024 - E2475. Reimplement student_task view]]
* [[CSC/ECE 517 Fall 2024 - E2478. Reimplement the Question hierarchy as Item hierarchy]]
* [[CSC/ECE 517 Fall 2024 - E2480. Implement testing for new Bookmarks Controller]]
* [[CSC/ECE 517 Fall 2024 - E2482. Reimplement heatgrid for reviews]]
* [[CSC/ECE 517 Fall 2024 - E2481 Reimplement response_map.rb]]
* [[CSC/ECE 517 Fall 2024 - G2401 Refactor Graphql API endpoint for contribution metrics]]
* [[CSC/ECE 517 Fall 2024 - G2402 Refactor Graphql API endpoint for repositories]]

CSC/ECE 517 Fall 2024

2024-10-30T01:38:56Z

Asharm67:

* [[CSC/ECE 517 Fall 2024 - E2450. Refactor assignments_controller.rb
* [[CSC/ECE 517 Fall 2024 - E2452. Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2453. Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Fall 2024 - E2454. Refactor student_task.rb]]
* [[CSC/ECE 517 Fall 2024 - E2456. Refactor teams_user.rb]]
* [[CSC/ECE 517 Fall 2024 - E2455. Refactor sign_up_sheet_controller.rb]]
* [[CSC/ECE 517 Fall 2024 - E2458. User management and users table]]
* [[CSC/ECE 517 Fall 2024 - E2459. View for results of bidding]]
* [[CSC/ECE 517 Fall 2024 - E2460 Mentor-Meeting Management]]
* [[CSC/ECE 517 Fall 2024 - E2461. UI for Courses]]
* [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2024_-_E2462._UI_for_Questionnaires CSC/ECE 517 Fall 2024 - E2462. UI for Questionnaire.rb]
* [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2024_-_E2463_Implement_Front_End_for_Student_Task_List CSC/ECE 517 Fall 2024 - E2463. UI for Student Task List]
* [[CSC/ECE 517 Fall 2024 - E2464 UI for Project Topics (was: Sign_up_Topics)]]
* [[CSC/ECE 517 Fall 2024 - E2465. UI for Institutions and Notification]]
* [[CSC/ECE 517 Fall 2024 - E2466. UI for Impersonate User]]
* [[CSC/ECE 517 Fall 2024 - E2467. UI for View Submissions]]
* [[CSC/ECE 517 Fall 2024 - E2468. Reimplement due_date]]
* [[CSC/ECE 517 Fall 2024 - E2469. Reimplement grades/view_team]]
* [[CSC/ECE 517 Fall 2024 - E2470. Reimplement grades_controller]]
* [[CSC/ECE 517 Fall 2024 - E2471. Reimplement logger]]
* [[CSC/ECE 517 Fall 2024 - E2475. Reimplement student_task view]]
* [[CSC/ECE 517 Fall 2024 - E2478. Reimplement the Question hierarchy as Item hierarchy]]
* [[CSC/ECE 517 Fall 2024 - E2480. Implement testing for new Bookmarks Controller]]
* [[CSC/ECE 517 Fall 2024 - E2482. Reimplement heatgrid for reviews]]
* [[CSC/ECE 517 Fall 2024 - E2481 Reimplement response_map.rb]]
* [[CSC/ECE 517 Fall 2024 - G2401 Refactor Graphql API endpoint for contribution metrics]]
* [[CSC/ECE 517 Fall 2024 - G2402 Refactor Graphql API endpoint for repositories]]