Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-23T03:49:36Z

Uraycha: /* TeamsController */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation ==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''

* '''Teams:'''
** '''index:''' Fetches all teams and renders them.
** '''show:''' Retrieves and displays a team’s details.
** '''create:''' Persists a new team record.
:[[File:E2533 teams controller crud team.png]]

* '''validate_team_type:''' Validates the team type before team creation to ensure it's among allowed types.
:[[File:E2533 teams controller validate team type.png]]

* '''Team members:'''
** '''members:''' Lists all members of a specific team
** '''add_member:''' Prepares data for adding a new team or adding members to an existing team.
** '''remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
:[[File:E2533 teams controller members.png]]

* '''Join requests:'''
** '''create_join_request:''' Creates a new join request for a team.
** '''join_requests:''' Lists all join requests for the team.
** '''update_join_request:''' Updates the status or details of a specific join request
:[[File:E2533 teams controller join requests.png]]

=== TeamOperationsHelper ===
'''Purpose:'''
TeamOperationsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

[[File:E2533 team helper2.png]]

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''full?:''' Checks if team if full and returns a boolean.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.
* '''member?:''' Checks if a user is a member of the team.
* '''team_size:''' Returns the current count of team members.
* '''validate_membership:''' To be used by the subclasses.

[[File:E2533 team model2.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''copy_to_course_team(course):''' Copies details if the assignment team to a course team. Includes team name, team members and team size.
* '''validate_membership:''' Checks if user is enrolled in the assignment.
* '''type_must_be_assignment_or_mentored_team:''' Checks if the team type is either assignment team or mentored team.

[[File:E2533 assignment team model2.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===
'''Inherits From:''' Team

'''Purpose:'''
CourseTeam is designed for teams that persist across an entire course. It validates the course membership of a user.

'''Additions:'''
* '''add_member(user):''' Ensures the user is eligible for the course team before joining.
* '''copy_to_assignment_team:''' Copies the details of a course team, consisting of team name, team size and team members to a new assignment team.
* '''validate_membership:''' Checks if user is enrolled in any assignment in the course.
* '''type_must_be_course_team:''' Checks if the team type is 'CourseTeam'

[[File:E2533 course team model2.png]]

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

''' Additions:'''
* '''add_member(user):''' Ensures the user being added to the team is not already a mentor.
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., mentor role).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_must_have_mentor_role:''' Ensures that the chosen mentor is valid for the assignment and has the role 'mentor'.

[[File:E2533 mentored team model2.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment'''
'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 2participant model.png]]

== Testing Plan ==

Implemented RSpec tests to validate all team-related operations. Positive and negative test cases have been covered through these test cases.

To successfully run the test cases, we would need to bypass the authentication controller, otherwise we will end up getting a 404 Unauthorized Error!

* Command to run tests for TeamsController:

:<code> bundle exec rspec ./spec/requests/api/v1/teams_spec.rb </code>

: RSpec output:

:[[File:E2533-TeamsController-RSpec.jpg]]

* Command to run tests for AssignmentTeam model:

:<code>bundle exec rspec spec/models/assignment_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-AssignmentTeam-RSpec.jpg]] 

* Command to run tests for CourseTeam model:

:<code>bundle exec rspec spec/models/course_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-course-team-rspec.jpg]]

* Command to run tests for MentoredTeam model:

:<code>bundle exec rspec spec/models/mentored_team_spec.rb</code>

: RSpec output:

:[[File:E2533-MentoredTeam-RSpec.jpg]]

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==
Repository: https://github.com/valorant-dhruv/reimplementation-back-end 
Pull request: https://github.com/expertiza/reimplementation-back-end/pull/193 
Demo Video: https://youtu.be/gKZXYk8HNWc

File:E2533 teams controller crud team.png

2025-04-23T03:48:51Z

Uraycha:

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-23T03:46:14Z

Uraycha: /* TeamsHelper */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation ==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''

* '''show:''' Retrieves and displays a team’s details.
:[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
:[[File:E2533 teams controller create team.png]]
* '''validate_team_type:''' Validates the team type before team creation to ensure it's among allowed types.
:[[File:E2533 teams controller validate team type.png]]

* '''Team members:'''
** '''members:''' Lists all members of a specific team
** '''add_member:''' Prepares data for adding a new team or adding members to an existing team.
** '''remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
:[[File:E2533 teams controller members.png]]

* '''Join requests:'''
** '''create_join_request:''' Creates a new join request for a team.
** '''join_requests:''' Lists all join requests for the team.
** '''update_join_request:''' Updates the status or details of a specific join request
:[[File:E2533 teams controller join requests.png]]

=== TeamOperationsHelper ===
'''Purpose:'''
TeamOperationsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

[[File:E2533 team helper2.png]]

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''full?:''' Checks if team if full and returns a boolean.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.
* '''member?:''' Checks if a user is a member of the team.
* '''team_size:''' Returns the current count of team members.
* '''validate_membership:''' To be used by the subclasses.

[[File:E2533 team model2.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''copy_to_course_team(course):''' Copies details if the assignment team to a course team. Includes team name, team members and team size.
* '''validate_membership:''' Checks if user is enrolled in the assignment.
* '''type_must_be_assignment_or_mentored_team:''' Checks if the team type is either assignment team or mentored team.

[[File:E2533 assignment team model2.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===
'''Inherits From:''' Team

'''Purpose:'''
CourseTeam is designed for teams that persist across an entire course. It validates the course membership of a user.

'''Additions:'''
* '''add_member(user):''' Ensures the user is eligible for the course team before joining.
* '''copy_to_assignment_team:''' Copies the details of a course team, consisting of team name, team size and team members to a new assignment team.
* '''validate_membership:''' Checks if user is enrolled in any assignment in the course.
* '''type_must_be_course_team:''' Checks if the team type is 'CourseTeam'

[[File:E2533 course team model2.png]]

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

''' Additions:'''
* '''add_member(user):''' Ensures the user being added to the team is not already a mentor.
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., mentor role).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_must_have_mentor_role:''' Ensures that the chosen mentor is valid for the assignment and has the role 'mentor'.

[[File:E2533 mentored team model2.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment'''
'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 2participant model.png]]

== Testing Plan ==

Implemented RSpec tests to validate all team-related operations. Positive and negative test cases have been covered through these test cases.

To successfully run the test cases, we would need to bypass the authentication controller, otherwise we will end up getting a 404 Unauthorized Error!

* Command to run tests for TeamsController:

:<code> bundle exec rspec ./spec/requests/api/v1/teams_spec.rb </code>

: RSpec output:

:[[File:E2533-TeamsController-RSpec.jpg]]

* Command to run tests for AssignmentTeam model:

:<code>bundle exec rspec spec/models/assignment_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-AssignmentTeam-RSpec.jpg]] 

* Command to run tests for CourseTeam model:

:<code>bundle exec rspec spec/models/course_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-course-team-rspec.jpg]]

* Command to run tests for MentoredTeam model:

:<code>bundle exec rspec spec/models/mentored_team_spec.rb</code>

: RSpec output:

:[[File:E2533-MentoredTeam-RSpec.jpg]]

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==
Repository: https://github.com/valorant-dhruv/reimplementation-back-end 
Pull request: https://github.com/expertiza/reimplementation-back-end/pull/193 
Demo Video: https://youtu.be/gKZXYk8HNWc

File:E2533 team helper2.png

2025-04-23T03:45:15Z

Uraycha:

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-23T03:43:35Z

Uraycha: /* Team */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation ==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''

* '''show:''' Retrieves and displays a team’s details.
:[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
:[[File:E2533 teams controller create team.png]]
* '''validate_team_type:''' Validates the team type before team creation to ensure it's among allowed types.
:[[File:E2533 teams controller validate team type.png]]

* '''Team members:'''
** '''members:''' Lists all members of a specific team
** '''add_member:''' Prepares data for adding a new team or adding members to an existing team.
** '''remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
:[[File:E2533 teams controller members.png]]

* '''Join requests:'''
** '''create_join_request:''' Creates a new join request for a team.
** '''join_requests:''' Lists all join requests for the team.
** '''update_join_request:''' Updates the status or details of a specific join request
:[[File:E2533 teams controller join requests.png]]

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

[[File:E2533 team helper.png]]

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''full?:''' Checks if team if full and returns a boolean.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.
* '''member?:''' Checks if a user is a member of the team.
* '''team_size:''' Returns the current count of team members.
* '''validate_membership:''' To be used by the subclasses.

[[File:E2533 team model2.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''copy_to_course_team(course):''' Copies details if the assignment team to a course team. Includes team name, team members and team size.
* '''validate_membership:''' Checks if user is enrolled in the assignment.
* '''type_must_be_assignment_or_mentored_team:''' Checks if the team type is either assignment team or mentored team.

[[File:E2533 assignment team model2.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===
'''Inherits From:''' Team

'''Purpose:'''
CourseTeam is designed for teams that persist across an entire course. It validates the course membership of a user.

'''Additions:'''
* '''add_member(user):''' Ensures the user is eligible for the course team before joining.
* '''copy_to_assignment_team:''' Copies the details of a course team, consisting of team name, team size and team members to a new assignment team.
* '''validate_membership:''' Checks if user is enrolled in any assignment in the course.
* '''type_must_be_course_team:''' Checks if the team type is 'CourseTeam'

[[File:E2533 course team model2.png]]

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

''' Additions:'''
* '''add_member(user):''' Ensures the user being added to the team is not already a mentor.
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., mentor role).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_must_have_mentor_role:''' Ensures that the chosen mentor is valid for the assignment and has the role 'mentor'.

[[File:E2533 mentored team model2.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment'''
'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 2participant model.png]]

== Testing Plan ==

Implemented RSpec tests to validate all team-related operations. Positive and negative test cases have been covered through these test cases.

To successfully run the test cases, we would need to bypass the authentication controller, otherwise we will end up getting a 404 Unauthorized Error!

* Command to run tests for TeamsController:

:<code> bundle exec rspec ./spec/requests/api/v1/teams_spec.rb </code>

: RSpec output:

:[[File:E2533-TeamsController-RSpec.jpg]]

* Command to run tests for AssignmentTeam model:

:<code>bundle exec rspec spec/models/assignment_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-AssignmentTeam-RSpec.jpg]] 

* Command to run tests for CourseTeam model:

:<code>bundle exec rspec spec/models/course_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-course-team-rspec.jpg]]

* Command to run tests for MentoredTeam model:

:<code>bundle exec rspec spec/models/mentored_team_spec.rb</code>

: RSpec output:

:[[File:E2533-MentoredTeam-RSpec.jpg]]

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==
Repository: https://github.com/valorant-dhruv/reimplementation-back-end 
Pull request: https://github.com/expertiza/reimplementation-back-end/pull/193 
Demo Video: https://youtu.be/gKZXYk8HNWc

File:E2533 team model2.png

2025-04-23T03:40:02Z

Uraycha:

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-23T03:38:43Z

Uraycha: /* AssignmentTeam */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation ==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''

* '''show:''' Retrieves and displays a team’s details.
:[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
:[[File:E2533 teams controller create team.png]]
* '''validate_team_type:''' Validates the team type before team creation to ensure it's among allowed types.
:[[File:E2533 teams controller validate team type.png]]

* '''Team members:'''
** '''members:''' Lists all members of a specific team
** '''add_member:''' Prepares data for adding a new team or adding members to an existing team.
** '''remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
:[[File:E2533 teams controller members.png]]

* '''Join requests:'''
** '''create_join_request:''' Creates a new join request for a team.
** '''join_requests:''' Lists all join requests for the team.
** '''update_join_request:''' Updates the status or details of a specific join request
:[[File:E2533 teams controller join requests.png]]

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

[[File:E2533 team helper.png]]

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

[[File:E2533 team model.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''copy_to_course_team(course):''' Copies details if the assignment team to a course team. Includes team name, team members and team size.
* '''validate_membership:''' Checks if user is enrolled in the assignment.
* '''type_must_be_assignment_or_mentored_team:''' Checks if the team type is either assignment team or mentored team.

[[File:E2533 assignment team model2.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===
'''Inherits From:''' Team

'''Purpose:'''
CourseTeam is designed for teams that persist across an entire course. It validates the course membership of a user.

'''Additions:'''
* '''add_member(user):''' Ensures the user is eligible for the course team before joining.
* '''copy_to_assignment_team:''' Copies the details of a course team, consisting of team name, team size and team members to a new assignment team.
* '''validate_membership:''' Checks if user is enrolled in any assignment in the course.
* '''type_must_be_course_team:''' Checks if the team type is 'CourseTeam'

[[File:E2533 course team model2.png]]

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

''' Additions:'''
* '''add_member(user):''' Ensures the user being added to the team is not already a mentor.
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., mentor role).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_must_have_mentor_role:''' Ensures that the chosen mentor is valid for the assignment and has the role 'mentor'.

[[File:E2533 mentored team model2.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment'''
'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 2participant model.png]]

== Testing Plan ==

Implemented RSpec tests to validate all team-related operations. Positive and negative test cases have been covered through these test cases.

To successfully run the test cases, we would need to bypass the authentication controller, otherwise we will end up getting a 404 Unauthorized Error!

* Command to run tests for TeamsController:

:<code> bundle exec rspec ./spec/requests/api/v1/teams_spec.rb </code>

: RSpec output:

:[[File:E2533-TeamsController-RSpec.jpg]]

* Command to run tests for AssignmentTeam model:

:<code>bundle exec rspec spec/models/assignment_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-AssignmentTeam-RSpec.jpg]] 

* Command to run tests for CourseTeam model:

:<code>bundle exec rspec spec/models/course_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-course-team-rspec.jpg]]

* Command to run tests for MentoredTeam model:

:<code>bundle exec rspec spec/models/mentored_team_spec.rb</code>

: RSpec output:

:[[File:E2533-MentoredTeam-RSpec.jpg]]

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==
Repository: https://github.com/valorant-dhruv/reimplementation-back-end 
Pull request: https://github.com/expertiza/reimplementation-back-end/pull/193 
Demo Video: https://youtu.be/gKZXYk8HNWc

File:E2533 assignment team model2.png

2025-04-23T03:34:47Z

Uraycha:

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-23T03:33:47Z

Uraycha: /* CourseTeam */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation ==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''

* '''show:''' Retrieves and displays a team’s details.
:[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
:[[File:E2533 teams controller create team.png]]
* '''validate_team_type:''' Validates the team type before team creation to ensure it's among allowed types.
:[[File:E2533 teams controller validate team type.png]]

* '''Team members:'''
** '''members:''' Lists all members of a specific team
** '''add_member:''' Prepares data for adding a new team or adding members to an existing team.
** '''remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
:[[File:E2533 teams controller members.png]]

* '''Join requests:'''
** '''create_join_request:''' Creates a new join request for a team.
** '''join_requests:''' Lists all join requests for the team.
** '''update_join_request:''' Updates the status or details of a specific join request
:[[File:E2533 teams controller join requests.png]]

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

[[File:E2533 team helper.png]]

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

[[File:E2533 team model.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===
'''Inherits From:''' Team

'''Purpose:'''
CourseTeam is designed for teams that persist across an entire course. It validates the course membership of a user.

'''Additions:'''
* '''add_member(user):''' Ensures the user is eligible for the course team before joining.
* '''copy_to_assignment_team:''' Copies the details of a course team, consisting of team name, team size and team members to a new assignment team.
* '''validate_membership:''' Checks if user is enrolled in any assignment in the course.
* '''type_must_be_course_team:''' Checks if the team type is 'CourseTeam'

[[File:E2533 course team model2.png]]

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

''' Additions:'''
* '''add_member(user):''' Ensures the user being added to the team is not already a mentor.
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., mentor role).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_must_have_mentor_role:''' Ensures that the chosen mentor is valid for the assignment and has the role 'mentor'.

[[File:E2533 mentored team model2.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment'''
'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 2participant model.png]]

== Testing Plan ==

Implemented RSpec tests to validate all team-related operations. Positive and negative test cases have been covered through these test cases.

To successfully run the test cases, we would need to bypass the authentication controller, otherwise we will end up getting a 404 Unauthorized Error!

* Command to run tests for TeamsController:

:<code> bundle exec rspec ./spec/requests/api/v1/teams_spec.rb </code>

: RSpec output:

:[[File:E2533-TeamsController-RSpec.jpg]]

* Command to run tests for AssignmentTeam model:

:<code>bundle exec rspec spec/models/assignment_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-AssignmentTeam-RSpec.jpg]] 

* Command to run tests for CourseTeam model:

:<code>bundle exec rspec spec/models/course_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-course-team-rspec.jpg]]

* Command to run tests for MentoredTeam model:

:<code>bundle exec rspec spec/models/mentored_team_spec.rb</code>

: RSpec output:

:[[File:E2533-MentoredTeam-RSpec.jpg]]

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==
Repository: https://github.com/valorant-dhruv/reimplementation-back-end 
Pull request: https://github.com/expertiza/reimplementation-back-end/pull/193 
Demo Video: https://youtu.be/gKZXYk8HNWc

File:E2533 course team model2.png

2025-04-23T03:33:31Z

Uraycha:

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-23T03:32:15Z

Uraycha: /* MentoredTeam */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation ==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''

* '''show:''' Retrieves and displays a team’s details.
:[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
:[[File:E2533 teams controller create team.png]]
* '''validate_team_type:''' Validates the team type before team creation to ensure it's among allowed types.
:[[File:E2533 teams controller validate team type.png]]

* '''Team members:'''
** '''members:''' Lists all members of a specific team
** '''add_member:''' Prepares data for adding a new team or adding members to an existing team.
** '''remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
:[[File:E2533 teams controller members.png]]

* '''Join requests:'''
** '''create_join_request:''' Creates a new join request for a team.
** '''join_requests:''' Lists all join requests for the team.
** '''update_join_request:''' Updates the status or details of a specific join request
:[[File:E2533 teams controller join requests.png]]

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

[[File:E2533 team helper.png]]

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

[[File:E2533 team model.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===
'''Inherits From:''' Team

'''Purpose:'''
CourseTeam is designed for teams that persist across an entire course. It validates the course membership of a user.

'''Additions:'''
* '''add_member(user):''' Ensures the user is eligible for the course team before joining.
* '''copy_to_assignment_team:''' Copies the details of a course team, consisting of team name, team size and team members to a new assignment team.
* '''validate_membership:''' Checks if user is enrolled in any assignment in the course.
* '''type_must_be_course_team:''' Checks if the team type is 'CourseTeam'

[[File:E2533 course team model.png]]

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

''' Additions:'''
* '''add_member(user):''' Ensures the user being added to the team is not already a mentor.
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., mentor role).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_must_have_mentor_role:''' Ensures that the chosen mentor is valid for the assignment and has the role 'mentor'.

[[File:E2533 mentored team model2.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment'''
'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 2participant model.png]]

== Testing Plan ==

Implemented RSpec tests to validate all team-related operations. Positive and negative test cases have been covered through these test cases.

To successfully run the test cases, we would need to bypass the authentication controller, otherwise we will end up getting a 404 Unauthorized Error!

* Command to run tests for TeamsController:

:<code> bundle exec rspec ./spec/requests/api/v1/teams_spec.rb </code>

: RSpec output:

:[[File:E2533-TeamsController-RSpec.jpg]]

* Command to run tests for AssignmentTeam model:

:<code>bundle exec rspec spec/models/assignment_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-AssignmentTeam-RSpec.jpg]] 

* Command to run tests for CourseTeam model:

:<code>bundle exec rspec spec/models/course_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-course-team-rspec.jpg]]

* Command to run tests for MentoredTeam model:

:<code>bundle exec rspec spec/models/mentored_team_spec.rb</code>

: RSpec output:

:[[File:E2533-MentoredTeam-RSpec.jpg]]

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==
Repository: https://github.com/valorant-dhruv/reimplementation-back-end 
Pull request: https://github.com/expertiza/reimplementation-back-end/pull/193 
Demo Video: https://youtu.be/gKZXYk8HNWc

File:E2533 mentored team model2.png

2025-04-23T03:31:36Z

Uraycha:

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-23T03:29:19Z

Uraycha: /* Participant */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation ==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''

* '''show:''' Retrieves and displays a team’s details.
:[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
:[[File:E2533 teams controller create team.png]]
* '''validate_team_type:''' Validates the team type before team creation to ensure it's among allowed types.
:[[File:E2533 teams controller validate team type.png]]

* '''Team members:'''
** '''members:''' Lists all members of a specific team
** '''add_member:''' Prepares data for adding a new team or adding members to an existing team.
** '''remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
:[[File:E2533 teams controller members.png]]

* '''Join requests:'''
** '''create_join_request:''' Creates a new join request for a team.
** '''join_requests:''' Lists all join requests for the team.
** '''update_join_request:''' Updates the status or details of a specific join request
:[[File:E2533 teams controller join requests.png]]

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

[[File:E2533 team helper.png]]

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

[[File:E2533 team model.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===
'''Inherits From:''' Team

'''Purpose:'''
CourseTeam is designed for teams that persist across an entire course. It validates the course membership of a user.

'''Additions:'''
* '''add_member(user):''' Ensures the user is eligible for the course team before joining.
* '''copy_to_assignment_team:''' Copies the details of a course team, consisting of team name, team size and team members to a new assignment team.
* '''validate_membership:''' Checks if user is enrolled in any assignment in the course.
* '''type_must_be_course_team:''' Checks if the team type is 'CourseTeam'

[[File:E2533 course team model.png]]

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

''' Additions:'''
* '''add_member(user):''' Ensures the user being added to the team is not already a mentor.
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., mentor role).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_must_have_mentor_role:''' Ensures that the chosen mentor is valid for the assignment and has the role 'mentor'.

[[File:E2533 mentored team model.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment'''
'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 2participant model.png]]

== Testing Plan ==

Implemented RSpec tests to validate all team-related operations. Positive and negative test cases have been covered through these test cases.

To successfully run the test cases, we would need to bypass the authentication controller, otherwise we will end up getting a 404 Unauthorized Error!

* Command to run tests for TeamsController:

:<code> bundle exec rspec ./spec/requests/api/v1/teams_spec.rb </code>

: RSpec output:

:[[File:E2533-TeamsController-RSpec.jpg]]

* Command to run tests for AssignmentTeam model:

:<code>bundle exec rspec spec/models/assignment_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-AssignmentTeam-RSpec.jpg]] 

* Command to run tests for CourseTeam model:

:<code>bundle exec rspec spec/models/course_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-course-team-rspec.jpg]]

* Command to run tests for MentoredTeam model:

:<code>bundle exec rspec spec/models/mentored_team_spec.rb</code>

: RSpec output:

:[[File:E2533-MentoredTeam-RSpec.jpg]]

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==
Repository: https://github.com/valorant-dhruv/reimplementation-back-end 
Pull request: https://github.com/expertiza/reimplementation-back-end/pull/193 
Demo Video: https://youtu.be/gKZXYk8HNWc

File:E2533 2participant model.png

2025-04-23T03:29:01Z

Uraycha:

File:E2533 participant model.png

2025-04-23T03:24:38Z

Uraycha: Uraycha uploaded a new version of File:E2533 participant model.png

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-23T03:13:22Z

Uraycha: /* TeamsController */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation ==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''

* '''show:''' Retrieves and displays a team’s details.
:[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
:[[File:E2533 teams controller create team.png]]
* '''validate_team_type:''' Validates the team type before team creation to ensure it's among allowed types.
:[[File:E2533 teams controller validate team type.png]]

* '''Team members:'''
** '''members:''' Lists all members of a specific team
** '''add_member:''' Prepares data for adding a new team or adding members to an existing team.
** '''remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
:[[File:E2533 teams controller members.png]]

* '''Join requests:'''
** '''create_join_request:''' Creates a new join request for a team.
** '''join_requests:''' Lists all join requests for the team.
** '''update_join_request:''' Updates the status or details of a specific join request
:[[File:E2533 teams controller join requests.png]]

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

[[File:E2533 team helper.png]]

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

[[File:E2533 team model.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===
'''Inherits From:''' Team

'''Purpose:'''
CourseTeam is designed for teams that persist across an entire course. It validates the course membership of a user.

'''Additions:'''
* '''add_member(user):''' Ensures the user is eligible for the course team before joining.
* '''copy_to_assignment_team:''' Copies the details of a course team, consisting of team name, team size and team members to a new assignment team.
* '''validate_membership:''' Checks if user is enrolled in any assignment in the course.
* '''type_must_be_course_team:''' Checks if the team type is 'CourseTeam'

[[File:E2533 course team model.png]]

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

''' Additions:'''
* '''add_member(user):''' Ensures the user being added to the team is not already a mentor.
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., mentor role).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_must_have_mentor_role:''' Ensures that the chosen mentor is valid for the assignment and has the role 'mentor'.

[[File:E2533 mentored team model.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment'''
'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 participant model.png]]

== Testing Plan ==

Implemented RSpec tests to validate all team-related operations. Positive and negative test cases have been covered through these test cases.

To successfully run the test cases, we would need to bypass the authentication controller, otherwise we will end up getting a 404 Unauthorized Error!

* Command to run tests for TeamsController:

:<code> bundle exec rspec ./spec/requests/api/v1/teams_spec.rb </code>

: RSpec output:

:[[File:E2533-TeamsController-RSpec.jpg]]

* Command to run tests for AssignmentTeam model:

:<code>bundle exec rspec spec/models/assignment_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-AssignmentTeam-RSpec.jpg]] 

* Command to run tests for CourseTeam model:

:<code>bundle exec rspec spec/models/course_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-course-team-rspec.jpg]]

* Command to run tests for MentoredTeam model:

:<code>bundle exec rspec spec/models/mentored_team_spec.rb</code>

: RSpec output:

:[[File:E2533-MentoredTeam-RSpec.jpg]]

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==
Repository: https://github.com/valorant-dhruv/reimplementation-back-end 
Pull request: https://github.com/expertiza/reimplementation-back-end/pull/193 
Demo Video: https://youtu.be/gKZXYk8HNWc

File:E2533 teams controller members.png

2025-04-23T03:11:42Z

Uraycha:

File:E2533 teams controller validate team type.png

2025-04-23T03:04:05Z

Uraycha:

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-23T03:00:38Z

Uraycha: /* TeamsController */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation ==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''
* '''add_member:''' Prepares data for adding a new team or adding members to an existing team.
[[File:E2533 teams controller add member.png]]
* '''show:''' Retrieves and displays a team’s details.
:[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
:[[File:E2533 teams controller create team.png]]
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
:[[File:E2533 teams controller remove member.png]]
* '''Join requests:'''
** '''create_join_request:''' Creates a new join request for a team.
** '''join_requests:''' Lists all join requests for the team.
** '''update_join_request:''' Updates the status or details of a specific join request
** '''empty:''' Checks if a team currently has no members, useful for certain validations or cleanup tasks.
:[[File:E2533 teams controller join requests.png]]

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

[[File:E2533 team helper.png]]

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

[[File:E2533 team model.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===
'''Inherits From:''' Team

'''Purpose:'''
CourseTeam is designed for teams that persist across an entire course. It validates the course membership of a user.

'''Additions:'''
* '''add_member(user):''' Ensures the user is eligible for the course team before joining.
* '''copy_to_assignment_team:''' Copies the details of a course team, consisting of team name, team size and team members to a new assignment team.
* '''validate_membership:''' Checks if user is enrolled in any assignment in the course.
* '''type_must_be_course_team:''' Checks if the team type is 'CourseTeam'

[[File:E2533 course team model.png]]

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

''' Additions:'''
* '''add_member(user):''' Ensures the user being added to the team is not already a mentor.
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., mentor role).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_must_have_mentor_role:''' Ensures that the chosen mentor is valid for the assignment and has the role 'mentor'.

[[File:E2533 mentored team model.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment'''
'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 participant model.png]]

== Testing Plan ==

Implemented RSpec tests to validate all team-related operations. Positive and negative test cases have been covered through these test cases.

To successfully run the test cases, we would need to bypass the authentication controller, otherwise we will end up getting a 404 Unauthorized Error!

* Command to run tests for TeamsController:

:<code> bundle exec rspec ./spec/requests/api/v1/teams_spec.rb </code>

: RSpec output:

:[[File:E2533-TeamsController-RSpec.jpg]]

* Command to run tests for AssignmentTeam model:

:<code>bundle exec rspec spec/models/assignment_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-AssignmentTeam-RSpec.jpg]] 

* Command to run tests for CourseTeam model:

:<code>bundle exec rspec spec/models/course_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-course-team-rspec.jpg]]

* Command to run tests for MentoredTeam model:

:<code>bundle exec rspec spec/models/mentored_team_spec.rb</code>

: RSpec output:

:[[File:E2533-MentoredTeam-RSpec.jpg]]

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==
Repository: https://github.com/valorant-dhruv/reimplementation-back-end 
Pull request: https://github.com/expertiza/reimplementation-back-end/pull/193 
Demo Video: https://youtu.be/gKZXYk8HNWc

File:E2533 teams controller join requests.png

2025-04-23T02:59:45Z

Uraycha:

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-23T02:07:51Z

Uraycha: /* CourseTeam */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation ==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''
* '''add / add_member:''' Prepares data for adding a new team or adding members to an existing team.
[[File:E2533 teams controller add member.png]]
* '''show:''' Retrieves and displays a team’s details.
[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
[[File:E2533 teams controller create team.png]]
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
[[File:E2533 teams controller remove member.png]]
* '''copy_to_assignment:''' Allows teams to be copied or migrated into the context of an assignment.
* '''empty:''' Checks if a team currently has no members, useful for certain validations or cleanup tasks.

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

[[File:E2533 team helper.png]]

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

[[File:E2533 team model.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===
'''Inherits From:''' Team

'''Purpose:'''
CourseTeam is designed for teams that persist across an entire course. It validates the course membership of a user.

'''Additions:'''
* '''add_member(user):''' Ensures the user is eligible for the course team before joining.
* '''copy_to_assignment_team:''' Copies the details of a course team, consisting of team name, team size and team members to a new assignment team.
* '''validate_membership:''' Checks if user is enrolled in any assignment in the course.
* '''type_must_be_course_team:''' Checks if the team type is 'CourseTeam'

[[File:E2533 course team model.png]]

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

''' Additions:'''
* '''add_member(user):''' Ensures the user being added to the team is not already a mentor.
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., mentor role).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_must_have_mentor_role:''' Ensures that the chosen mentor is valid for the assignment and has the role 'mentor'.

[[File:E2533 mentored team model.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment'''
'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 participant model.png]]

== Testing Plan ==

Implemented RSpec tests to validate all team-related operations. Positive and negative test cases have been covered through these test cases.

To successfully run the test cases, we would need to bypass the authentication controller, otherwise we will end up getting a 404 Unauthorized Error!

* Command to run tests for TeamsController:

:<code> bundle exec rspec ./spec/requests/api/v1/teams_spec.rb </code>

: RSpec output:

:[[File:E2533-TeamsController-RSpec.jpg]]

* Command to run tests for AssignmentTeam model:

:<code>bundle exec rspec spec/models/assignment_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-AssignmentTeam-RSpec.jpg]] 

* Command to run tests for CourseTeam model:

:<code>bundle exec rspec spec/models/course_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-course-team-rspec.jpg]]

* Command to run tests for MentoredTeam model:

:<code>bundle exec rspec spec/models/mentored_team_spec.rb</code>

: RSpec output:

:[[File:E2533-MentoredTeam-RSpec.jpg]]

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==
Repository: https://github.com/valorant-dhruv/reimplementation-back-end 
Pull request: https://github.com/expertiza/reimplementation-back-end/pull/193 
Demo Video: https://youtu.be/gKZXYk8HNWc

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-23T01:55:25Z

Uraycha: /* Overview of classes and Implementation (In editing !!!) */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation ==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''
* '''add / add_member:''' Prepares data for adding a new team or adding members to an existing team.
[[File:E2533 teams controller add member.png]]
* '''show:''' Retrieves and displays a team’s details.
[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
[[File:E2533 teams controller create team.png]]
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
[[File:E2533 teams controller remove member.png]]
* '''copy_to_assignment:''' Allows teams to be copied or migrated into the context of an assignment.
* '''empty:''' Checks if a team currently has no members, useful for certain validations or cleanup tasks.

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

[[File:E2533 team helper.png]]

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

[[File:E2533 team model.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===
'''Inherits From:''' Team

'''Purpose:'''
CourseTeam is designed for teams that persist across an entire course. It validates the course membership of a user.

'''Additions:'''
* '''add_member(user):''' Ensures the user is eligible for the course team before joining.
* '''validate_membership:''' Checks if user is enrolled in any assignment in the course.

[[File:E2533 course team model.png]]

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

''' Additions:'''
* '''add_member(user):''' Ensures the user being added to the team is not already a mentor.
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., mentor role).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_must_have_mentor_role:''' Ensures that the chosen mentor is valid for the assignment and has the role 'mentor'.

[[File:E2533 mentored team model.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment'''
'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 participant model.png]]

== Testing Plan ==

Implemented RSpec tests to validate all team-related operations. Positive and negative test cases have been covered through these test cases.

To successfully run the test cases, we would need to bypass the authentication controller, otherwise we will end up getting a 404 Unauthorized Error!

* Command to run tests for TeamsController:

:<code> bundle exec rspec ./spec/requests/api/v1/teams_spec.rb </code>

: RSpec output:

:[[File:E2533-TeamsController-RSpec.jpg]]

* Command to run tests for AssignmentTeam model:

:<code>bundle exec rspec spec/models/assignment_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-AssignmentTeam-RSpec.jpg]] 

* Command to run tests for CourseTeam model:

:<code>bundle exec rspec spec/models/course_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-course-team-rspec.jpg]]

* Command to run tests for MentoredTeam model:

:<code>bundle exec rspec spec/models/mentored_team_spec.rb</code>

: RSpec output:

:[[File:E2533-MentoredTeam-RSpec.jpg]]

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==
Repository: https://github.com/valorant-dhruv/reimplementation-back-end 
Pull request: https://github.com/expertiza/reimplementation-back-end/pull/193 
Demo Video: https://youtu.be/gKZXYk8HNWc

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-23T01:35:49Z

Uraycha: /* Relevant Links */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation (In editing !!!)==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''
* '''add / add_member:''' Prepares data for adding a new team or adding members to an existing team.
[[File:E2533 teams controller add member.png]]
* '''show:''' Retrieves and displays a team’s details.
[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
[[File:E2533 teams controller create team.png]]
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
[[File:E2533 teams controller remove member.png]]
* '''copy_to_assignment:''' Allows teams to be copied or migrated into the context of an assignment.
* '''empty:''' Checks if a team currently has no members, useful for certain validations or cleanup tasks.

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

[[File:E2533 team helper.png]]

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

[[File:E2533 team model.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===
'''Inherits From:''' Team

'''Purpose:'''
CourseTeam is designed for teams that persist across an entire course. It validates the course membership of a user.

'''Additions:'''
* '''add_member(user):''' Ensures the user is eligible for the course team before joining.
* '''validate_membership:''' Checks if user is enrolled in any assignment in the course.

[[File:E2533 course team model.png]]

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

'''Possible Additions/Overrides:'''
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., correct privileges or expertise).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_validation:''' Ensures that the chosen mentor is valid for the assignment.
* '''view_team_with_mentor:''' Presents a combined view of the team members and mentor details.

[[File:E2533 mentored team model.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment'''
'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 participant model.png]]

== Testing Plan ==

Implemented RSpec tests to validate all team-related operations. Positive and negative test cases have been covered through these test cases.

To successfully run the test cases, we would need to bypass the authentication controller, otherwise we will end up getting a 404 Unauthorized Error!

* Command to run tests for TeamsController:

:<code> bundle exec rspec ./spec/requests/api/v1/teams_spec.rb </code>

: RSpec output:

:[[File:E2533-TeamsController-RSpec.jpg]]

* Command to run tests for AssignmentTeam model:

:<code>bundle exec rspec spec/models/assignment_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-AssignmentTeam-RSpec.jpg]] 

* Command to run tests for CourseTeam model:

:<code>bundle exec rspec spec/models/course_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-course-team-rspec.jpg]]

* Command to run tests for MentoredTeam model:

:<code>bundle exec rspec spec/models/mentored_team_spec.rb</code>

: RSpec output:

:[[File:E2533-MentoredTeam-RSpec.jpg]]

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==
Repository: https://github.com/valorant-dhruv/reimplementation-back-end 
Pull request: https://github.com/expertiza/reimplementation-back-end/pull/193 
Demo Video: https://youtu.be/gKZXYk8HNWc

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-23T01:03:30Z

Uraycha: /* CourseTeam */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation (In editing !!!)==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''
* '''add / add_member:''' Prepares data for adding a new team or adding members to an existing team.
[[File:E2533 teams controller add member.png]]
* '''show:''' Retrieves and displays a team’s details.
[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
[[File:E2533 teams controller create team.png]]
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
[[File:E2533 teams controller remove member.png]]
* '''copy_to_assignment:''' Allows teams to be copied or migrated into the context of an assignment.
* '''empty:''' Checks if a team currently has no members, useful for certain validations or cleanup tasks.

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

[[File:E2533 team helper.png]]

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

[[File:E2533 team model.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===
'''Inherits From:''' Team

'''Purpose:'''
CourseTeam is designed for teams that persist across an entire course. It validates the course membership of a user.

'''Additions:'''
* '''add_member(user):''' Ensures the user is eligible for the course team before joining.
* '''validate_membership:''' Checks if user is enrolled in any assignment in the course.

[[File:E2533 course team model.png]]

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

'''Possible Additions/Overrides:'''
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., correct privileges or expertise).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_validation:''' Ensures that the chosen mentor is valid for the assignment.
* '''view_team_with_mentor:''' Presents a combined view of the team members and mentor details.

[[File:E2533 mentored team model.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment'''
'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 participant model.png]]

== Testing Plan ==

Implemented RSpec tests to validate all team-related operations. Positive and negative test cases have been covered through these test cases.

To successfully run the test cases, we would need to bypass the authentication controller, otherwise we will end up getting a 404 Unauthorized Error!

* Command to run tests for TeamsController:

:<code> bundle exec rspec ./spec/requests/api/v1/teams_spec.rb </code>

: RSpec output:

:[[File:E2533-TeamsController-RSpec.jpg]]

* Command to run tests for AssignmentTeam model:

:<code>bundle exec rspec spec/models/assignment_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-AssignmentTeam-RSpec.jpg]] 

* Command to run tests for CourseTeam model:

:<code>bundle exec rspec spec/models/course_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-course-team-rspec.jpg]]

* Command to run tests for MentoredTeam model:

:<code>bundle exec rspec spec/models/mentored_team_spec.rb</code>

: RSpec output:

:[[File:E2533-MentoredTeam-RSpec.jpg]]

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==
Repository: https://github.com/valorant-dhruv/reimplementation-back-end 
Pull request: 
Demo Video:

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-23T00:58:17Z

Uraycha: /* Participant */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation (In editing !!!)==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''
* '''add / add_member:''' Prepares data for adding a new team or adding members to an existing team.
[[File:E2533 teams controller add member.png]]
* '''show:''' Retrieves and displays a team’s details.
[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
[[File:E2533 teams controller create team.png]]
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
[[File:E2533 teams controller remove member.png]]
* '''copy_to_assignment:''' Allows teams to be copied or migrated into the context of an assignment.
* '''empty:''' Checks if a team currently has no members, useful for certain validations or cleanup tasks.

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

[[File:E2533 team helper.png]]

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

[[File:E2533 team model.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===
[[File:E2533 course team model.png]]

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

'''Possible Additions/Overrides:'''
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., correct privileges or expertise).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_validation:''' Ensures that the chosen mentor is valid for the assignment.
* '''view_team_with_mentor:''' Presents a combined view of the team members and mentor details.

[[File:E2533 mentored team model.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment'''
'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 participant model.png]]

== Testing Plan ==

Implemented RSpec tests to validate all team-related operations. Positive and negative test cases have been covered through these test cases.

To successfully run the test cases, we would need to bypass the authentication controller, otherwise we will end up getting a 404 Unauthorized Error!

* Command to run tests for TeamsController:

:<code> bundle exec rspec ./spec/requests/api/v1/teams_spec.rb </code>

: RSpec output:

:[[File:E2533-TeamsController-RSpec.jpg]]

* Command to run tests for AssignmentTeam model:

:<code>bundle exec rspec spec/models/assignment_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-AssignmentTeam-RSpec.jpg]] 

* Command to run tests for CourseTeam model:

:<code>bundle exec rspec spec/models/course_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-course-team-rspec.jpg]]

* Command to run tests for MentoredTeam model:

:<code>bundle exec rspec spec/models/mentored_team_spec.rb</code>

: RSpec output:

:[[File:E2533-MentoredTeam-RSpec.jpg]]

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==
Repository: https://github.com/valorant-dhruv/reimplementation-back-end 
Pull request: 
Demo Video:

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-23T00:57:06Z

Uraycha: /* Testing Plan */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation (In editing !!!)==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''
* '''add / add_member:''' Prepares data for adding a new team or adding members to an existing team.
[[File:E2533 teams controller add member.png]]
* '''show:''' Retrieves and displays a team’s details.
[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
[[File:E2533 teams controller create team.png]]
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
[[File:E2533 teams controller remove member.png]]
* '''copy_to_assignment:''' Allows teams to be copied or migrated into the context of an assignment.
* '''empty:''' Checks if a team currently has no members, useful for certain validations or cleanup tasks.

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

[[File:E2533 team helper.png]]

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

[[File:E2533 team model.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===
[[File:E2533 course team model.png]]

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

'''Possible Additions/Overrides:'''
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., correct privileges or expertise).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_validation:''' Ensures that the chosen mentor is valid for the assignment.
* '''view_team_with_mentor:''' Presents a combined view of the team members and mentor details.

[[File:E2533 mentored team model.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment''' (if applicable)

'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 participant model.png]]

== Testing Plan ==

Implemented RSpec tests to validate all team-related operations. Positive and negative test cases have been covered through these test cases.

To successfully run the test cases, we would need to bypass the authentication controller, otherwise we will end up getting a 404 Unauthorized Error!

* Command to run tests for TeamsController:

:<code> bundle exec rspec ./spec/requests/api/v1/teams_spec.rb </code>

: RSpec output:

:[[File:E2533-TeamsController-RSpec.jpg]]

* Command to run tests for AssignmentTeam model:

:<code>bundle exec rspec spec/models/assignment_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-AssignmentTeam-RSpec.jpg]] 

* Command to run tests for CourseTeam model:

:<code>bundle exec rspec spec/models/course_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-course-team-rspec.jpg]]

* Command to run tests for MentoredTeam model:

:<code>bundle exec rspec spec/models/mentored_team_spec.rb</code>

: RSpec output:

:[[File:E2533-MentoredTeam-RSpec.jpg]]

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==
Repository: https://github.com/valorant-dhruv/reimplementation-back-end 
Pull request: 
Demo Video:

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-23T00:47:48Z

Uraycha: /* Final Notes */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation (In editing !!!)==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''
* '''add / add_member:''' Prepares data for adding a new team or adding members to an existing team.
[[File:E2533 teams controller add member.png]]
* '''show:''' Retrieves and displays a team’s details.
[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
[[File:E2533 teams controller create team.png]]
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
[[File:E2533 teams controller remove member.png]]
* '''copy_to_assignment:''' Allows teams to be copied or migrated into the context of an assignment.
* '''empty:''' Checks if a team currently has no members, useful for certain validations or cleanup tasks.

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

[[File:E2533 team helper.png]]

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

[[File:E2533 team model.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===
[[File:E2533 course team model.png]]

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

'''Possible Additions/Overrides:'''
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., correct privileges or expertise).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_validation:''' Ensures that the chosen mentor is valid for the assignment.
* '''view_team_with_mentor:''' Presents a combined view of the team members and mentor details.

[[File:E2533 mentored team model.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment''' (if applicable)

'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 participant model.png]]

== Testing Plan ==

Implemented RSpec tests to validate all team-related operations. Positive and negative test cases have been covered through these test cases.

* Command to run tests for TeamsController:

:<code> bundle exec rspec ./spec/requests/api/v1/teams_spec.rb </code>

: RSpec output:

:[[File:E2533-TeamsController-RSpec.jpg]]

* Command to run tests for AssignmentTeam model:

:<code>bundle exec rspec spec/models/assignment_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-AssignmentTeam-RSpec.jpg]] 

* Command to run tests for CourseTeam model:

:<code>bundle exec rspec spec/models/course_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-course-team-rspec.jpg]]

* Command to run tests for MentoredTeam model:

:<code>bundle exec rspec spec/models/mentored_team_spec.rb</code>

: RSpec output:

:[[File:E2533-MentoredTeam-RSpec.jpg]]

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==
Repository: https://github.com/valorant-dhruv/reimplementation-back-end 
Pull request: 
Demo Video:

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-23T00:46:10Z

Uraycha: /* Testing Plan */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation (In editing !!!)==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''
* '''add / add_member:''' Prepares data for adding a new team or adding members to an existing team.
[[File:E2533 teams controller add member.png]]
* '''show:''' Retrieves and displays a team’s details.
[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
[[File:E2533 teams controller create team.png]]
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
[[File:E2533 teams controller remove member.png]]
* '''copy_to_assignment:''' Allows teams to be copied or migrated into the context of an assignment.
* '''empty:''' Checks if a team currently has no members, useful for certain validations or cleanup tasks.

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

[[File:E2533 team helper.png]]

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

[[File:E2533 team model.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===
[[File:E2533 course team model.png]]

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

'''Possible Additions/Overrides:'''
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., correct privileges or expertise).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_validation:''' Ensures that the chosen mentor is valid for the assignment.
* '''view_team_with_mentor:''' Presents a combined view of the team members and mentor details.

[[File:E2533 mentored team model.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment''' (if applicable)

'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 participant model.png]]

=== Final Notes ===
* '''Implementation & Testing:'''
We have not yet implemented or tested the classes and methods described here. Once we begin coding, we will follow these designs closely and write RSpec tests to ensure all functionalities work as intended.

* '''Code Readability & Documentation:'''
We plan to maintain thorough inline documentation and adopt clear method names. This will make it easier for new contributors to understand and modify our team hierarchy.

* '''Project Mentorship:'''
Sahithi Ammana is providing guidance throughout this project, ensuring that our approach aligns with best practices and remains scalable for future needs.

== Testing Plan ==

Implemented RSpec tests to validate all team-related operations. Positive and negative test cases have been covered through these test cases.

* Command to run tests for TeamsController:

:<code> bundle exec rspec ./spec/requests/api/v1/teams_spec.rb </code>

: RSpec output:

:[[File:E2533-TeamsController-RSpec.jpg]]

* Command to run tests for AssignmentTeam model:

:<code>bundle exec rspec spec/models/assignment_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-AssignmentTeam-RSpec.jpg]] 

* Command to run tests for CourseTeam model:

:<code>bundle exec rspec spec/models/course_team_spec.rb</code>

: RSpec output: 

:[[File:E2533-course-team-rspec.jpg]]

* Command to run tests for MentoredTeam model:

:<code>bundle exec rspec spec/models/mentored_team_spec.rb</code>

: RSpec output:

:[[File:E2533-MentoredTeam-RSpec.jpg]]

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==
Repository: https://github.com/valorant-dhruv/reimplementation-back-end 
Pull request: 
Demo Video:

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-23T00:45:09Z

Uraycha: /* Testing Plan */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation (In editing !!!)==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''
* '''add / add_member:''' Prepares data for adding a new team or adding members to an existing team.
[[File:E2533 teams controller add member.png]]
* '''show:''' Retrieves and displays a team’s details.
[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
[[File:E2533 teams controller create team.png]]
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
[[File:E2533 teams controller remove member.png]]
* '''copy_to_assignment:''' Allows teams to be copied or migrated into the context of an assignment.
* '''empty:''' Checks if a team currently has no members, useful for certain validations or cleanup tasks.

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

[[File:E2533 team helper.png]]

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

[[File:E2533 team model.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===
[[File:E2533 course team model.png]]

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

'''Possible Additions/Overrides:'''
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., correct privileges or expertise).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_validation:''' Ensures that the chosen mentor is valid for the assignment.
* '''view_team_with_mentor:''' Presents a combined view of the team members and mentor details.

[[File:E2533 mentored team model.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment''' (if applicable)

'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 participant model.png]]

=== Final Notes ===
* '''Implementation & Testing:'''
We have not yet implemented or tested the classes and methods described here. Once we begin coding, we will follow these designs closely and write RSpec tests to ensure all functionalities work as intended.

* '''Code Readability & Documentation:'''
We plan to maintain thorough inline documentation and adopt clear method names. This will make it easier for new contributors to understand and modify our team hierarchy.

* '''Project Mentorship:'''
Sahithi Ammana is providing guidance throughout this project, ensuring that our approach aligns with best practices and remains scalable for future needs.

== Testing Plan ==

Implemented RSpec tests to validate all team-related operations. Positive and negative test cases have been covered through these test cases.

* Command to run tests for teams_controller:

:<code> bundle exec rspec ./spec/requests/api/v1/teams_spec.rb </code>

: RSpec output for TeamsController:

:[[File:E2533-TeamsController-RSpec.jpg]]

* Command to run tests for AssignmentTeam model:

:<code>bundle exec rspec spec/models/assignment_team_spec.rb</code>

: RSpec output for AssignmentTeam model: 

:[[File:E2533-AssignmentTeam-RSpec.jpg]] 

* Command to run tests for CourseTeam model:

:<code>bundle exec rspec spec/models/course_team_spec.rb</code>

: RSpec output for CourseTeam model: 

:[[File:E2533-course-team-rspec.jpg]]

* Command to run tests for MentoredTeam model:

:<code>bundle exec rspec spec/models/mentored_team_spec.rb</code>

: RSpec output for MentoredTeam model:

:[[File:E2533-MentoredTeam-RSpec.jpg]]

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==
Repository: https://github.com/valorant-dhruv/reimplementation-back-end 
Pull request: 
Demo Video:

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-23T00:33:17Z

Uraycha: /* Testing Plan */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation (In editing !!!)==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''
* '''add / add_member:''' Prepares data for adding a new team or adding members to an existing team.
[[File:E2533 teams controller add member.png]]
* '''show:''' Retrieves and displays a team’s details.
[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
[[File:E2533 teams controller create team.png]]
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
[[File:E2533 teams controller remove member.png]]
* '''copy_to_assignment:''' Allows teams to be copied or migrated into the context of an assignment.
* '''empty:''' Checks if a team currently has no members, useful for certain validations or cleanup tasks.

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

[[File:E2533 team helper.png]]

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

[[File:E2533 team model.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===
[[File:E2533 course team model.png]]

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

'''Possible Additions/Overrides:'''
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., correct privileges or expertise).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_validation:''' Ensures that the chosen mentor is valid for the assignment.
* '''view_team_with_mentor:''' Presents a combined view of the team members and mentor details.

[[File:E2533 mentored team model.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment''' (if applicable)

'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 participant model.png]]

=== Final Notes ===
* '''Implementation & Testing:'''
We have not yet implemented or tested the classes and methods described here. Once we begin coding, we will follow these designs closely and write RSpec tests to ensure all functionalities work as intended.

* '''Code Readability & Documentation:'''
We plan to maintain thorough inline documentation and adopt clear method names. This will make it easier for new contributors to understand and modify our team hierarchy.

* '''Project Mentorship:'''
Sahithi Ammana is providing guidance throughout this project, ensuring that our approach aligns with best practices and remains scalable for future needs.

== Testing Plan ==

Implemented RSpec tests to validate all team-related operations. Positive and negative test cases have been covered through these test cases.

RSpec output for TeamsController:

[[File:E2533-TeamsController-RSpec.jpg]]

RSpec output for AssignmentTeam model: 

[[File:E2533-AssignmentTeam-RSpec.jpg]] 

RSpec output for CourseTeam model: 

[[File:E2533-course-team-rspec.jpg]]

RSpec output for MentoredTeam model:

[[File:E2533-MentoredTeam-RSpec.jpg]]

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==
Repository: https://github.com/valorant-dhruv/reimplementation-back-end 
Pull request: 
Demo Video:

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-23T00:09:42Z

Uraycha: /* Relevant Links */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation (In editing !!!)==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''
* '''add / add_member:''' Prepares data for adding a new team or adding members to an existing team.
[[File:E2533 teams controller add member.png]]
* '''show:''' Retrieves and displays a team’s details.
[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
[[File:E2533 teams controller create team.png]]
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
[[File:E2533 teams controller remove member.png]]
* '''copy_to_assignment:''' Allows teams to be copied or migrated into the context of an assignment.
* '''empty:''' Checks if a team currently has no members, useful for certain validations or cleanup tasks.

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

[[File:E2533 team helper.png]]

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

[[File:E2533 team model.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===
[[File:E2533 course team model.png]]

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

'''Possible Additions/Overrides:'''
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., correct privileges or expertise).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_validation:''' Ensures that the chosen mentor is valid for the assignment.
* '''view_team_with_mentor:''' Presents a combined view of the team members and mentor details.

[[File:E2533 mentored team model.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment''' (if applicable)

'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 participant model.png]]

=== Final Notes ===
* '''Implementation & Testing:'''
We have not yet implemented or tested the classes and methods described here. Once we begin coding, we will follow these designs closely and write RSpec tests to ensure all functionalities work as intended.

* '''Code Readability & Documentation:'''
We plan to maintain thorough inline documentation and adopt clear method names. This will make it easier for new contributors to understand and modify our team hierarchy.

* '''Project Mentorship:'''
Sahithi Ammana is providing guidance throughout this project, ensuring that our approach aligns with best practices and remains scalable for future needs.

== Testing Plan ==
TeamsController:

[[File:E2533-TeamsController-RSpec.jpg]]

AssignmentTeam: 

[[File:E2533-AssignmentTeam-RSpec.jpg]] 

CourseTeam: 

[[File:E2533-course-team-rspec.jpg]]

Mentored Team:

[[File:E2533-MentoredTeam-RSpec.jpg]]

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==
Repository: https://github.com/valorant-dhruv/reimplementation-back-end 
Pull request: 
Demo Video:

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-22T23:42:42Z

Uraycha:

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation (In editing !!!)==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''
* '''add / add_member:''' Prepares data for adding a new team or adding members to an existing team.
[[File:E2533 teams controller add member.png]]
* '''show:''' Retrieves and displays a team’s details.
[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
[[File:E2533 teams controller create team.png]]
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
[[File:E2533 teams controller remove member.png]]
* '''copy_to_assignment:''' Allows teams to be copied or migrated into the context of an assignment.
* '''empty:''' Checks if a team currently has no members, useful for certain validations or cleanup tasks.

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

[[File:E2533 team helper.png]]

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

[[File:E2533 team model.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===
[[File:E2533 course team model.png]]

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

'''Possible Additions/Overrides:'''
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., correct privileges or expertise).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_validation:''' Ensures that the chosen mentor is valid for the assignment.
* '''view_team_with_mentor:''' Presents a combined view of the team members and mentor details.

[[File:E2533 mentored team model.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment''' (if applicable)

'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 participant model.png]]

=== Final Notes ===
* '''Implementation & Testing:'''
We have not yet implemented or tested the classes and methods described here. Once we begin coding, we will follow these designs closely and write RSpec tests to ensure all functionalities work as intended.

* '''Code Readability & Documentation:'''
We plan to maintain thorough inline documentation and adopt clear method names. This will make it easier for new contributors to understand and modify our team hierarchy.

* '''Project Mentorship:'''
Sahithi Ammana is providing guidance throughout this project, ensuring that our approach aligns with best practices and remains scalable for future needs.

== Testing Plan ==
TeamsController:

[[File:E2533-TeamsController-RSpec.jpg]]

AssignmentTeam: 

[[File:E2533-AssignmentTeam-RSpec.jpg]] 

CourseTeam: 

[[File:E2533-course-team-rspec.jpg]]

Mentored Team:

[[File:E2533-MentoredTeam-RSpec.jpg]]

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==

File:E2533-MentoredTeam-RSpec.jpg

2025-04-22T23:42:04Z

Uraycha:

File:E2533-TeamsController-RSpec.jpg

2025-04-22T23:40:34Z

Uraycha:

File:E2533-AssignmentTeam-RSpec.jpg

2025-04-22T23:36:52Z

Uraycha:

File:E2533-course-team-rspec.jpg

2025-04-22T23:34:35Z

Uraycha:

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-22T22:00:32Z

Uraycha: /* TeamsHelper */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation (In editing !!!)==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''
* '''add / add_member:''' Prepares data for adding a new team or adding members to an existing team.
[[File:E2533 teams controller add member.png]]
* '''show:''' Retrieves and displays a team’s details.
[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
[[File:E2533 teams controller create team.png]]
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
[[File:E2533 teams controller remove member.png]]
* '''copy_to_assignment:''' Allows teams to be copied or migrated into the context of an assignment.
* '''empty:''' Checks if a team currently has no members, useful for certain validations or cleanup tasks.

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

[[File:E2533 team helper.png]]

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

[[File:E2533 team model.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===
[[File:E2533 course team model.png]]

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

'''Possible Additions/Overrides:'''
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., correct privileges or expertise).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_validation:''' Ensures that the chosen mentor is valid for the assignment.
* '''view_team_with_mentor:''' Presents a combined view of the team members and mentor details.

[[File:E2533 mentored team model.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment''' (if applicable)

'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 participant model.png]]

=== Final Notes ===
* '''Implementation & Testing:'''
We have not yet implemented or tested the classes and methods described here. Once we begin coding, we will follow these designs closely and write RSpec tests to ensure all functionalities work as intended.

* '''Code Readability & Documentation:'''
We plan to maintain thorough inline documentation and adopt clear method names. This will make it easier for new contributors to understand and modify our team hierarchy.

* '''Project Mentorship:'''
Sahithi Ammana is providing guidance throughout this project, ensuring that our approach aligns with best practices and remains scalable for future needs.

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==

File:E2533 team helper.png

2025-04-22T22:00:08Z

Uraycha:

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-22T18:04:57Z

Uraycha: /* Overview of classes and Implementation */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation (In editing !!!)==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''
* '''add / add_member:''' Prepares data for adding a new team or adding members to an existing team.
[[File:E2533 teams controller add member.png]]
* '''show:''' Retrieves and displays a team’s details.
[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
[[File:E2533 teams controller create team.png]]
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
[[File:E2533 teams controller remove member.png]]
* '''copy_to_assignment:''' Allows teams to be copied or migrated into the context of an assignment.
* '''empty:''' Checks if a team currently has no members, useful for certain validations or cleanup tasks.

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

[[File:E2533 team model.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===
[[File:E2533 course team model.png]]

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

'''Possible Additions/Overrides:'''
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., correct privileges or expertise).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_validation:''' Ensures that the chosen mentor is valid for the assignment.
* '''view_team_with_mentor:''' Presents a combined view of the team members and mentor details.

[[File:E2533 mentored team model.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment''' (if applicable)

'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 participant model.png]]

=== Final Notes ===
* '''Implementation & Testing:'''
We have not yet implemented or tested the classes and methods described here. Once we begin coding, we will follow these designs closely and write RSpec tests to ensure all functionalities work as intended.

* '''Code Readability & Documentation:'''
We plan to maintain thorough inline documentation and adopt clear method names. This will make it easier for new contributors to understand and modify our team hierarchy.

* '''Project Mentorship:'''
Sahithi Ammana is providing guidance throughout this project, ensuring that our approach aligns with best practices and remains scalable for future needs.

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-22T18:04:03Z

Uraycha: /* CourseTeam */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation ==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''
* '''add / add_member:''' Prepares data for adding a new team or adding members to an existing team.
[[File:E2533 teams controller add member.png]]
* '''show:''' Retrieves and displays a team’s details.
[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
[[File:E2533 teams controller create team.png]]
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
[[File:E2533 teams controller remove member.png]]
* '''copy_to_assignment:''' Allows teams to be copied or migrated into the context of an assignment.
* '''empty:''' Checks if a team currently has no members, useful for certain validations or cleanup tasks.

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

[[File:E2533 team model.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===
[[File:E2533 course team model.png]]

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

'''Possible Additions/Overrides:'''
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., correct privileges or expertise).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_validation:''' Ensures that the chosen mentor is valid for the assignment.
* '''view_team_with_mentor:''' Presents a combined view of the team members and mentor details.

[[File:E2533 mentored team model.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment''' (if applicable)

'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 participant model.png]]

=== Final Notes ===
* '''Implementation & Testing:'''
We have not yet implemented or tested the classes and methods described here. Once we begin coding, we will follow these designs closely and write RSpec tests to ensure all functionalities work as intended.

* '''Code Readability & Documentation:'''
We plan to maintain thorough inline documentation and adopt clear method names. This will make it easier for new contributors to understand and modify our team hierarchy.

* '''Project Mentorship:'''
Sahithi Ammana is providing guidance throughout this project, ensuring that our approach aligns with best practices and remains scalable for future needs.

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==

File:E2533 course team model.png

2025-04-22T18:03:41Z

Uraycha:

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-22T18:02:29Z

Uraycha: /* Overview of classes and Implementation */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation ==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''
* '''add / add_member:''' Prepares data for adding a new team or adding members to an existing team.
[[File:E2533 teams controller add member.png]]
* '''show:''' Retrieves and displays a team’s details.
[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
[[File:E2533 teams controller create team.png]]
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
[[File:E2533 teams controller remove member.png]]
* '''copy_to_assignment:''' Allows teams to be copied or migrated into the context of an assignment.
* '''empty:''' Checks if a team currently has no members, useful for certain validations or cleanup tasks.

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

[[File:E2533 team model.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== CourseTeam ===

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

'''Possible Additions/Overrides:'''
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., correct privileges or expertise).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_validation:''' Ensures that the chosen mentor is valid for the assignment.
* '''view_team_with_mentor:''' Presents a combined view of the team members and mentor details.

[[File:E2533 mentored team model.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment''' (if applicable)

'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 participant model.png]]

=== Final Notes ===
* '''Implementation & Testing:'''
We have not yet implemented or tested the classes and methods described here. Once we begin coding, we will follow these designs closely and write RSpec tests to ensure all functionalities work as intended.

* '''Code Readability & Documentation:'''
We plan to maintain thorough inline documentation and adopt clear method names. This will make it easier for new contributors to understand and modify our team hierarchy.

* '''Project Mentorship:'''
Sahithi Ammana is providing guidance throughout this project, ensuring that our approach aligns with best practices and remains scalable for future needs.

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-22T16:45:18Z

Uraycha: /* Team */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation ==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''
* '''add / add_member:''' Prepares data for adding a new team or adding members to an existing team.
[[File:E2533 teams controller add member.png]]
* '''show:''' Retrieves and displays a team’s details.
[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
[[File:E2533 teams controller create team.png]]
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
[[File:E2533 teams controller remove member.png]]
* '''copy_to_assignment:''' Allows teams to be copied or migrated into the context of an assignment.
* '''empty:''' Checks if a team currently has no members, useful for certain validations or cleanup tasks.

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

[[File:E2533 team model.png]]

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

'''Possible Additions/Overrides:'''
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., correct privileges or expertise).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_validation:''' Ensures that the chosen mentor is valid for the assignment.
* '''view_team_with_mentor:''' Presents a combined view of the team members and mentor details.

[[File:E2533 mentored team model.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment''' (if applicable)

'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 participant model.png]]

=== Final Notes ===
* '''Implementation & Testing:'''
We have not yet implemented or tested the classes and methods described here. Once we begin coding, we will follow these designs closely and write RSpec tests to ensure all functionalities work as intended.

* '''Code Readability & Documentation:'''
We plan to maintain thorough inline documentation and adopt clear method names. This will make it easier for new contributors to understand and modify our team hierarchy.

* '''Project Mentorship:'''
Sahithi Ammana is providing guidance throughout this project, ensuring that our approach aligns with best practices and remains scalable for future needs.

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==

File:E2533 team model.png

2025-04-22T16:44:52Z

Uraycha:

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-22T16:43:42Z

Uraycha: /* Participant */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation ==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''
* '''add / add_member:''' Prepares data for adding a new team or adding members to an existing team.
[[File:E2533 teams controller add member.png]]
* '''show:''' Retrieves and displays a team’s details.
[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
[[File:E2533 teams controller create team.png]]
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
[[File:E2533 teams controller remove member.png]]
* '''copy_to_assignment:''' Allows teams to be copied or migrated into the context of an assignment.
* '''empty:''' Checks if a team currently has no members, useful for certain validations or cleanup tasks.

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

'''Possible Additions/Overrides:'''
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., correct privileges or expertise).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_validation:''' Ensures that the chosen mentor is valid for the assignment.
* '''view_team_with_mentor:''' Presents a combined view of the team members and mentor details.

[[File:E2533 mentored team model.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment''' (if applicable)

'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

[[File:E2533 participant model.png]]

=== Final Notes ===
* '''Implementation & Testing:'''
We have not yet implemented or tested the classes and methods described here. Once we begin coding, we will follow these designs closely and write RSpec tests to ensure all functionalities work as intended.

* '''Code Readability & Documentation:'''
We plan to maintain thorough inline documentation and adopt clear method names. This will make it easier for new contributors to understand and modify our team hierarchy.

* '''Project Mentorship:'''
Sahithi Ammana is providing guidance throughout this project, ensuring that our approach aligns with best practices and remains scalable for future needs.

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==

File:E2533 participant model.png

2025-04-22T16:43:20Z

Uraycha:

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-22T16:41:15Z

Uraycha: /* MentoredTeam */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation ==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''
* '''add / add_member:''' Prepares data for adding a new team or adding members to an existing team.
[[File:E2533 teams controller add member.png]]
* '''show:''' Retrieves and displays a team’s details.
[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
[[File:E2533 teams controller create team.png]]
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
[[File:E2533 teams controller remove member.png]]
* '''copy_to_assignment:''' Allows teams to be copied or migrated into the context of an assignment.
* '''empty:''' Checks if a team currently has no members, useful for certain validations or cleanup tasks.

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

'''Possible Additions/Overrides:'''
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., correct privileges or expertise).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_validation:''' Ensures that the chosen mentor is valid for the assignment.
* '''view_team_with_mentor:''' Presents a combined view of the team members and mentor details.

[[File:E2533 mentored team model.png]]

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment''' (if applicable)

'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

=== Final Notes ===
* '''Implementation & Testing:'''
We have not yet implemented or tested the classes and methods described here. Once we begin coding, we will follow these designs closely and write RSpec tests to ensure all functionalities work as intended.

* '''Code Readability & Documentation:'''
We plan to maintain thorough inline documentation and adopt clear method names. This will make it easier for new contributors to understand and modify our team hierarchy.

* '''Project Mentorship:'''
Sahithi Ammana is providing guidance throughout this project, ensuring that our approach aligns with best practices and remains scalable for future needs.

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==

File:E2533 mentored team model.png

2025-04-22T16:40:40Z

Uraycha:

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

2025-04-22T16:39:46Z

Uraycha: /* AssignmentTeam */

Wiki page for E2533 - reimplementing the Team hierarchy
== Introduction ==
The Team hierarchy consists of classes that manage student teams within Expertiza. These teams can reserve topics and submit assignments. The hierarchy includes four classes: Team (the superclass), CourseTeam, AssignmentTeam, and MentoredTeam. Since all functional teams belong to one of the three subclasses, direct instances of the Team superclass should never be created.

CourseTeams remain intact throughout a course, collaborating on all assignments. While some instructors opt not to use them, others find CourseTeams beneficial, especially in Team-Based Learning environments. These teams can be converted into AssignmentTeams (and vice versa) as needed.

AssignmentTeams are formed specifically for individual assignments. However, if an assignment is configured to automatically assign mentors, teams are instantiated as MentoredTeams—a subclass of AssignmentTeam with a designated mentor guiding the group.

== Objective ==
This project seeks to modernize and streamline Expertiza’s Team hierarchy, transforming it into a leaner, more intuitive system by eliminating legacy inefficiencies. The current design suffers from code bloat, tangled dependencies, and duplicated logic, particularly in the Team and AssignmentTeam classes, which host numerous overlapping methods. By rearchitecting the hierarchy, we will enforce cleaner inheritance, remove redundant functions, and introduce a more flexible team membership model—shifting from Users to Participants for better alignment with the platform’s evolving structure. The overhaul will emphasize modularity, maintainability, and scalability, ensuring a robust foundation for future enhancements. Through principled object-oriented design, we will redefine relationships between CourseTeam, AssignmentTeam, and MentoredTeam, optimizing their interactions while preserving functionality. The end goal is a decluttered, high-performance team management system that supports seamless collaboration across courses and assignments.

== Requirements ==
The project requires the implementation of a well-structured team hierarchy with clearly defined responsibilities.
# Base Team Class must be created to serve as the parent class, encapsulating core team functionality such as managing members (adding/removing), checking team size, and verifying if a team is empty.
# Specialized subclasses that must be implemented with distinct behaviors while inheriting shared logic:
## CourseTeam.rb - teams persisting throughout a course
## AssignmentTeam,rb - assignment-specific teams
## MentoredTeam.rb - mentor-included variant of AssignmentTeam
# Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams.
# Team operations must support copying teams between categories (e.g., converting a CourseTeam to an AssignmentTeam) while maintaining data integrity.
# Comprehensive RSpec tests must validate all team operations, including edge cases like exceeding team limits or handling empty teams.
# Code readability and documentation are critical—methods should be self-documenting with clear naming conventions, supplemented by detailed comments explaining complex logic. The implementation must prioritize modularity, maintainability, and adherence to object-oriented principles to ensure long-term scalability.

== Existing Issues ==

The current Team hierarchy in Expertiza suffers from several structural and functional deficiencies that hinder maintainability and scalability. The system exhibits excessive code duplication, particularly between the Team superclass and its subclasses (AssignmentTeam, CourseTeam), with redundant methods bloating the codebase (e.g., AssignmentTeam contains many methods that overlap with Team's methods). Poor inheritance design forces subclasses to reimplement logic that should be inherited, violating DRY principles. Team membership is tightly coupled to the User model, requiring a disruptive migration to the newer Participant system. Additionally, ambiguous team-type relationships complicate operations like copying teams between course and assignment contexts. The lack of modular boundaries creates brittle dependencies, while insufficient test coverage for edge cases (e.g., team size limits, empty teams) risks regression errors. These issues collectively result in a fragile, hard-to-extend architecture that necessitates a thorough redesign.

While code duplication, inheritance issues, and the User-to-Participant transition were addressed in the previous implementation, foundational work like base class implementation, membership rules, comprehensive testing, and documentation remains to be completed.

== Design ==

=== Controller diagram ===

The following diagram illustrates the interaction between the controller, helper, and models in the proposed Team hierarchy reimplementation. The controller acts as the main entry point for all team-related API calls, delegating logic to helpers and interacting with the appropriate Team subclass.

[[File:E2533 ControllerDiagram.jpg|center|500px|Controller, Helper, and Model Interaction Diagram]]

=== TeamsController.rb: Method / API calls ===

{| class="wikitable"
! # !! Method !! Endpoint !! Description
|-
| 1 || index || GET /teams/:type || Return a list of teams of a specific type (CourseTeam / AssignmentTeam)
|-
| 2 || show || GET /teams/:id || Return details of a specific team
|-
| 3 || create || POST /teams || Create a new team
|-
| 4 || add_members || PATCH /teams/:id/add_member || Add a participant to a team
|-
| 5 || remove_member || DELETE /teams/:id/remove_member/:participant_id || Remove a participant from a team
|-
| 6 || copy_to_assignment || POST /teams/:id/copy_to_assignment/:assignment_id || Copy a course team to a new assignment team
|-
| 7 || check_size || GET /teams/:id/size || Return current size of the team
|-
| 8 || Empty || GET /teams/:id/empty || Returns true/false if the team has no members
|}

=== TeamsHelper.rb methods ===

1. Valid_member?(user, team_type) – It will check if a user is valid for a given team type (e.g., participant type matches). 
2. team_full?(team) – It will cehck if the team has reached max size. 
3. sanitize_team_params() – It will ensure only permitted params are accepted for team creation. 
4. mentor_of?(user, team) – It will check if a user is the designated mentor (MentoredTeam only). 
5. copy_team_structure() – It will be used for copying team members and metadata. 

=== Patterns ===

'''Template Method Pattern'''

This project will use the Template Method Pattern, which allows subclasses to override certain stages without changing the general structure. It defines the foundation of fundamental team-related processes in a base class. This pattern is especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but implements its own unique logic.

'''Where Will It Be Used?''' 
'''Base Class: Team''' 
Generic methods like `add_member`, `remove_member`, `copy_to`, and `empty?` will be defined by the `Team` class. These methods will use placeholder or hook methods, such as `validate_participant_type` or `handle_special_roles`, which will be implemented by subclasses, while adhering to a standard structure.

'''Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam''' 
These subclasses will define unique validations and behaviors by overriding the hook methods:
* `CourseTeam` will validate participants in the course.
* `AssignmentTeam` will define assignment-specific logic.
* `MentoredTeam` will take precedence over the member addition rationale to handle mentor responsibilities.

'''Reason for Using Template Method:'''
* Promotes code reuse by including shared functionality in the main `Team` class.
* Enforces a consistent framework for all team operations.
* Allows customizable behavior in subclasses without duplicating code.
* Simplifies future enhancements by offering a scalable and maintainable solution (e.g., when introducing new team types).

=== SOLID Principles ===

'''Open/Closed Principle (OCP)''' 
The Open/Closed Principle states that software entities should be open for extension but closed for modification. This principle will be a core part of the Team hierarchy reimplementation. 
The Team base class in this project will be created so that when more team kinds are added, it doesn't need to be changed. Instead, by constructing subclasses like CourseTeam, AssignmentTeam, and MentoredTeam, developers will be able to expand the current structure. 
Without changing the shared logic specified in the Team base class, each subclass will extend or override particular methods (such as add_member, validate_participant_type, or copy_to). With this design, the basic class will continue to be dependable and robust while providing room for expansion and personalisation

== Overview of classes and Implementation ==

=== TeamsController ===
'''Inherits From:''' ApplicationController

'''Purpose:'''
The TeamsController is our main interface for handling team-related requests. It orchestrates creating, showing, updating, and removing teams while also providing actions for specific operations like copying teams to assignments. By extending ApplicationController, it leverages Rails conventions for RESTful endpoints.

'''Key Actions (as referenced in the diagram):'''
* '''add / add_member:''' Prepares data for adding a new team or adding members to an existing team.
[[File:E2533 teams controller add member.png]]
* '''show:''' Retrieves and displays a team’s details.
[[File:E2533 teams controller show team.png]]
* '''create:''' Persists a new team record.
[[File:E2533 teams controller create team.png]]
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
[[File:E2533 teams controller remove member.png]]
* '''copy_to_assignment:''' Allows teams to be copied or migrated into the context of an assignment.
* '''empty:''' Checks if a team currently has no members, useful for certain validations or cleanup tasks.

=== TeamsHelper ===
'''Purpose:'''
TeamsHelper provides shared view or utility methods that can be reused across different views related to teams. This might include form helpers, formatting functions, or any specialized logic that doesn’t belong directly in the controller or model. By extracting these methods into a helper, we keep our controllers lean and our views consistent.

=== Validation / Utility ===
'''Purpose:'''
These are modules or classes that encapsulate common validation logic or utility functions. For example, methods may ensure that team size constraints are met or that certain data formats are respected. The TeamsController can call these utilities to keep business logic separate from controller actions.

=== Team ===
'''Purpose:'''
Team is our base model, defining attributes and behaviors common to all team types. It maintains core relationships (like having many members) and implements fundamental methods that child classes can inherit or override.

'''Key Methods:'''
* '''add_member(user):''' Adds a user to the team, performing basic checks like duplicate membership.
* '''remove_member(user):''' Removes a user from the team.
* '''size:''' Returns the current count of team members.
* '''empty?:''' Checks whether the team has no members, useful for validating if a team is still active or viable.

Because Team is the parent class, it keeps the shared logic centralized, ensuring consistency across specialized team models.

=== AssignmentTeam ===
'''Inherits From:''' Team

'''Purpose:'''
AssignmentTeam is designed for short-term or one-off teams formed specifically for an assignment. It enforces membership rules based on assignment criteria, such as whether a user is actually participating in that assignment.

'''Possible Additions/Overrides:'''
* '''add_assignment_member(user):''' Ensures the user is eligible for the assignment before joining.
* '''validate_team:''' Checks constraints like maximum size or required roles for an assignment.

[[File:E2533 assignment team model.png]]

By keeping assignment-specific logic here, we avoid mixing it with course-level concerns.

=== MentoredTeam ===
'''Inherits From:''' AssignmentTeam

'''Purpose:'''
MentoredTeam extends AssignmentTeam by adding a designated mentor role. This can be especially helpful for assignments requiring expert oversight or guidance.

'''Possible Additions/Overrides:'''
* '''assign_mentor(user):''' Sets a mentor for the team after confirming they meet certain criteria (e.g., correct privileges or expertise).
* '''remove_mentor:''' Allows for unassigning a mentor if needed.
* '''mentor_validation:''' Ensures that the chosen mentor is valid for the assignment.
* '''view_team_with_mentor:''' Presents a combined view of the team members and mentor details.

By placing mentor logic in its own subclass, we keep assignment-level functionality clean while MentoredTeam handles the extra mentorship features.

=== Participant ===
'''Associations:'''
* '''belongs_to :team'''
* '''belongs_to :user'''
* '''belongs_to :assignment''' (if applicable)

'''Purpose:'''
Participant acts as a linking model in some contexts, ensuring we can track which user belongs to which team for a given assignment or course. This model helps us keep membership records organized and may include additional data (like submission status or peer reviews).

=== Final Notes ===
* '''Implementation & Testing:'''
We have not yet implemented or tested the classes and methods described here. Once we begin coding, we will follow these designs closely and write RSpec tests to ensure all functionalities work as intended.

* '''Code Readability & Documentation:'''
We plan to maintain thorough inline documentation and adopt clear method names. This will make it easier for new contributors to understand and modify our team hierarchy.

* '''Project Mentorship:'''
Sahithi Ammana is providing guidance throughout this project, ensuring that our approach aligns with best practices and remains scalable for future needs.

== Team ==
'''Mentor''' 
Sahithi Ammana

'''Team Members '''
* Dhruv Soni (dbsoni)
* Ananya Doshi (avdoshi)
* Udita Raychaudhury (uraycha)

== Relevant Links ==

File:E2533 assignment team model.png

2025-04-22T16:37:46Z

Uraycha:

Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

File:E2533 teams controller crud team.png

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

File:E2533 team helper2.png

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

File:E2533 team model2.png

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

File:E2533 assignment team model2.png

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

File:E2533 course team model2.png

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

File:E2533 mentored team model2.png

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

File:E2533 2participant model.png

File:E2533 participant model.png

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

File:E2533 teams controller members.png

File:E2533 teams controller validate team type.png

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

File:E2533 teams controller join requests.png

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

File:E2533-MentoredTeam-RSpec.jpg

File:E2533-TeamsController-RSpec.jpg

File:E2533-AssignmentTeam-RSpec.jpg

File:E2533-course-team-rspec.jpg

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

File:E2533 team helper.png

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

File:E2533 course team model.png

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

File:E2533 team model.png

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

File:E2533 participant model.png

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

File:E2533 mentored team model.png

CSC/ECE 517 Spring 2025 - E2533. ​​Reimplement the Team hierarchy

File:E2533 assignment team model.png

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy

CSC/ECE 517 Spring 2025 - E2533. Reimplement the Team hierarchy