Expertiza_Wiki - User contributions [en]

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

2025-04-07T20:18:12Z

Avdoshi: /* teams_controller.rb: Method / API calls */

Wiki page for E2533 - reimplementing the Team hierarchy
== About Expertiza ==

'''Expertiza''' is an open-source platform developed with the Ruby on Rails MVC framework, aimed at supporting peer review and group-based learning. Over time, the project has evolved through several updates, with current work centered on restructuring the code to boost maintainability, performance, and scalability. There are also plans to develop a redesigned version of Expertiza to modernize its architecture and expand its features.

== 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. First, a 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 — CourseTeam.rb (persisting throughout a course), AssignmentTeam,rb (assignment-specific), and MentoredTeam.rb (mentor-included variant of AssignmentTeam) must be implemented with distinct behaviors while inheriting shared logic. Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams. Additionally, 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. Finally, 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 ==
== 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 ==

=== 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.
* '''show:''' Retrieves and displays a team’s details.
* '''create:''' Persists a new team record.
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
* '''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.

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 ==

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

2025-04-07T20:17:55Z

Avdoshi: /* teams_helper.rb methods */

Wiki page for E2533 - reimplementing the Team hierarchy
== About Expertiza ==

'''Expertiza''' is an open-source platform developed with the Ruby on Rails MVC framework, aimed at supporting peer review and group-based learning. Over time, the project has evolved through several updates, with current work centered on restructuring the code to boost maintainability, performance, and scalability. There are also plans to develop a redesigned version of Expertiza to modernize its architecture and expand its features.

== 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. First, a 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 — CourseTeam.rb (persisting throughout a course), AssignmentTeam,rb (assignment-specific), and MentoredTeam.rb (mentor-included variant of AssignmentTeam) must be implemented with distinct behaviors while inheriting shared logic. Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams. Additionally, 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. Finally, 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 ==
== 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]]

=== teams_controller.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 ==

=== 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.
* '''show:''' Retrieves and displays a team’s details.
* '''create:''' Persists a new team record.
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
* '''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.

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 ==

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

2025-04-07T20:15:03Z

Avdoshi: /* Patterns */

Wiki page for E2533 - reimplementing the Team hierarchy
== About Expertiza ==

'''Expertiza''' is an open-source platform developed with the Ruby on Rails MVC framework, aimed at supporting peer review and group-based learning. Over time, the project has evolved through several updates, with current work centered on restructuring the code to boost maintainability, performance, and scalability. There are also plans to develop a redesigned version of Expertiza to modernize its architecture and expand its features.

== 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. First, a 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 — CourseTeam.rb (persisting throughout a course), AssignmentTeam,rb (assignment-specific), and MentoredTeam.rb (mentor-included variant of AssignmentTeam) must be implemented with distinct behaviors while inheriting shared logic. Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams. Additionally, 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. Finally, 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 ==
== 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]]

=== teams_controller.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
|}

=== teams_helper.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 ==

=== 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.
* '''show:''' Retrieves and displays a team’s details.
* '''create:''' Persists a new team record.
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
* '''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.

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 ==

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

2025-04-07T20:14:36Z

Avdoshi: /* Patterns */

Wiki page for E2533 - reimplementing the Team hierarchy
== About Expertiza ==

'''Expertiza''' is an open-source platform developed with the Ruby on Rails MVC framework, aimed at supporting peer review and group-based learning. Over time, the project has evolved through several updates, with current work centered on restructuring the code to boost maintainability, performance, and scalability. There are also plans to develop a redesigned version of Expertiza to modernize its architecture and expand its features.

== 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. First, a 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 — CourseTeam.rb (persisting throughout a course), AssignmentTeam,rb (assignment-specific), and MentoredTeam.rb (mentor-included variant of AssignmentTeam) must be implemented with distinct behaviors while inheriting shared logic. Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams. Additionally, 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. Finally, 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 ==
== 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]]

=== teams_controller.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
|}

=== teams_helper.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 ==

=== 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.
* '''show:''' Retrieves and displays a team’s details.
* '''create:''' Persists a new team record.
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
* '''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.

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 ==

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

2025-04-07T20:14:01Z

Avdoshi: /* Patterns */

Wiki page for E2533 - reimplementing the Team hierarchy
== About Expertiza ==

'''Expertiza''' is an open-source platform developed with the Ruby on Rails MVC framework, aimed at supporting peer review and group-based learning. Over time, the project has evolved through several updates, with current work centered on restructuring the code to boost maintainability, performance, and scalability. There are also plans to develop a redesigned version of Expertiza to modernize its architecture and expand its features.

== 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. First, a 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 — CourseTeam.rb (persisting throughout a course), AssignmentTeam,rb (assignment-specific), and MentoredTeam.rb (mentor-included variant of AssignmentTeam) must be implemented with distinct behaviors while inheriting shared logic. Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams. Additionally, 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. Finally, 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 ==
== 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]]

=== teams_controller.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
|}

=== teams_helper.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 ==

=== 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.
* '''show:''' Retrieves and displays a team’s details.
* '''create:''' Persists a new team record.
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
* '''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.

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 ==

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

2025-04-07T20:12:54Z

Avdoshi: /* Overview of classes */

Wiki page for E2533 - reimplementing the Team hierarchy
== About Expertiza ==

'''Expertiza''' is an open-source platform developed with the Ruby on Rails MVC framework, aimed at supporting peer review and group-based learning. Over time, the project has evolved through several updates, with current work centered on restructuring the code to boost maintainability, performance, and scalability. There are also plans to develop a redesigned version of Expertiza to modernize its architecture and expand its features.

== 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. First, a 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 — CourseTeam.rb (persisting throughout a course), AssignmentTeam,rb (assignment-specific), and MentoredTeam.rb (mentor-included variant of AssignmentTeam) must be implemented with distinct behaviors while inheriting shared logic. Team membership rules must enforce valid user assignments, ensuring course participants are correctly mapped to CourseTeams and assignment participants to AssignmentTeams. Additionally, 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. Finally, 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 ==
== 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]]

=== teams_controller.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
|}

=== teams_helper.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 while defining the foundation of fundamental team-related processes in a base class. This pattern will be especially useful for creating a uniform but adaptable team hierarchy architecture, where each team type adheres to the same overall process but has its own unique logic. 
Where Will It Be Used? 
1. 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, and will adhere to a standard structure. 
2. Subclasses: CourseTeam, AssignmentTeam, and MentoredTeam. 
These subclasses will define unique validations and behaviours by overriding the hook methods: 
- Participants in the course will be validated by CourseTeam. 
- Assignment-specific logic will be defined by AssignmentTeam. 
- To assign mentor responsibilities, MentoredTeam will take precedence over the member addition rationale. 
Reason for using Template method: 
- Because the main Team class will include shared functionality, it will encourage code duplication. 
- For all team operations, it will impose a uniform framework. 
- Without needing code duplication, it will enable subclasses to exhibit customisable behaviour. 
- It will simplify future additions (for example, if more team types are developed) by offering a scalable and maintainable solution. 

=== 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 ==

=== 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.
* '''show:''' Retrieves and displays a team’s details.
* '''create:''' Persists a new team record.
* '''remove / remove_member:''' Handles deletion of teams or the removal of a specific member from a team.
* '''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.

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 ==

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

2025-04-07T20:08:05Z

Avdoshi: /* Overview of classes */

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

2025-04-07T20:06:55Z

Avdoshi: /* Design */

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

2025-04-07T20:05:02Z

Avdoshi: /* Patterns */

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

2025-04-07T20:04:27Z

Avdoshi: /* Patterns */

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

2025-04-07T20:03:59Z

Avdoshi: /* Design */

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

2025-04-07T19:58:39Z

Avdoshi: /* teams_helper.rb methods */

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

2025-04-07T19:57:28Z

Avdoshi: /* Design */

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

2025-04-07T19:56:35Z

Avdoshi: /* teams_controller.rb: Method / API calls */

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

2025-04-07T19:55:18Z

Avdoshi: /* teams_controller.rb: Method / API calls */

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

2025-04-07T19:55:02Z

Avdoshi: /* Design */

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

2025-04-07T19:54:10Z

Avdoshi: /* Design */

File:E2533 ControllerDiagram.jpg

2025-04-07T19:52:01Z

Avdoshi:

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

2025-04-07T19:51:24Z

Avdoshi: /* Design */

Expertiza_Wiki - User contributions [en]

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

File:E2533 ControllerDiagram.jpg

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