Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2025 - E2516. Reimplement teams users controller.rb

2025-04-08T00:30:28Z

Asingh78:

==E2516: Reimplement teams_users_controller.rb==

===About Expertiza===
Expertiza is an open-source platform designed to support education by streamlining assignment management. It offers a wide range of features: instructors can create and manage assignments, while students can submit their work in various file formats. One unique aspect is the peer review system, where students can review each other’s submissions. It also supports team-based work, allowing students to collaborate on assignments or projects. Overall, the platform helps both professors and students stay organized and work more efficiently.

===Overview===
Our goal for this project is to reimplement the TeamUsersController and change it to TeamsParticipantsController thereby strictly following DRY and SOLID principles. Presently, the TeamsUsersController is responsible for managing the interactions between teams and participants. Teams are associated with assignments and courses while participants are associated with these.

As of now, the controller achieves below mentioned functionalities:

1. Listing team members

2. Adding participants to teams

3. Removing participants from teams

4. Updating participants' duties within teams

5. Providing autocomplete suggestions for participant names when adding new members

6. Bulk deletion of team members

For the next project deliverable, we plan to achieve below mentioned functionalities:

1. Modifying the TeamsUsersController to TeamsParticipantsController and respectively modifying the associations and related methods and classes

2. We plan to achieve separation of concerns between models and classes and aim to minimize coupling

3. More test cases and test suites will be implement to test the robustness and effectiveness of the changes modified

4. Achieving code readability and maintainability by providing descriptive comments wherever necessary and maintaining consistent naming conventions for variables

===Problem Description===
Currently our controller presents with below mentioned major issues:

1. Incorrect Association Representation: The TeamsUser model links a User with a Team , not taking into consideration whether the User is assigned with a course or an assignment and generating ambiguity.

2. Violation of SOLID/DRY Principles: The methods in the controllers are very long and contain unnecessary logic and redundant code

3. Tight Coupling: Currently, there is a business logic code that resides in the model whereas it should have been placed in the controller. This results in a higher coupling and introduces difficulties in the future while modifying code.

4. Inconsistent code quality: Many places in the code have inconsistent naming conventions for the variables.

5. Insufficient Testing: Currently, testing has not been performed to a great extent and so the effectiveness of the existing codebase cannot be determined.

===Scope of Work===
The current work will involve the below implementation effort:

1. Model Refactoring
* Replace TeamsUsers controller with TeamsParticipants
* Update the database association structure to link TeamsParticipant with Partipant and Team
2. Controller Redesign
* Reimplementing a new TeamsParticipantsController which handles associations between teams and participants and achieves all functionalities listed in above section
* Ensure controller actions focus on request/response handling and delegating business logic to models
3. Create Method Refactor
* Breaking down create method in the controller into smaller, reusable, testable private methods
* Eliminate code duplication and unnecessary nesting
4. Model Enhancements
* Using the concept of polymorphism to clearly handle team membership and association rules
* Introducing checks related to whether a user is part of multiple teams and ensuring this is satisfied only in case of a mentor who can be assigned multiple teams
5. Code Quality Improvements
* Ensuring consistent naming conventions for variables
* Descriptive comments to make code more reliable and understandable
* Applying code best practises throughout codebase to ensure consistency
6. Testing
* Including RSpec tests for each controller method (e.g. index, create, delete etc.)
* Implement tests in models wherever additional business logic has been added
* Perform manual testing to ensure feature completeness and correctness
7. Documentation
* A detailed documentation providing the behavior of the controller and what it tries to achieve
* It should also include the associations between different entities and model and controller interactions
===Changes Proposed===
= Summary of Refactor =

* '''Replaced''' all references to <code>TeamsUser</code> with <code>TeamsParticipant</code>.

* '''Refactored''' long methods (especially <code>create</code>) into smaller private methods.

* '''Moved''' business logic to <code>AssignmentTeam</code> and <code>MentoredTeam</code> where appropriate (e.g., mentor-specific rules).

* '''Removed''' unnecessary nesting in methods like <code>create</code>.

* '''Improved''' naming conventions for all variables.

* '''Enhanced''' comments to explain functionality clearly.

* '''Ensured''' SOLID Principles are followed across all code.

* '''Wrote''' new unit and integration tests for controller methods.

= Proposed Flow for Major Methods =

== index ==

'''Input:''' <code>team_id</code>

'''Action:'''
Find team → Retrieve associated participants → Render list (JSON or HTML view).

'''Notes:'''
Simplicity focus: Only data retrieval, no complex logic.

== create ==

'''Input:''' Participant information, <code>team_id</code>

'''Steps:'''

Validate participant (exists, belongs to assignment/course).
Check team eligibility:
If participant is already on another team → Validate mentor exception rules (handled in model).
Create <code>TeamsParticipant</code> record linking the participant and team.
Handle success/failure gracefully with appropriate responses.
'''Important:''' Keep business rules outside the controller wherever possible (delegate to model methods).

== destroy ==

'''Input:''' <code>teams_participant_id</code>

'''Action:'''
Remove participant from the team cleanly, handling foreign key constraints.

== autocomplete_participants ==

'''Input:''' <code>assignment_id</code>, search string

'''Action:'''
Return a list of matching participants for the given assignment.

== bulk_delete ==

'''Input:''' List of participant IDs

'''Action:'''
Mass remove participants from their teams, validate permissions.

= Helper Methods (Private) =

<code>find_team</code>

<code>find_participant</code>

<code>validate_participant_eligibility</code>

<code>add_participant_to_team</code>

<code>remove_participant_from_team</code>

<code>mentor_eligibility_check</code> (Delegated to <code>AssignmentTeam</code> / <code>MentoredTeam</code>)

Each method will have a clear single responsibility and promote reuse across the controller.

= Notes on Migration =

All foreign keys linking teams to users will point through <code>TeamsParticipants</code>, not <code>TeamsUsers</code>.

Update any related services or background jobs that previously depended on <code>TeamsUser</code>.

Backward compatibility should be evaluated carefully to avoid breaking existing assignments or teams during the migration phase.

= Files Changed =

== TeamsParticipantsController ==

{| class="wikitable"
! Method
! Change
! Reason
|-
| action_allowed?
| No Change
| Determines if the current user has the necessary privileges to perform the requested action.
|-
| auto_complete_for_user_name
| No Change
| Provides a list of possible team members based on a partial name search for autocomplete functionality.
|-
| update_duties
| No Change
| Updates the duty assigned to a participant within a team and redirects to the student's team view.
|-
| list
| No Change
| Displays all participants of a specific team with pagination support.
|-
| new
| No Change
| Prepares the form for adding a new participant.
|-
| create
| Refactored
| Validates eligibility before adding a participant; delegates business logic.
|-
| delete
| Refactored
| Removes participant cleanly with undo option.
|-
| delete_selected
| New
| Bulk deletes multiple participants from a team.
|-
| user_not_found_message (private)
| New
| Returns a specific message if a user is not found.
|-
| valid_participant? (private)
| New
| Checks eligibility of participant for assignment/course.
|-
| participant_not_found_message (private)
| New
| Provides feedback if participant not linked to assignment/course.
|}

== AssignmentTeam.rb ==

{| class="wikitable"
! Method
! Change
! Reason
|-
| user_id(current_user = nil)
| Modified
| Added optional current_user param for better flexibility.
|-
| set_current_user
| Removed
| Logic merged into user_id.
|-
| includes?(participant)
| Retained (Minor rewording)
| Direct comparison with updated participant fetching logic.
|-
| parent_model
| Retained
| Returns 'Assignment' as parent model.
|-
| self.parent_model(id)
| Removed
| Responsibility moved elsewhere for separation of concerns.
|-
| fullname
| Removed
| Deemed unnecessary alias.
|-
| review_map_type
| Removed
| Hardcoding removed to reduce tight coupling.
|-
| prototype
| Removed
| Not needed under Rails ActiveRecord conventions.
|-
| assign_reviewer
| Modified
| Extracted review map creation into create_review_map.
|-
| create_review_map
| New
| Dedicated method for creating review maps.
|-
| get_reviewer
| Removed
| Reviewer assignment simplified.
|-
| reviewed_by?
| Modified
| Now uses ReviewResponseMap.exists? for better DB efficiency.
|-
| topic
| Removed
| Responsibility split for cleaner structure.
|-
| has_submissions?
| Retained
| Basic file/submission existence checks.
|-
| participants
| Modified
| Refactored using TeamsParticipant.team_members(id).
|-
| add_participant
| Modified
| Creates a TeamsParticipant directly.
|-
| delete & destroy
| Removed
| Simplified elsewhere.
|-
| first_member
| Removed
| SRP enforcement.
|-
| submitted_files(path)
| Removed
| File access logic shifted to service.
|-
| import/export methods
| Removed
| Responsibility moved to helpers/services.
|-
| copy(course_id)
| Removed
| Refactored externally.
|-
| hyperlinks
| Removed
| Delegated to service.
|-
| submit_hyperlink(hyperlink)
| Modified (Delegated)
| Handled by TeamFileService.
|-
| remove_hyperlink(hyperlink)
| Modified (Delegated)
| Handled by TeamFileService.
|-
| files(directory)
| Removed
| File traversal extracted.
|-
| team(participant)
| Removed
| Moved to higher-level service.
|-
| export_fields(options)
| Removed
| Offloaded for SRP.
|-
| remove_team_by_id(id)
| Removed
| Refactored.
|-
| path
| Removed
| File path responsibility shifted.
|-
| set_student_directory_num
| Removed
| Directory numbering moved.
|-
| received_any_peer_review?
| Removed
| Simplified elsewhere.
|-
| most_recent_submission
| Retained (Optimized)
| Improved query efficiency.
|-
| get_logged_in_reviewer_id(current_user_id)
| Removed
| Participant-reviewer handling refactored.
|-
| current_user_is_reviewer?(current_user_id)
| Removed
| Responsibility simplified.
|-
| create_new_team(user_id, signuptopic)
| Modified (Simplified)
| Refactored for better exception handling.
|}

== MentoredTeam.rb ==

{| class="wikitable"
! Method
! Change
! Reason
|-
| add_member(user, _assignment_id = nil)
| Refactored
| Broken into modular private methods for adding users and assigning mentors.
|-
| import_team_members(row_hash)
| Refactored
| Improved to skip blanks, safe user lookup, and error handling.
|-
| can_add_member?(user)
| New
| Private method for team capacity and mentor assignment validation.
|-
| add_team_user(user)
| New
| Cleanly adds a TeamsUser.
|-
| add_participant_to_team(user)
| New
| Adds participant based on assignment.
|-
| assign_mentor_if_needed(_assignment_id)
| New
| Ensures no duplicate mentors are assigned.
|-
| mentor_assignment_valid?(user)
| New
| Validates mentor assignment rules.
|-
| user_not_in_team?(user)
| New
| Checks if user is already part of the team.
|-
| find_or_raise_user(teammate)
| New
| Finds user or raises informative ImportError.
|}

== TeamsParticipants Model ==

{| class="wikitable"
! Aspect
! Change
! Reason
|-
| Association
| New
| Establishes direct link between Participant and Team to maintain integrity.
|-
| team_members
| New
| Retrieves all users associated through participants.
|-
| remove_participant_from_team
| New
| Safely removes participant from team.
|-
| username delegation
| New
| Delegates access to participant's username.
|-
| Integrity
| New
| Ensures only valid assignment participants can join teams.
|-
| Maintainability
| New
| Designed to align with SOLID principles and Rails best practices.
|}

= Testing Plan =
We plan to cover the reimplementation and refactoring of the following:
* AssignmentTeam
* MentoredTeam
* TeamsParticipantsController
* TeamsParticipant model

We use RSpec for model, controller, and request specs. API tests are also included where applicable.
Both positive and negative test cases are included to ensure robust functionality, along with validation checks and authorization verifications.

== AssignmentTeam Model Tests ==
{| class="wikitable"
! # !! Method !! Test Description
|-
| 1 || user_id || Verify that the correct user ID is returned; prioritize current user if available.
|-
| 2 || includes? || Check if a given participant is part of the team.
|-
| 3 || parent_model || Ensure the parent model returns "Assignment".
|-
| 4 || assign_reviewer || Test reviewer assignment creation and error handling when assignment is not found.
|-
| 5 || create_review_map || Confirm a new ReviewResponseMap record is created successfully.
|-
| 6 || reviewed_by? || Verify if a reviewer has reviewed the team; test both true and false scenarios.
|-
| 7 || participants || Ensure the correct participants are retrieved via TeamsParticipant.
|-
| 8 || add_participant || Confirm that a participant is added, and prevent duplicate addition.
|-
| 9 || create_new_team || Ensure that a new team-user linkage, sign-up, and nodes are created properly.
|-
| 10 || submit_hyperlink || Verify delegation to TeamFileService for hyperlink submission.
|-
| 11 || remove_hyperlink || Verify delegation to TeamFileService for hyperlink removal.
|-
| 12 || has_submissions? || Check behavior when team has submissions and when it doesn't.
|-
| 13 || most_recent_submission || Ensure the most recent submission is retrieved based on updated_at.
|}

== MentoredTeam Model Tests ==
{| class="wikitable"
! # !! Method !! Test Description
|-
| 1 || import_team_members || Ensure team members are imported from a list correctly.
|-
| 2 || find_or_raise_user || Test for successful user lookup and error raising if user not found.
|-
| 3 || user_not_in_team? || Confirm whether a user is already in the team or not.
|-
| 4 || mentor_assignment_valid? || Verify that a mentor can be assigned properly and prevent duplicate mentors.
|-
| 5 || add_member || Ensure user is added successfully and prevent re-adding existing team members.
|-
| 6 || can_add_member? || Verify team capacity check before adding a member.
|-
| 7 || add_team_user || Ensure that a TeamsUser is created and linked correctly.
|-
| 8 || add_participant_to_team || Confirm that a participant is correctly linked to the team.
|-
| 9 || assign_mentor_if_needed || Validate that mentor is assigned only when needed (no double assignment).
|}

== TeamsParticipantsController Tests ==
{| class="wikitable"
! # !! Method !! Test Description
|-
| 1 || valid_participant? || Confirm existence check for a participant; return true/false accordingly.
|-
| 2 || update_duties || Test participant duty update flow and ensure a redirect occurs.
|-
| 3 || user_not_found_message || Validate that a proper flash message is returned when a user isn't found.
|-
| 4 || participant_not_found_message || Validate correct error message if participant isn't linked.
|-
| 5 || create || Confirm that creating a TeamsParticipant increases record count.
|-
| 6 || list || Test that the participant list view renders correctly.
|-
| 7 || action_allowed? || Ensure access control is enforced based on user roles (admin/TA/student).
|-
| 8 || delete || Confirm deletion of a TeamsParticipant entry works correctly.
|-
| 9 || auto_complete_for_user_name || Verify that JSON autocomplete results are returned based on user input.
|-
| 10 || new || Test that the new participant view loads successfully.
|-
| 11 || delete_selected || Ensure multiple TeamsParticipant records can be deleted at once.
|}

== TeamsParticipant Model Tests ==
{| class="wikitable"
! # !! Method !! Test Description
|-
| 1 || Associations || Ensure that a TeamsParticipant correctly belongs to a team and participant.
|-
| 2 || Validations || Confirm presence validations on team and participant relationships.
|-
| 3 || team_members || Validate fetching all team members given a team ID.
|-
| 4 || participant? || Verify participant existence check for a given user; test positive and negative cases.
|}

== TeamsParticipants API (Request Specs) ==
{| class="wikitable"
! # !! Endpoint !! Test Description
|-
| 1 || POST /teams_participants || Ensure a participant is added via API and redirects successfully.
|-
| 2 || DELETE /teams_participants/:id || Ensure a participant is deleted via API and redirects successfully.
|}

===Mentor===
* Vihar Manojkumar Shah([mailto:vshah23@ncsu.edu vshah23@ncsu.edu])

===Team Members===

* Manav Kamdar ([mailto:mkamdar@ncsu.edu mkamdar@ncsu.edu])
* Aditya Singh ([mailto:asingh78@ncsu.edu asingh78@ncsu.edu])
* Shivang Patel ([mailto:spatel74@ncsu.edu spatel74@ncsu.edu])

CSC/ECE 517 Spring 2025 - E2516. Reimplement teams users controller.rb

2025-04-08T00:29:15Z

Asingh78:

==E2516: Reimplement teams_users_controller.rb==

===About Expertiza===
Expertiza is an open-source platform designed to support education by streamlining assignment management. It offers a wide range of features: instructors can create and manage assignments, while students can submit their work in various file formats. One unique aspect is the peer review system, where students can review each other’s submissions. It also supports team-based work, allowing students to collaborate on assignments or projects. Overall, the platform helps both professors and students stay organized and work more efficiently.

===Overview===
Our goal for this project is to reimplement the TeamUsersController and change it to TeamsParticipantsController thereby strictly following DRY and SOLID principles. Presently, the TeamsUsersController is responsible for managing the interactions between teams and participants. Teams are associated with assignments and courses while participants are associated with these.

As of now, the controller achieves below mentioned functionalities:

1. Listing team members

2. Adding participants to teams

3. Removing participants from teams

4. Updating participants' duties within teams

5. Providing autocomplete suggestions for participant names when adding new members

6. Bulk deletion of team members

For the next project deliverable, we plan to achieve below mentioned functionalities:

1. Modifying the TeamsUsersController to TeamsParticipantsController and respectively modifying the associations and related methods and classes

2. We plan to achieve separation of concerns between models and classes and aim to minimize coupling

3. More test cases and test suites will be implement to test the robustness and effectiveness of the changes modified

4. Achieving code readability and maintainability by providing descriptive comments wherever necessary and maintaining consistent naming conventions for variables

===Problem Description===
Currently our controller presents with below mentioned major issues:

1. Incorrect Association Representation: The TeamsUser model links a User with a Team , not taking into consideration whether the User is assigned with a course or an assignment and generating ambiguity.

2. Violation of SOLID/DRY Principles: The methods in the controllers are very long and contain unnecessary logic and redundant code

3. Tight Coupling: Currently, there is a business logic code that resides in the model whereas it should have been placed in the controller. This results in a higher coupling and introduces difficulties in the future while modifying code.

4. Inconsistent code quality: Many places in the code have inconsistent naming conventions for the variables.

5. Insufficient Testing: Currently, testing has not been performed to a great extent and so the effectiveness of the existing codebase cannot be determined.

===Scope of Work===
The current work will involve the below implementation effort:

1. Model Refactoring
* Replace TeamsUsers controller with TeamsParticipants
* Update the database association structure to link TeamsParticipant with Partipant and Team
2. Controller Redesign
* Reimplementing a new TeamsParticipantsController which handles associations between teams and participants and achieves all functionalities listed in above section
* Ensure controller actions focus on request/response handling and delegating business logic to models
3. Create Method Refactor
* Breaking down create method in the controller into smaller, reusable, testable private methods
* Eliminate code duplication and unnecessary nesting
4. Model Enhancements
* Using the concept of polymorphism to clearly handle team membership and association rules
* Introducing checks related to whether a user is part of multiple teams and ensuring this is satisfied only in case of a mentor who can be assigned multiple teams
5. Code Quality Improvements
* Ensuring consistent naming conventions for variables
* Descriptive comments to make code more reliable and understandable
* Applying code best practises throughout codebase to ensure consistency
6. Testing
* Including RSpec tests for each controller method (e.g. index, create, delete etc.)
* Implement tests in models wherever additional business logic has been added
* Perform manual testing to ensure feature completeness and correctness
7. Documentation
* A detailed documentation providing the behavior of the controller and what it tries to achieve
* It should also include the associations between different entities and model and controller interactions
===Changes Proposed===
= Summary of Refactor =

'''Replaced''' all references to <code>TeamsUser</code> with <code>TeamsParticipant</code>.

'''Refactored''' long methods (especially <code>create</code>) into smaller private methods.

'''Moved''' business logic to <code>AssignmentTeam</code> and <code>MentoredTeam</code> where appropriate (e.g., mentor-specific rules).

'''Removed''' unnecessary nesting in methods like <code>create</code>.

'''Improved''' naming conventions for all variables.

'''Enhanced''' comments to explain functionality clearly.

'''Ensured''' SOLID Principles are followed across all code.

'''Wrote''' new unit and integration tests for controller methods.

= Proposed Flow for Major Methods =

== index ==

'''Input:''' <code>team_id</code>

'''Action:'''
Find team → Retrieve associated participants → Render list (JSON or HTML view).

'''Notes:'''
Simplicity focus: Only data retrieval, no complex logic.

== create ==

'''Input:''' Participant information, <code>team_id</code>

'''Steps:'''

Validate participant (exists, belongs to assignment/course).
Check team eligibility:
If participant is already on another team → Validate mentor exception rules (handled in model).
Create <code>TeamsParticipant</code> record linking the participant and team.
Handle success/failure gracefully with appropriate responses.
'''Important:''' Keep business rules outside the controller wherever possible (delegate to model methods).

== destroy ==

'''Input:''' <code>teams_participant_id</code>

'''Action:'''
Remove participant from the team cleanly, handling foreign key constraints.

== autocomplete_participants ==

'''Input:''' <code>assignment_id</code>, search string

'''Action:'''
Return a list of matching participants for the given assignment.

== bulk_delete ==

'''Input:''' List of participant IDs

'''Action:'''
Mass remove participants from their teams, validate permissions.

= Helper Methods (Private) =

<code>find_team</code>

<code>find_participant</code>

<code>validate_participant_eligibility</code>

<code>add_participant_to_team</code>

<code>remove_participant_from_team</code>

<code>mentor_eligibility_check</code> (Delegated to <code>AssignmentTeam</code> / <code>MentoredTeam</code>)

Each method will have a clear single responsibility and promote reuse across the controller.

= Notes on Migration =

All foreign keys linking teams to users will point through <code>TeamsParticipants</code>, not <code>TeamsUsers</code>.

Update any related services or background jobs that previously depended on <code>TeamsUser</code>.

Backward compatibility should be evaluated carefully to avoid breaking existing assignments or teams during the migration phase.

= Files Changed =

== TeamsParticipantsController ==

{| class="wikitable"
! Method
! Change
! Reason
|-
| action_allowed?
| No Change
| Determines if the current user has the necessary privileges to perform the requested action.
|-
| auto_complete_for_user_name
| No Change
| Provides a list of possible team members based on a partial name search for autocomplete functionality.
|-
| update_duties
| No Change
| Updates the duty assigned to a participant within a team and redirects to the student's team view.
|-
| list
| No Change
| Displays all participants of a specific team with pagination support.
|-
| new
| No Change
| Prepares the form for adding a new participant.
|-
| create
| Refactored
| Validates eligibility before adding a participant; delegates business logic.
|-
| delete
| Refactored
| Removes participant cleanly with undo option.
|-
| delete_selected
| New
| Bulk deletes multiple participants from a team.
|-
| user_not_found_message (private)
| New
| Returns a specific message if a user is not found.
|-
| valid_participant? (private)
| New
| Checks eligibility of participant for assignment/course.
|-
| participant_not_found_message (private)
| New
| Provides feedback if participant not linked to assignment/course.
|}

== AssignmentTeam.rb ==

{| class="wikitable"
! Method
! Change
! Reason
|-
| user_id(current_user = nil)
| Modified
| Added optional current_user param for better flexibility.
|-
| set_current_user
| Removed
| Logic merged into user_id.
|-
| includes?(participant)
| Retained (Minor rewording)
| Direct comparison with updated participant fetching logic.
|-
| parent_model
| Retained
| Returns 'Assignment' as parent model.
|-
| self.parent_model(id)
| Removed
| Responsibility moved elsewhere for separation of concerns.
|-
| fullname
| Removed
| Deemed unnecessary alias.
|-
| review_map_type
| Removed
| Hardcoding removed to reduce tight coupling.
|-
| prototype
| Removed
| Not needed under Rails ActiveRecord conventions.
|-
| assign_reviewer
| Modified
| Extracted review map creation into create_review_map.
|-
| create_review_map
| New
| Dedicated method for creating review maps.
|-
| get_reviewer
| Removed
| Reviewer assignment simplified.
|-
| reviewed_by?
| Modified
| Now uses ReviewResponseMap.exists? for better DB efficiency.
|-
| topic
| Removed
| Responsibility split for cleaner structure.
|-
| has_submissions?
| Retained
| Basic file/submission existence checks.
|-
| participants
| Modified
| Refactored using TeamsParticipant.team_members(id).
|-
| add_participant
| Modified
| Creates a TeamsParticipant directly.
|-
| delete & destroy
| Removed
| Simplified elsewhere.
|-
| first_member
| Removed
| SRP enforcement.
|-
| submitted_files(path)
| Removed
| File access logic shifted to service.
|-
| import/export methods
| Removed
| Responsibility moved to helpers/services.
|-
| copy(course_id)
| Removed
| Refactored externally.
|-
| hyperlinks
| Removed
| Delegated to service.
|-
| submit_hyperlink(hyperlink)
| Modified (Delegated)
| Handled by TeamFileService.
|-
| remove_hyperlink(hyperlink)
| Modified (Delegated)
| Handled by TeamFileService.
|-
| files(directory)
| Removed
| File traversal extracted.
|-
| team(participant)
| Removed
| Moved to higher-level service.
|-
| export_fields(options)
| Removed
| Offloaded for SRP.
|-
| remove_team_by_id(id)
| Removed
| Refactored.
|-
| path
| Removed
| File path responsibility shifted.
|-
| set_student_directory_num
| Removed
| Directory numbering moved.
|-
| received_any_peer_review?
| Removed
| Simplified elsewhere.
|-
| most_recent_submission
| Retained (Optimized)
| Improved query efficiency.
|-
| get_logged_in_reviewer_id(current_user_id)
| Removed
| Participant-reviewer handling refactored.
|-
| current_user_is_reviewer?(current_user_id)
| Removed
| Responsibility simplified.
|-
| create_new_team(user_id, signuptopic)
| Modified (Simplified)
| Refactored for better exception handling.
|}

== MentoredTeam.rb ==

{| class="wikitable"
! Method
! Change
! Reason
|-
| add_member(user, _assignment_id = nil)
| Refactored
| Broken into modular private methods for adding users and assigning mentors.
|-
| import_team_members(row_hash)
| Refactored
| Improved to skip blanks, safe user lookup, and error handling.
|-
| can_add_member?(user)
| New
| Private method for team capacity and mentor assignment validation.
|-
| add_team_user(user)
| New
| Cleanly adds a TeamsUser.
|-
| add_participant_to_team(user)
| New
| Adds participant based on assignment.
|-
| assign_mentor_if_needed(_assignment_id)
| New
| Ensures no duplicate mentors are assigned.
|-
| mentor_assignment_valid?(user)
| New
| Validates mentor assignment rules.
|-
| user_not_in_team?(user)
| New
| Checks if user is already part of the team.
|-
| find_or_raise_user(teammate)
| New
| Finds user or raises informative ImportError.
|}

== TeamsParticipants Model ==

{| class="wikitable"
! Aspect
! Change
! Reason
|-
| Association
| New
| Establishes direct link between Participant and Team to maintain integrity.
|-
| team_members
| New
| Retrieves all users associated through participants.
|-
| remove_participant_from_team
| New
| Safely removes participant from team.
|-
| username delegation
| New
| Delegates access to participant's username.
|-
| Integrity
| New
| Ensures only valid assignment participants can join teams.
|-
| Maintainability
| New
| Designed to align with SOLID principles and Rails best practices.
|}

= Testing Plan =
We plan to cover the reimplementation and refactoring of the following:
* AssignmentTeam
* MentoredTeam
* TeamsParticipantsController
* TeamsParticipant model

We use RSpec for model, controller, and request specs. API tests are also included where applicable.
Both positive and negative test cases are included to ensure robust functionality, along with validation checks and authorization verifications.

== AssignmentTeam Model Tests ==
{| class="wikitable"
! # !! Method !! Test Description
|-
| 1 || user_id || Verify that the correct user ID is returned; prioritize current user if available.
|-
| 2 || includes? || Check if a given participant is part of the team.
|-
| 3 || parent_model || Ensure the parent model returns "Assignment".
|-
| 4 || assign_reviewer || Test reviewer assignment creation and error handling when assignment is not found.
|-
| 5 || create_review_map || Confirm a new ReviewResponseMap record is created successfully.
|-
| 6 || reviewed_by? || Verify if a reviewer has reviewed the team; test both true and false scenarios.
|-
| 7 || participants || Ensure the correct participants are retrieved via TeamsParticipant.
|-
| 8 || add_participant || Confirm that a participant is added, and prevent duplicate addition.
|-
| 9 || create_new_team || Ensure that a new team-user linkage, sign-up, and nodes are created properly.
|-
| 10 || submit_hyperlink || Verify delegation to TeamFileService for hyperlink submission.
|-
| 11 || remove_hyperlink || Verify delegation to TeamFileService for hyperlink removal.
|-
| 12 || has_submissions? || Check behavior when team has submissions and when it doesn't.
|-
| 13 || most_recent_submission || Ensure the most recent submission is retrieved based on updated_at.
|}

== MentoredTeam Model Tests ==
{| class="wikitable"
! # !! Method !! Test Description
|-
| 1 || import_team_members || Ensure team members are imported from a list correctly.
|-
| 2 || find_or_raise_user || Test for successful user lookup and error raising if user not found.
|-
| 3 || user_not_in_team? || Confirm whether a user is already in the team or not.
|-
| 4 || mentor_assignment_valid? || Verify that a mentor can be assigned properly and prevent duplicate mentors.
|-
| 5 || add_member || Ensure user is added successfully and prevent re-adding existing team members.
|-
| 6 || can_add_member? || Verify team capacity check before adding a member.
|-
| 7 || add_team_user || Ensure that a TeamsUser is created and linked correctly.
|-
| 8 || add_participant_to_team || Confirm that a participant is correctly linked to the team.
|-
| 9 || assign_mentor_if_needed || Validate that mentor is assigned only when needed (no double assignment).
|}

== TeamsParticipantsController Tests ==
{| class="wikitable"
! # !! Method !! Test Description
|-
| 1 || valid_participant? || Confirm existence check for a participant; return true/false accordingly.
|-
| 2 || update_duties || Test participant duty update flow and ensure a redirect occurs.
|-
| 3 || user_not_found_message || Validate that a proper flash message is returned when a user isn't found.
|-
| 4 || participant_not_found_message || Validate correct error message if participant isn't linked.
|-
| 5 || create || Confirm that creating a TeamsParticipant increases record count.
|-
| 6 || list || Test that the participant list view renders correctly.
|-
| 7 || action_allowed? || Ensure access control is enforced based on user roles (admin/TA/student).
|-
| 8 || delete || Confirm deletion of a TeamsParticipant entry works correctly.
|-
| 9 || auto_complete_for_user_name || Verify that JSON autocomplete results are returned based on user input.
|-
| 10 || new || Test that the new participant view loads successfully.
|-
| 11 || delete_selected || Ensure multiple TeamsParticipant records can be deleted at once.
|}

== TeamsParticipant Model Tests ==
{| class="wikitable"
! # !! Method !! Test Description
|-
| 1 || Associations || Ensure that a TeamsParticipant correctly belongs to a team and participant.
|-
| 2 || Validations || Confirm presence validations on team and participant relationships.
|-
| 3 || team_members || Validate fetching all team members given a team ID.
|-
| 4 || participant? || Verify participant existence check for a given user; test positive and negative cases.
|}

== TeamsParticipants API (Request Specs) ==
{| class="wikitable"
! # !! Endpoint !! Test Description
|-
| 1 || POST /teams_participants || Ensure a participant is added via API and redirects successfully.
|-
| 2 || DELETE /teams_participants/:id || Ensure a participant is deleted via API and redirects successfully.
|}

===Mentor===
* Vihar Manojkumar Shah([mailto:vshah23@ncsu.edu vshah23@ncsu.edu])

===Team Members===

* Manav Kamdar ([mailto:mkamdar@ncsu.edu mkamdar@ncsu.edu])
* Aditya Singh ([mailto:asingh78@ncsu.edu asingh78@ncsu.edu])
* Shivang Patel ([mailto:spatel74@ncsu.edu spatel74@ncsu.edu])

CSC/ECE 517 Spring 2025 - E2516. Reimplement teams users controller.rb

2025-04-08T00:23:21Z

Asingh78:

==E2516: Reimplement teams_users_controller.rb==

===About Expertiza===
Expertiza is an open-source platform designed to support education by streamlining assignment management. It offers a wide range of features: instructors can create and manage assignments, while students can submit their work in various file formats. One unique aspect is the peer review system, where students can review each other’s submissions. It also supports team-based work, allowing students to collaborate on assignments or projects. Overall, the platform helps both professors and students stay organized and work more efficiently.

===Overview===
Our goal for this project is to reimplement the TeamUsersController and change it to TeamsParticipantsController thereby strictly following DRY and SOLID principles. Presently, the TeamsUsersController is responsible for managing the interactions between teams and participants. Teams are associated with assignments and courses while participants are associated with these.

As of now, the controller achieves below mentioned functionalities:

1. Listing team members
2. Adding participants to teams
3. Removing participants from teams
4. Updating participants' duties within teams
5. Providing autocomplete suggestions for participant names when adding new members
6. Bulk deletion of team members

For the next project deliverable, we plan to achieve below mentioned functionalities:

1. Modifying the TeamsUsersController to TeamsParticipantsController and respectively modifying the associations and related methods and classes
2. We plan to achieve separation of concerns between models and classes and aim to minimize coupling
3. More test cases and test suites will be implement to test the robustness and effectiveness of the changes modified
4. Achieving code readability and maintainability by providing descriptive comments wherever necessary and maintaining consistent naming conventions for variables

===Problem Description===
Currently our controller presents with below mentioned major issues:

1. Incorrect Association Representation: The TeamsUser model links a User with a Team , not taking into consideration whether the User is assigned with a course or an assignment and generating ambiguity.
2. Violation of SOLID/DRY Principles: The methods in the controllers are very long and contain unnecessary logic and redundant code
3. Tight Coupling: Currently, there is a business logic code that resides in the model whereas it should have been placed in the controller. This results in a higher coupling and introduces difficulties in the future while modifying code.
4. Inconsistent code quality: Many places in the code have inconsistent naming conventions for the variables.
5. Insufficient Testing: Currently, testing has not been performed to a great extent and so the effectiveness of the existing codebase cannot be determined.

===Scope of Work===
The current work will involve the below implementation effort:

1. Model Refactoring
* Replace TeamsUsers controller with TeamsParticipants
* Update the database association structure to link TeamsParticipant with Partipant and Team
2. Controller Redesign
* Reimplementing a new TeamsParticipantsController which handles associations between teams and participants and achieves all functionalities listed in above section
* Ensure controller actions focus on request/response handling and delegating business logic to models
3. Create Method Refactor
* Breaking down create method in the controller into smaller, reusable, testable private methods
* Eliminate code duplication and unnecessary nesting
4. Model Enhancements
* Using the concept of polymorphism to clearly handle team membership and association rules
* Introducing checks related to whether a user is part of multiple teams and ensuring this is satisfied only in case of a mentor who can be assigned multiple teams
5. Code Quality Improvements
* Ensuring consistent naming conventions for variables
* Descriptive comments to make code more reliable and understandable
* Applying code best practises throughout codebase to ensure consistency
6. Testing
* Including RSpec tests for each controller method (e.g. index, create, delete etc.)
* Implement tests in models wherever additional business logic has been added
* Perform manual testing to ensure feature completeness and correctness
7. Documentation
* A detailed documentation providing the behavior of the controller and what it tries to achieve
* It should also include the associations between different entities and model and controller interactions
===Changes Proposed===
= Summary of Refactor =

'''Replaced''' all references to <code>TeamsUser</code> with <code>TeamsParticipant</code>.

'''Refactored''' long methods (especially <code>create</code>) into smaller private methods.

'''Moved''' business logic to <code>AssignmentTeam</code> and <code>MentoredTeam</code> where appropriate (e.g., mentor-specific rules).

'''Removed''' unnecessary nesting in methods like <code>create</code>.

'''Improved''' naming conventions for all variables.

'''Enhanced''' comments to explain functionality clearly.

'''Ensured''' SOLID Principles are followed across all code.

'''Wrote''' new unit and integration tests for controller methods.

= Proposed Flow for Major Methods =

== index ==

'''Input:''' <code>team_id</code>

'''Action:'''
Find team → Retrieve associated participants → Render list (JSON or HTML view).

'''Notes:'''
Simplicity focus: Only data retrieval, no complex logic.

== create ==

'''Input:''' Participant information, <code>team_id</code>

'''Steps:'''

Validate participant (exists, belongs to assignment/course).
Check team eligibility:
If participant is already on another team → Validate mentor exception rules (handled in model).
Create <code>TeamsParticipant</code> record linking the participant and team.
Handle success/failure gracefully with appropriate responses.
'''Important:''' Keep business rules outside the controller wherever possible (delegate to model methods).

== destroy ==

'''Input:''' <code>teams_participant_id</code>

'''Action:'''
Remove participant from the team cleanly, handling foreign key constraints.

== autocomplete_participants ==

'''Input:''' <code>assignment_id</code>, search string

'''Action:'''
Return a list of matching participants for the given assignment.

== bulk_delete ==

'''Input:''' List of participant IDs

'''Action:'''
Mass remove participants from their teams, validate permissions.

= Helper Methods (Private) =

<code>find_team</code>

<code>find_participant</code>

<code>validate_participant_eligibility</code>

<code>add_participant_to_team</code>

<code>remove_participant_from_team</code>

<code>mentor_eligibility_check</code> (Delegated to <code>AssignmentTeam</code> / <code>MentoredTeam</code>)

Each method will have a clear single responsibility and promote reuse across the controller.

= Notes on Migration =

All foreign keys linking teams to users will point through <code>TeamsParticipants</code>, not <code>TeamsUsers</code>.

Update any related services or background jobs that previously depended on <code>TeamsUser</code>.

Backward compatibility should be evaluated carefully to avoid breaking existing assignments or teams during the migration phase.

= Files Changed =

== TeamsParticipantsController ==

{| class="wikitable"
! Method
! Change
! Reason
|-
| action_allowed?
| No Change
| Determines if the current user has the necessary privileges to perform the requested action.
|-
| auto_complete_for_user_name
| No Change
| Provides a list of possible team members based on a partial name search for autocomplete functionality.
|-
| update_duties
| No Change
| Updates the duty assigned to a participant within a team and redirects to the student's team view.
|-
| list
| No Change
| Displays all participants of a specific team with pagination support.
|-
| new
| No Change
| Prepares the form for adding a new participant.
|-
| create
| Refactored
| Validates eligibility before adding a participant; delegates business logic.
|-
| delete
| Refactored
| Removes participant cleanly with undo option.
|-
| delete_selected
| New
| Bulk deletes multiple participants from a team.
|-
| user_not_found_message (private)
| New
| Returns a specific message if a user is not found.
|-
| valid_participant? (private)
| New
| Checks eligibility of participant for assignment/course.
|-
| participant_not_found_message (private)
| New
| Provides feedback if participant not linked to assignment/course.
|}

== AssignmentTeam.rb ==

{| class="wikitable"
! Method
! Change
! Reason
|-
| user_id(current_user = nil)
| Modified
| Added optional current_user param for better flexibility.
|-
| set_current_user
| Removed
| Logic merged into user_id.
|-
| includes?(participant)
| Retained (Minor rewording)
| Direct comparison with updated participant fetching logic.
|-
| parent_model
| Retained
| Returns 'Assignment' as parent model.
|-
| self.parent_model(id)
| Removed
| Responsibility moved elsewhere for separation of concerns.
|-
| fullname
| Removed
| Deemed unnecessary alias.
|-
| review_map_type
| Removed
| Hardcoding removed to reduce tight coupling.
|-
| prototype
| Removed
| Not needed under Rails ActiveRecord conventions.
|-
| assign_reviewer
| Modified
| Extracted review map creation into create_review_map.
|-
| create_review_map
| New
| Dedicated method for creating review maps.
|-
| get_reviewer
| Removed
| Reviewer assignment simplified.
|-
| reviewed_by?
| Modified
| Now uses ReviewResponseMap.exists? for better DB efficiency.
|-
| topic
| Removed
| Responsibility split for cleaner structure.
|-
| has_submissions?
| Retained
| Basic file/submission existence checks.
|-
| participants
| Modified
| Refactored using TeamsParticipant.team_members(id).
|-
| add_participant
| Modified
| Creates a TeamsParticipant directly.
|-
| delete & destroy
| Removed
| Simplified elsewhere.
|-
| first_member
| Removed
| SRP enforcement.
|-
| submitted_files(path)
| Removed
| File access logic shifted to service.
|-
| import/export methods
| Removed
| Responsibility moved to helpers/services.
|-
| copy(course_id)
| Removed
| Refactored externally.
|-
| hyperlinks
| Removed
| Delegated to service.
|-
| submit_hyperlink(hyperlink)
| Modified (Delegated)
| Handled by TeamFileService.
|-
| remove_hyperlink(hyperlink)
| Modified (Delegated)
| Handled by TeamFileService.
|-
| files(directory)
| Removed
| File traversal extracted.
|-
| team(participant)
| Removed
| Moved to higher-level service.
|-
| export_fields(options)
| Removed
| Offloaded for SRP.
|-
| remove_team_by_id(id)
| Removed
| Refactored.
|-
| path
| Removed
| File path responsibility shifted.
|-
| set_student_directory_num
| Removed
| Directory numbering moved.
|-
| received_any_peer_review?
| Removed
| Simplified elsewhere.
|-
| most_recent_submission
| Retained (Optimized)
| Improved query efficiency.
|-
| get_logged_in_reviewer_id(current_user_id)
| Removed
| Participant-reviewer handling refactored.
|-
| current_user_is_reviewer?(current_user_id)
| Removed
| Responsibility simplified.
|-
| create_new_team(user_id, signuptopic)
| Modified (Simplified)
| Refactored for better exception handling.
|}

== MentoredTeam.rb ==

{| class="wikitable"
! Method
! Change
! Reason
|-
| add_member(user, _assignment_id = nil)
| Refactored
| Broken into modular private methods for adding users and assigning mentors.
|-
| import_team_members(row_hash)
| Refactored
| Improved to skip blanks, safe user lookup, and error handling.
|-
| can_add_member?(user)
| New
| Private method for team capacity and mentor assignment validation.
|-
| add_team_user(user)
| New
| Cleanly adds a TeamsUser.
|-
| add_participant_to_team(user)
| New
| Adds participant based on assignment.
|-
| assign_mentor_if_needed(_assignment_id)
| New
| Ensures no duplicate mentors are assigned.
|-
| mentor_assignment_valid?(user)
| New
| Validates mentor assignment rules.
|-
| user_not_in_team?(user)
| New
| Checks if user is already part of the team.
|-
| find_or_raise_user(teammate)
| New
| Finds user or raises informative ImportError.
|}

== TeamsParticipants Model ==

{| class="wikitable"
! Aspect
! Change
! Reason
|-
| Association
| New
| Establishes direct link between Participant and Team to maintain integrity.
|-
| team_members
| New
| Retrieves all users associated through participants.
|-
| remove_participant_from_team
| New
| Safely removes participant from team.
|-
| username delegation
| New
| Delegates access to participant's username.
|-
| Integrity
| New
| Ensures only valid assignment participants can join teams.
|-
| Maintainability
| New
| Designed to align with SOLID principles and Rails best practices.
|}

= Testing Plan =
We plan to cover the reimplementation and refactoring of the following:
* AssignmentTeam
* MentoredTeam
* TeamsParticipantsController
* TeamsParticipant model

We use RSpec for model, controller, and request specs. API tests are also included where applicable.
Both positive and negative test cases are included to ensure robust functionality, along with validation checks and authorization verifications.

== AssignmentTeam Model Tests ==
{| class="wikitable"
! # !! Method !! Test Description
|-
| 1 || user_id || Verify that the correct user ID is returned; prioritize current user if available.
|-
| 2 || includes? || Check if a given participant is part of the team.
|-
| 3 || parent_model || Ensure the parent model returns "Assignment".
|-
| 4 || assign_reviewer || Test reviewer assignment creation and error handling when assignment is not found.
|-
| 5 || create_review_map || Confirm a new ReviewResponseMap record is created successfully.
|-
| 6 || reviewed_by? || Verify if a reviewer has reviewed the team; test both true and false scenarios.
|-
| 7 || participants || Ensure the correct participants are retrieved via TeamsParticipant.
|-
| 8 || add_participant || Confirm that a participant is added, and prevent duplicate addition.
|-
| 9 || create_new_team || Ensure that a new team-user linkage, sign-up, and nodes are created properly.
|-
| 10 || submit_hyperlink || Verify delegation to TeamFileService for hyperlink submission.
|-
| 11 || remove_hyperlink || Verify delegation to TeamFileService for hyperlink removal.
|-
| 12 || has_submissions? || Check behavior when team has submissions and when it doesn't.
|-
| 13 || most_recent_submission || Ensure the most recent submission is retrieved based on updated_at.
|}

== MentoredTeam Model Tests ==
{| class="wikitable"
! # !! Method !! Test Description
|-
| 1 || import_team_members || Ensure team members are imported from a list correctly.
|-
| 2 || find_or_raise_user || Test for successful user lookup and error raising if user not found.
|-
| 3 || user_not_in_team? || Confirm whether a user is already in the team or not.
|-
| 4 || mentor_assignment_valid? || Verify that a mentor can be assigned properly and prevent duplicate mentors.
|-
| 5 || add_member || Ensure user is added successfully and prevent re-adding existing team members.
|-
| 6 || can_add_member? || Verify team capacity check before adding a member.
|-
| 7 || add_team_user || Ensure that a TeamsUser is created and linked correctly.
|-
| 8 || add_participant_to_team || Confirm that a participant is correctly linked to the team.
|-
| 9 || assign_mentor_if_needed || Validate that mentor is assigned only when needed (no double assignment).
|}

== TeamsParticipantsController Tests ==
{| class="wikitable"
! # !! Method !! Test Description
|-
| 1 || valid_participant? || Confirm existence check for a participant; return true/false accordingly.
|-
| 2 || update_duties || Test participant duty update flow and ensure a redirect occurs.
|-
| 3 || user_not_found_message || Validate that a proper flash message is returned when a user isn't found.
|-
| 4 || participant_not_found_message || Validate correct error message if participant isn't linked.
|-
| 5 || create || Confirm that creating a TeamsParticipant increases record count.
|-
| 6 || list || Test that the participant list view renders correctly.
|-
| 7 || action_allowed? || Ensure access control is enforced based on user roles (admin/TA/student).
|-
| 8 || delete || Confirm deletion of a TeamsParticipant entry works correctly.
|-
| 9 || auto_complete_for_user_name || Verify that JSON autocomplete results are returned based on user input.
|-
| 10 || new || Test that the new participant view loads successfully.
|-
| 11 || delete_selected || Ensure multiple TeamsParticipant records can be deleted at once.
|}

== TeamsParticipant Model Tests ==
{| class="wikitable"
! # !! Method !! Test Description
|-
| 1 || Associations || Ensure that a TeamsParticipant correctly belongs to a team and participant.
|-
| 2 || Validations || Confirm presence validations on team and participant relationships.
|-
| 3 || team_members || Validate fetching all team members given a team ID.
|-
| 4 || participant? || Verify participant existence check for a given user; test positive and negative cases.
|}

== TeamsParticipants API (Request Specs) ==
{| class="wikitable"
! # !! Endpoint !! Test Description
|-
| 1 || POST /teams_participants || Ensure a participant is added via API and redirects successfully.
|-
| 2 || DELETE /teams_participants/:id || Ensure a participant is deleted via API and redirects successfully.
|}

===Mentor===
* Vihar Manojkumar Shah([mailto:vshah23@ncsu.edu vshah23@ncsu.edu])

===Team Members===

* Manav Kamdar ([mailto:mkamdar@ncsu.edu mkamdar@ncsu.edu])
* Aditya Singh ([mailto:asingh78@ncsu.edu asingh78@ncsu.edu])
* Shivang Patel ([mailto:spatel74@ncsu.edu spatel74@ncsu.edu])

CSC/ECE 517 Spring 2025

2025-04-07T22:14:45Z

Asingh78:

* [[CSC/ECE 517 Spring 2025 - E2503. Refactor the Team hierarchy]]
* [[CSC/ECE 517 Spring 2025 - E2504. Mentor-meeting management]]
* [[CSC/ECE 517 Spring 2025 - E2505. Testing Answer Tagging]]
* [[CSC/ECE 517 Spring 2025 - E2508. Reimplement bidding-algorithm web service]]
* [[CSC/ECE 517 Spring 2025 - E2509. Reimplement feedback_response_map.rb]]
* [[CSC/ECE 517 Spring 2025 - E2519. Implement view for results of bidding]]
* [[CSC/ECE 517 Spring 2025 - E2522. Enhancing UI Consistency in Expertiza 1]]
* [[CSC/ECE 517 Spring 2025 - E2520. Reimplement heatgrid UI for reviews]]
* [[CSC/ECE 517 Spring 2025 - E2517. Reimplement internationalization (frontend + backend)]]
* [[CSC/ECE 517 Spring 2025 - E2523: Enhancing UI Consistency in Expertiza 2]]
* [[CSC/ECE 517 Spring 2025 - E2515: Reimplement student_teams_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2501: Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2025 - E2502: Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2512. Reimplement responses controller]]
* [[CSC/ECE 517 Spring 2025 - E2510. Reimplement grades_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records]]
* [[CSC/ECE 517 Spring 2025 - E2514. Reimplement student_quizzes_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2518. Reimplement password resets (frontend + backend)]]
* [[CSC/ECE 517 Spring 2025 - E2516. Reimplement teams_users_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2511. Reimplement participants_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2521. UI for View submissions/assign grades (except heatgrid)]]
* [[CSC/ECE 517 Spring 2025 - E2513. Reimplement sign_up_topic.rb as project_topic.rb]]
* [[CSC/ECE 517 Spring 2025 - E2506. Implement testing for new Bookmarks Controller]]
* [[CSC/ECE 517 Spring 2025 - E2527. Mentor-meeting management: assignments with topics]]

== Final Projects ==
* [[CSC/ECE 517 Spring 2025 - E2509 Refactoring and Enhancing the Feedback Response Map Controller]]
* [[CSC/ECE 517 Spring 2025 - E2539 Reimplement Student Task View (Frontend + Backend)]]
* [[CSC/ECE 517 Spring 2025 - E2521 UI for View submissions/assign grades (except heatgrid)]]
* [[CSC/ECE 517 Spring 2025 - E2524 Reimplement student review controller]]
* [[CSC/ECE 517 Spring 2025 - E2525 Reimplement review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2526 Reimplement Teams and Participant hierarchies]]
* [[CSC/ECE 517 Spring 2025 - E2530 Reimplement Grades Controller (Frontend + Backend)]]
* [[CSC/ECE 517 Spring 2025 - E2538 Reimplementing Questionnaire Page in Expertiza]]
* [[CSC/ECE 517 Spring 2025 - E2534 UI for Assign Reviewers]]
* [[CSC/ECE 517 Spring 2025 - E2540 Integration of Assignment participant Frontend with participant controller Backend]]
* [[CSC/ECE 517 Spring 2025 - E2532. Reimplement Missing ResponseMap Subclasses]]
* [[CSC/ECE 517 Spring 2025 - E2542. Refactor review_bids_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy]]
* [[CSC/ECE 517 Spring 2025 - E2531 Refactor participants_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2528 Testing for Survey Deployment]]
* [[CSC/ECE 517 Spring 2025 - E2514. Reimplement student_quizzes_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2516. Reimplement teams_users_controller.rb]]

CSC/ECE 517 Spring 2025

2025-03-25T03:27:35Z

Asingh78:

* [[CSC/ECE 517 Spring 2025 - E2504. Mentor-meeting management]]
* [[CSC/ECE 517 Spring 2025 - E2505. Testing Answer Tagging]]
* [[CSC/ECE 517 Spring 2025 - E2508. Reimplement bidding-algorithm web service]]
* [[CSC/ECE 517 Spring 2025 - E2509. Reimplement feedback_response_map.rb]]
* [[CSC/ECE 517 Spring 2025 - E2519. Implement view for results of bidding]]
* [[CSC/ECE 517 Spring 2025 - E2522. Enhancing UI Consistency in Expertiza 1]]
* [[CSC/ECE 517 Spring 2025 - E2520. Reimplement heatgrid UI for reviews]]
* [[CSC/ECE 517 Spring 2025 - E2517. Reimplement internationalization (frontend + backend)]]
* [[CSC/ECE 517 Spring 2025 - E2523: Enhancing UI Consistency in Expertiza 2]]
* [[CSC/ECE 517 Spring 2025 - E2515: Reimplement student_teams_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2501: Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2025 - E2502: Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2512. Reimplement responses controller]]
* [[CSC/ECE 517 Spring 2025 - E2510. Reimplement grades_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2507. Reimplement back end for submission records]]
* [[CSC/ECE 517 Spring 2025 - E2514. Reimplement student_quizzes_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2518. Reimplement password resets (frontend + backend)]]
* [[CSC/ECE 517 Spring 2025 - E2516. Reimplement teams_users_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2511. Reimplement participants_controller.rb]]
* [[CSC/ECE 517 Spring 2025 - E2521. UI for View submissions/assign grades (except heatgrid)]]
* [[CSC/ECE 517 Spring 2025 - E2513. Reimplement sign_up_topic.rb as project_topic.rb]]
* [[CSC/ECE 517 Spring 2025 - E2506. Implement testing for new Bookmarks Controller]]

CSC/ECE 517 Spring 2025 - E2516. Reimplement teams users controller.rb

2025-03-25T00:48:48Z

Asingh78:

==E2516: Reimplement teams_users_controller.rb==

===Introduction===
Expertiza is an open-source project implementation for an educational platform. It hosts a lot of functionalities: the professor can create assignments for the students; the students can submit their assignments supported across multiple file formats and also review assignments uploaded by other students; the students can form team and work together for an assignment or a project. This platform provides synchronicity to the professor as well as students to effectively manage their work.

===Project Overview===
Through this project, we have reimplement a controller component, namely, teams_users_controller. The entire component is shifted to another controller, namely teams_participants_controller. It now achieves below mentioned functionalities:

* The code change now follows the SOLID and DRY principles
* All associations and references between participants and assignments and courses have been modified
* Clear distinction between "general user" and "assignment participant"
* Improved code readability by integrating helper methods

===Files Modified===
The following files have been modified to achieve the mentioned functionalities:
* TeamsParticipantsController
* AssignmentTeam
* MentoredTeam
* TeamsParticipant

===TeamsParticipantsController===
The changes made in this controller included refactoring the TeamsUsersController to TeamsParticipantsController. This name change reflects a very important feature that needs to be implemented:
A participant is compulsorily to be assigned a course or an assignment whereas a user is general purpose member who uses the expertiza platform. Helper methods and various other methods have been modified in this controller file. One other association that is also implemented simultaneously is that a participant is to be assigned only and only one team unless the participant is a mentor.

def valid_participant?(user, assignment_or_course)
if assignment_or_course.user_on_team?(user)
flash[:error] = "This user is already assigned to a team for this #{assignment_or_course.class.name.downcase}."
return false
end
participant = assignment_or_course.participants.find_by(user_id: user.id)
unless participant
flash[:error] = participant_not_found_message(user.name, assignment_or_course)
return false
end
true
end

Above method in the controller file implements this functionality where it checks whether a participant is assigned a team or not. If the participant is already assigned a team, it throws an error that the participant is already assigned a team. If not, it finds the participant id and accordingly assigns a team.

===AssignmentTeam===
The AssignmentTeam class is inherited from the Team class to include all functionalities present in the Team class. The primary purpose of this model is to depict the team members present for a given assignment or course. A lot of things could be achieved by having such a model and necessary methods have been devised to achieve them. Firstly, association rules have been established where each team can be assigned to multiple reviewers and can have multiple review responses. It defines rules for returning participants of a team, whether a participant is part of a team, assigning a reviewer to a team, drafting the review map when a reviewer reviews the work of the team, detailing participants of a team and if necessary, adding participants to a team, creating a new team and assigning a topic to the team, and lastly adding or modifying or deleting a hyperlink which represents the link to the work done by a particular team.

belongs_to :assignment, class_name: 'Assignment', foreign_key: 'parent_id'
has_many :review_mappings, class_name: 'ReviewResponseMap', foreign_key: 'reviewee_id'
has_many :review_response_maps, foreign_key: 'reviewee_id'
has_many :responses, through: :review_response_maps, foreign_key: 'map_id'

===MentoredTeam===
The MentoredTeam class is inherited from the AssignmentTeam class. The purpose of this class is to validating a team in regards to participants already present and adding a mentor to the team compulsorily and that too only once. One other feature achieved through this model is to automate the task of creating teams by importing the team member data from a csv file and validating at the same time whether a user can be added to the team based on the capacity of the team and whether the user exists or not. One other feature achieved through this is that of logging every action performed from above description.

===TeamsParticipant===
The TeamsParticipant class is inherited from the ApplicationRecord class meaning that it is an active record model. This model manages the association between the participant and the teams including adding, removing and fetching participants from the team. It establishes relationships which state that each team can have many participants and one participant can have only one team.

===Test Cases for AssignmentTeam===
Below are the test cases implemented for the `AssignmentTeam` model:

require 'rails_helper'
RSpec.describe AssignmentTeam, type: :model do
let(:assignment) { create(:assignment) }
let(:team) { create(:assignment_team, assignment: assignment) }
let(:user) { create(:user) }
let(:participant) { create(:participant, user: user, assignment: assignment) }
let(:reviewer) { create(:participant, assignment: assignment) }
let(:review_response_map) { create(:review_response_map, reviewee: team, reviewer: reviewer) }
describe '#user_id' do
it 'returns the user_id of the first team member' do
team.users << user
expect(team.user_id).to eq(user.id)
end
it 'returns current_user.id if they are in the team' do
team.users << user
expect(team.user_id(user)).to eq(user.id)
end
end
describe '#includes?' do
it 'returns true if a participant is in the team' do
allow(team).to receive(:participants).and_return([participant])
expect(team.includes?(participant)).to be true
end
it 'returns false if a participant is not in the team' do
allow(team).to receive(:participants).and_return([])
expect(team.includes?(participant)).to be false
end
end
describe '#parent_model' do
it 'returns "Assignment"' do
expect(team.parent_model).to eq('Assignment')
end
end
describe '#assign_reviewer' do
it 'raises an error if the assignment is not found' do
allow(Assignment).to receive(:find_by).and_return(nil)
expect { team.assign_reviewer(reviewer) }.to raise_error('The assignment cannot be found.')
end
it 'creates a review map for the reviewer' do
expect { team.assign_reviewer(reviewer) }.to change { ReviewResponseMap.count }.by(1)
end
end
describe '#create_review_map' do
it 'creates a new ReviewResponseMap' do
expect {
team.create_review_map(reviewer, assignment)
}.to change { ReviewResponseMap.count }.by(1)
end
end
describe '#reviewed_by?' do
it 'returns true if the team has been reviewed by the given reviewer' do
review_response_map
expect(team.reviewed_by?(reviewer)).to be true
end
it 'returns false if the team has not been reviewed by the given reviewer' do
expect(team.reviewed_by?(reviewer)).to be false
end
end
describe '#participants' do
it 'returns the participants of the team' do
allow(TeamsParticipant).to receive(:team_members).with(team.id).and_return([participant])
expect(team.participants).to include(participant)
end
end
describe '#add_participant' do
it 'adds a participant to the team' do
expect {
team.add_participant(assignment.id, user)
}.to change { TeamsParticipant.count }.by(1)
end
it 'does not add a participant if they are already in the team' do
team.add_participant(assignment.id, user)
expect {
team.add_participant(assignment.id, user)
}.not_to change { TeamsParticipant.count }
end
end
describe '#create_new_team' do
let(:signuptopic) { create(:sign_up_topic, assignment: assignment) }
it 'creates a new team user and associates topic' do
expect {
team.create_new_team(user.id, signuptopic)
}.to change { TeamsUser.count }.by(1)
.and change { SignedUpTeam.count }.by(1)
.and change { TeamNode.count }.by(1)
.and change { TeamUserNode.count }.by(1)
end
end
describe '#submit_hyperlink' do
it 'calls TeamFileService.submit_hyperlink' do
expect(TeamFileService).to receive(:submit_hyperlink).with(team, 'http://example.com')
team.submit_hyperlink('http://example.com')
end
end
describe '#remove_hyperlink' do
it 'calls TeamFileService.remove_hyperlink' do
expect(TeamFileService).to receive(:remove_hyperlink).with(team, 'http://example.com')
team.remove_hyperlink('http://example.com')
end
end
describe '#has_submissions?' do
it 'returns true if the team has submissions' do
allow(team).to receive(:submitted_files).and_return(['file1'])
allow(team).to receive(:submitted_hyperlinks).and_return(nil)
expect(team.has_submissions?).to be true
end
it 'returns false if the team has no submissions' do
allow(team).to receive(:submitted_files).and_return([])
allow(team).to receive(:submitted_hyperlinks).and_return(nil)
expect(team.has_submissions?).to be false
end
end
describe '#most_recent_submission' do
it 'returns the latest submission' do
submission1 = create(:submission_record, team: team, assignment: assignment, updated_at: 1.day.ago)
submission2 = create(:submission_record, team: team, assignment: assignment, updated_at: Time.current)
expect(team.most_recent_submission).to eq(submission2)
end
end
end

===Test Cases for MentoredTeam===
Below are the test cases implemented for the `MentoredTeam` model:

require 'rails_helper'
RSpec.describe MentoredTeam, type: :model do
let(:team) { create(:mentored_team) }
let(:user) { create(:user) }
let(:mentor) { create(:user, role: :mentor) }
describe '#import_team_members' do
it 'imports members successfully from a given list' do
members = [create(:user), create(:user)]
expect { team.import_team_members(members) }.to change { team.users.count }.by(2)
end
end
describe '#find_or_raise_user' do
it 'returns the user if found' do
expect(team.find_or_raise_user(user.id)).to eq(user)
end
it 'raises an error if the user is not found' do
expect { team.find_or_raise_user(999) }.to raise_error(ActiveRecord::RecordNotFound)
end
end
describe '#user_not_in_team?' do
it 'returns true if user is not in the team' do
expect(team.user_not_in_team?(user)).to be true
end
it 'returns false if user is in the team' do
team.users << user
expect(team.user_not_in_team?(user)).to be false
end
end
describe '#mentor_assignment_valid?' do
it 'returns true if a mentor can be assigned' do
expect(team.mentor_assignment_valid?(mentor)).to be true
end
it 'returns false if an invalid mentor is assigned' do
expect(team.mentor_assignment_valid?(user)).to be false
end
end
describe '#add_member' do
it 'adds a user to the team' do
expect { team.add_member(user) }.to change { team.users.count }.by(1)
end
it 'does not add a user who is already in the team' do
team.users << user
expect { team.add_member(user) }.not_to change { team.users.count }
end
end
describe '#can_add_member?' do
it 'returns true if the team can add a member' do
expect(team.can_add_member?).to be true
end
it 'returns false if the team has reached its limit' do
allow(team).to receive(:users).and_return(Array.new(10) { create(:user) })
expect(team.can_add_member?).to be false
end
end
describe '#add_team_user' do
it 'adds a user to the team successfully' do
expect { team.add_team_user(user) }.to change { team.users.count }.by(1)
end
end
describe '#add_participant_to_team' do
it 'adds a participant to the team' do
participant = create(:participant)
expect { team.add_participant_to_team(participant) }.to change { team.users.count }.by(1)
end
end
describe '#assign_mentor_if_needed' do
it 'assigns a mentor if no mentor is present' do
team.assign_mentor_if_needed(mentor)
expect(team.mentor).to eq(mentor)
end
it 'does not assign a mentor if one is already assigned' do
existing_mentor = create(:user, role: :mentor)
team.mentor = existing_mentor
team.assign_mentor_if_needed(mentor)
expect(team.mentor).to eq(existing_mentor)
end
end
end

===Mentor===
* Vihar Manojkumar Shah([mailto:vshah23@ncsu.edu vshah23@ncsu.edu])

===Team Members===

* Manav Kamdar ([mailto:mkamdar@ncsu.edu mkamdar@ncsu.edu])
* Aditya Singh ([mailto:asingh78@ncsu.edu asingh78@ncsu.edu])
* Shivang Patel ([mailto:spatel74@ncsu.edu spatel74@ncsu.edu])

CSC/ECE 517 Spring 2025 - E2516. Reimplement teams users controller.rb

2025-03-25T00:44:49Z

Asingh78:

==E2516: Reimplement teams_users_controller.rb==

===Introduction===
Expertiza is an open-source project implementation for an educational platform. It hosts a lot of functionalities: the professor can create assignments for the students; the students can submit their assignments supported across multiple file formats and also review assignments uploaded by other students; the students can form team and work together for an assignment or a project. This platform provides synchronicity to the professor as well as students to effectively manage their work.

===Project Overview===
Through this project, we have reimplement a controller component, namely, teams_users_controller. The entire component is shifted to another controller, namely teams_participants_controller. It now achieves below mentioned functionalities:

* The code change now follows the SOLID and DRY principles
* All associations and references between participants and assignments and courses have been modified
* Clear distinction between "general user" and "assignment participant"
* Improved code readability by integrating helper methods

===Files Modified===
The following files have been modified to achieve the mentioned functionalities:
* TeamsParticipantsController
* AssignmentTeam
* MentoredTeam
* TeamsParticipant

===TeamsParticipantsController===
The changes made in this controller included refactoring the TeamsUsersController to TeamsParticipantsController. This name change reflects a very important feature that needs to be implemented:
A participant is compulsorily to be assigned a course or an assignment whereas a user is general purpose member who uses the expertiza platform. Helper methods and various other methods have been modified in this controller file. One other association that is also implemented simultaneously is that a participant is to be assigned only and only one team unless the participant is a mentor.

def valid_participant?(user, assignment_or_course)
if assignment_or_course.user_on_team?(user)
flash[:error] = "This user is already assigned to a team for this #{assignment_or_course.class.name.downcase}."
return false
end
participant = assignment_or_course.participants.find_by(user_id: user.id)
unless participant
flash[:error] = participant_not_found_message(user.name, assignment_or_course)
return false
end
true
end

Above method in the controller file implements this functionality where it checks whether a participant is assigned a team or not. If the participant is already assigned a team, it throws an error that the participant is already assigned a team. If not, it finds the participant id and accordingly assigns a team.

===AssignmentTeam===
The AssignmentTeam class is inherited from the Team class to include all functionalities present in the Team class. The primary purpose of this model is to depict the team members present for a given assignment or course. A lot of things could be achieved by having such a model and necessary methods have been devised to achieve them. Firstly, association rules have been established where each team can be assigned to multiple reviewers and can have multiple review responses. It defines rules for returning participants of a team, whether a participant is part of a team, assigning a reviewer to a team, drafting the review map when a reviewer reviews the work of the team, detailing participants of a team and if necessary, adding participants to a team, creating a new team and assigning a topic to the team, and lastly adding or modifying or deleting a hyperlink which represents the link to the work done by a particular team.

belongs_to :assignment, class_name: 'Assignment', foreign_key: 'parent_id'
has_many :review_mappings, class_name: 'ReviewResponseMap', foreign_key: 'reviewee_id'
has_many :review_response_maps, foreign_key: 'reviewee_id'
has_many :responses, through: :review_response_maps, foreign_key: 'map_id'

===MentoredTeam===
The MentoredTeam class is inherited from the AssignmentTeam class. The purpose of this class is to validating a team in regards to participants already present and adding a mentor to the team compulsorily and that too only once. One other feature achieved through this model is to automate the task of creating teams by importing the team member data from a csv file and validating at the same time whether a user can be added to the team based on the capacity of the team and whether the user exists or not. One other feature achieved through this is that of logging every action performed from above description.

===TeamsParticipant===
The TeamsParticipant class is inherited from the ApplicationRecord class meaning that it is an active record model. This model manages the association between the participant and the teams including adding, removing and fetching participants from the team. It establishes relationships which state that each team can have many participants and one participant can have only one team.

===Test Cases for AssignmentTeam===
Below are the test cases implemented for the `AssignmentTeam` model:

require 'rails_helper'
RSpec.describe AssignmentTeam, type: :model do
let(:assignment) { create(:assignment) }
let(:team) { create(:assignment_team, parent_id: assignment.id) }
let(:user) { create(:user) }
describe '#add_participant' do
context 'when participant is not in the team' do
it 'adds the participant successfully' do
expect(team.add_participant(assignment.id, user)).to be_truthy
expect(AssignmentParticipant.exists?(parent_id: assignment.id, user_id: user.id)).to be true
end
end
context 'when participant already exists' do
it 'does not create a duplicate' do
team.add_participant(assignment.id, user)
expect { team.add_participant(assignment.id, user) }.not_to change(AssignmentParticipant, :count)
end
end
end
end

===Test Cases for MentoredTeam===
Below are the test cases implemented for the `MentoredTeam` model:

require 'rails_helper'
RSpec.describe MentoredTeam, type: :model do
let(:team) { create(:mentored_team) }
let(:user) { create(:user) }
let(:mentor) { create(:user, role: :mentor) }
describe '#import_team_members' do
it 'imports members successfully from a given list' do
members = [create(:user), create(:user)]
expect { team.import_team_members(members) }.to change { team.users.count }.by(2)
end
end
describe '#find_or_raise_user' do
it 'returns the user if found' do
expect(team.find_or_raise_user(user.id)).to eq(user)
end
it 'raises an error if the user is not found' do
expect { team.find_or_raise_user(999) }.to raise_error(ActiveRecord::RecordNotFound)
end
end
describe '#user_not_in_team?' do
it 'returns true if user is not in the team' do
expect(team.user_not_in_team?(user)).to be true
end
it 'returns false if user is in the team' do
team.users << user
expect(team.user_not_in_team?(user)).to be false
end
end
describe '#mentor_assignment_valid?' do
it 'returns true if a mentor can be assigned' do
expect(team.mentor_assignment_valid?(mentor)).to be true
end
it 'returns false if an invalid mentor is assigned' do
expect(team.mentor_assignment_valid?(user)).to be false
end
end
describe '#add_member' do
it 'adds a user to the team' do
expect { team.add_member(user) }.to change { team.users.count }.by(1)
end
it 'does not add a user who is already in the team' do
team.users << user
expect { team.add_member(user) }.not_to change { team.users.count }
end
end
describe '#can_add_member?' do
it 'returns true if the team can add a member' do
expect(team.can_add_member?).to be true
end
it 'returns false if the team has reached its limit' do
allow(team).to receive(:users).and_return(Array.new(10) { create(:user) })
expect(team.can_add_member?).to be false
end
end
describe '#add_team_user' do
it 'adds a user to the team successfully' do
expect { team.add_team_user(user) }.to change { team.users.count }.by(1)
end
end
describe '#add_participant_to_team' do
it 'adds a participant to the team' do
participant = create(:participant)
expect { team.add_participant_to_team(participant) }.to change { team.users.count }.by(1)
end
end
describe '#assign_mentor_if_needed' do
it 'assigns a mentor if no mentor is present' do
team.assign_mentor_if_needed(mentor)
expect(team.mentor).to eq(mentor)
end
it 'does not assign a mentor if one is already assigned' do
existing_mentor = create(:user, role: :mentor)
team.mentor = existing_mentor
team.assign_mentor_if_needed(mentor)
expect(team.mentor).to eq(existing_mentor)
end
end
end

===Mentor===
* Vihar Manojkumar Shah([mailto:vshah23@ncsu.edu vshah23@ncsu.edu])

===Team Members===

* Manav Kamdar ([mailto:mkamdar@ncsu.edu mkamdar@ncsu.edu])
* Aditya Singh ([mailto:asingh78@ncsu.edu asingh78@ncsu.edu])
* Shivang Patel ([mailto:spatel74@ncsu.edu spatel74@ncsu.edu])