Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2024 - E2479. Reimplement teams users controller.rb

2024-11-18T02:40:18Z

Bkurra: /* Implementation Plan */

== Expertiza ==
Expertiza is an open-source learning management system built with Ruby on Rails as its core. Its features include creating tests and assignments, managing assignment teams and courses, and having a solid framework to facilitate peer reviews and group comments. The main objective of this project is to reimplement teams_users_controller.rb. The goal is to reimplement teams_users_controller.rb from the Expertiza repository to the reimplementation-back-end repository to follow SOLID and DRY principles.

== Problem Statement ==
The following were the problems with the previous implementation :
* Lack of Modularity and SRP Violations: The create method is excessively long and handles multiple concerns such as finding users, checking assignments/courses, adding members, and handling various flash messages. This violates the Single Responsibility Principle (SRP) and makes the method difficult to maintain. Similar complexity is observed in other methods like auto_complete_for_user_name and delete.
* Redundant and Repetitive Code: There is significant duplication in handling AssignmentTeam and CourseTeam logic in the create method. This could be abstracted into separate model methods or helper functions. The repeated checks for user membership and participant status introduce unnecessary redundancy.
* Error Handling and Flash Message Management: Flash messages are scattered throughout the code, with some being overly complex and not user-friendly.
* Inconsistent and Non-Descriptive Naming: Variable and method names, such as urlCreate, add_member_return, and urlCourseParticipantList, do not follow consistent naming conventions and are not very descriptive.
* Tightly Coupled Logic: Business logic, such as validating membership and handling team participant status, resides within the controller instead of being abstracted into model methods. This makes the controller overly complex and difficult to test. Logic specific to AssignmentTeam and CourseTeam is handled in the controller, whereas it should ideally be part of respective models or services.
* Poor Use of Access Control Mechanism: The action_allowed? method is hardcoded to check for privileges using strings and is difficult to extend.
* Insufficient User Feedback and Validation: The implementation lacks comprehensive validation and feedback mechanisms, such as form-level client-side validation, detailed error messages, and modern UX elements like modal pop-ups or toast notifications.
* Limited Error Handling in Batch Operations: The delete_selected method performs deletions in a loop without adequate error handling or feedback for each item.
* Unclear Role Management: The update_duties method updates a duty using direct attribute assignment without validation or checks, potentially leading to data inconsistency.

==Implementation Plan==
* Break down the create method into smaller, helper methods to ensure each performs a specific, single task. Abstract shared logic into these helper methods to eliminate redundant code, improving modularity and maintainability.
* Move business logic out of the controller and into the model. The controller should primarily handle interactions between the views and models, while models encapsulate business logic such as team membership validation or user assignment checks.
* Replace action_allowed? with policy classes (e.g., using Pundit) to provide a clear, granular, and consistent approach to managing access control based on roles and permissions.
* Leverage polymorphism by coding common functionalities (e.g., user-team membership rules) in the AssignmentTeam and MentoredTeam models.
* Use AJAX to make core actions such as adding, updating, or removing members more dynamic and responsive without page reloads.
* Adhere to consistent and meaningful variable naming conventions throughout the controller. And document every method with clear, descriptive comments explaining its purpose, input parameters, and expected outcomes.
* Implement auto-complete, error messages, and toast notifications to provide better user feedback and guidance.
* Add filtering and UI improvements to manage member listings to enhance usability.
* Develop detailed unit and integration tests to ensure robust coverage of controller actions, focusing on both normal and edge cases.
* Design intuitive, interactive UI components such as dropdowns or drag-and-drop elements, for role assignments, and ensure they follow a modular, easily maintainable, and extendable modular structure.

*Refactoring TeamsUsersController to TeamsParticipantsController: The controller will be renamed and restructured to better align with the domain model. All associated views, routes, and models will be updated accordingly.

*Modular Methods and DRY Principles: Each method will be decomposed into smaller, reusable helper methods, ensuring adherence to the Single Responsibility Principle (SRP).

*create Method: Split into smaller helper methods:
find_user: Locates a user based on input.
create_user: Creates a user based on input
check_user_already_on_team?: Validates user is already in the team or not
add_user_to_team: Handles adding a user to the team if all conditions are met.
Move Logic to Models: E.g., team_exceeds_capacity?, to keep the controller clean.

*Role Management and UI Enhancement: Role management functionality, such as role assignments and updates, will use intuitive UI elements like dropdowns, with role descriptions available for clarity.

*AJAX Integration for Dynamic Updates: Key actions such as adding and removing members will use AJAX to provide a smooth user experience.

*Policy-Based Access Control: Replace action_allowed? with Policy Classes. Fine-grained permissions will be enforced using a library like Pundit to control access to various actions based on user roles.

*Auto-Complete and Filtering: Auto-complete for user search will provide more context (e.g., name, email), and filters will be added for improved member listing.

*Quality of Explanations: Clear and Detailed Explanations: All proposed changes, such as modularizing the create method, are clearly explained with an emphasis on improving readability and reducing complexity.

*Follow Consistent Naming Conventions: Ensure variable and method names are descriptive and consistent across the controller.

*Avoid Overloading Controllers: Ensure complex logic is moved to models, helpers, or service objects to prevent bloated controllers. This makes code easier to maintain and adheres to MVC principles.

*Proper Allocation of Responsibilities: E.g., methods for checking membership should be in Team or TeamsParticipant models, not the controller.

*Repetitive Logic and Nesting: Excessive nesting and duplicated logic can lead to code smell. Refactor common checks (e.g., user existence, membership) into helper methods.

*Verbose Controllers: Long controllers tend to indicate poor separation of concerns. Any domain-specific logic should reside in models or services.

== Flow Chart for the teams_users_controller Page ==
[[File:Teams_participants_controller.png]]
=UML Diagram=
[[File: teamsParticipants_uml.png]]

== Testing ==
Our test plan will generally involve testing using RSpec and UI tests to ensure the functionality remains the same without affecting the existing functionality. This involves adding RSpec test commands for teams_user_controller and teams_user model to verify that each component functions as expected within the refactored structure. Additionally, we will run UI tests to ensure that the teams_participants page display accurately and integrates seamlessly within the Expertiza interface.

1. Unit Tests
a. Test the create Method
Scenario 1: Successfully adding a user to a team.

Preconditions: User exists, user is not already on a team, and team capacity is not exceeded.
Expected Outcome: User is added to the team, a success message is displayed, and the user is redirected.
Scenario 2: Adding a non-existent user.

Preconditions: User does not exist in the system.
Expected Outcome: Appropriate error message is displayed with a link to create the user.
Scenario 3: Adding a user who is already a member of another team.

Preconditions: User is already assigned to a different team within the same assignment/course.
Expected Outcome: User is not added, and an error message is displayed.
Scenario 4: Adding a user as a mentor.

Preconditions: User is designated as a mentor and the team does not have a mentor yet.
Expected Outcome: User is added as a mentor, and appropriate success message is displayed.
Scenario 5: Team is at maximum capacity.

Preconditions: Team has reached its maximum allowed members.
Expected Outcome: User is not added, and an error message indicating maximum capacity is displayed.
b. Test the delete Method
Scenario 1: Successfully removing a user from a team.

Preconditions: User is a member of the team.
Expected Outcome: User is removed from the team, and a success message is displayed.
Scenario 2: Removing a non-existent TeamsUser record.

Preconditions: TeamsUser record does not exist.
Expected Outcome: Error is handled gracefully, and a suitable error message is displayed.
c. Test the delete_selected Method
Scenario 1: Successfully removing multiple selected users from a team.
Preconditions: Multiple valid TeamsUser records exist for the team.
Expected Outcome: All selected users are removed, and a success message is displayed.
d. Test the list Method
Scenario 2: Listing members with filters.

Preconditions: Filters are applied (e.g., by role).
Expected Outcome: Only filtered members are displayed.
e. Test the update_duties Method
Scenario 1: Updating a user’s role within a team.
Preconditions: Valid TeamsUser record exists.
Expected Outcome: User’s role is updated, and a success message is displayed.
2. Integration Tests
a. Test User Creation and Assignment Workflow
Scenario 1: Create a new user and add them to a team.
Expected Outcome: User is created, validated, and added to the team successfully.
b. Test Removing and Re-adding Users
Scenario 1: Remove a user from a team and re-add them.
Expected Outcome: User is successfully removed and can be re-added if team conditions are met.
c. Test Access Control Policies
Scenario 1: User with insufficient privileges tries to create, update, or delete team members.

Expected Outcome: Access is denied with an appropriate message.
Scenario 2: Admin users perform team member management actions.

Expected Outcome: Actions are allowed with expected results.
3. User Interface (UI) Tests
a. Test Auto-Complete Feature
Scenario 1: Search for a user by name using the auto-complete feature.
Expected Outcome: Matching users are displayed in real-time as suggestions.
b. Test Role Assignment UI
Scenario 1: Assign a role using a dropdown or drag-and-drop.
Expected Outcome: Role is correctly assigned, and UI updates accordingly.

4. Security Tests
a. Test Access Control and Authorization
Scenario 1: Ensure unauthorized users cannot access or modify team member information.
Expected Outcome: Proper access control is enforced, and unauthorized actions are blocked.

Test Plan Execution Steps
Setup Test Environment
Ensure all dependencies and environment configurations are in place.
Seed test data as necessary.
Run Unit Tests: Execute all unit tests and ensure all pass with expected behavior.
Run Integration Tests: Test workflows end-to-end to validate interactions between components.
UI and AJAX Testing: Test UI elements and AJAX responses to ensure smooth user interactions.

Testing Tools and Frameworks
RSpec: For unit and integration tests.
Capybara: For UI testing.
FactoryBot: For creating test data.

== Team ==
* Manideepika Reddy Myaka
* Bhuvan Chandra Kurra

CSC/ECE 517 Fall 2024 - E2479. Reimplement teams users controller.rb

2024-11-18T02:40:05Z

Bkurra: /* Implementation Plan */

CSC/ECE 517 Fall 2024 - E2479. Reimplement teams users controller.rb

2024-11-18T02:39:31Z

Bkurra: /* Implementation Plan */

== Expertiza ==
Expertiza is an open-source learning management system built with Ruby on Rails as its core. Its features include creating tests and assignments, managing assignment teams and courses, and having a solid framework to facilitate peer reviews and group comments. The main objective of this project is to reimplement teams_users_controller.rb. The goal is to reimplement teams_users_controller.rb from the Expertiza repository to the reimplementation-back-end repository to follow SOLID and DRY principles.

== Problem Statement ==
The following were the problems with the previous implementation :
* Lack of Modularity and SRP Violations: The create method is excessively long and handles multiple concerns such as finding users, checking assignments/courses, adding members, and handling various flash messages. This violates the Single Responsibility Principle (SRP) and makes the method difficult to maintain. Similar complexity is observed in other methods like auto_complete_for_user_name and delete.
* Redundant and Repetitive Code: There is significant duplication in handling AssignmentTeam and CourseTeam logic in the create method. This could be abstracted into separate model methods or helper functions. The repeated checks for user membership and participant status introduce unnecessary redundancy.
* Error Handling and Flash Message Management: Flash messages are scattered throughout the code, with some being overly complex and not user-friendly.
* Inconsistent and Non-Descriptive Naming: Variable and method names, such as urlCreate, add_member_return, and urlCourseParticipantList, do not follow consistent naming conventions and are not very descriptive.
* Tightly Coupled Logic: Business logic, such as validating membership and handling team participant status, resides within the controller instead of being abstracted into model methods. This makes the controller overly complex and difficult to test. Logic specific to AssignmentTeam and CourseTeam is handled in the controller, whereas it should ideally be part of respective models or services.
* Poor Use of Access Control Mechanism: The action_allowed? method is hardcoded to check for privileges using strings and is difficult to extend.
* Insufficient User Feedback and Validation: The implementation lacks comprehensive validation and feedback mechanisms, such as form-level client-side validation, detailed error messages, and modern UX elements like modal pop-ups or toast notifications.
* Limited Error Handling in Batch Operations: The delete_selected method performs deletions in a loop without adequate error handling or feedback for each item.
* Unclear Role Management: The update_duties method updates a duty using direct attribute assignment without validation or checks, potentially leading to data inconsistency.

==Implementation Plan==
* Break down the create method into smaller, helper methods to ensure each performs a specific, single task. Abstract shared logic into these helper methods to eliminate redundant code, improving modularity and maintainability.
* Move business logic out of the controller and into the model. The controller should primarily handle interactions between the views and models, while models encapsulate business logic such as team membership validation or user assignment checks.
* Replace action_allowed? with policy classes (e.g., using Pundit) to provide a clear, granular, and consistent approach to managing access control based on roles and permissions.
* Leverage polymorphism by coding common functionalities (e.g., user-team membership rules) in the AssignmentTeam and MentoredTeam models.
* Use AJAX to make core actions such as adding, updating, or removing members more dynamic and responsive without page reloads.
* Adhere to consistent and meaningful variable naming conventions throughout the controller. And document every method with clear, descriptive comments explaining its purpose, input parameters, and expected outcomes.
* Implement auto-complete, error messages, and toast notifications to provide better user feedback and guidance.
* Add filtering and UI improvements to manage member listings to enhance usability.
* Develop detailed unit and integration tests to ensure robust coverage of controller actions, focusing on both normal and edge cases.
* Design intuitive, interactive UI components such as dropdowns or drag-and-drop elements, for role assignments, and ensure they follow a modular, easily maintainable, and extendable modular structure.

*Refactoring TeamsUsersController to TeamsParticipantsController: The controller will be renamed and restructured to better align with the domain model. All associated views, routes, and models will be updated accordingly.

*Modular Methods and DRY Principles: Each method will be decomposed into smaller, reusable helper methods, ensuring adherence to the Single Responsibility Principle (SRP).
create Method: Split into smaller helper methods:
find_user: Locates a user based on input.
create_user: Creates a user based on input
check_user_already_on_team?: Validates user is already in the team or not
add_user_to_team: Handles adding a user to the team if all conditions are met.
Move Logic to Models: E.g., team_exceeds_capacity?, to keep the controller clean.

*Role Management and UI Enhancement: Role management functionality, such as role assignments and updates, will use intuitive UI elements like dropdowns, with role descriptions available for clarity.

*AJAX Integration for Dynamic Updates: Key actions such as adding and removing members will use AJAX to provide a smooth user experience.

*Policy-Based Access Control: Replace action_allowed? with Policy Classes. Fine-grained permissions will be enforced using a library like Pundit to control access to various actions based on user roles.

*Auto-Complete and Filtering: Auto-complete for user search will provide more context (e.g., name, email), and filters will be added for improved member listing.

*Quality of Explanations: Clear and Detailed Explanations: All proposed changes, such as modularizing the create method, are clearly explained with an emphasis on improving readability and reducing complexity.

*Follow Consistent Naming Conventions: Ensure variable and method names are descriptive and consistent across the controller.

*Avoid Overloading Controllers: Ensure complex logic is moved to models, helpers, or service objects to prevent bloated controllers. This makes code easier to maintain and adheres to MVC principles.

*Proper Allocation of Responsibilities: E.g., methods for checking membership should be in Team or TeamsParticipant models, not the controller.

*Repetitive Logic and Nesting: Excessive nesting and duplicated logic can lead to code smell. Refactor common checks (e.g., user existence, membership) into helper methods.

*Verbose Controllers: Long controllers tend to indicate poor separation of concerns. Any domain-specific logic should reside in models or services.

== Flow Chart for the teams_users_controller Page ==
[[File:Teams_participants_controller.png]]
=UML Diagram=
[[File: teamsParticipants_uml.png]]

== Testing ==
Our test plan will generally involve testing using RSpec and UI tests to ensure the functionality remains the same without affecting the existing functionality. This involves adding RSpec test commands for teams_user_controller and teams_user model to verify that each component functions as expected within the refactored structure. Additionally, we will run UI tests to ensure that the teams_participants page display accurately and integrates seamlessly within the Expertiza interface.

1. Unit Tests
a. Test the create Method
Scenario 1: Successfully adding a user to a team.

Preconditions: User exists, user is not already on a team, and team capacity is not exceeded.
Expected Outcome: User is added to the team, a success message is displayed, and the user is redirected.
Scenario 2: Adding a non-existent user.

Preconditions: User does not exist in the system.
Expected Outcome: Appropriate error message is displayed with a link to create the user.
Scenario 3: Adding a user who is already a member of another team.

Preconditions: User is already assigned to a different team within the same assignment/course.
Expected Outcome: User is not added, and an error message is displayed.
Scenario 4: Adding a user as a mentor.

Preconditions: User is designated as a mentor and the team does not have a mentor yet.
Expected Outcome: User is added as a mentor, and appropriate success message is displayed.
Scenario 5: Team is at maximum capacity.

Preconditions: Team has reached its maximum allowed members.
Expected Outcome: User is not added, and an error message indicating maximum capacity is displayed.
b. Test the delete Method
Scenario 1: Successfully removing a user from a team.

Preconditions: User is a member of the team.
Expected Outcome: User is removed from the team, and a success message is displayed.
Scenario 2: Removing a non-existent TeamsUser record.

Preconditions: TeamsUser record does not exist.
Expected Outcome: Error is handled gracefully, and a suitable error message is displayed.
c. Test the delete_selected Method
Scenario 1: Successfully removing multiple selected users from a team.
Preconditions: Multiple valid TeamsUser records exist for the team.
Expected Outcome: All selected users are removed, and a success message is displayed.
d. Test the list Method
Scenario 2: Listing members with filters.

Preconditions: Filters are applied (e.g., by role).
Expected Outcome: Only filtered members are displayed.
e. Test the update_duties Method
Scenario 1: Updating a user’s role within a team.
Preconditions: Valid TeamsUser record exists.
Expected Outcome: User’s role is updated, and a success message is displayed.
2. Integration Tests
a. Test User Creation and Assignment Workflow
Scenario 1: Create a new user and add them to a team.
Expected Outcome: User is created, validated, and added to the team successfully.
b. Test Removing and Re-adding Users
Scenario 1: Remove a user from a team and re-add them.
Expected Outcome: User is successfully removed and can be re-added if team conditions are met.
c. Test Access Control Policies
Scenario 1: User with insufficient privileges tries to create, update, or delete team members.

Expected Outcome: Access is denied with an appropriate message.
Scenario 2: Admin users perform team member management actions.

Expected Outcome: Actions are allowed with expected results.
3. User Interface (UI) Tests
a. Test Auto-Complete Feature
Scenario 1: Search for a user by name using the auto-complete feature.
Expected Outcome: Matching users are displayed in real-time as suggestions.
b. Test Role Assignment UI
Scenario 1: Assign a role using a dropdown or drag-and-drop.
Expected Outcome: Role is correctly assigned, and UI updates accordingly.

4. Security Tests
a. Test Access Control and Authorization
Scenario 1: Ensure unauthorized users cannot access or modify team member information.
Expected Outcome: Proper access control is enforced, and unauthorized actions are blocked.

Test Plan Execution Steps
Setup Test Environment
Ensure all dependencies and environment configurations are in place.
Seed test data as necessary.
Run Unit Tests: Execute all unit tests and ensure all pass with expected behavior.
Run Integration Tests: Test workflows end-to-end to validate interactions between components.
UI and AJAX Testing: Test UI elements and AJAX responses to ensure smooth user interactions.

Testing Tools and Frameworks
RSpec: For unit and integration tests.
Capybara: For UI testing.
FactoryBot: For creating test data.

== Team ==
* Manideepika Reddy Myaka
* Bhuvan Chandra Kurra

CSC/ECE 517 Fall 2024 - E2479. Reimplement teams users controller.rb

2024-11-18T02:39:03Z

Bkurra: /* Implementation Plan */

== Expertiza ==
Expertiza is an open-source learning management system built with Ruby on Rails as its core. Its features include creating tests and assignments, managing assignment teams and courses, and having a solid framework to facilitate peer reviews and group comments. The main objective of this project is to reimplement teams_users_controller.rb. The goal is to reimplement teams_users_controller.rb from the Expertiza repository to the reimplementation-back-end repository to follow SOLID and DRY principles.

== Problem Statement ==
The following were the problems with the previous implementation :
* Lack of Modularity and SRP Violations: The create method is excessively long and handles multiple concerns such as finding users, checking assignments/courses, adding members, and handling various flash messages. This violates the Single Responsibility Principle (SRP) and makes the method difficult to maintain. Similar complexity is observed in other methods like auto_complete_for_user_name and delete.
* Redundant and Repetitive Code: There is significant duplication in handling AssignmentTeam and CourseTeam logic in the create method. This could be abstracted into separate model methods or helper functions. The repeated checks for user membership and participant status introduce unnecessary redundancy.
* Error Handling and Flash Message Management: Flash messages are scattered throughout the code, with some being overly complex and not user-friendly.
* Inconsistent and Non-Descriptive Naming: Variable and method names, such as urlCreate, add_member_return, and urlCourseParticipantList, do not follow consistent naming conventions and are not very descriptive.
* Tightly Coupled Logic: Business logic, such as validating membership and handling team participant status, resides within the controller instead of being abstracted into model methods. This makes the controller overly complex and difficult to test. Logic specific to AssignmentTeam and CourseTeam is handled in the controller, whereas it should ideally be part of respective models or services.
* Poor Use of Access Control Mechanism: The action_allowed? method is hardcoded to check for privileges using strings and is difficult to extend.
* Insufficient User Feedback and Validation: The implementation lacks comprehensive validation and feedback mechanisms, such as form-level client-side validation, detailed error messages, and modern UX elements like modal pop-ups or toast notifications.
* Limited Error Handling in Batch Operations: The delete_selected method performs deletions in a loop without adequate error handling or feedback for each item.
* Unclear Role Management: The update_duties method updates a duty using direct attribute assignment without validation or checks, potentially leading to data inconsistency.

==Implementation Plan==
* Break down the create method into smaller, helper methods to ensure each performs a specific, single task. Abstract shared logic into these helper methods to eliminate redundant code, improving modularity and maintainability.
* Move business logic out of the controller and into the model. The controller should primarily handle interactions between the views and models, while models encapsulate business logic such as team membership validation or user assignment checks.
* Replace action_allowed? with policy classes (e.g., using Pundit) to provide a clear, granular, and consistent approach to managing access control based on roles and permissions.
* Leverage polymorphism by coding common functionalities (e.g., user-team membership rules) in the AssignmentTeam and MentoredTeam models.
* Use AJAX to make core actions such as adding, updating, or removing members more dynamic and responsive without page reloads.
* Adhere to consistent and meaningful variable naming conventions throughout the controller. And document every method with clear, descriptive comments explaining its purpose, input parameters, and expected outcomes.
* Implement auto-complete, error messages, and toast notifications to provide better user feedback and guidance.
* Add filtering and UI improvements to manage member listings to enhance usability.
* Develop detailed unit and integration tests to ensure robust coverage of controller actions, focusing on both normal and edge cases.
* Design intuitive, interactive UI components such as dropdowns or drag-and-drop elements, for role assignments, and ensure they follow a modular, easily maintainable, and extendable modular structure.

*Refactoring TeamsUsersController to TeamsParticipantsController: The controller will be renamed and restructured to better align with the domain model. All associated views, routes, and models will be updated accordingly.

*Modular Methods and DRY Principles: Each method will be decomposed into smaller, reusable helper methods, ensuring adherence to the Single Responsibility Principle (SRP).
create Method: Split into smaller helper methods:
find_user: Locates a user based on input.
create_user: Creates a user based on input
check_user_already_on_team?: Validates user is already in the team or not
add_user_to_team: Handles adding a user to the team if all conditions are met.
Move Logic to Models: E.g., team_exceeds_capacity?, to keep the controller clean.

*Role Management and UI Enhancement: Role management functionality, such as role assignments and updates, will use intuitive UI elements like dropdowns, with role descriptions available for clarity.

*AJAX Integration for Dynamic Updates: Key actions such as adding and removing members will use AJAX to provide a smooth user experience.

*Policy-Based Access Control: Replace action_allowed? with Policy Classes. Fine-grained permissions will be enforced using a library like Pundit to control access to various actions based on user roles.

*Auto-Complete and Filtering: Auto-complete for user search will provide more context (e.g., name, email), and filters will be added for improved member listing.

*Quality of Explanations: Clear and Detailed Explanations: All proposed changes, such as modularizing the create method, are clearly explained with an emphasis on improving readability and reducing complexity.

*Follow Consistent Naming Conventions: Ensure variable and method names are descriptive and consistent across the controller.

*Avoid Overloading Controllers: Ensure complex logic is moved to models, helpers, or service objects to prevent bloated controllers. This makes code easier to maintain and adheres to MVC principles.
Proper Allocation of Responsibilities: E.g., methods for checking membership should be in Team or TeamsParticipant models, not the controller.

*Repetitive Logic and Nesting: Excessive nesting and duplicated logic can lead to code smell. Refactor common checks (e.g., user existence, membership) into helper methods.

*Verbose Controllers: Long controllers tend to indicate poor separation of concerns. Any domain-specific logic should reside in models or services.

== Flow Chart for the teams_users_controller Page ==
[[File:Teams_participants_controller.png]]
=UML Diagram=
[[File: teamsParticipants_uml.png]]

== Testing ==
Our test plan will generally involve testing using RSpec and UI tests to ensure the functionality remains the same without affecting the existing functionality. This involves adding RSpec test commands for teams_user_controller and teams_user model to verify that each component functions as expected within the refactored structure. Additionally, we will run UI tests to ensure that the teams_participants page display accurately and integrates seamlessly within the Expertiza interface.

1. Unit Tests
a. Test the create Method
Scenario 1: Successfully adding a user to a team.

Preconditions: User exists, user is not already on a team, and team capacity is not exceeded.
Expected Outcome: User is added to the team, a success message is displayed, and the user is redirected.
Scenario 2: Adding a non-existent user.

Preconditions: User does not exist in the system.
Expected Outcome: Appropriate error message is displayed with a link to create the user.
Scenario 3: Adding a user who is already a member of another team.

Preconditions: User is already assigned to a different team within the same assignment/course.
Expected Outcome: User is not added, and an error message is displayed.
Scenario 4: Adding a user as a mentor.

Preconditions: User is designated as a mentor and the team does not have a mentor yet.
Expected Outcome: User is added as a mentor, and appropriate success message is displayed.
Scenario 5: Team is at maximum capacity.

Preconditions: Team has reached its maximum allowed members.
Expected Outcome: User is not added, and an error message indicating maximum capacity is displayed.
b. Test the delete Method
Scenario 1: Successfully removing a user from a team.

Preconditions: User is a member of the team.
Expected Outcome: User is removed from the team, and a success message is displayed.
Scenario 2: Removing a non-existent TeamsUser record.

Preconditions: TeamsUser record does not exist.
Expected Outcome: Error is handled gracefully, and a suitable error message is displayed.
c. Test the delete_selected Method
Scenario 1: Successfully removing multiple selected users from a team.
Preconditions: Multiple valid TeamsUser records exist for the team.
Expected Outcome: All selected users are removed, and a success message is displayed.
d. Test the list Method
Scenario 2: Listing members with filters.

Preconditions: Filters are applied (e.g., by role).
Expected Outcome: Only filtered members are displayed.
e. Test the update_duties Method
Scenario 1: Updating a user’s role within a team.
Preconditions: Valid TeamsUser record exists.
Expected Outcome: User’s role is updated, and a success message is displayed.
2. Integration Tests
a. Test User Creation and Assignment Workflow
Scenario 1: Create a new user and add them to a team.
Expected Outcome: User is created, validated, and added to the team successfully.
b. Test Removing and Re-adding Users
Scenario 1: Remove a user from a team and re-add them.
Expected Outcome: User is successfully removed and can be re-added if team conditions are met.
c. Test Access Control Policies
Scenario 1: User with insufficient privileges tries to create, update, or delete team members.

Expected Outcome: Access is denied with an appropriate message.
Scenario 2: Admin users perform team member management actions.

Expected Outcome: Actions are allowed with expected results.
3. User Interface (UI) Tests
a. Test Auto-Complete Feature
Scenario 1: Search for a user by name using the auto-complete feature.
Expected Outcome: Matching users are displayed in real-time as suggestions.
b. Test Role Assignment UI
Scenario 1: Assign a role using a dropdown or drag-and-drop.
Expected Outcome: Role is correctly assigned, and UI updates accordingly.

4. Security Tests
a. Test Access Control and Authorization
Scenario 1: Ensure unauthorized users cannot access or modify team member information.
Expected Outcome: Proper access control is enforced, and unauthorized actions are blocked.

Test Plan Execution Steps
Setup Test Environment
Ensure all dependencies and environment configurations are in place.
Seed test data as necessary.
Run Unit Tests: Execute all unit tests and ensure all pass with expected behavior.
Run Integration Tests: Test workflows end-to-end to validate interactions between components.
UI and AJAX Testing: Test UI elements and AJAX responses to ensure smooth user interactions.

Testing Tools and Frameworks
RSpec: For unit and integration tests.
Capybara: For UI testing.
FactoryBot: For creating test data.

== Team ==
* Manideepika Reddy Myaka
* Bhuvan Chandra Kurra

CSC/ECE 517 Fall 2024 - E2479. Reimplement teams users controller.rb

2024-11-18T02:37:09Z

Bkurra: /* Implementation Plan */

== Expertiza ==
Expertiza is an open-source learning management system built with Ruby on Rails as its core. Its features include creating tests and assignments, managing assignment teams and courses, and having a solid framework to facilitate peer reviews and group comments. The main objective of this project is to reimplement teams_users_controller.rb. The goal is to reimplement teams_users_controller.rb from the Expertiza repository to the reimplementation-back-end repository to follow SOLID and DRY principles.

== Problem Statement ==
The following were the problems with the previous implementation :
* Lack of Modularity and SRP Violations: The create method is excessively long and handles multiple concerns such as finding users, checking assignments/courses, adding members, and handling various flash messages. This violates the Single Responsibility Principle (SRP) and makes the method difficult to maintain. Similar complexity is observed in other methods like auto_complete_for_user_name and delete.
* Redundant and Repetitive Code: There is significant duplication in handling AssignmentTeam and CourseTeam logic in the create method. This could be abstracted into separate model methods or helper functions. The repeated checks for user membership and participant status introduce unnecessary redundancy.
* Error Handling and Flash Message Management: Flash messages are scattered throughout the code, with some being overly complex and not user-friendly.
* Inconsistent and Non-Descriptive Naming: Variable and method names, such as urlCreate, add_member_return, and urlCourseParticipantList, do not follow consistent naming conventions and are not very descriptive.
* Tightly Coupled Logic: Business logic, such as validating membership and handling team participant status, resides within the controller instead of being abstracted into model methods. This makes the controller overly complex and difficult to test. Logic specific to AssignmentTeam and CourseTeam is handled in the controller, whereas it should ideally be part of respective models or services.
* Poor Use of Access Control Mechanism: The action_allowed? method is hardcoded to check for privileges using strings and is difficult to extend.
* Insufficient User Feedback and Validation: The implementation lacks comprehensive validation and feedback mechanisms, such as form-level client-side validation, detailed error messages, and modern UX elements like modal pop-ups or toast notifications.
* Limited Error Handling in Batch Operations: The delete_selected method performs deletions in a loop without adequate error handling or feedback for each item.
* Unclear Role Management: The update_duties method updates a duty using direct attribute assignment without validation or checks, potentially leading to data inconsistency.

==Implementation Plan==
* Break down the create method into smaller, helper methods to ensure each performs a specific, single task. Abstract shared logic into these helper methods to eliminate redundant code, improving modularity and maintainability.
* Move business logic out of the controller and into the model. The controller should primarily handle interactions between the views and models, while models encapsulate business logic such as team membership validation or user assignment checks.
* Replace action_allowed? with policy classes (e.g., using Pundit) to provide a clear, granular, and consistent approach to managing access control based on roles and permissions.
* Leverage polymorphism by coding common functionalities (e.g., user-team membership rules) in the AssignmentTeam and MentoredTeam models.
* Use AJAX to make core actions such as adding, updating, or removing members more dynamic and responsive without page reloads.
* Adhere to consistent and meaningful variable naming conventions throughout the controller. And document every method with clear, descriptive comments explaining its purpose, input parameters, and expected outcomes.
* Implement auto-complete, error messages, and toast notifications to provide better user feedback and guidance.
* Add filtering and UI improvements to manage member listings to enhance usability.
* Develop detailed unit and integration tests to ensure robust coverage of controller actions, focusing on both normal and edge cases.
* Design intuitive, interactive UI components such as dropdowns or drag-and-drop elements, for role assignments, and ensure they follow a modular, easily maintainable, and extendable modular structure.

Refactoring TeamsUsersController to TeamsParticipantsController: The controller will be renamed and restructured to better align with the domain model. All associated views, routes, and models will be updated accordingly.

Modular Methods and DRY Principles: Each method will be decomposed into smaller, reusable helper methods, ensuring adherence to the Single Responsibility Principle (SRP).
create Method: Split into smaller helper methods:
find_user: Locates a user based on input.
create_user: Creates a user based on input
check_user_already_on_team?: Validates user is already in the team or not
add_user_to_team: Handles adding a user to the team if all conditions are met.
Move Logic to Models: E.g., team_exceeds_capacity?, to keep the controller clean.

Role Management and UI Enhancement: Role management functionality, such as role assignments and updates, will use intuitive UI elements like dropdowns, with role descriptions available for clarity.

AJAX Integration for Dynamic Updates: Key actions such as adding and removing members will use AJAX to provide a smooth user experience.

Policy-Based Access Control: Replace action_allowed? with Policy Classes. Fine-grained permissions will be enforced using a library like Pundit to control access to various actions based on user roles.

Auto-Complete and Filtering: Auto-complete for user search will provide more context (e.g., name, email), and filters will be added for improved member listing.

Quality of Explanations: Clear and Detailed Explanations: All proposed changes, such as modularizing the create method, are clearly explained with an emphasis on improving readability and reducing complexity.

Follow Consistent Naming Conventions: Ensure variable and method names are descriptive and consistent across the controller.

Avoid Overloading Controllers: Ensure complex logic is moved to models, helpers, or service objects to prevent bloated controllers. This makes code easier to maintain and adheres to MVC principles.
Proper Allocation of Responsibilities: E.g., methods for checking membership should be in Team or TeamsParticipant models, not the controller.

Repetitive Logic and Nesting: Excessive nesting and duplicated logic can lead to code smell. Refactor common checks (e.g., user existence, membership) into helper methods.

Verbose Controllers: Long controllers tend to indicate poor separation of concerns. Any domain-specific logic should reside in models or services.

== Flow Chart for the teams_users_controller Page ==
[[File:Teams_participants_controller.png]]
=UML Diagram=
[[File: teamsParticipants_uml.png]]

== Testing ==
Our test plan will generally involve testing using RSpec and UI tests to ensure the functionality remains the same without affecting the existing functionality. This involves adding RSpec test commands for teams_user_controller and teams_user model to verify that each component functions as expected within the refactored structure. Additionally, we will run UI tests to ensure that the teams_participants page display accurately and integrates seamlessly within the Expertiza interface.

1. Unit Tests
a. Test the create Method
Scenario 1: Successfully adding a user to a team.

Preconditions: User exists, user is not already on a team, and team capacity is not exceeded.
Expected Outcome: User is added to the team, a success message is displayed, and the user is redirected.
Scenario 2: Adding a non-existent user.

Preconditions: User does not exist in the system.
Expected Outcome: Appropriate error message is displayed with a link to create the user.
Scenario 3: Adding a user who is already a member of another team.

Preconditions: User is already assigned to a different team within the same assignment/course.
Expected Outcome: User is not added, and an error message is displayed.
Scenario 4: Adding a user as a mentor.

Preconditions: User is designated as a mentor and the team does not have a mentor yet.
Expected Outcome: User is added as a mentor, and appropriate success message is displayed.
Scenario 5: Team is at maximum capacity.

Preconditions: Team has reached its maximum allowed members.
Expected Outcome: User is not added, and an error message indicating maximum capacity is displayed.
b. Test the delete Method
Scenario 1: Successfully removing a user from a team.

Preconditions: User is a member of the team.
Expected Outcome: User is removed from the team, and a success message is displayed.
Scenario 2: Removing a non-existent TeamsUser record.

Preconditions: TeamsUser record does not exist.
Expected Outcome: Error is handled gracefully, and a suitable error message is displayed.
c. Test the delete_selected Method
Scenario 1: Successfully removing multiple selected users from a team.
Preconditions: Multiple valid TeamsUser records exist for the team.
Expected Outcome: All selected users are removed, and a success message is displayed.
d. Test the list Method
Scenario 2: Listing members with filters.

Preconditions: Filters are applied (e.g., by role).
Expected Outcome: Only filtered members are displayed.
e. Test the update_duties Method
Scenario 1: Updating a user’s role within a team.
Preconditions: Valid TeamsUser record exists.
Expected Outcome: User’s role is updated, and a success message is displayed.
2. Integration Tests
a. Test User Creation and Assignment Workflow
Scenario 1: Create a new user and add them to a team.
Expected Outcome: User is created, validated, and added to the team successfully.
b. Test Removing and Re-adding Users
Scenario 1: Remove a user from a team and re-add them.
Expected Outcome: User is successfully removed and can be re-added if team conditions are met.
c. Test Access Control Policies
Scenario 1: User with insufficient privileges tries to create, update, or delete team members.

Expected Outcome: Access is denied with an appropriate message.
Scenario 2: Admin users perform team member management actions.

Expected Outcome: Actions are allowed with expected results.
3. User Interface (UI) Tests
a. Test Auto-Complete Feature
Scenario 1: Search for a user by name using the auto-complete feature.
Expected Outcome: Matching users are displayed in real-time as suggestions.
b. Test Role Assignment UI
Scenario 1: Assign a role using a dropdown or drag-and-drop.
Expected Outcome: Role is correctly assigned, and UI updates accordingly.

4. Security Tests
a. Test Access Control and Authorization
Scenario 1: Ensure unauthorized users cannot access or modify team member information.
Expected Outcome: Proper access control is enforced, and unauthorized actions are blocked.

Test Plan Execution Steps
Setup Test Environment
Ensure all dependencies and environment configurations are in place.
Seed test data as necessary.
Run Unit Tests: Execute all unit tests and ensure all pass with expected behavior.
Run Integration Tests: Test workflows end-to-end to validate interactions between components.
UI and AJAX Testing: Test UI elements and AJAX responses to ensure smooth user interactions.

Testing Tools and Frameworks
RSpec: For unit and integration tests.
Capybara: For UI testing.
FactoryBot: For creating test data.

== Team ==
* Manideepika Reddy Myaka
* Bhuvan Chandra Kurra

CSC/ECE 517 Fall 2024 - E2479. Reimplement teams users controller.rb

2024-11-18T02:36:00Z

Bkurra: /* Testing */

== Expertiza ==
Expertiza is an open-source learning management system built with Ruby on Rails as its core. Its features include creating tests and assignments, managing assignment teams and courses, and having a solid framework to facilitate peer reviews and group comments. The main objective of this project is to reimplement teams_users_controller.rb. The goal is to reimplement teams_users_controller.rb from the Expertiza repository to the reimplementation-back-end repository to follow SOLID and DRY principles.

== Problem Statement ==
The following were the problems with the previous implementation :
* Lack of Modularity and SRP Violations: The create method is excessively long and handles multiple concerns such as finding users, checking assignments/courses, adding members, and handling various flash messages. This violates the Single Responsibility Principle (SRP) and makes the method difficult to maintain. Similar complexity is observed in other methods like auto_complete_for_user_name and delete.
* Redundant and Repetitive Code: There is significant duplication in handling AssignmentTeam and CourseTeam logic in the create method. This could be abstracted into separate model methods or helper functions. The repeated checks for user membership and participant status introduce unnecessary redundancy.
* Error Handling and Flash Message Management: Flash messages are scattered throughout the code, with some being overly complex and not user-friendly.
* Inconsistent and Non-Descriptive Naming: Variable and method names, such as urlCreate, add_member_return, and urlCourseParticipantList, do not follow consistent naming conventions and are not very descriptive.
* Tightly Coupled Logic: Business logic, such as validating membership and handling team participant status, resides within the controller instead of being abstracted into model methods. This makes the controller overly complex and difficult to test. Logic specific to AssignmentTeam and CourseTeam is handled in the controller, whereas it should ideally be part of respective models or services.
* Poor Use of Access Control Mechanism: The action_allowed? method is hardcoded to check for privileges using strings and is difficult to extend.
* Insufficient User Feedback and Validation: The implementation lacks comprehensive validation and feedback mechanisms, such as form-level client-side validation, detailed error messages, and modern UX elements like modal pop-ups or toast notifications.
* Limited Error Handling in Batch Operations: The delete_selected method performs deletions in a loop without adequate error handling or feedback for each item.
* Unclear Role Management: The update_duties method updates a duty using direct attribute assignment without validation or checks, potentially leading to data inconsistency.

==Implementation Plan==
* Break down the create method into smaller, helper methods to ensure each performs a specific, single task. Abstract shared logic into these helper methods to eliminate redundant code, improving modularity and maintainability.
* Move business logic out of the controller and into the model. The controller should primarily handle interactions between the views and models, while models encapsulate business logic such as team membership validation or user assignment checks.
* Replace action_allowed? with policy classes (e.g., using Pundit) to provide a clear, granular, and consistent approach to managing access control based on roles and permissions.
* Leverage polymorphism by coding common functionalities (e.g., user-team membership rules) in the AssignmentTeam and MentoredTeam models.
* Use AJAX to make core actions such as adding, updating, or removing members more dynamic and responsive without page reloads.
* Adhere to consistent and meaningful variable naming conventions throughout the controller. And document every method with clear, descriptive comments explaining its purpose, input parameters, and expected outcomes.
* Implement auto-complete, error messages, and toast notifications to provide better user feedback and guidance.
* Add filtering and UI improvements to manage member listings to enhance usability.
* Develop detailed unit and integration tests to ensure robust coverage of controller actions, focusing on both normal and edge cases.
* Design intuitive, interactive UI components such as dropdowns or drag-and-drop elements, for role assignments, and ensure they follow a modular, easily maintainable, and extendable modular structure.

== Flow Chart for the teams_users_controller Page ==
[[File:Teams_participants_controller.png]]
=UML Diagram=
[[File: teamsParticipants_uml.png]]

== Testing ==
Our test plan will generally involve testing using RSpec and UI tests to ensure the functionality remains the same without affecting the existing functionality. This involves adding RSpec test commands for teams_user_controller and teams_user model to verify that each component functions as expected within the refactored structure. Additionally, we will run UI tests to ensure that the teams_participants page display accurately and integrates seamlessly within the Expertiza interface.

1. Unit Tests
a. Test the create Method
Scenario 1: Successfully adding a user to a team.

Preconditions: User exists, user is not already on a team, and team capacity is not exceeded.
Expected Outcome: User is added to the team, a success message is displayed, and the user is redirected.
Scenario 2: Adding a non-existent user.

Preconditions: User does not exist in the system.
Expected Outcome: Appropriate error message is displayed with a link to create the user.
Scenario 3: Adding a user who is already a member of another team.

Preconditions: User is already assigned to a different team within the same assignment/course.
Expected Outcome: User is not added, and an error message is displayed.
Scenario 4: Adding a user as a mentor.

Preconditions: User is designated as a mentor and the team does not have a mentor yet.
Expected Outcome: User is added as a mentor, and appropriate success message is displayed.
Scenario 5: Team is at maximum capacity.

Preconditions: Team has reached its maximum allowed members.
Expected Outcome: User is not added, and an error message indicating maximum capacity is displayed.
b. Test the delete Method
Scenario 1: Successfully removing a user from a team.

Preconditions: User is a member of the team.
Expected Outcome: User is removed from the team, and a success message is displayed.
Scenario 2: Removing a non-existent TeamsUser record.

Preconditions: TeamsUser record does not exist.
Expected Outcome: Error is handled gracefully, and a suitable error message is displayed.
c. Test the delete_selected Method
Scenario 1: Successfully removing multiple selected users from a team.
Preconditions: Multiple valid TeamsUser records exist for the team.
Expected Outcome: All selected users are removed, and a success message is displayed.
d. Test the list Method
Scenario 2: Listing members with filters.

Preconditions: Filters are applied (e.g., by role).
Expected Outcome: Only filtered members are displayed.
e. Test the update_duties Method
Scenario 1: Updating a user’s role within a team.
Preconditions: Valid TeamsUser record exists.
Expected Outcome: User’s role is updated, and a success message is displayed.
2. Integration Tests
a. Test User Creation and Assignment Workflow
Scenario 1: Create a new user and add them to a team.
Expected Outcome: User is created, validated, and added to the team successfully.
b. Test Removing and Re-adding Users
Scenario 1: Remove a user from a team and re-add them.
Expected Outcome: User is successfully removed and can be re-added if team conditions are met.
c. Test Access Control Policies
Scenario 1: User with insufficient privileges tries to create, update, or delete team members.

Expected Outcome: Access is denied with an appropriate message.
Scenario 2: Admin users perform team member management actions.

Expected Outcome: Actions are allowed with expected results.
3. User Interface (UI) Tests
a. Test Auto-Complete Feature
Scenario 1: Search for a user by name using the auto-complete feature.
Expected Outcome: Matching users are displayed in real-time as suggestions.
b. Test Role Assignment UI
Scenario 1: Assign a role using a dropdown or drag-and-drop.
Expected Outcome: Role is correctly assigned, and UI updates accordingly.

4. Security Tests
a. Test Access Control and Authorization
Scenario 1: Ensure unauthorized users cannot access or modify team member information.
Expected Outcome: Proper access control is enforced, and unauthorized actions are blocked.

Test Plan Execution Steps
Setup Test Environment
Ensure all dependencies and environment configurations are in place.
Seed test data as necessary.
Run Unit Tests: Execute all unit tests and ensure all pass with expected behavior.
Run Integration Tests: Test workflows end-to-end to validate interactions between components.
UI and AJAX Testing: Test UI elements and AJAX responses to ensure smooth user interactions.

Testing Tools and Frameworks
RSpec: For unit and integration tests.
Capybara: For UI testing.
FactoryBot: For creating test data.

== Team ==
* Manideepika Reddy Myaka
* Bhuvan Chandra Kurra

CSC/ECE 517 Fall 2024 - E2479. Reimplement teams users controller.rb

2024-11-18T02:35:42Z

Bkurra: /* Testing */

== Expertiza ==
Expertiza is an open-source learning management system built with Ruby on Rails as its core. Its features include creating tests and assignments, managing assignment teams and courses, and having a solid framework to facilitate peer reviews and group comments. The main objective of this project is to reimplement teams_users_controller.rb. The goal is to reimplement teams_users_controller.rb from the Expertiza repository to the reimplementation-back-end repository to follow SOLID and DRY principles.

== Problem Statement ==
The following were the problems with the previous implementation :
* Lack of Modularity and SRP Violations: The create method is excessively long and handles multiple concerns such as finding users, checking assignments/courses, adding members, and handling various flash messages. This violates the Single Responsibility Principle (SRP) and makes the method difficult to maintain. Similar complexity is observed in other methods like auto_complete_for_user_name and delete.
* Redundant and Repetitive Code: There is significant duplication in handling AssignmentTeam and CourseTeam logic in the create method. This could be abstracted into separate model methods or helper functions. The repeated checks for user membership and participant status introduce unnecessary redundancy.
* Error Handling and Flash Message Management: Flash messages are scattered throughout the code, with some being overly complex and not user-friendly.
* Inconsistent and Non-Descriptive Naming: Variable and method names, such as urlCreate, add_member_return, and urlCourseParticipantList, do not follow consistent naming conventions and are not very descriptive.
* Tightly Coupled Logic: Business logic, such as validating membership and handling team participant status, resides within the controller instead of being abstracted into model methods. This makes the controller overly complex and difficult to test. Logic specific to AssignmentTeam and CourseTeam is handled in the controller, whereas it should ideally be part of respective models or services.
* Poor Use of Access Control Mechanism: The action_allowed? method is hardcoded to check for privileges using strings and is difficult to extend.
* Insufficient User Feedback and Validation: The implementation lacks comprehensive validation and feedback mechanisms, such as form-level client-side validation, detailed error messages, and modern UX elements like modal pop-ups or toast notifications.
* Limited Error Handling in Batch Operations: The delete_selected method performs deletions in a loop without adequate error handling or feedback for each item.
* Unclear Role Management: The update_duties method updates a duty using direct attribute assignment without validation or checks, potentially leading to data inconsistency.

==Implementation Plan==
* Break down the create method into smaller, helper methods to ensure each performs a specific, single task. Abstract shared logic into these helper methods to eliminate redundant code, improving modularity and maintainability.
* Move business logic out of the controller and into the model. The controller should primarily handle interactions between the views and models, while models encapsulate business logic such as team membership validation or user assignment checks.
* Replace action_allowed? with policy classes (e.g., using Pundit) to provide a clear, granular, and consistent approach to managing access control based on roles and permissions.
* Leverage polymorphism by coding common functionalities (e.g., user-team membership rules) in the AssignmentTeam and MentoredTeam models.
* Use AJAX to make core actions such as adding, updating, or removing members more dynamic and responsive without page reloads.
* Adhere to consistent and meaningful variable naming conventions throughout the controller. And document every method with clear, descriptive comments explaining its purpose, input parameters, and expected outcomes.
* Implement auto-complete, error messages, and toast notifications to provide better user feedback and guidance.
* Add filtering and UI improvements to manage member listings to enhance usability.
* Develop detailed unit and integration tests to ensure robust coverage of controller actions, focusing on both normal and edge cases.
* Design intuitive, interactive UI components such as dropdowns or drag-and-drop elements, for role assignments, and ensure they follow a modular, easily maintainable, and extendable modular structure.

== Flow Chart for the teams_users_controller Page ==
[[File:Teams_participants_controller.png]]
=UML Diagram=
[[File: teamsParticipants_uml.png]]

== Testing ==
Our test plan will generally involve testing using RSpec and UI tests to ensure the functionality remains the same without affecting the existing functionality. This involves adding RSpec test commands for teams_user_controller and teams_user model to verify that each component functions as expected within the refactored structure. Additionally, we will run UI tests to ensure that the teams_participants page display accurately and integrates seamlessly within the Expertiza interface.
1. Unit Tests
a. Test the create Method
Scenario 1: Successfully adding a user to a team.

Preconditions: User exists, user is not already on a team, and team capacity is not exceeded.
Expected Outcome: User is added to the team, a success message is displayed, and the user is redirected.
Scenario 2: Adding a non-existent user.

Preconditions: User does not exist in the system.
Expected Outcome: Appropriate error message is displayed with a link to create the user.
Scenario 3: Adding a user who is already a member of another team.

Preconditions: User is already assigned to a different team within the same assignment/course.
Expected Outcome: User is not added, and an error message is displayed.
Scenario 4: Adding a user as a mentor.

Preconditions: User is designated as a mentor and the team does not have a mentor yet.
Expected Outcome: User is added as a mentor, and appropriate success message is displayed.
Scenario 5: Team is at maximum capacity.

Preconditions: Team has reached its maximum allowed members.
Expected Outcome: User is not added, and an error message indicating maximum capacity is displayed.
b. Test the delete Method
Scenario 1: Successfully removing a user from a team.

Preconditions: User is a member of the team.
Expected Outcome: User is removed from the team, and a success message is displayed.
Scenario 2: Removing a non-existent TeamsUser record.

Preconditions: TeamsUser record does not exist.
Expected Outcome: Error is handled gracefully, and a suitable error message is displayed.
c. Test the delete_selected Method
Scenario 1: Successfully removing multiple selected users from a team.
Preconditions: Multiple valid TeamsUser records exist for the team.
Expected Outcome: All selected users are removed, and a success message is displayed.
d. Test the list Method
Scenario 2: Listing members with filters.

Preconditions: Filters are applied (e.g., by role).
Expected Outcome: Only filtered members are displayed.
e. Test the update_duties Method
Scenario 1: Updating a user’s role within a team.
Preconditions: Valid TeamsUser record exists.
Expected Outcome: User’s role is updated, and a success message is displayed.
2. Integration Tests
a. Test User Creation and Assignment Workflow
Scenario 1: Create a new user and add them to a team.
Expected Outcome: User is created, validated, and added to the team successfully.
b. Test Removing and Re-adding Users
Scenario 1: Remove a user from a team and re-add them.
Expected Outcome: User is successfully removed and can be re-added if team conditions are met.
c. Test Access Control Policies
Scenario 1: User with insufficient privileges tries to create, update, or delete team members.

Expected Outcome: Access is denied with an appropriate message.
Scenario 2: Admin users perform team member management actions.

Expected Outcome: Actions are allowed with expected results.
3. User Interface (UI) Tests
a. Test Auto-Complete Feature
Scenario 1: Search for a user by name using the auto-complete feature.
Expected Outcome: Matching users are displayed in real-time as suggestions.
b. Test Role Assignment UI
Scenario 1: Assign a role using a dropdown or drag-and-drop.
Expected Outcome: Role is correctly assigned, and UI updates accordingly.

4. Security Tests
a. Test Access Control and Authorization
Scenario 1: Ensure unauthorized users cannot access or modify team member information.
Expected Outcome: Proper access control is enforced, and unauthorized actions are blocked.

Test Plan Execution Steps
Setup Test Environment
Ensure all dependencies and environment configurations are in place.
Seed test data as necessary.
Run Unit Tests: Execute all unit tests and ensure all pass with expected behavior.
Run Integration Tests: Test workflows end-to-end to validate interactions between components.
UI and AJAX Testing: Test UI elements and AJAX responses to ensure smooth user interactions.

Testing Tools and Frameworks
RSpec: For unit and integration tests.
Capybara: For UI testing.
FactoryBot: For creating test data.

== Team ==
* Manideepika Reddy Myaka
* Bhuvan Chandra Kurra

CSC/ECE 517 Fall 2024 - E2479. Reimplement teams users controller.rb

2024-11-18T02:35:34Z

Bkurra: /* Implementation Plan */

CSC/ECE 517 Fall 2024 - E2479. Reimplement teams users controller.rb

2024-11-18T02:35:14Z

Bkurra: /* Implementation Plan */

== Expertiza ==
Expertiza is an open-source learning management system built with Ruby on Rails as its core. Its features include creating tests and assignments, managing assignment teams and courses, and having a solid framework to facilitate peer reviews and group comments. The main objective of this project is to reimplement teams_users_controller.rb. The goal is to reimplement teams_users_controller.rb from the Expertiza repository to the reimplementation-back-end repository to follow SOLID and DRY principles.

== Problem Statement ==
The following were the problems with the previous implementation :
* Lack of Modularity and SRP Violations: The create method is excessively long and handles multiple concerns such as finding users, checking assignments/courses, adding members, and handling various flash messages. This violates the Single Responsibility Principle (SRP) and makes the method difficult to maintain. Similar complexity is observed in other methods like auto_complete_for_user_name and delete.
* Redundant and Repetitive Code: There is significant duplication in handling AssignmentTeam and CourseTeam logic in the create method. This could be abstracted into separate model methods or helper functions. The repeated checks for user membership and participant status introduce unnecessary redundancy.
* Error Handling and Flash Message Management: Flash messages are scattered throughout the code, with some being overly complex and not user-friendly.
* Inconsistent and Non-Descriptive Naming: Variable and method names, such as urlCreate, add_member_return, and urlCourseParticipantList, do not follow consistent naming conventions and are not very descriptive.
* Tightly Coupled Logic: Business logic, such as validating membership and handling team participant status, resides within the controller instead of being abstracted into model methods. This makes the controller overly complex and difficult to test. Logic specific to AssignmentTeam and CourseTeam is handled in the controller, whereas it should ideally be part of respective models or services.
* Poor Use of Access Control Mechanism: The action_allowed? method is hardcoded to check for privileges using strings and is difficult to extend.
* Insufficient User Feedback and Validation: The implementation lacks comprehensive validation and feedback mechanisms, such as form-level client-side validation, detailed error messages, and modern UX elements like modal pop-ups or toast notifications.
* Limited Error Handling in Batch Operations: The delete_selected method performs deletions in a loop without adequate error handling or feedback for each item.
* Unclear Role Management: The update_duties method updates a duty using direct attribute assignment without validation or checks, potentially leading to data inconsistency.

==Implementation Plan==
* Break down the create method into smaller, helper methods to ensure each performs a specific, single task. Abstract shared logic into these helper methods to eliminate redundant code, improving modularity and maintainability.
* Move business logic out of the controller and into the model. The controller should primarily handle interactions between the views and models, while models encapsulate business logic such as team membership validation or user assignment checks.
* Replace action_allowed? with policy classes (e.g., using Pundit) to provide a clear, granular, and consistent approach to managing access control based on roles and permissions.
* Leverage polymorphism by coding common functionalities (e.g., user-team membership rules) in the AssignmentTeam and MentoredTeam models.
* Use AJAX to make core actions such as adding, updating, or removing members more dynamic and responsive without page reloads.
* Adhere to consistent and meaningful variable naming conventions throughout the controller. And document every method with clear, descriptive comments explaining its purpose, input parameters, and expected outcomes.
* Implement auto-complete, error messages, and toast notifications to provide better user feedback and guidance.
* Add filtering and UI improvements to manage member listings to enhance usability.
* Develop detailed unit and integration tests to ensure robust coverage of controller actions, focusing on both normal and edge cases.
* Design intuitive, interactive UI components such as dropdowns or drag-and-drop elements, for role assignments, and ensure they follow a modular, easily maintainable, and extendable modular structure.
1. Unit Tests
a. Test the create Method
Scenario 1: Successfully adding a user to a team.

Preconditions: User exists, user is not already on a team, and team capacity is not exceeded.
Expected Outcome: User is added to the team, a success message is displayed, and the user is redirected.
Scenario 2: Adding a non-existent user.

Preconditions: User does not exist in the system.
Expected Outcome: Appropriate error message is displayed with a link to create the user.
Scenario 3: Adding a user who is already a member of another team.

Preconditions: User is already assigned to a different team within the same assignment/course.
Expected Outcome: User is not added, and an error message is displayed.
Scenario 4: Adding a user as a mentor.

Preconditions: User is designated as a mentor and the team does not have a mentor yet.
Expected Outcome: User is added as a mentor, and appropriate success message is displayed.
Scenario 5: Team is at maximum capacity.

Preconditions: Team has reached its maximum allowed members.
Expected Outcome: User is not added, and an error message indicating maximum capacity is displayed.
b. Test the delete Method
Scenario 1: Successfully removing a user from a team.

Preconditions: User is a member of the team.
Expected Outcome: User is removed from the team, and a success message is displayed.
Scenario 2: Removing a non-existent TeamsUser record.

Preconditions: TeamsUser record does not exist.
Expected Outcome: Error is handled gracefully, and a suitable error message is displayed.
c. Test the delete_selected Method
Scenario 1: Successfully removing multiple selected users from a team.
Preconditions: Multiple valid TeamsUser records exist for the team.
Expected Outcome: All selected users are removed, and a success message is displayed.
d. Test the list Method
Scenario 2: Listing members with filters.

Preconditions: Filters are applied (e.g., by role).
Expected Outcome: Only filtered members are displayed.
e. Test the update_duties Method
Scenario 1: Updating a user’s role within a team.
Preconditions: Valid TeamsUser record exists.
Expected Outcome: User’s role is updated, and a success message is displayed.
2. Integration Tests
a. Test User Creation and Assignment Workflow
Scenario 1: Create a new user and add them to a team.
Expected Outcome: User is created, validated, and added to the team successfully.
b. Test Removing and Re-adding Users
Scenario 1: Remove a user from a team and re-add them.
Expected Outcome: User is successfully removed and can be re-added if team conditions are met.
c. Test Access Control Policies
Scenario 1: User with insufficient privileges tries to create, update, or delete team members.

Expected Outcome: Access is denied with an appropriate message.
Scenario 2: Admin users perform team member management actions.

Expected Outcome: Actions are allowed with expected results.
3. User Interface (UI) Tests
a. Test Auto-Complete Feature
Scenario 1: Search for a user by name using the auto-complete feature.
Expected Outcome: Matching users are displayed in real-time as suggestions.
b. Test Role Assignment UI
Scenario 1: Assign a role using a dropdown or drag-and-drop.
Expected Outcome: Role is correctly assigned, and UI updates accordingly.

4. Security Tests
a. Test Access Control and Authorization
Scenario 1: Ensure unauthorized users cannot access or modify team member information.
Expected Outcome: Proper access control is enforced, and unauthorized actions are blocked.

Test Plan Execution Steps
Setup Test Environment
Ensure all dependencies and environment configurations are in place.
Seed test data as necessary.
Run Unit Tests: Execute all unit tests and ensure all pass with expected behavior.
Run Integration Tests: Test workflows end-to-end to validate interactions between components.
UI and AJAX Testing: Test UI elements and AJAX responses to ensure smooth user interactions.

Testing Tools and Frameworks
RSpec: For unit and integration tests.
Capybara: For UI testing.
FactoryBot: For creating test data.

== Flow Chart for the teams_users_controller Page ==
[[File:Teams_participants_controller.png]]
=UML Diagram=
[[File: teamsParticipants_uml.png]]

== Testing ==
Our test plan will generally involve testing using RSpec and UI tests to ensure the functionality remains the same without affecting the existing functionality. This involves adding RSpec test commands for teams_user_controller and teams_user model to verify that each component functions as expected within the refactored structure. Additionally, we will run UI tests to ensure that the teams_participants page display accurately and integrates seamlessly within the Expertiza interface.

== Team ==
* Manideepika Reddy Myaka
* Bhuvan Chandra Kurra

CSC/ECE 517 Fall 2024 - E2479. Reimplement teams users controller.rb

2024-11-18T02:34:55Z

Bkurra: /* Implementation Plan */

== Expertiza ==
Expertiza is an open-source learning management system built with Ruby on Rails as its core. Its features include creating tests and assignments, managing assignment teams and courses, and having a solid framework to facilitate peer reviews and group comments. The main objective of this project is to reimplement teams_users_controller.rb. The goal is to reimplement teams_users_controller.rb from the Expertiza repository to the reimplementation-back-end repository to follow SOLID and DRY principles.

== Problem Statement ==
The following were the problems with the previous implementation :
* Lack of Modularity and SRP Violations: The create method is excessively long and handles multiple concerns such as finding users, checking assignments/courses, adding members, and handling various flash messages. This violates the Single Responsibility Principle (SRP) and makes the method difficult to maintain. Similar complexity is observed in other methods like auto_complete_for_user_name and delete.
* Redundant and Repetitive Code: There is significant duplication in handling AssignmentTeam and CourseTeam logic in the create method. This could be abstracted into separate model methods or helper functions. The repeated checks for user membership and participant status introduce unnecessary redundancy.
* Error Handling and Flash Message Management: Flash messages are scattered throughout the code, with some being overly complex and not user-friendly.
* Inconsistent and Non-Descriptive Naming: Variable and method names, such as urlCreate, add_member_return, and urlCourseParticipantList, do not follow consistent naming conventions and are not very descriptive.
* Tightly Coupled Logic: Business logic, such as validating membership and handling team participant status, resides within the controller instead of being abstracted into model methods. This makes the controller overly complex and difficult to test. Logic specific to AssignmentTeam and CourseTeam is handled in the controller, whereas it should ideally be part of respective models or services.
* Poor Use of Access Control Mechanism: The action_allowed? method is hardcoded to check for privileges using strings and is difficult to extend.
* Insufficient User Feedback and Validation: The implementation lacks comprehensive validation and feedback mechanisms, such as form-level client-side validation, detailed error messages, and modern UX elements like modal pop-ups or toast notifications.
* Limited Error Handling in Batch Operations: The delete_selected method performs deletions in a loop without adequate error handling or feedback for each item.
* Unclear Role Management: The update_duties method updates a duty using direct attribute assignment without validation or checks, potentially leading to data inconsistency.

==Implementation Plan==
* Break down the create method into smaller, helper methods to ensure each performs a specific, single task. Abstract shared logic into these helper methods to eliminate redundant code, improving modularity and maintainability.
* Move business logic out of the controller and into the model. The controller should primarily handle interactions between the views and models, while models encapsulate business logic such as team membership validation or user assignment checks.
* Replace action_allowed? with policy classes (e.g., using Pundit) to provide a clear, granular, and consistent approach to managing access control based on roles and permissions.
* Leverage polymorphism by coding common functionalities (e.g., user-team membership rules) in the AssignmentTeam and MentoredTeam models.
* Use AJAX to make core actions such as adding, updating, or removing members more dynamic and responsive without page reloads.
* Adhere to consistent and meaningful variable naming conventions throughout the controller. And document every method with clear, descriptive comments explaining its purpose, input parameters, and expected outcomes.
* Implement auto-complete, error messages, and toast notifications to provide better user feedback and guidance.
* Add filtering and UI improvements to manage member listings to enhance usability.
* Develop detailed unit and integration tests to ensure robust coverage of controller actions, focusing on both normal and edge cases.
* Design intuitive, interactive UI components such as dropdowns or drag-and-drop elements, for role assignments, and ensure they follow a modular, easily maintainable, and extendable modular structure.
1. 1. Unit Tests
a. Test the create Method
Scenario 1: Successfully adding a user to a team.

Preconditions: User exists, user is not already on a team, and team capacity is not exceeded.
Expected Outcome: User is added to the team, a success message is displayed, and the user is redirected.
Scenario 2: Adding a non-existent user.

Preconditions: User does not exist in the system.
Expected Outcome: Appropriate error message is displayed with a link to create the user.
Scenario 3: Adding a user who is already a member of another team.

Preconditions: User is already assigned to a different team within the same assignment/course.
Expected Outcome: User is not added, and an error message is displayed.
Scenario 4: Adding a user as a mentor.

Preconditions: User is designated as a mentor and the team does not have a mentor yet.
Expected Outcome: User is added as a mentor, and appropriate success message is displayed.
Scenario 5: Team is at maximum capacity.

Preconditions: Team has reached its maximum allowed members.
Expected Outcome: User is not added, and an error message indicating maximum capacity is displayed.
b. Test the delete Method
Scenario 1: Successfully removing a user from a team.

Preconditions: User is a member of the team.
Expected Outcome: User is removed from the team, and a success message is displayed.
Scenario 2: Removing a non-existent TeamsUser record.

Preconditions: TeamsUser record does not exist.
Expected Outcome: Error is handled gracefully, and a suitable error message is displayed.
c. Test the delete_selected Method
Scenario 1: Successfully removing multiple selected users from a team.
Preconditions: Multiple valid TeamsUser records exist for the team.
Expected Outcome: All selected users are removed, and a success message is displayed.
d. Test the list Method
Scenario 2: Listing members with filters.

Preconditions: Filters are applied (e.g., by role).
Expected Outcome: Only filtered members are displayed.
e. Test the update_duties Method
Scenario 1: Updating a user’s role within a team.
Preconditions: Valid TeamsUser record exists.
Expected Outcome: User’s role is updated, and a success message is displayed.
2. Integration Tests
a. Test User Creation and Assignment Workflow
Scenario 1: Create a new user and add them to a team.
Expected Outcome: User is created, validated, and added to the team successfully.
b. Test Removing and Re-adding Users
Scenario 1: Remove a user from a team and re-add them.
Expected Outcome: User is successfully removed and can be re-added if team conditions are met.
c. Test Access Control Policies
Scenario 1: User with insufficient privileges tries to create, update, or delete team members.

Expected Outcome: Access is denied with an appropriate message.
Scenario 2: Admin users perform team member management actions.

Expected Outcome: Actions are allowed with expected results.
3. User Interface (UI) Tests
a. Test Auto-Complete Feature
Scenario 1: Search for a user by name using the auto-complete feature.
Expected Outcome: Matching users are displayed in real-time as suggestions.
b. Test Role Assignment UI
Scenario 1: Assign a role using a dropdown or drag-and-drop.
Expected Outcome: Role is correctly assigned, and UI updates accordingly.

4. Security Tests
a. Test Access Control and Authorization
Scenario 1: Ensure unauthorized users cannot access or modify team member information.
Expected Outcome: Proper access control is enforced, and unauthorized actions are blocked.

Test Plan Execution Steps
Setup Test Environment
Ensure all dependencies and environment configurations are in place.
Seed test data as necessary.
Run Unit Tests: Execute all unit tests and ensure all pass with expected behavior.
Run Integration Tests: Test workflows end-to-end to validate interactions between components.
UI and AJAX Testing: Test UI elements and AJAX responses to ensure smooth user interactions.

Testing Tools and Frameworks
RSpec: For unit and integration tests.
Capybara: For UI testing.
FactoryBot: For creating test data.

== Flow Chart for the teams_users_controller Page ==
[[File:Teams_participants_controller.png]]
=UML Diagram=
[[File: teamsParticipants_uml.png]]

== Testing ==
Our test plan will generally involve testing using RSpec and UI tests to ensure the functionality remains the same without affecting the existing functionality. This involves adding RSpec test commands for teams_user_controller and teams_user model to verify that each component functions as expected within the refactored structure. Additionally, we will run UI tests to ensure that the teams_participants page display accurately and integrates seamlessly within the Expertiza interface.

== Team ==
* Manideepika Reddy Myaka
* Bhuvan Chandra Kurra

User:Bkurra

2024-10-30T01:48:36Z

Bkurra:

==Expertiza==
The Expertiza project, an open-source initiative based on Ruby on Rails, pursues ongoing enhancement to incorporate contemporary software engineering methodologies. The Responses Controller is designed to aid reviewers in supplying organized data that conforms to an assignment's rubrics, assuring the availability of pertinent questions for each round within the appropriate deadline. It allows a reviewer to assess and grade the rubric questions relevant to the assignment's subjects. Moreover, it guarantees the provision of relevant questions for each assignment round, enabling reviewers to generate and adjust scores and remarks for each rubric question linked to the assignment. Upon the submission of scored questions and comments by reviewers, the Responses Controller sends an email message to the instructor and the members of the reviewed team.

==Problem Statement==
The ResponseController in Expertiza, a historical system with conventions that predate Rails standards, is too intricate, incorporating functionalities that extend beyond simple CRUD operations and requiring compliance with contemporary Rails nomenclature and design concepts. Critical concerns encompass the direct execution of functions such as sorting reviews and verifying reviewer roles within the controller, indicating a transition towards polymorphism and a more systematic method of code organization. Moreover, the controller's management of email notifications and feedback systems is erratic, highlighting the need for a specialized assistant to optimize communication procedures. The reimplementation initiative must concentrate on streamlining the controller, conforming to Rails principles, and enhancing code readability and maintainability through the judicious allocation of responsibilities.

==Design Goal ==
The redesign of `responses_controller.rb` is driven by several primary aims aimed at enhancing code quality, system performance, and developer engagement. The objectives encompass:

* Maintainability and Scalability: Guaranteeing the code is comprehensible, modifiable, and extensible. The reimplementation should facilitate future updates and the incorporation of new features.

* Compliance with Rails Best Practices: Adhering to Rails conventions on nomenclature, architecture, and coding methodologies to guarantee code uniformity and dependability.

* DRY Principle: "Don't Repeat Yourself" - eliminating unnecessary code and logic to enhance efficiency and reduce errors in the codebase.

* Single Responsibility Principle: Reorganizing the controller and related models to ensure that each class and method has a singular purpose, hence facilitating enhanced testing and management.

* Enhanced Testing and Coverage: Augmenting test suites to encompass a broader range of scenarios and edge situations, hence bolstering confidence in the application's stability and performance.

* Performance Optimization: Recognizing and enhancing sluggish or ineffective segments in the code to guarantee the application operates seamlessly.

* Eliminate Obsolete Methods: Conduct an audit of the codebase to identify and delete any unneeded ("dead") methods inside the present controller to streamline the code.

* Diminished Controller Complexity: We have already streamlined the `ResponseController` to concentrate mostly on CRUD activities and have extracted non-essential functionality to suitable models or helpers; now we intend to implement the remaining operations.

By achieving these design objectives, the project seeks to create a `responses_controller.rb` that is resilient, efficient, and user-friendly for both the current development team and future system maintainers.

== Design Pattern ==

Throughout the code rewriting effort, we meticulously adhered to certain design patterns to improve the overall architecture.
During the redesign of the Response model and its corresponding controller and helper methods within the application, several fundamental design patterns and concepts were adhered to in order to enhance code quality, maintainability, and scalability. The following are the principal patterns and principles that were taken into account:

=== Single Responsibility Principle (SRP) ===
This technique was utilized to decompose intricate methods into smaller, more targeted functions that manage a specific aspect of the process.

In the Response Model, Validate_params was subdivided into several smaller methods, each responsible for a distinct aspect of the validation process. This enables each method to oversee a specific facet of the validation, hence enhancing the maintainability and modifiability of the code.
The establishment and administration of relationships and fundamental properties were distinctly articulated, ensuring that the Response class remains unencumbered by logic unrelated to its specific attributes or relationships.

In the ResponsesController, the methods such as create, update, and show are designed solely to manage HTTP requests while delegating business logic to the model or helper methods. This maintains the controller actions in a clean and focused manner for routing and fundamental request management.

In the ResponseHelper, methods like create_answers and update_answers exemplify the principle that each method is designated for either the creation or the updating of answers, but not both. This adheres to SRP by partitioning duties into more manageable, distinct operations.

===Factory Method===
The Factory Method design is implicitly evident when object generation procedures are encapsulated within the model or auxiliary methods, such as instantiating a new ResponseMap or generating new Answer objects. This guarantees that object instantiation is modular and distinct from the primary application logic.
===Strategy Pattern===
The strategy design enables the independent variation of algorithms by establishing a family of encapsulated algorithms, such as validation criteria for activities like creation or updating, and allowing them to be interchangeable for the clients that utilize them. Separating the validation criteria for response creation and updating facilitates the flexible interchange and enhancement of validation logic without necessitating direct alterations to the controller or model.
Observer Pattern
Typically employed in situations where modifications to a certain object must automatically inform other dependant objects. Within the framework of this program, this may pertain to alerting instructors or peers following the submission or modification of responses, managed via the auxiliary ways for dispatching emails.
===Template Method===
This pattern can be employed to delineate the framework of an operation within a method, postponing certain phases to subclasses or other methods. The validation process in validate_params employs a generic framework while delegating specific details to methods such as validate_create_conditions and validate_update_conditions.

The refactoring seeks to establish a more resilient, manageable, and scalable system through the integration of various design patterns and concepts. This method not only resolves existing complexities but also establishes a basis for more straightforward future improvements and alterations.

== Class Diagram ==
[[File:controller_Class_diagram.png|900px]]

== Use cases ==
[[File:Use_cases_controller.png|900px]]

== Solutions/Details of Changes Made==
=== Response Model ===
Methods in the response model were either refactored or newly added, including:
==== set_content ====
Reengineered to collect and organize the necessary data for response objects, enhancing the interaction with related models.
==== validate_params ====
This is the original approach including 46 lines.

[[File:Validate parameters before.png|900px]]

==This method underwent substantial refactoring to enhance parameter validation. It was divided into several smaller, targeted procedures, each assigned to address a certain facet of the validation process. Each new method performs a singular function, hence enhancing comprehension and maintainability.==
*Assigns the map_id for the response according to the specified parameters, ensuring the accurate map ID is utilized for both creation and modification of responses.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Confirms and verifies the existence of the response_map according to map_id. It is essential to verify that any answer being generated or modified is associated with a proper response map.This method seeks to locate a ResponseMap using map_id. If it cannot locate one, it logs an error and ceases further validation, indicating a problem early in the procedure.
[[File:Set and validate response.png|900px]]

*set_response_attributes(params): Allocates supplementary attributes to the response object derived from the parameters. This consolidates attribute configuration, minimizing redundancy and errors.Extracts values such as round, version_num, additional_comment, and visibility from the arguments and assigns them to the answer object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, activity): Orchestrates the validation process contingent upon whether the action pertains to creating or updating a response, systematically structuring the logic to avert condition proliferation in the primary validation procedure.Invokes various validation methods according to the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Verifies that a new response does not replicate an existing response inside the same response map, round, and version number.Conducts a search for a pre-existing response that corresponds to the current map_id, round, and version_num. If such a response exists, it generates a validation error and inhibits the generation of a duplicate answer.
[[File:Validate create condition.png|900px]]

validate_update_conditions(params): Verifies the validity of updates to a response, specifically confirming that the response has not been previously sent and that its map_id remains constant.Verifies the submission status and assesses any attempts to modify the map_id. Should either criteria be breached, an error is documented.
[[File:Validate update conditions.png|900px]]

validate_submission_status(params): Modifies the submission status of the response during the update procedure, guaranteeing that the attribute is accurately configured according to the supplied parameters.Extracts and establishes the is_submitted state from the parameters, which is essential for regulating the editability of the answer.
[[File:Validate submission status.png|900px]]

==== serialize_response ====
Optimized for the effective serialization of answer data in API contacts, hence boosting the clarity and usefulness of data exchanges.

=== Response Controller ===
The ResponseController, initially comprehensive with several features exceeding simple CRUD operations, has been optimized for our API application. In this scenario, it is unnecessary to manage data variables for view pages, hence streamlining the handling of request data exclusively through request methods.To improve the architecture and efficiency of our program, we have removed unnecessary methods and integrated functionality across the model, controller, and helper files. The restructure was crucial for optimizing the response endpoints specifically designed for an API application.

Prior to the incorporation of fundamental CRUD operations such as Create, Read, Update, Edit, and Delete.

Removed Methods: The legacy methods Questionnaire_from_response_map and Questionnaire_from_response were eliminated with the reworking of set_content, which now internally manages their functionalities.

==== Show_calibration_results_for_student ==== =
Before:

[[File:Display calibration outcomes for student.PNG|900px]]

The previous solution also utilized database queries within the display. The reimplemented Expertiza will not permit this, necessitating that the relevant data be included in the JSON response sent by the controller.
[[File:DB access in view.PNG|900px]]
[[File:DB access in view 2.PNG|900 pixels]]

The new show_calibration_results_for_student method obtains and presents calibration and review replies according to specified map IDs. It retrieves responses utilizing these IDs, acquires corresponding questions and answers, and presents the data as a structured JSON object. In the absence of a response, an error is generated to signify the lack of a response. The method manages all exceptions by providing a standardized error message, hence assuring comprehensive error handling during the operation.
Functions as an API endpoint to retrieve comprehensive response data for a student's calibration and review activities, supplying all pertinent information regarding the questions posed and the answers given in both scenarios.

[[File:Show_calibration_results.png|900px]]

=== Response Helper ===

The method create_update_answers(response, answers) initially managed both the generation and modification of answer records within a singular function.

[[File:Create_update_answers_before.png|900px]]

To enhance code maintainability and comply with the Single Responsibility Principle, this method has been separated into two distinct methods:

Create_answers ==== ====
This method is exclusively concerned with generating new answer records. It traverses the submitted responses, verifying that each answer is not already present in the database. If the response is absent, it generates a new record for that answer. This guarantees the uniqueness of each response and inhibits redundancy.
[[File:Create_answers_after.png|900px]]

====Update_answers ====
This technique updates existing response records. It queries the database for existing replies using the response and question identifiers. Upon discovering an answer, it revises the current record with the newly supplied information. This method guarantees the precise recording of all response updates and maintains the database's currency.

[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==Test==

===Validate Parameters===
====Postman Tests====

[[File:Postman_after_update.png|900px]]
[[File:DB validate parameters update test.png|900px]]

===Separated Answer Creation and Update Logic===
====Postman Tests====
Creation:
[[File:Postman after create for answer.png|900px]]
[[File:DB after create.png|900px]]

Update:
[[File:Postman after update for answer.png|900px]]
[[File:DB after update.png|900px]]

==Team==
===== Mentor=====
*Richard Li

=====Members=====
* Loyda Yusufova
* Bhuvan Chandra Kurra

==Links==
Postman Video Links:
*create: https://youtu.be/hXQl-JkfuUc
*update: https://youtu.be/BeifLsCRQlk
*show_calibration_results_for_student: https://www.youtube.com/watch?v=ltJarFGb25k

Pull request: https://github.com/expertiza/reimplementation-back-end/pull/92

Model Tests Video: https://youtu.be/7x8x4l3AksE

Controller Tests Video: https://youtu.be/0PV-ycXfyZU

==References==

*

User:Bkurra

2024-10-30T00:39:09Z

Bkurra: /* Solutions/Details of Changes Made */

CSC/ECE 517 Spring 2024 - E2415: Reimplementation of responses_controller.rb (Design Document)

==Expertiza==
The Expertiza project, an open-source initiative based on Ruby on Rails, pursues ongoing enhancement to incorporate contemporary software engineering methodologies. The Responses Controller is designed to aid reviewers in supplying organized data that conforms to an assignment's rubrics, assuring the availability of pertinent questions for each round within the appropriate deadline. It allows a reviewer to assess and grade the rubric questions relevant to the assignment's subjects. Moreover, it guarantees the provision of relevant questions for each assignment round, enabling reviewers to generate and adjust scores and remarks for each rubric question linked to the assignment. Upon the submission of scored questions and comments by reviewers, the Responses Controller sends an email message to the instructor and the members of the reviewed team.

==Problem Statement==
The ResponseController in Expertiza, a historical system with conventions that predate Rails standards, is too intricate, incorporating functionalities that extend beyond simple CRUD operations and requiring compliance with contemporary Rails nomenclature and design concepts. Critical concerns encompass the direct execution of functions such as sorting reviews and verifying reviewer roles within the controller, indicating a transition towards polymorphism and a more systematic method of code organization. Moreover, the controller's management of email notifications and feedback systems is erratic, highlighting the need for a specialized assistant to optimize communication procedures. The reimplementation initiative must concentrate on streamlining the controller, conforming to Rails principles, and enhancing code readability and maintainability through the judicious allocation of responsibilities.

==Design Goal ==
The redesign of `responses_controller.rb` is driven by several primary aims aimed at enhancing code quality, system performance, and developer engagement. The objectives encompass:

* Maintainability and Scalability: Guaranteeing the code is comprehensible, modifiable, and extensible. The reimplementation should facilitate future updates and the incorporation of new features.

* Compliance with Rails Best Practices: Adhering to Rails conventions on nomenclature, architecture, and coding methodologies to guarantee code uniformity and dependability.

* DRY Principle: "Don't Repeat Yourself" - eliminating unnecessary code and logic to enhance efficiency and reduce errors in the codebase.

* Single Responsibility Principle: Reorganizing the controller and related models to ensure that each class and method has a singular purpose, hence facilitating enhanced testing and management.

* Enhanced Testing and Coverage: Augmenting test suites to encompass a broader range of scenarios and edge situations, hence bolstering confidence in the application's stability and performance.

* Performance Optimization: Recognizing and enhancing sluggish or ineffective segments in the code to guarantee the application operates seamlessly.

* Eliminate Obsolete Methods: Conduct an audit of the codebase to identify and delete any unneeded ("dead") methods inside the present controller to streamline the code.

* Diminished Controller Complexity: We have already streamlined the `ResponseController` to concentrate mostly on CRUD activities and have extracted non-essential functionality to suitable models or helpers; now we intend to implement the remaining operations.

By achieving these design objectives, the project seeks to create a `responses_controller.rb` that is resilient, efficient, and user-friendly for both the current development team and future system maintainers.

== Design Pattern ==

Throughout the code rewriting effort, we meticulously adhered to certain design patterns to improve the overall architecture.
During the redesign of the Response model and its corresponding controller and helper methods within the application, several fundamental design patterns and concepts were adhered to in order to enhance code quality, maintainability, and scalability. The following are the principal patterns and principles that were taken into account:

=== Single Responsibility Principle (SRP) ===
This technique was utilized to decompose intricate methods into smaller, more targeted functions that manage a specific aspect of the process.

In the Response Model, Validate_params was subdivided into several smaller methods, each responsible for a distinct aspect of the validation process. This enables each method to oversee a specific facet of the validation, hence enhancing the maintainability and modifiability of the code.
The establishment and administration of relationships and fundamental properties were distinctly articulated, ensuring that the Response class remains unencumbered by logic unrelated to its specific attributes or relationships.

In the ResponsesController, the methods such as create, update, and show are designed solely to manage HTTP requests while delegating business logic to the model or helper methods. This maintains the controller actions in a clean and focused manner for routing and fundamental request management.

In the ResponseHelper, methods like create_answers and update_answers exemplify the principle that each method is designated for either the creation or the updating of answers, but not both. This adheres to SRP by partitioning duties into more manageable, distinct operations.

===Factory Method===
The Factory Method design is implicitly evident when object generation procedures are encapsulated within the model or auxiliary methods, such as instantiating a new ResponseMap or generating new Answer objects. This guarantees that object instantiation is modular and distinct from the primary application logic.
===Strategy Pattern===
The strategy design enables the independent variation of algorithms by establishing a family of encapsulated algorithms, such as validation criteria for activities like creation or updating, and allowing them to be interchangeable for the clients that utilize them. Separating the validation criteria for response creation and updating facilitates the flexible interchange and enhancement of validation logic without necessitating direct alterations to the controller or model.
Observer Pattern
Typically employed in situations where modifications to a certain object must automatically inform other dependant objects. Within the framework of this program, this may pertain to alerting instructors or peers following the submission or modification of responses, managed via the auxiliary ways for dispatching emails.
===Template Method===
This pattern can be employed to delineate the framework of an operation within a method, postponing certain phases to subclasses or other methods. The validation process in validate_params employs a generic framework while delegating specific details to methods such as validate_create_conditions and validate_update_conditions.

The refactoring seeks to establish a more resilient, manageable, and scalable system through the integration of various design patterns and concepts. This method not only resolves existing complexities but also establishes a basis for more straightforward future improvements and alterations.

== Class Diagram ==
[[File:controller_Class_diagram.png|900px]]

== Use cases ==
[[File:Use_cases_controller.png|900px]]

== Solutions/Details of Changes Made==
=== Response Model ===
Methods in the response model were either refactored or newly added, including:
==== set_content ====
Reengineered to collect and organize the necessary data for response objects, enhancing the interaction with related models.
==== validate_params ====
This is the original approach including 46 lines.

[[File:Validate parameters before.png|900px]]

==This method underwent substantial refactoring to enhance parameter validation. It was divided into several smaller, targeted procedures, each assigned to address a certain facet of the validation process. Each new method performs a singular function, hence enhancing comprehension and maintainability.==
*Assigns the map_id for the response according to the specified parameters, ensuring the accurate map ID is utilized for both creation and modification of responses.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Confirms and verifies the existence of the response_map according to map_id. It is essential to verify that any answer being generated or modified is associated with a proper response map.This method seeks to locate a ResponseMap using map_id. If it cannot locate one, it logs an error and ceases further validation, indicating a problem early in the procedure.
[[File:Set and validate response.png|900px]]

*set_response_attributes(params): Allocates supplementary attributes to the response object derived from the parameters. This consolidates attribute configuration, minimizing redundancy and errors.Extracts values such as round, version_num, additional_comment, and visibility from the arguments and assigns them to the answer object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, activity): Orchestrates the validation process contingent upon whether the action pertains to creating or updating a response, systematically structuring the logic to avert condition proliferation in the primary validation procedure.Invokes various validation methods according to the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Verifies that a new response does not replicate an existing response inside the same response map, round, and version number.Conducts a search for a pre-existing response that corresponds to the current map_id, round, and version_num. If such a response exists, it generates a validation error and inhibits the generation of a duplicate answer.
[[File:Validate create condition.png|900px]]

validate_update_conditions(params): Verifies the validity of updates to a response, specifically confirming that the response has not been previously sent and that its map_id remains constant.Verifies the submission status and assesses any attempts to modify the map_id. Should either criteria be breached, an error is documented.
[[File:Validate update conditions.png|900px]]

validate_submission_status(params): Modifies the submission status of the response during the update procedure, guaranteeing that the attribute is accurately configured according to the supplied parameters.Extracts and establishes the is_submitted state from the parameters, which is essential for regulating the editability of the answer.
[[File:Validate submission status.png|900px]]

==== serialize_response ====
Optimized for the effective serialization of answer data in API contacts, hence boosting the clarity and usefulness of data exchanges.

=== Response Controller ===
The ResponseController, initially comprehensive with several features exceeding simple CRUD operations, has been optimized for our API application. In this scenario, it is unnecessary to manage data variables for view pages, hence streamlining the handling of request data exclusively through request methods.To improve the architecture and efficiency of our program, we have removed unnecessary methods and integrated functionality across the model, controller, and helper files. The restructure was crucial for optimizing the response endpoints specifically designed for an API application.

Prior to the incorporation of fundamental CRUD operations such as Create, Read, Update, Edit, and Delete.

Removed Methods: The legacy methods Questionnaire_from_response_map and Questionnaire_from_response were eliminated with the reworking of set_content, which now internally manages their functionalities.

==== Show_calibration_results_for_student ==== =
Before:

[[File:Display calibration outcomes for student.PNG|900px]]

The previous solution also utilized database queries within the display. The reimplemented Expertiza will not permit this, necessitating that the relevant data be included in the JSON response sent by the controller.
[[File:DB access in view.PNG|900px]]
[[File:DB access in view 2.PNG|900 pixels]]

The new show_calibration_results_for_student method obtains and presents calibration and review replies according to specified map IDs. It retrieves responses utilizing these IDs, acquires corresponding questions and answers, and presents the data as a structured JSON object. In the absence of a response, an error is generated to signify the lack of a response. The method manages all exceptions by providing a standardized error message, hence assuring comprehensive error handling during the operation.
Functions as an API endpoint to retrieve comprehensive response data for a student's calibration and review activities, supplying all pertinent information regarding the questions posed and the answers given in both scenarios.

[[File:Show_calibration_results.png|900px]]

=== Response Helper ===

The method create_update_answers(response, answers) initially managed both the generation and modification of answer records within a singular function.

[[File:Create_update_answers_before.png|900px]]

To enhance code maintainability and comply with the Single Responsibility Principle, this method has been separated into two distinct methods:

Create_answers ==== ====
This method is exclusively concerned with generating new answer records. It traverses the submitted responses, verifying that each answer is not already present in the database. If the response is absent, it generates a new record for that answer. This guarantees the uniqueness of each response and inhibits redundancy.
[[File:Create_answers_after.png|900px]]

====Update_answers ====
This technique updates existing response records. It queries the database for existing replies using the response and question identifiers. Upon discovering an answer, it revises the current record with the newly supplied information. This method guarantees the precise recording of all response updates and maintains the database's currency.

[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==Test==

===Validate Parameters===
====Postman Tests====

[[File:Postman_after_update.png|900px]]
[[File:DB validate parameters update test.png|900px]]

===Separated Answer Creation and Update Logic===
====Postman Tests====
Creation:
[[File:Postman after create for answer.png|900px]]
[[File:DB after create.png|900px]]

Update:
[[File:Postman after update for answer.png|900px]]
[[File:DB after update.png|900px]]

==Team==
===== Mentor=====
*Richard Li

=====Members=====
* Loyda Yusufova
* Bhuvan Chandra Kurra

==Links==
Postman Video Links:
*create: https://youtu.be/hXQl-JkfuUc
*update: https://youtu.be/BeifLsCRQlk
*show_calibration_results_for_student: https://www.youtube.com/watch?v=ltJarFGb25k

Pull request: https://github.com/expertiza/reimplementation-back-end/pull/92

Model Tests Video: https://youtu.be/7x8x4l3AksE

Controller Tests Video: https://youtu.be/0PV-ycXfyZU

==References==

*

User:Bkurra

2024-10-29T22:33:53Z

Bkurra: /* Team */

CSC/ECE 517 Spring 2024 - E2415: Reimplementation of responses_controller.rb (Design Document)

==Expertiza==
The Expertiza project, an open-source initiative based on Ruby on Rails, pursues ongoing enhancement to incorporate contemporary software engineering methodologies. The Responses Controller is designed to aid reviewers in supplying organized data that conforms to an assignment's rubrics, assuring the availability of pertinent questions for each round within the appropriate deadline. It allows a reviewer to assess and grade the rubric questions relevant to the assignment's subjects. Moreover, it guarantees the provision of relevant questions for each assignment round, enabling reviewers to generate and adjust scores and remarks for each rubric question linked to the assignment. Upon the submission of scored questions and comments by reviewers, the Responses Controller sends an email message to the instructor and the members of the reviewed team.

==Problem Statement==
The ResponseController in Expertiza, a historical system with conventions that predate Rails standards, is too intricate, incorporating functionalities that extend beyond simple CRUD operations and requiring compliance with contemporary Rails nomenclature and design concepts. Critical concerns encompass the direct execution of functions such as sorting reviews and verifying reviewer roles within the controller, indicating a transition towards polymorphism and a more systematic method of code organization. Moreover, the controller's management of email notifications and feedback systems is erratic, highlighting the need for a specialized assistant to optimize communication procedures. The reimplementation initiative must concentrate on streamlining the controller, conforming to Rails principles, and enhancing code readability and maintainability through the judicious allocation of responsibilities.

==Design Goal ==
The redesign of `responses_controller.rb` is driven by several primary aims aimed at enhancing code quality, system performance, and developer engagement. The objectives encompass:

* Maintainability and Scalability: Guaranteeing the code is comprehensible, modifiable, and extensible. The reimplementation should facilitate future updates and the incorporation of new features.

* Compliance with Rails Best Practices: Adhering to Rails conventions on nomenclature, architecture, and coding methodologies to guarantee code uniformity and dependability.

* DRY Principle: "Don't Repeat Yourself" - eliminating unnecessary code and logic to enhance efficiency and reduce errors in the codebase.

* Single Responsibility Principle: Reorganizing the controller and related models to ensure that each class and method has a singular purpose, hence facilitating enhanced testing and management.

* Enhanced Testing and Coverage: Augmenting test suites to encompass a broader range of scenarios and edge situations, hence bolstering confidence in the application's stability and performance.

* Performance Optimization: Recognizing and enhancing sluggish or ineffective segments in the code to guarantee the application operates seamlessly.

* Eliminate Obsolete Methods: Conduct an audit of the codebase to identify and delete any unneeded ("dead") methods inside the present controller to streamline the code.

* Diminished Controller Complexity: We have already streamlined the `ResponseController` to concentrate mostly on CRUD activities and have extracted non-essential functionality to suitable models or helpers; now we intend to implement the remaining operations.

By achieving these design objectives, the project seeks to create a `responses_controller.rb` that is resilient, efficient, and user-friendly for both the current development team and future system maintainers.

== Design Pattern ==

Throughout the code rewriting effort, we meticulously adhered to certain design patterns to improve the overall architecture.
During the redesign of the Response model and its corresponding controller and helper methods within the application, several fundamental design patterns and concepts were adhered to in order to enhance code quality, maintainability, and scalability. The following are the principal patterns and principles that were taken into account:

=== Single Responsibility Principle (SRP) ===
This technique was utilized to decompose intricate methods into smaller, more targeted functions that manage a specific aspect of the process.

In the Response Model, Validate_params was subdivided into several smaller methods, each responsible for a distinct aspect of the validation process. This enables each method to oversee a specific facet of the validation, hence enhancing the maintainability and modifiability of the code.
The establishment and administration of relationships and fundamental properties were distinctly articulated, ensuring that the Response class remains unencumbered by logic unrelated to its specific attributes or relationships.

In the ResponsesController, the methods such as create, update, and show are designed solely to manage HTTP requests while delegating business logic to the model or helper methods. This maintains the controller actions in a clean and focused manner for routing and fundamental request management.

In the ResponseHelper, methods like create_answers and update_answers exemplify the principle that each method is designated for either the creation or the updating of answers, but not both. This adheres to SRP by partitioning duties into more manageable, distinct operations.

===Factory Method===
The Factory Method design is implicitly evident when object generation procedures are encapsulated within the model or auxiliary methods, such as instantiating a new ResponseMap or generating new Answer objects. This guarantees that object instantiation is modular and distinct from the primary application logic.
===Strategy Pattern===
The strategy design enables the independent variation of algorithms by establishing a family of encapsulated algorithms, such as validation criteria for activities like creation or updating, and allowing them to be interchangeable for the clients that utilize them. Separating the validation criteria for response creation and updating facilitates the flexible interchange and enhancement of validation logic without necessitating direct alterations to the controller or model.
Observer Pattern
Typically employed in situations where modifications to a certain object must automatically inform other dependant objects. Within the framework of this program, this may pertain to alerting instructors or peers following the submission or modification of responses, managed via the auxiliary ways for dispatching emails.
===Template Method===
This pattern can be employed to delineate the framework of an operation within a method, postponing certain phases to subclasses or other methods. The validation process in validate_params employs a generic framework while delegating specific details to methods such as validate_create_conditions and validate_update_conditions.

The refactoring seeks to establish a more resilient, manageable, and scalable system through the integration of various design patterns and concepts. This method not only resolves existing complexities but also establishes a basis for more straightforward future improvements and alterations.

== Class Diagram ==
[[File:controller_Class_diagram.png|900px]]

== Use cases ==
[[File:Use_cases_controller.png|900px]]

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response model were refactored or introduced, including:
==== set_content ====
Redesigned to gather and prepare the required data for response objects, optimizing the interaction with associated models
==== validate_params ====
This is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===This method was significantly refactored to improve parameter validation. It was split into multiple smaller, focused methods, each dedicated to handling a specific aspect of the validation process. Each new method does one thing only, which makes them easier to understand and maintain.===
* assign_map_id_from_params: Sets the map_id for the response based on the provided parameters, ensuring the correct map ID is used for both creating and updating responses.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

==== serialize_response ====
Improved to efficiently serialize response data for API interactions, enhancing the clarity and usability of data exchanges.

=== Response Controller ===
The ResponseController, originally extensive with numerous functions beyond basic CRUD operations, has been streamlined for our API application. In this context, there's no need to manage data variables for view pages, simplifying the handling of request data solely through request methods.To enhance the architecture and efficiency of our application, we've eliminated redundant methods and consolidated functionalities across the model, controller, and helper files. This restructuring was essential for refining the response endpoints specifically tailored for an API application.

Before we added Basic CRUD like New, Create, Update, edit, destroy.

Removed Methods: Legacy methods like Questionnaire_from_response_map and Questionnaire_from_response were removed following the refactoring of set_content, which now handles its functionalities internally without the need for these methods.

==== Show_calibration_results_for_student ====
Before:

[[File:Show calibration results for student.PNG|900px]]

The old implementation also made use of database queries in the view. This will not be possible in the reimplemented Expertiza, and the required data will need to be made available in the JSON response sent by the controller.
[[File:DB access in view.PNG|900px]]
[[File:DB access in view 2.PNG|900px]]

The new show_calibration_results_for_student method retrieves and displays calibration and review responses based on provided map IDs. It fetches responses using these IDs, retrieves associated questions and answers, and returns the data as a formatted JSON object. If a response is not found, it returns an error indicating the missing response. The method handles any exceptions by returning a standard error message, ensuring robust error handling throughout the process.
Serves as an API endpoint to fetch detailed response data for a student's calibration and review tasks, providing all necessary details about the questions asked and the answers provided in both contexts

[[File:Show_calibration_results.png|900px]]

=== Response Helper ===

The method create_update_answers(response, answers) was originally handling both the creation and updating of answer records within a single method:

[[File:Create_update_answers_before.png|900px]]

To improve code maintainability and adhere to the Single Responsibility Principle, this method has been divided into two distinct methods:

==== Create_answers ====
This method focuses solely on creating new answer records. It iterates over the answers provided, checking if each answer does not already exist in the database. If the answer does not exist, it creates a new record for that answer. This ensures that each answer is unique and prevents duplication.
[[File:Create_answers_after.png|900px]]

==== Update_answers ====
This method is responsible for updating existing answer records. It searches for existing answers in the database based on the response and question identifiers. If an answer is found, it updates the existing record with the new information provided. This method ensures that all modifications to answers are captured accurately and that the database is kept up-to-date.

[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==Test==

===Validate Parameters===
====Postman Tests====

[[File:Postman_after_update.png|900px]]
[[File:DB validate parameters update test.png|900px]]

===Separated Answer Creation and Update Logic===
====Postman Tests====
Creation:
[[File:Postman after create for answer.png|900px]]
[[File:DB after create.png|900px]]

Update:
[[File:Postman after update for answer.png|900px]]
[[File:DB after update.png|900px]]

==Team==
===== Mentor=====
*Richard Li

=====Members=====
* Loyda Yusufova
* Bhuvan Chandra Kurra

==Links==
Postman Video Links:
*create: https://youtu.be/hXQl-JkfuUc
*update: https://youtu.be/BeifLsCRQlk
*show_calibration_results_for_student: https://www.youtube.com/watch?v=ltJarFGb25k

Pull request: https://github.com/expertiza/reimplementation-back-end/pull/92

Model Tests Video: https://youtu.be/7x8x4l3AksE

Controller Tests Video: https://youtu.be/0PV-ycXfyZU

==References==

*

User:Bkurra

2024-10-29T22:17:54Z

Bkurra: /* Design Pattern */

CSC/ECE 517 Spring 2024 - E2415: Reimplementation of responses_controller.rb (Design Document)

==Expertiza==
The Expertiza project, an open-source initiative based on Ruby on Rails, pursues ongoing enhancement to incorporate contemporary software engineering methodologies. The Responses Controller is designed to aid reviewers in supplying organized data that conforms to an assignment's rubrics, assuring the availability of pertinent questions for each round within the appropriate deadline. It allows a reviewer to assess and grade the rubric questions relevant to the assignment's subjects. Moreover, it guarantees the provision of relevant questions for each assignment round, enabling reviewers to generate and adjust scores and remarks for each rubric question linked to the assignment. Upon the submission of scored questions and comments by reviewers, the Responses Controller sends an email message to the instructor and the members of the reviewed team.

==Problem Statement==
The ResponseController in Expertiza, a historical system with conventions that predate Rails standards, is too intricate, incorporating functionalities that extend beyond simple CRUD operations and requiring compliance with contemporary Rails nomenclature and design concepts. Critical concerns encompass the direct execution of functions such as sorting reviews and verifying reviewer roles within the controller, indicating a transition towards polymorphism and a more systematic method of code organization. Moreover, the controller's management of email notifications and feedback systems is erratic, highlighting the need for a specialized assistant to optimize communication procedures. The reimplementation initiative must concentrate on streamlining the controller, conforming to Rails principles, and enhancing code readability and maintainability through the judicious allocation of responsibilities.

==Design Goal ==
The redesign of `responses_controller.rb` is driven by several primary aims aimed at enhancing code quality, system performance, and developer engagement. The objectives encompass:

* Maintainability and Scalability: Guaranteeing the code is comprehensible, modifiable, and extensible. The reimplementation should facilitate future updates and the incorporation of new features.

* Compliance with Rails Best Practices: Adhering to Rails conventions on nomenclature, architecture, and coding methodologies to guarantee code uniformity and dependability.

* DRY Principle: "Don't Repeat Yourself" - eliminating unnecessary code and logic to enhance efficiency and reduce errors in the codebase.

* Single Responsibility Principle: Reorganizing the controller and related models to ensure that each class and method has a singular purpose, hence facilitating enhanced testing and management.

* Enhanced Testing and Coverage: Augmenting test suites to encompass a broader range of scenarios and edge situations, hence bolstering confidence in the application's stability and performance.

* Performance Optimization: Recognizing and enhancing sluggish or ineffective segments in the code to guarantee the application operates seamlessly.

* Eliminate Obsolete Methods: Conduct an audit of the codebase to identify and delete any unneeded ("dead") methods inside the present controller to streamline the code.

* Diminished Controller Complexity: We have already streamlined the `ResponseController` to concentrate mostly on CRUD activities and have extracted non-essential functionality to suitable models or helpers; now we intend to implement the remaining operations.

By achieving these design objectives, the project seeks to create a `responses_controller.rb` that is resilient, efficient, and user-friendly for both the current development team and future system maintainers.

== Design Pattern ==

Throughout the code rewriting effort, we meticulously adhered to certain design patterns to improve the overall architecture.
During the redesign of the Response model and its corresponding controller and helper methods within the application, several fundamental design patterns and concepts were adhered to in order to enhance code quality, maintainability, and scalability. The following are the principal patterns and principles that were taken into account:

=== Single Responsibility Principle (SRP) ===
This technique was utilized to decompose intricate methods into smaller, more targeted functions that manage a specific aspect of the process.

In the Response Model, Validate_params was subdivided into several smaller methods, each responsible for a distinct aspect of the validation process. This enables each method to oversee a specific facet of the validation, hence enhancing the maintainability and modifiability of the code.
The establishment and administration of relationships and fundamental properties were distinctly articulated, ensuring that the Response class remains unencumbered by logic unrelated to its specific attributes or relationships.

In the ResponsesController, the methods such as create, update, and show are designed solely to manage HTTP requests while delegating business logic to the model or helper methods. This maintains the controller actions in a clean and focused manner for routing and fundamental request management.

In the ResponseHelper, methods like create_answers and update_answers exemplify the principle that each method is designated for either the creation or the updating of answers, but not both. This adheres to SRP by partitioning duties into more manageable, distinct operations.

===Factory Method===
The Factory Method design is implicitly evident when object generation procedures are encapsulated within the model or auxiliary methods, such as instantiating a new ResponseMap or generating new Answer objects. This guarantees that object instantiation is modular and distinct from the primary application logic.
===Strategy Pattern===
The strategy design enables the independent variation of algorithms by establishing a family of encapsulated algorithms, such as validation criteria for activities like creation or updating, and allowing them to be interchangeable for the clients that utilize them. Separating the validation criteria for response creation and updating facilitates the flexible interchange and enhancement of validation logic without necessitating direct alterations to the controller or model.
Observer Pattern
Typically employed in situations where modifications to a certain object must automatically inform other dependant objects. Within the framework of this program, this may pertain to alerting instructors or peers following the submission or modification of responses, managed via the auxiliary ways for dispatching emails.
===Template Method===
This pattern can be employed to delineate the framework of an operation within a method, postponing certain phases to subclasses or other methods. The validation process in validate_params employs a generic framework while delegating specific details to methods such as validate_create_conditions and validate_update_conditions.

The refactoring seeks to establish a more resilient, manageable, and scalable system through the integration of various design patterns and concepts. This method not only resolves existing complexities but also establishes a basis for more straightforward future improvements and alterations.

== Class Diagram ==
[[File:controller_Class_diagram.png|900px]]

== Use cases ==
[[File:Use_cases_controller.png|900px]]

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response model were refactored or introduced, including:
==== set_content ====
Redesigned to gather and prepare the required data for response objects, optimizing the interaction with associated models
==== validate_params ====
This is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===This method was significantly refactored to improve parameter validation. It was split into multiple smaller, focused methods, each dedicated to handling a specific aspect of the validation process. Each new method does one thing only, which makes them easier to understand and maintain.===
* assign_map_id_from_params: Sets the map_id for the response based on the provided parameters, ensuring the correct map ID is used for both creating and updating responses.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

==== serialize_response ====
Improved to efficiently serialize response data for API interactions, enhancing the clarity and usability of data exchanges.

=== Response Controller ===
The ResponseController, originally extensive with numerous functions beyond basic CRUD operations, has been streamlined for our API application. In this context, there's no need to manage data variables for view pages, simplifying the handling of request data solely through request methods.To enhance the architecture and efficiency of our application, we've eliminated redundant methods and consolidated functionalities across the model, controller, and helper files. This restructuring was essential for refining the response endpoints specifically tailored for an API application.

Before we added Basic CRUD like New, Create, Update, edit, destroy.

Removed Methods: Legacy methods like Questionnaire_from_response_map and Questionnaire_from_response were removed following the refactoring of set_content, which now handles its functionalities internally without the need for these methods.

==== Show_calibration_results_for_student ====
Before:

[[File:Show calibration results for student.PNG|900px]]

The old implementation also made use of database queries in the view. This will not be possible in the reimplemented Expertiza, and the required data will need to be made available in the JSON response sent by the controller.
[[File:DB access in view.PNG|900px]]
[[File:DB access in view 2.PNG|900px]]

The new show_calibration_results_for_student method retrieves and displays calibration and review responses based on provided map IDs. It fetches responses using these IDs, retrieves associated questions and answers, and returns the data as a formatted JSON object. If a response is not found, it returns an error indicating the missing response. The method handles any exceptions by returning a standard error message, ensuring robust error handling throughout the process.
Serves as an API endpoint to fetch detailed response data for a student's calibration and review tasks, providing all necessary details about the questions asked and the answers provided in both contexts

[[File:Show_calibration_results.png|900px]]

=== Response Helper ===

The method create_update_answers(response, answers) was originally handling both the creation and updating of answer records within a single method:

[[File:Create_update_answers_before.png|900px]]

To improve code maintainability and adhere to the Single Responsibility Principle, this method has been divided into two distinct methods:

==== Create_answers ====
This method focuses solely on creating new answer records. It iterates over the answers provided, checking if each answer does not already exist in the database. If the answer does not exist, it creates a new record for that answer. This ensures that each answer is unique and prevents duplication.
[[File:Create_answers_after.png|900px]]

==== Update_answers ====
This method is responsible for updating existing answer records. It searches for existing answers in the database based on the response and question identifiers. If an answer is found, it updates the existing record with the new information provided. This method ensures that all modifications to answers are captured accurately and that the database is kept up-to-date.

[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==Test==

===Validate Parameters===
====Postman Tests====

[[File:Postman_after_update.png|900px]]
[[File:DB validate parameters update test.png|900px]]

===Separated Answer Creation and Update Logic===
====Postman Tests====
Creation:
[[File:Postman after create for answer.png|900px]]
[[File:DB after create.png|900px]]

Update:
[[File:Postman after update for answer.png|900px]]
[[File:DB after update.png|900px]]

==Team==
===== Mentor=====
*Ameya Vaichalkar

=====Members=====
* Jeff Riehle
* Maday Moya
* Shardul Ladekar

==Links==
Postman Video Links:
*create: https://youtu.be/hXQl-JkfuUc
*update: https://youtu.be/BeifLsCRQlk
*show_calibration_results_for_student: https://www.youtube.com/watch?v=ltJarFGb25k

Pull request: https://github.com/expertiza/reimplementation-back-end/pull/92

Model Tests Video: https://youtu.be/7x8x4l3AksE

Controller Tests Video: https://youtu.be/0PV-ycXfyZU

==References==

*

User:Bkurra

2024-10-29T22:13:19Z

Bkurra: /* Design Goal */

CSC/ECE 517 Spring 2024 - E2415: Reimplementation of responses_controller.rb (Design Document)

==Expertiza==
The Expertiza project, an open-source initiative based on Ruby on Rails, pursues ongoing enhancement to incorporate contemporary software engineering methodologies. The Responses Controller is designed to aid reviewers in supplying organized data that conforms to an assignment's rubrics, assuring the availability of pertinent questions for each round within the appropriate deadline. It allows a reviewer to assess and grade the rubric questions relevant to the assignment's subjects. Moreover, it guarantees the provision of relevant questions for each assignment round, enabling reviewers to generate and adjust scores and remarks for each rubric question linked to the assignment. Upon the submission of scored questions and comments by reviewers, the Responses Controller sends an email message to the instructor and the members of the reviewed team.

==Problem Statement==
The ResponseController in Expertiza, a historical system with conventions that predate Rails standards, is too intricate, incorporating functionalities that extend beyond simple CRUD operations and requiring compliance with contemporary Rails nomenclature and design concepts. Critical concerns encompass the direct execution of functions such as sorting reviews and verifying reviewer roles within the controller, indicating a transition towards polymorphism and a more systematic method of code organization. Moreover, the controller's management of email notifications and feedback systems is erratic, highlighting the need for a specialized assistant to optimize communication procedures. The reimplementation initiative must concentrate on streamlining the controller, conforming to Rails principles, and enhancing code readability and maintainability through the judicious allocation of responsibilities.

==Design Goal ==
The redesign of `responses_controller.rb` is driven by several primary aims aimed at enhancing code quality, system performance, and developer engagement. The objectives encompass:

* Maintainability and Scalability: Guaranteeing the code is comprehensible, modifiable, and extensible. The reimplementation should facilitate future updates and the incorporation of new features.

* Compliance with Rails Best Practices: Adhering to Rails conventions on nomenclature, architecture, and coding methodologies to guarantee code uniformity and dependability.

* DRY Principle: "Don't Repeat Yourself" - eliminating unnecessary code and logic to enhance efficiency and reduce errors in the codebase.

* Single Responsibility Principle: Reorganizing the controller and related models to ensure that each class and method has a singular purpose, hence facilitating enhanced testing and management.

* Enhanced Testing and Coverage: Augmenting test suites to encompass a broader range of scenarios and edge situations, hence bolstering confidence in the application's stability and performance.

* Performance Optimization: Recognizing and enhancing sluggish or ineffective segments in the code to guarantee the application operates seamlessly.

* Eliminate Obsolete Methods: Conduct an audit of the codebase to identify and delete any unneeded ("dead") methods inside the present controller to streamline the code.

* Diminished Controller Complexity: We have already streamlined the `ResponseController` to concentrate mostly on CRUD activities and have extracted non-essential functionality to suitable models or helpers; now we intend to implement the remaining operations.

By achieving these design objectives, the project seeks to create a `responses_controller.rb` that is resilient, efficient, and user-friendly for both the current development team and future system maintainers.

== Design Pattern ==

During the code refactoring process, we conscientiously followed various design patterns to enhance the overall structure.
When refactoring the Response model and associated controller and helper methods in the application, several key design patterns and principles were followed to ensure improved code quality, maintainability, and scalability. Here are the primary patterns and principles that were considered:

=== Single Responsibility Principle (SRP) ===
This principle was applied to break down complex methods into smaller, more focused functions that handle a specific part of the process

*In the Response Model:
Validate_params was broken down into multiple smaller methods, each handling a specific part of the validation process. This allows each method to manage one aspect of the validation, making the code easier to maintain and modify.
Creation and management of relationships and basic attributes were clearly defined, ensuring that the Response class isn't overloaded with logic that doesn't pertain to its direct attributes or relationships.

*In the ResponsesController:
The controller methods like create, update, show, etc., were defined to handle only HTTP requests and delegate business logic to the model or helper methods. This keeps the controller actions clean and focused on routing and basic request handling.

*In the ResponseHelper:
Methods such as create_answers and update_answers are good examples where each method is tasked with either creating or updating answers but not both. This follows SRP by dividing the responsibilities into more manageable, discrete operations.

===Factory Method===
The Factory Method pattern can be seen implicitly where object creation processes are encapsulated within the model or helper methods, such as creating a new ResponseMap or generating new Answer objects. This ensures that object creation is modular and separated from the main application logic.
===Strategy Pattern===
By defining a family of algorithms (in this case, validation rules for different actions like create or update), encapsulating each one, and making them interchangeable, the strategy pattern lets the algorithm vary independently from the clients that use it. For instance, separating the validation conditions for creating and updating responses allows for flexible swapping and extension of validation logic without modifying the controller or model directly.
===Observer Pattern===
Used typically in scenarios where changes to a particular object need to notify other dependent objects automatically. In the context of this application, this could relate to notifying instructors or peers upon the submission or update of responses, handled through the helper methods for sending emails.
===Template Method===
This pattern can be used in defining the skeleton of an operation in a method, deferring some steps to subclasses or other methods. It's seen in how validate_params uses a general structure for validation but defers the specifics to methods like validate_create_conditions and validate_update_conditions.

By integrating these design patterns and principles, the refactoring aims to achieve a more robust, maintainable, and scalable system. This approach not only addresses current complexities but also lays a foundation for easier future enhancements and modifications.

== Class Diagram ==
[[File:controller_Class_diagram.png|900px]]

== Use cases ==
[[File:Use_cases_controller.png|900px]]

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response model were refactored or introduced, including:
==== set_content ====
Redesigned to gather and prepare the required data for response objects, optimizing the interaction with associated models
==== validate_params ====
This is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===This method was significantly refactored to improve parameter validation. It was split into multiple smaller, focused methods, each dedicated to handling a specific aspect of the validation process. Each new method does one thing only, which makes them easier to understand and maintain.===
* assign_map_id_from_params: Sets the map_id for the response based on the provided parameters, ensuring the correct map ID is used for both creating and updating responses.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

==== serialize_response ====
Improved to efficiently serialize response data for API interactions, enhancing the clarity and usability of data exchanges.

=== Response Controller ===
The ResponseController, originally extensive with numerous functions beyond basic CRUD operations, has been streamlined for our API application. In this context, there's no need to manage data variables for view pages, simplifying the handling of request data solely through request methods.To enhance the architecture and efficiency of our application, we've eliminated redundant methods and consolidated functionalities across the model, controller, and helper files. This restructuring was essential for refining the response endpoints specifically tailored for an API application.

Before we added Basic CRUD like New, Create, Update, edit, destroy.

Removed Methods: Legacy methods like Questionnaire_from_response_map and Questionnaire_from_response were removed following the refactoring of set_content, which now handles its functionalities internally without the need for these methods.

==== Show_calibration_results_for_student ====
Before:

[[File:Show calibration results for student.PNG|900px]]

The old implementation also made use of database queries in the view. This will not be possible in the reimplemented Expertiza, and the required data will need to be made available in the JSON response sent by the controller.
[[File:DB access in view.PNG|900px]]
[[File:DB access in view 2.PNG|900px]]

The new show_calibration_results_for_student method retrieves and displays calibration and review responses based on provided map IDs. It fetches responses using these IDs, retrieves associated questions and answers, and returns the data as a formatted JSON object. If a response is not found, it returns an error indicating the missing response. The method handles any exceptions by returning a standard error message, ensuring robust error handling throughout the process.
Serves as an API endpoint to fetch detailed response data for a student's calibration and review tasks, providing all necessary details about the questions asked and the answers provided in both contexts

[[File:Show_calibration_results.png|900px]]

=== Response Helper ===

The method create_update_answers(response, answers) was originally handling both the creation and updating of answer records within a single method:

[[File:Create_update_answers_before.png|900px]]

To improve code maintainability and adhere to the Single Responsibility Principle, this method has been divided into two distinct methods:

==== Create_answers ====
This method focuses solely on creating new answer records. It iterates over the answers provided, checking if each answer does not already exist in the database. If the answer does not exist, it creates a new record for that answer. This ensures that each answer is unique and prevents duplication.
[[File:Create_answers_after.png|900px]]

==== Update_answers ====
This method is responsible for updating existing answer records. It searches for existing answers in the database based on the response and question identifiers. If an answer is found, it updates the existing record with the new information provided. This method ensures that all modifications to answers are captured accurately and that the database is kept up-to-date.

[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==Test==

===Validate Parameters===
====Postman Tests====

[[File:Postman_after_update.png|900px]]
[[File:DB validate parameters update test.png|900px]]

===Separated Answer Creation and Update Logic===
====Postman Tests====
Creation:
[[File:Postman after create for answer.png|900px]]
[[File:DB after create.png|900px]]

Update:
[[File:Postman after update for answer.png|900px]]
[[File:DB after update.png|900px]]

==Team==
===== Mentor=====
*Ameya Vaichalkar

=====Members=====
* Jeff Riehle
* Maday Moya
* Shardul Ladekar

==Links==
Postman Video Links:
*create: https://youtu.be/hXQl-JkfuUc
*update: https://youtu.be/BeifLsCRQlk
*show_calibration_results_for_student: https://www.youtube.com/watch?v=ltJarFGb25k

Pull request: https://github.com/expertiza/reimplementation-back-end/pull/92

Model Tests Video: https://youtu.be/7x8x4l3AksE

Controller Tests Video: https://youtu.be/0PV-ycXfyZU

==References==

*

User:Bkurra

2024-10-29T20:56:11Z

Bkurra: /* Problem Statement */

CSC/ECE 517 Spring 2024 - E2415: Reimplementation of responses_controller.rb (Design Document)

==Expertiza==
The Expertiza project, an open-source initiative based on Ruby on Rails, pursues ongoing enhancement to incorporate contemporary software engineering methodologies. The Responses Controller is designed to aid reviewers in supplying organized data that conforms to an assignment's rubrics, assuring the availability of pertinent questions for each round within the appropriate deadline. It allows a reviewer to assess and grade the rubric questions relevant to the assignment's subjects. Moreover, it guarantees the provision of relevant questions for each assignment round, enabling reviewers to generate and adjust scores and remarks for each rubric question linked to the assignment. Upon the submission of scored questions and comments by reviewers, the Responses Controller sends an email message to the instructor and the members of the reviewed team.

==Problem Statement==
The ResponseController in Expertiza, a historical system with conventions that predate Rails standards, is too intricate, incorporating functionalities that extend beyond simple CRUD operations and requiring compliance with contemporary Rails nomenclature and design concepts. Critical concerns encompass the direct execution of functions such as sorting reviews and verifying reviewer roles within the controller, indicating a transition towards polymorphism and a more systematic method of code organization. Moreover, the controller's management of email notifications and feedback systems is erratic, highlighting the need for a specialized assistant to optimize communication procedures. The reimplementation initiative must concentrate on streamlining the controller, conforming to Rails principles, and enhancing code readability and maintainability through the judicious allocation of responsibilities.

==Design Goal==
The redesign of the `responses_controller.rb` is guided by several key objectives to improve the code quality, system behavior, and developer interaction. The goals include:

* Maintainability and Scalability: Ensuring the code is easy to understand, modify, and extend. The reimplementation should simplify future updates and feature additions.

* Adherence to Rails Best Practices: Following Rails conventions for naming, structure, and coding practices to ensure code consistency and reliability.

* DRY Principle: "Don't Repeat Yourself" - removing redundant code and logic to create a more efficient and error-resistant codebase.

* Single Responsibility Principle: Restructuring the controller and associated models so that each class and method has one purpose and one purpose only, leading to easier testing and management.

* Improved Testing and Coverage: Enhancing test suites to cover more scenarios and edge cases, increasing confidence in the application's stability and performance.

* Performance Optimization: Identifying and optimizing slow or inefficient areas in the code to ensure the application runs smoothly.

* Clean Up Dead Methods: Audit the codebase for any unused ("dead") methods within the current controller and remove them to declutter the code.

* Reduced Controller Complexity: We already have streamline the `ResponseController` to focus primarily on CRUD operations and extract non-essential logic to appropriate models or helpers, now we aim to implement the rest operations.

By meeting these design goals, the project aims to produce a `responses_controller.rb` that is robust, efficient, and a pleasure to work with, both for the current development team and for those who will maintain the system in the future.

== Design Pattern ==

During the code refactoring process, we conscientiously followed various design patterns to enhance the overall structure.
When refactoring the Response model and associated controller and helper methods in the application, several key design patterns and principles were followed to ensure improved code quality, maintainability, and scalability. Here are the primary patterns and principles that were considered:

=== Single Responsibility Principle (SRP) ===
This principle was applied to break down complex methods into smaller, more focused functions that handle a specific part of the process

*In the Response Model:
Validate_params was broken down into multiple smaller methods, each handling a specific part of the validation process. This allows each method to manage one aspect of the validation, making the code easier to maintain and modify.
Creation and management of relationships and basic attributes were clearly defined, ensuring that the Response class isn't overloaded with logic that doesn't pertain to its direct attributes or relationships.

*In the ResponsesController:
The controller methods like create, update, show, etc., were defined to handle only HTTP requests and delegate business logic to the model or helper methods. This keeps the controller actions clean and focused on routing and basic request handling.

*In the ResponseHelper:
Methods such as create_answers and update_answers are good examples where each method is tasked with either creating or updating answers but not both. This follows SRP by dividing the responsibilities into more manageable, discrete operations.

===Factory Method===
The Factory Method pattern can be seen implicitly where object creation processes are encapsulated within the model or helper methods, such as creating a new ResponseMap or generating new Answer objects. This ensures that object creation is modular and separated from the main application logic.
===Strategy Pattern===
By defining a family of algorithms (in this case, validation rules for different actions like create or update), encapsulating each one, and making them interchangeable, the strategy pattern lets the algorithm vary independently from the clients that use it. For instance, separating the validation conditions for creating and updating responses allows for flexible swapping and extension of validation logic without modifying the controller or model directly.
===Observer Pattern===
Used typically in scenarios where changes to a particular object need to notify other dependent objects automatically. In the context of this application, this could relate to notifying instructors or peers upon the submission or update of responses, handled through the helper methods for sending emails.
===Template Method===
This pattern can be used in defining the skeleton of an operation in a method, deferring some steps to subclasses or other methods. It's seen in how validate_params uses a general structure for validation but defers the specifics to methods like validate_create_conditions and validate_update_conditions.

By integrating these design patterns and principles, the refactoring aims to achieve a more robust, maintainable, and scalable system. This approach not only addresses current complexities but also lays a foundation for easier future enhancements and modifications.

== Class Diagram ==
[[File:controller_Class_diagram.png|900px]]

== Use cases ==
[[File:Use_cases_controller.png|900px]]

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response model were refactored or introduced, including:
==== set_content ====
Redesigned to gather and prepare the required data for response objects, optimizing the interaction with associated models
==== validate_params ====
This is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===This method was significantly refactored to improve parameter validation. It was split into multiple smaller, focused methods, each dedicated to handling a specific aspect of the validation process. Each new method does one thing only, which makes them easier to understand and maintain.===
* assign_map_id_from_params: Sets the map_id for the response based on the provided parameters, ensuring the correct map ID is used for both creating and updating responses.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

==== serialize_response ====
Improved to efficiently serialize response data for API interactions, enhancing the clarity and usability of data exchanges.

=== Response Controller ===
The ResponseController, originally extensive with numerous functions beyond basic CRUD operations, has been streamlined for our API application. In this context, there's no need to manage data variables for view pages, simplifying the handling of request data solely through request methods.To enhance the architecture and efficiency of our application, we've eliminated redundant methods and consolidated functionalities across the model, controller, and helper files. This restructuring was essential for refining the response endpoints specifically tailored for an API application.

Before we added Basic CRUD like New, Create, Update, edit, destroy.

Removed Methods: Legacy methods like Questionnaire_from_response_map and Questionnaire_from_response were removed following the refactoring of set_content, which now handles its functionalities internally without the need for these methods.

==== Show_calibration_results_for_student ====
Before:

[[File:Show calibration results for student.PNG|900px]]

The old implementation also made use of database queries in the view. This will not be possible in the reimplemented Expertiza, and the required data will need to be made available in the JSON response sent by the controller.
[[File:DB access in view.PNG|900px]]
[[File:DB access in view 2.PNG|900px]]

The new show_calibration_results_for_student method retrieves and displays calibration and review responses based on provided map IDs. It fetches responses using these IDs, retrieves associated questions and answers, and returns the data as a formatted JSON object. If a response is not found, it returns an error indicating the missing response. The method handles any exceptions by returning a standard error message, ensuring robust error handling throughout the process.
Serves as an API endpoint to fetch detailed response data for a student's calibration and review tasks, providing all necessary details about the questions asked and the answers provided in both contexts

[[File:Show_calibration_results.png|900px]]

=== Response Helper ===

The method create_update_answers(response, answers) was originally handling both the creation and updating of answer records within a single method:

[[File:Create_update_answers_before.png|900px]]

To improve code maintainability and adhere to the Single Responsibility Principle, this method has been divided into two distinct methods:

==== Create_answers ====
This method focuses solely on creating new answer records. It iterates over the answers provided, checking if each answer does not already exist in the database. If the answer does not exist, it creates a new record for that answer. This ensures that each answer is unique and prevents duplication.
[[File:Create_answers_after.png|900px]]

==== Update_answers ====
This method is responsible for updating existing answer records. It searches for existing answers in the database based on the response and question identifiers. If an answer is found, it updates the existing record with the new information provided. This method ensures that all modifications to answers are captured accurately and that the database is kept up-to-date.

[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==Test==

===Validate Parameters===
====Postman Tests====

[[File:Postman_after_update.png|900px]]
[[File:DB validate parameters update test.png|900px]]

===Separated Answer Creation and Update Logic===
====Postman Tests====
Creation:
[[File:Postman after create for answer.png|900px]]
[[File:DB after create.png|900px]]

Update:
[[File:Postman after update for answer.png|900px]]
[[File:DB after update.png|900px]]

==Team==
===== Mentor=====
*Ameya Vaichalkar

=====Members=====
* Jeff Riehle
* Maday Moya
* Shardul Ladekar

==Links==
Postman Video Links:
*create: https://youtu.be/hXQl-JkfuUc
*update: https://youtu.be/BeifLsCRQlk
*show_calibration_results_for_student: https://www.youtube.com/watch?v=ltJarFGb25k

Pull request: https://github.com/expertiza/reimplementation-back-end/pull/92

Model Tests Video: https://youtu.be/7x8x4l3AksE

Controller Tests Video: https://youtu.be/0PV-ycXfyZU

==References==

*

User:Bkurra

2024-10-29T20:54:49Z

Bkurra: /* Expertiza */

CSC/ECE 517 Spring 2024 - E2415: Reimplementation of responses_controller.rb (Design Document)

==Expertiza==
The Expertiza project, an open-source initiative based on Ruby on Rails, pursues ongoing enhancement to incorporate contemporary software engineering methodologies. The Responses Controller is designed to aid reviewers in supplying organized data that conforms to an assignment's rubrics, assuring the availability of pertinent questions for each round within the appropriate deadline. It allows a reviewer to assess and grade the rubric questions relevant to the assignment's subjects. Moreover, it guarantees the provision of relevant questions for each assignment round, enabling reviewers to generate and adjust scores and remarks for each rubric question linked to the assignment. Upon the submission of scored questions and comments by reviewers, the Responses Controller sends an email message to the instructor and the members of the reviewed team.

==Problem Statement==
The ResponseController in Expertiza, a legacy system with conventions predating Rails standards, is overly complex, encompassing functionalities beyond basic CRUD operations and needing adherence to modern Rails naming and design principles. Key issues include the direct implementation of functionalities like sorting reviews and checking reviewer roles within the controller, suggesting a shift towards polymorphism and a more structured approach to code organization. Furthermore, the controller's handling of email notifications and feedback mechanisms is inconsistent, indicating the necessity for a dedicated helper to streamline communication processes. The reimplementation effort must focus on simplifying the controller, adhering to Rails conventions, and improving code readability and maintainability by appropriately distributing responsibilities.

==Design Goal==
The redesign of the `responses_controller.rb` is guided by several key objectives to improve the code quality, system behavior, and developer interaction. The goals include:

* Maintainability and Scalability: Ensuring the code is easy to understand, modify, and extend. The reimplementation should simplify future updates and feature additions.

* Adherence to Rails Best Practices: Following Rails conventions for naming, structure, and coding practices to ensure code consistency and reliability.

* DRY Principle: "Don't Repeat Yourself" - removing redundant code and logic to create a more efficient and error-resistant codebase.

* Single Responsibility Principle: Restructuring the controller and associated models so that each class and method has one purpose and one purpose only, leading to easier testing and management.

* Improved Testing and Coverage: Enhancing test suites to cover more scenarios and edge cases, increasing confidence in the application's stability and performance.

* Performance Optimization: Identifying and optimizing slow or inefficient areas in the code to ensure the application runs smoothly.

* Clean Up Dead Methods: Audit the codebase for any unused ("dead") methods within the current controller and remove them to declutter the code.

* Reduced Controller Complexity: We already have streamline the `ResponseController` to focus primarily on CRUD operations and extract non-essential logic to appropriate models or helpers, now we aim to implement the rest operations.

By meeting these design goals, the project aims to produce a `responses_controller.rb` that is robust, efficient, and a pleasure to work with, both for the current development team and for those who will maintain the system in the future.

== Design Pattern ==

During the code refactoring process, we conscientiously followed various design patterns to enhance the overall structure.
When refactoring the Response model and associated controller and helper methods in the application, several key design patterns and principles were followed to ensure improved code quality, maintainability, and scalability. Here are the primary patterns and principles that were considered:

=== Single Responsibility Principle (SRP) ===
This principle was applied to break down complex methods into smaller, more focused functions that handle a specific part of the process

*In the Response Model:
Validate_params was broken down into multiple smaller methods, each handling a specific part of the validation process. This allows each method to manage one aspect of the validation, making the code easier to maintain and modify.
Creation and management of relationships and basic attributes were clearly defined, ensuring that the Response class isn't overloaded with logic that doesn't pertain to its direct attributes or relationships.

*In the ResponsesController:
The controller methods like create, update, show, etc., were defined to handle only HTTP requests and delegate business logic to the model or helper methods. This keeps the controller actions clean and focused on routing and basic request handling.

*In the ResponseHelper:
Methods such as create_answers and update_answers are good examples where each method is tasked with either creating or updating answers but not both. This follows SRP by dividing the responsibilities into more manageable, discrete operations.

===Factory Method===
The Factory Method pattern can be seen implicitly where object creation processes are encapsulated within the model or helper methods, such as creating a new ResponseMap or generating new Answer objects. This ensures that object creation is modular and separated from the main application logic.
===Strategy Pattern===
By defining a family of algorithms (in this case, validation rules for different actions like create or update), encapsulating each one, and making them interchangeable, the strategy pattern lets the algorithm vary independently from the clients that use it. For instance, separating the validation conditions for creating and updating responses allows for flexible swapping and extension of validation logic without modifying the controller or model directly.
===Observer Pattern===
Used typically in scenarios where changes to a particular object need to notify other dependent objects automatically. In the context of this application, this could relate to notifying instructors or peers upon the submission or update of responses, handled through the helper methods for sending emails.
===Template Method===
This pattern can be used in defining the skeleton of an operation in a method, deferring some steps to subclasses or other methods. It's seen in how validate_params uses a general structure for validation but defers the specifics to methods like validate_create_conditions and validate_update_conditions.

By integrating these design patterns and principles, the refactoring aims to achieve a more robust, maintainable, and scalable system. This approach not only addresses current complexities but also lays a foundation for easier future enhancements and modifications.

== Class Diagram ==
[[File:controller_Class_diagram.png|900px]]

== Use cases ==
[[File:Use_cases_controller.png|900px]]

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response model were refactored or introduced, including:
==== set_content ====
Redesigned to gather and prepare the required data for response objects, optimizing the interaction with associated models
==== validate_params ====
This is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===This method was significantly refactored to improve parameter validation. It was split into multiple smaller, focused methods, each dedicated to handling a specific aspect of the validation process. Each new method does one thing only, which makes them easier to understand and maintain.===
* assign_map_id_from_params: Sets the map_id for the response based on the provided parameters, ensuring the correct map ID is used for both creating and updating responses.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

==== serialize_response ====
Improved to efficiently serialize response data for API interactions, enhancing the clarity and usability of data exchanges.

=== Response Controller ===
The ResponseController, originally extensive with numerous functions beyond basic CRUD operations, has been streamlined for our API application. In this context, there's no need to manage data variables for view pages, simplifying the handling of request data solely through request methods.To enhance the architecture and efficiency of our application, we've eliminated redundant methods and consolidated functionalities across the model, controller, and helper files. This restructuring was essential for refining the response endpoints specifically tailored for an API application.

Before we added Basic CRUD like New, Create, Update, edit, destroy.

Removed Methods: Legacy methods like Questionnaire_from_response_map and Questionnaire_from_response were removed following the refactoring of set_content, which now handles its functionalities internally without the need for these methods.

==== Show_calibration_results_for_student ====
Before:

[[File:Show calibration results for student.PNG|900px]]

The old implementation also made use of database queries in the view. This will not be possible in the reimplemented Expertiza, and the required data will need to be made available in the JSON response sent by the controller.
[[File:DB access in view.PNG|900px]]
[[File:DB access in view 2.PNG|900px]]

The new show_calibration_results_for_student method retrieves and displays calibration and review responses based on provided map IDs. It fetches responses using these IDs, retrieves associated questions and answers, and returns the data as a formatted JSON object. If a response is not found, it returns an error indicating the missing response. The method handles any exceptions by returning a standard error message, ensuring robust error handling throughout the process.
Serves as an API endpoint to fetch detailed response data for a student's calibration and review tasks, providing all necessary details about the questions asked and the answers provided in both contexts

[[File:Show_calibration_results.png|900px]]

=== Response Helper ===

The method create_update_answers(response, answers) was originally handling both the creation and updating of answer records within a single method:

[[File:Create_update_answers_before.png|900px]]

To improve code maintainability and adhere to the Single Responsibility Principle, this method has been divided into two distinct methods:

==== Create_answers ====
This method focuses solely on creating new answer records. It iterates over the answers provided, checking if each answer does not already exist in the database. If the answer does not exist, it creates a new record for that answer. This ensures that each answer is unique and prevents duplication.
[[File:Create_answers_after.png|900px]]

==== Update_answers ====
This method is responsible for updating existing answer records. It searches for existing answers in the database based on the response and question identifiers. If an answer is found, it updates the existing record with the new information provided. This method ensures that all modifications to answers are captured accurately and that the database is kept up-to-date.

[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==Test==

===Validate Parameters===
====Postman Tests====

[[File:Postman_after_update.png|900px]]
[[File:DB validate parameters update test.png|900px]]

===Separated Answer Creation and Update Logic===
====Postman Tests====
Creation:
[[File:Postman after create for answer.png|900px]]
[[File:DB after create.png|900px]]

Update:
[[File:Postman after update for answer.png|900px]]
[[File:DB after update.png|900px]]

==Team==
===== Mentor=====
*Ameya Vaichalkar

=====Members=====
* Jeff Riehle
* Maday Moya
* Shardul Ladekar

==Links==
Postman Video Links:
*create: https://youtu.be/hXQl-JkfuUc
*update: https://youtu.be/BeifLsCRQlk
*show_calibration_results_for_student: https://www.youtube.com/watch?v=ltJarFGb25k

Pull request: https://github.com/expertiza/reimplementation-back-end/pull/92

Model Tests Video: https://youtu.be/7x8x4l3AksE

Controller Tests Video: https://youtu.be/0PV-ycXfyZU

==References==

*

User:Bkurra

2024-10-29T20:52:49Z

Bkurra: Created page with "CSC/ECE 517 Spring 2024 - E2415: Reimplementation of responses_controller.rb (Design Document) ==Expertiza== The Expertiza project, an open-source endeavor rooted in Ruby on Rails, embarks on continuous improvement to adapt and integrate modern software engineering practices. The Responses Controller is engineered to assist reviewers in submitting structured data that is specifically aligned with an assignment's rubrics, ensuring the provision of relevant questions for..."

CSC/ECE 517 Spring 2024 - E2415: Reimplementation of responses_controller.rb (Design Document)

==Expertiza==
The Expertiza project, an open-source endeavor rooted in Ruby on Rails, embarks on continuous improvement to adapt and integrate modern software engineering practices. The Responses Controller is engineered to assist reviewers in submitting structured data that is specifically aligned with an assignment's rubrics, ensuring the provision of relevant questions for each round within the correct due date period. It enables a reviewer to evaluate and score the rubric questions pertinent to the assignment's topics. Furthermore, it ensures the delivery of appropriate questions for each assignment round, allowing reviewers to create and modify scores and comments for each of the rubric questions associated with the assignment. After reviewers submit their scored questions and comments, the Responses Controller dispatches an email notification to the instructor and the reviewed team's members.

==Problem Statement==
The ResponseController in Expertiza, a legacy system with conventions predating Rails standards, is overly complex, encompassing functionalities beyond basic CRUD operations and needing adherence to modern Rails naming and design principles. Key issues include the direct implementation of functionalities like sorting reviews and checking reviewer roles within the controller, suggesting a shift towards polymorphism and a more structured approach to code organization. Furthermore, the controller's handling of email notifications and feedback mechanisms is inconsistent, indicating the necessity for a dedicated helper to streamline communication processes. The reimplementation effort must focus on simplifying the controller, adhering to Rails conventions, and improving code readability and maintainability by appropriately distributing responsibilities.

==Design Goal==
The redesign of the `responses_controller.rb` is guided by several key objectives to improve the code quality, system behavior, and developer interaction. The goals include:

* Maintainability and Scalability: Ensuring the code is easy to understand, modify, and extend. The reimplementation should simplify future updates and feature additions.

* Adherence to Rails Best Practices: Following Rails conventions for naming, structure, and coding practices to ensure code consistency and reliability.

* DRY Principle: "Don't Repeat Yourself" - removing redundant code and logic to create a more efficient and error-resistant codebase.

* Single Responsibility Principle: Restructuring the controller and associated models so that each class and method has one purpose and one purpose only, leading to easier testing and management.

* Improved Testing and Coverage: Enhancing test suites to cover more scenarios and edge cases, increasing confidence in the application's stability and performance.

* Performance Optimization: Identifying and optimizing slow or inefficient areas in the code to ensure the application runs smoothly.

* Clean Up Dead Methods: Audit the codebase for any unused ("dead") methods within the current controller and remove them to declutter the code.

* Reduced Controller Complexity: We already have streamline the `ResponseController` to focus primarily on CRUD operations and extract non-essential logic to appropriate models or helpers, now we aim to implement the rest operations.

By meeting these design goals, the project aims to produce a `responses_controller.rb` that is robust, efficient, and a pleasure to work with, both for the current development team and for those who will maintain the system in the future.

== Design Pattern ==

During the code refactoring process, we conscientiously followed various design patterns to enhance the overall structure.
When refactoring the Response model and associated controller and helper methods in the application, several key design patterns and principles were followed to ensure improved code quality, maintainability, and scalability. Here are the primary patterns and principles that were considered:

=== Single Responsibility Principle (SRP) ===
This principle was applied to break down complex methods into smaller, more focused functions that handle a specific part of the process

*In the Response Model:
Validate_params was broken down into multiple smaller methods, each handling a specific part of the validation process. This allows each method to manage one aspect of the validation, making the code easier to maintain and modify.
Creation and management of relationships and basic attributes were clearly defined, ensuring that the Response class isn't overloaded with logic that doesn't pertain to its direct attributes or relationships.

*In the ResponsesController:
The controller methods like create, update, show, etc., were defined to handle only HTTP requests and delegate business logic to the model or helper methods. This keeps the controller actions clean and focused on routing and basic request handling.

*In the ResponseHelper:
Methods such as create_answers and update_answers are good examples where each method is tasked with either creating or updating answers but not both. This follows SRP by dividing the responsibilities into more manageable, discrete operations.

===Factory Method===
The Factory Method pattern can be seen implicitly where object creation processes are encapsulated within the model or helper methods, such as creating a new ResponseMap or generating new Answer objects. This ensures that object creation is modular and separated from the main application logic.
===Strategy Pattern===
By defining a family of algorithms (in this case, validation rules for different actions like create or update), encapsulating each one, and making them interchangeable, the strategy pattern lets the algorithm vary independently from the clients that use it. For instance, separating the validation conditions for creating and updating responses allows for flexible swapping and extension of validation logic without modifying the controller or model directly.
===Observer Pattern===
Used typically in scenarios where changes to a particular object need to notify other dependent objects automatically. In the context of this application, this could relate to notifying instructors or peers upon the submission or update of responses, handled through the helper methods for sending emails.
===Template Method===
This pattern can be used in defining the skeleton of an operation in a method, deferring some steps to subclasses or other methods. It's seen in how validate_params uses a general structure for validation but defers the specifics to methods like validate_create_conditions and validate_update_conditions.

By integrating these design patterns and principles, the refactoring aims to achieve a more robust, maintainable, and scalable system. This approach not only addresses current complexities but also lays a foundation for easier future enhancements and modifications.

== Class Diagram ==
[[File:controller_Class_diagram.png|900px]]

== Use cases ==
[[File:Use_cases_controller.png|900px]]

== Solutions/Details of Changes Made==
=== Response Model ===
Methods within the response model were refactored or introduced, including:
==== set_content ====
Redesigned to gather and prepare the required data for response objects, optimizing the interaction with associated models
==== validate_params ====
This is the original method that was 46 lines long:

[[File:Validate parameters before.png|900px]]

===This method was significantly refactored to improve parameter validation. It was split into multiple smaller, focused methods, each dedicated to handling a specific aspect of the validation process. Each new method does one thing only, which makes them easier to understand and maintain.===
* assign_map_id_from_params: Sets the map_id for the response based on the provided parameters, ensuring the correct map ID is used for both creating and updating responses.
[[File:Assign map id.png|900px]]

*set_and_validate_response_map: Establishes and validates the presence of the response_map based on map_id. It's crucial to ensure that any response being created or updated is linked to a valid response map.This method attempts to find a ResponseMap based on map_id. If it fails to find one, it records an error and halts further validation, signaling an issue early in the process.
[[File:Set and validte response.png|900px]]

*set_response_attributes(params):Assigns additional attributes to the response object from the parameters. This centralizes attribute setting, reducing redundancy and errors.Directly extracts values like round, version_num, additional_comment, and visibility from the parameters and assigns them to the response object.
[[File:Set response attributes.png|900px]]

*action_specific_validation(params, action): Directs the validation flow based on whether the action is to create or update a response, organizing the logic clearly and preventing condition sprawl in the main validation method.Calls specific validation methods based on the action type: validate_create_conditions for creation and validate_update_conditions for updates.
[[File:Action specific validation.png|900px]]

*validate_create_conditions: Ensures that a new response doesn't duplicate an existing one under the same response map, round, and version number.Searches for an existing response that matches the current map_id, round, and version_num. If such a response exists, it adds a validation error and prevents the creation of a duplicate response.
[[File:Validate create condition.png|900px]]

*validate_update_conditions(params): Ensures that updates to a response are valid, specifically checking that a response isn't already submitted and that its map_id remains unchanged.Checks the submission status and whether there's an attempt to change the map_id. If either condition is violated, it records an error.
[[File:Validate update conditions.png|900px]]

*validate_submission_status(params): Updates the submission status of the response during the update process, ensuring the attribute is correctly set based on the provided parameters.Extracts and sets the is_submitted status from the parameters, which is crucial for controlling the editability of the response.
[[File:Validate submission status .png|900px]]

==== serialize_response ====
Improved to efficiently serialize response data for API interactions, enhancing the clarity and usability of data exchanges.

=== Response Controller ===
The ResponseController, originally extensive with numerous functions beyond basic CRUD operations, has been streamlined for our API application. In this context, there's no need to manage data variables for view pages, simplifying the handling of request data solely through request methods.To enhance the architecture and efficiency of our application, we've eliminated redundant methods and consolidated functionalities across the model, controller, and helper files. This restructuring was essential for refining the response endpoints specifically tailored for an API application.

Before we added Basic CRUD like New, Create, Update, edit, destroy.

Removed Methods: Legacy methods like Questionnaire_from_response_map and Questionnaire_from_response were removed following the refactoring of set_content, which now handles its functionalities internally without the need for these methods.

==== Show_calibration_results_for_student ====
Before:

[[File:Show calibration results for student.PNG|900px]]

The old implementation also made use of database queries in the view. This will not be possible in the reimplemented Expertiza, and the required data will need to be made available in the JSON response sent by the controller.
[[File:DB access in view.PNG|900px]]
[[File:DB access in view 2.PNG|900px]]

The new show_calibration_results_for_student method retrieves and displays calibration and review responses based on provided map IDs. It fetches responses using these IDs, retrieves associated questions and answers, and returns the data as a formatted JSON object. If a response is not found, it returns an error indicating the missing response. The method handles any exceptions by returning a standard error message, ensuring robust error handling throughout the process.
Serves as an API endpoint to fetch detailed response data for a student's calibration and review tasks, providing all necessary details about the questions asked and the answers provided in both contexts

[[File:Show_calibration_results.png|900px]]

=== Response Helper ===

The method create_update_answers(response, answers) was originally handling both the creation and updating of answer records within a single method:

[[File:Create_update_answers_before.png|900px]]

To improve code maintainability and adhere to the Single Responsibility Principle, this method has been divided into two distinct methods:

==== Create_answers ====
This method focuses solely on creating new answer records. It iterates over the answers provided, checking if each answer does not already exist in the database. If the answer does not exist, it creates a new record for that answer. This ensures that each answer is unique and prevents duplication.
[[File:Create_answers_after.png|900px]]

==== Update_answers ====
This method is responsible for updating existing answer records. It searches for existing answers in the database based on the response and question identifiers. If an answer is found, it updates the existing record with the new information provided. This method ensures that all modifications to answers are captured accurately and that the database is kept up-to-date.

[[File:Update_answers_after.png|900px]]

==Files Modified/Added==
List of primary files modified or created includes:
* responses_controller.rb
* response_helper.rb
* response.rb

==Test==

===Validate Parameters===
====Postman Tests====

[[File:Postman_after_update.png|900px]]
[[File:DB validate parameters update test.png|900px]]

===Separated Answer Creation and Update Logic===
====Postman Tests====
Creation:
[[File:Postman after create for answer.png|900px]]
[[File:DB after create.png|900px]]

Update:
[[File:Postman after update for answer.png|900px]]
[[File:DB after update.png|900px]]

==Team==
===== Mentor=====
*Ameya Vaichalkar

=====Members=====
* Jeff Riehle
* Maday Moya
* Shardul Ladekar

==Links==
Postman Video Links:
*create: https://youtu.be/hXQl-JkfuUc
*update: https://youtu.be/BeifLsCRQlk
*show_calibration_results_for_student: https://www.youtube.com/watch?v=ltJarFGb25k

Pull request: https://github.com/expertiza/reimplementation-back-end/pull/92

Model Tests Video: https://youtu.be/7x8x4l3AksE

Controller Tests Video: https://youtu.be/0PV-ycXfyZU

==References==

*