Expertiza_Wiki - User contributions [en]

MainPage

2024-03-18T21:01:49Z

Kmalick: /* Expertiza */

==Expertiza==
* [[Expertiza documentation]]

* [[CSC/ECE 517 Summer 2008]]
* [[CSC/ECE 517 Fall 2010]]
* [[CSC/ECE 517 Fall 2011]]
* [[CSC/ECE 517 Fall 2012]]
* [[CSC/ECE 517 Fall 2013]]
* [[CSC/ECE 517 Fall 2014]]
* [[CSC/ECE 517 Fall 2015]]
* [[CSC/ECE 517 Fall 2016]]
* [[CSC/ECE 517 Spring 2014]]
* [[CSC/ECE 517 Spring 2015]]
* [[CSC/ECE 517 Spring 2016]]
* [[CSC/ECE 517 Spring 2017]]
* [[CSC/ECE 517 Fall 2017]]
* [[CSC/Independent Study Spring 2018]]
* [[CSC/ECE 517 Spring 2018]]
* [[CSC/ECE 517 Fall 2018]]
* [[CSC/ECE 517 Spring 2019]]
* [[CSC/ECE 517 Fall 2019]]
* [[CSC/ECE 517 Spring 2020]]
* [[CSC/ECE 517 Summer 2020]]
* [[CSC/ECE 517 Fall 2020]]
* [[CSC/ECE 517 Spring 2021]]
* [[CSC/ECE 517 Fall 2021]]
* [[CSC/ECE 517 Spring 2022]]
* [[CSC/ECE 517 Fall 2022]]
* [[CSC/ECE 517 Spring 2023]]
* [[CSC/ECE 517 Fall 2023]]
* [[CSC/ECE 517 Spring 2024]]
* [[CSC 456 Spring 2011|CSC 456 Spring 2012]]
* [[ECE 633]]
* [[KCU]]
* [[Progress reports]]
* [[ReactJs Frontend]]
* [[Front-End/Back-End]]

==Application Behavior==
* [[Grading]]

==Metaprogramming==
* [[CSC/ECE_517_Spring_2013/ch1b_1k_hf|Lecture on Metaprogramming]]

==Development==

''Expertiza now has a Java dependency, so the machine you are using to develop Expertiza on should have the JVM installed.''

* [[Setting Up a Development Machine]]
* [[Creating a Linux Development Environment for Expertiza - Installation Guide]]
* [[Using git and github for projects]]
* [[Using heroku to deploy your projects]]
* [[How to Begin a Project from the Current Expertiza Repository]]
* [[Git]]
* [[How to Change a User's Password on a Development Machine]]
* [[Debugging Rails]]
* [http://rajanalwan.com/ui_guidelines/ Design Template]

==Production==
* [[Deploying to Production]]
* [[Downloading Production Data]]
* [[Accessing the Production Server]]

==Testing==
* [[Using Cucumber with Expertiza]]
* [[Rails Testing Overview]]
* [[Expertiza Continuous Integration]]

==References==
* [[Object-Oriented Design and Programming]]

CSC/ECE 517 Fall 2023 - E2386. Reimplement teams users backend

2023-11-16T02:41:03Z

Kmalick:

===Description of Project===

The focal point of the project is the teams_user model, capturing information about mentors, team members, and affiliations with other models such as Users and Teams. This model undertakes various responsibilities, including the formation of teams with enrolled students and the display of team members. Oversight of team management falls under the purview of the teams_user_controller, which orchestrates CRUD operations on the teams_user model. Its duties span the creation, modification, and deletion of teams, along with the administration of team members through additions or removals. Furthermore, the controller provides a list of mentors associated with teams_users.

===Problem Statement===

The project involves creating a backend system for seamless CRUD operations on a relational database, specifically focusing on interactions between teams and users. This requires defining "teams_users" model with suitable attributes and relationships, establishing controllers to manage CRUD actions, and setting up corresponding routes. Emphasis is placed on rigorous testing, covering model validations and associations, as well as controller actions to ensure accurate execution of CRUD operations. A key project aspect involves refining code to produce precise JSON responses. Adhering to RESTful conventions, the re-implementation includes appropriate HTTP response codes. RSpec tests are mandatory for both the teams_users model and TeamUsersController, covering all endpoints and incorporating HTTP response codes. These controller tests are designed to integrate seamlessly with RSwag for generating API documentation and testing REST APIs through the Swagger UI.

===Objectives===

*Craft RESTful endpoints for creating, displaying, and deleting invitations, along with approving new invitations. Additionally, provide functionality for listing pending invitations, creating new invitations, and notifying students about newly formed team invitations.

*Develop and integrate methods within the teams_users_controller to facilitate invitation-related operations, including creating, accepting, declining, and canceling invitations. Ensure thorough checks of user and team statuses before initiating or accepting invitations.

*Establish a user-invitation system that empowers invited users to accept, decline, or cancel invitations, triggering corresponding updates to the associated teams_user records. This should seamlessly manage the addition or removal of users from teams.

*Implement an email notification system within the user-invitation framework, sending email notifications to invited users upon the issuance of new invitations.

*Enforce the use of proper status codes and robust validation mechanisms for all RESTful endpoints.

*Construct models and controllers for the teams_user model, incorporating contemporary approaches to writing Ruby code. This involves leveraging language features and adhering to best practices for object-oriented design.

*Compose comprehensive RSpec tests covering all APIs, models, and controllers to ensure the robustness and reliability of the entire system.

===Development Strategy===

Our development strategy adheres to the principles of Test-Driven Development (TDD) for the implementation of both the Invitation model and the Invitation Controller. The process begins with the creation of a failing test case, followed by the addition of code to address the identified issues and ensure the successful passage of the test.

Furthermore, we align with the Rails philosophy of "Fat models," aiming to migrate substantial business logic from the controller to the model. This approach is intended to maintain a clean and organized controller codebase while promoting code reusability throughout the application.

===Project Design and Implementation===

Considering the existing functionality of the teams_user model and controller, we have outlined a set of RESTful endpoints along with their corresponding request types for implementation. In the controller, we plan to adopt the Strategy Pattern, leveraging its ability to encapsulate controller actions and facilitate easy extensibility and usability. This pattern will enable a structured approach to defining and managing the various operations the controller can perform.

==== Functionality ====
In this project, we aim to add functions for the following:

1. Retrieve and display team members.

2. Add a new team member with checks for user existence and team limits.

3. Delete a specific team member.

4. Delete multiple selected team members based on item IDs.

5. Autocomplete functionality for user names within a team.

6. Updating duties of a team member.

===Code Snippets===

====Model====
The `TeamsUser` model in the Expertiza code represents a user's association with a team within the context of a collaborative assignment or project. It utilizes ActiveRecord associations to establish relationships with the `User` and `Team` models, indicating that a user belongs to a team. The model includes methods for deleting a team user, retrieving team members, removing a user from a team, checking if a team is empty, and adding a member to an invited team based on certain conditions. Additionally, there's a method for determining the team ID associated with a user in a specific assignment.

<pre>
class TeamsUser < ApplicationRecord
belongs_to :user
belongs_to :team
has_one :team_user_node, foreign_key: 'node_object_id', dependent: :destroy
has_paper_trail
# attr_accessible :user_id, :team_id # unnecessary protected attributes

def name(ip_address = nil)
name = user.name(ip_address)

# E2115 Mentor Management
# Indicate that someone is a Mentor in the UI. The view code is
# often hard to follow, and this is the best place we could find
# for this to go.
name += ' (Mentor)' if MentorManagement.user_a_mentor?(user)
name
end

def delete
TeamUserNode.find_by(node_object_id: id).destroy
team = self.team
destroy
team.delete if team.teams_users.empty?
end

def get_team_members(team_id); end

# Removes entry in the TeamUsers table for the given user and given team id
def self.remove_team(user_id, team_id)
team_user = TeamsUser.where('user_id = ? and team_id = ?', user_id, team_id).first
team_user&.destroy
end

# Returns the first entry in the TeamUsers table for a given team id
def self.first_by_team_id(team_id)
TeamsUser.where('team_id = ?', team_id).first
end

# Determines whether a team is empty of not
def self.team_empty?(team_id)
team_members = TeamsUser.where('team_id = ?', team_id)
team_members.blank?
end

# Add member to the team they were invited to and accepted the invite for
def self.add_member_to_invited_team(invitee_user_id, invited_user_id, assignment_id)
can_add_member = false
users_teams = TeamsUser.where(['user_id = ?', invitee_user_id])
users_teams.each do |team|
new_team = AssignmentTeam.where(['id = ? and parent_id = ?', team.team_id, assignment_id]).first
unless new_team.nil?
can_add_member = new_team.add_member(User.find(invited_user_id), assignment_id)
end
end
can_add_member
end

# 2015-5-27 [zhewei]:
# We just remove the topic_id field from the participants table.
def self.team_id(assignment_id, user_id)
# team_id variable represents the team_id for this user in this assignment
team_id = nil
teams_users = TeamsUser.where(user_id: user_id)
teams_users.each do |teams_user|
if teams_user.team_id == nil
next
end
team = Team.find(teams_user.team_id)
if team.parent_id == assignment_id
team_id = teams_user.team_id
break
end
end
team_id
end
end
</pre>

====Controller====
The `TeamsUsersController` handles various actions related to team management within the application. It includes methods for authorization checks, auto-completion of user names, updating team member duties, listing team members, creating new team members, deleting individual team members, and bulk deletion of selected team members. The controller also interacts with models such as `Team`, `Assignment`, `User`, and `TeamsUser` to manage teams, assignments, and users. Notably, the `create` method involves adding new team members, performing checks on user participation in assignments or courses, and triggering additional actions such as mentor assignments. The code emphasizes error handling and provides flash messages to communicate issues or successful operations to users.

<pre>
class TeamsUsersController < ApplicationController
include AuthorizationHelper

def action_allowed?
# Allow duty updation for a team if current user is student, else require TA or above Privileges.
if %w[update_duties].include? params[:action]
current_user_has_student_privileges?
else
current_user_has_ta_privileges?
end
end

def auto_complete_for_user_name
team = Team.find(session[:team_id])
@users = team.get_possible_team_members(params[:user][:name])
render inline: "<%= auto_complete_result @users, 'name' %>", layout: false
end

# Example of duties: manager, designer, programmer, tester. Finds TeamsUser and save preferred Duty
def update_duties
team_user = TeamsUser.find(params[:teams_user_id])
team_user.update_attribute(:duty_id, params[:teams_user]['duty_id'])
redirect_to controller: 'student_teams', action: 'view', student_id: params[:participant_id]
end

def list
@team = Team.find(params[:id])
@assignment = Assignment.find(@team.parent_id)
@teams_users = TeamsUser.page(params[:page]).per_page(10).where(['team_id = ?', params[:id]])
end

def new
@team = Team.find(params[:id])
end

def create
user = User.find_by(name: params[:user][:name].strip)
unless user
urlCreate = url_for controller: 'users', action: 'new'
flash[:error] = "\"#{params[:user][:name].strip}\" is not defined. Please <a href=\"#{urlCreate}\">create</a> this user before continuing."
end

team = Team.find(params[:id])
unless user.nil?
if team.is_a?(AssignmentTeam)
assignment = Assignment.find(team.parent_id)
if assignment.user_on_team?(user)
flash[:error] = "This user is already assigned to a team for this assignment"
redirect_back fallback_location: root_path
return
end
if AssignmentParticipant.find_by(user_id: user.id, parent_id: assignment.id).nil?
urlAssignmentParticipantList = url_for controller: 'participants', action: 'list', id: assignment.id, model: 'Assignment', authorization: 'participant'
flash[:error] = "\"#{user.name}\" is not a participant of the current assignment. Please <a href=\"#{urlAssignmentParticipantList}\">add</a> this user before continuing."
else
begin
add_member_return = team.add_member(user, team.parent_id)
rescue
flash[:error] = "The user #{user.name} is already a member of the team #{team.name}"
redirect_back fallback_location: root_path
return
end
flash[:error] = 'This team already has the maximum number of members.' if add_member_return == false
# E2115 Mentor Management
# Kick off the Mentor Management workflow
# Note: this is _not_ supported for CourseTeams which is why the other
# half of this if block does not include the same code
if add_member_return
user = TeamsUser.last
undo_link("The team @teams_user \"#{user.name}\" has been successfully added to \"#{team.name}\".")
MentorManagement.assign_mentor(assignment.id, team.id)
end
end
else # CourseTeam
course = Course.find(team.parent_id)
if course.user_on_team?(user)
flash[:error] = "This user is already assigned to a team for this course"
redirect_back fallback_location: root_path
return
end
if CourseParticipant.find_by(user_id: user.id, parent_id: course.id).nil?
urlCourseParticipantList = url_for controller: 'participants', action: 'list', id: course.id, model: 'Course', authorization: 'participant'
flash[:error] = "\"#{user.name}\" is not a participant of the current course. Please <a href=\"#{urlCourseParticipantList}\">add</a> this user before continuing."
else
begin
add_member_return = team.add_member(user, team.parent_id)
rescue
flash[:error] = "The user #{user.name} is already a member of the team #{team.name}"
redirect_back fallback_location: root_path
return
end
flash[:error] = 'This team already has the maximum number of members.' if add_member_return == false
if add_member_return
@teams_user = TeamsUser.last
undo_link("The team user \"#{user.name}\" has been successfully added to \"#{team.name}\".")
end
end
end
end

redirect_to controller: 'teams', action: 'list', id: team.parent_id
end

def delete
@teams_user = TeamsUser.find(params[:id])
parent_id = Team.find(@teams_user.team_id).parent_id
@user = User.find(@teams_user.user_id)
@teams_user.destroy
undo_link("The team user \"#{@user.name}\" has been successfully removed. ")
redirect_to controller: 'teams', action: 'list', id: parent_id
end

def delete_selected
params[:item].each do |item_id|
team_user = TeamsUser.find(item_id).first
team_user.destroy
end

redirect_to action: 'list', id: params[:id]
end
end
</pre>

====Schema====
<pre>
create_table "teams_users", id: :integer, force: :cascade, options: "ENGINE=InnoDB DEFAULT CHARSET=latin1" do |t|
t.integer "team_id"
t.integer "user_id"
t.integer "duty_id"
t.string "pair_programming_status", limit: 1
t.integer "participant_id"
t.index ["duty_id"], name: "index_teams_participants_on_duty_id"
t.index ["participant_id"], name: "fk_rails_f4d20198de"
t.index ["team_id"], name: "fk_users_teams"
t.index ["user_id"], name: "fk_teams_users"
end
</pre>

===Testing Plan===
The TeamsUsers model and controller will be tested using Rspec. FactoryBot will be utilized to create test fixtures and to build the required models. As the methods in the controller are defined as RESTful endpoints. The test take into consideration that the methods return the correct status codes for the output. Based on the current functionality of TeamsUsers model and controller we have defined the following test which are implemented to test the reimplemented code of teams_users model and controller.

{| class="wikitable" style="margin-left:40px"
|-
! Test No. !! Description
|-
| 1 || Tests if `#update_duties` updates duties for a participant successfully and redirects to '/student_teams/view?student_id=1'.
|-
| 2 || Tests if `#list` renders the list of users under Assignment team teams#users.
|-
| 3 || Tests if `#new` sets the Team object to an instance variable.
|-
| 4 || Tests if `#create` (User Not Defined) throws an error and redirects to 'http://test.host/teams/list?id=1' when a user is not defined.
|-
| 5 || Tests if `#create` (User Not a Participant) throws an error and redirects to 'http://test.host/teams/list?id=1' when the user added is not a participant of the current assignment.
|-
| 6 || Tests if `#create` (Assignment Team Full) throws an error 'This team already has the maximum number of members.' and redirects to 'http://test.host/teams/list?id=1'.
|-
| 7 || Tests if `#create` (User Successfully Added) new user gets successfully added to the assignment and redirects to 'http://test.host/teams/list?id=1'.
|-
| 8 || Tests if `#delete` deletes a user and redirects to 'http://test.host/teams/list?id=1'.
|-
| 9 || Tests if `#delete_selected` deletes selected users and redirects to 'http://test.host/teams_users/list'.
|}

===Relevant Links===
Github Repository: https://github.com/Kashika08/reimplementation-back-end

===Team Members===
*Jay Shah (github: jayjshah2000)

*Kashika Malick (github: kashika08)

*Riya Gori (github: riyagori1203)

===Mentor===
Kartiki Bhandakkar

CSC/ECE 517 Fall 2023 - E2386. Reimplement teams users backend

2023-11-16T02:36:26Z

Kmalick:

===Description of Project===

The focal point of the project is the teams_user model, capturing information about mentors, team members, and affiliations with other models such as Users and Teams. This model undertakes various responsibilities, including the formation of teams with enrolled students and the display of team members. Oversight of team management falls under the purview of the teams_user_controller, which orchestrates CRUD operations on the teams_user model. Its duties span the creation, modification, and deletion of teams, along with the administration of team members through additions or removals. Furthermore, the controller provides a list of mentors associated with teams_users.

===Problem Statement===

The project involves creating a backend system for seamless CRUD operations on a relational database, specifically focusing on interactions between teams and users. This requires defining "teams_users" model with suitable attributes and relationships, establishing controllers to manage CRUD actions, and setting up corresponding routes. Emphasis is placed on rigorous testing, covering model validations and associations, as well as controller actions to ensure accurate execution of CRUD operations. A key project aspect involves refining code to produce precise JSON responses. Adhering to RESTful conventions, the re-implementation includes appropriate HTTP response codes. RSpec tests are mandatory for both the teams_Users model and TeamUsersController, covering all endpoints and incorporating HTTP response codes. These controller tests are designed to integrate seamlessly with RSwag for generating API documentation and testing REST APIs through the Swagger UI.

===Objectives===

*Craft RESTful endpoints for creating, displaying, and deleting invitations, along with approving new invitations. Additionally, provide functionality for listing pending invitations, creating new invitations, and notifying students about newly formed team invitations.

*Develop and integrate methods within the teams_users_controller to facilitate invitation-related operations, including creating, accepting, declining, and canceling invitations. Ensure thorough checks of user and team statuses before initiating or accepting invitations.

*Establish a user-invitation system that empowers invited users to accept, decline, or cancel invitations, triggering corresponding updates to the associated teams_user records. This should seamlessly manage the addition or removal of users from teams.

*Implement an email notification system within the user-invitation framework, sending email notifications to invited users upon the issuance of new invitations.

*Enforce the use of proper status codes and robust validation mechanisms for all RESTful endpoints.

*Construct models and controllers for the teams_user model, incorporating contemporary approaches to writing Ruby code. This involves leveraging language features and adhering to best practices for object-oriented design.

*Compose comprehensive RSpec tests covering all APIs, models, and controllers to ensure the robustness and reliability of the entire system.

===Development Strategy===

Our development strategy adheres to the principles of Test-Driven Development (TDD) for the implementation of both the Invitation model and the Invitation Controller. The process begins with the creation of a failing test case, followed by the addition of code to address the identified issues and ensure the successful passage of the test.

Furthermore, we align with the Rails philosophy of "Fat models," aiming to migrate substantial business logic from the controller to the model. This approach is intended to maintain a clean and organized controller codebase while promoting code reusability throughout the application.

===Project Design and Implementation===

Considering the existing functionality of the teams_user model and controller, we have outlined a set of RESTful endpoints along with their corresponding request types for implementation. In the controller, we plan to adopt the Strategy Pattern, leveraging its ability to encapsulate controller actions and facilitate easy extensibility and usability. This pattern will enable a structured approach to defining and managing the various operations the controller can perform.

==== Functionality ====
In this project, we aim to add functions for the following:

1. Retrieve and display team members.

2. Add a new team member with checks for user existence and team limits.

3. Delete a specific team member.

4. Delete multiple selected team members based on item IDs.

5. Autocomplete functionality for user names within a team.

6. Updating duties of a team member.

===Code Snippets===

====Model====
The `TeamsUser` model in the Expertiza code represents a user's association with a team within the context of a collaborative assignment or project. It utilizes ActiveRecord associations to establish relationships with the `User` and `Team` models, indicating that a user belongs to a team. The model includes methods for deleting a team user, retrieving team members, removing a user from a team, checking if a team is empty, and adding a member to an invited team based on certain conditions. Additionally, there's a method for determining the team ID associated with a user in a specific assignment.

<pre>
class TeamsUser < ApplicationRecord
belongs_to :user
belongs_to :team
has_one :team_user_node, foreign_key: 'node_object_id', dependent: :destroy
has_paper_trail
# attr_accessible :user_id, :team_id # unnecessary protected attributes

def name(ip_address = nil)
name = user.name(ip_address)

# E2115 Mentor Management
# Indicate that someone is a Mentor in the UI. The view code is
# often hard to follow, and this is the best place we could find
# for this to go.
name += ' (Mentor)' if MentorManagement.user_a_mentor?(user)
name
end

def delete
TeamUserNode.find_by(node_object_id: id).destroy
team = self.team
destroy
team.delete if team.teams_users.empty?
end

def get_team_members(team_id); end

# Removes entry in the TeamUsers table for the given user and given team id
def self.remove_team(user_id, team_id)
team_user = TeamsUser.where('user_id = ? and team_id = ?', user_id, team_id).first
team_user&.destroy
end

# Returns the first entry in the TeamUsers table for a given team id
def self.first_by_team_id(team_id)
TeamsUser.where('team_id = ?', team_id).first
end

# Determines whether a team is empty of not
def self.team_empty?(team_id)
team_members = TeamsUser.where('team_id = ?', team_id)
team_members.blank?
end

# Add member to the team they were invited to and accepted the invite for
def self.add_member_to_invited_team(invitee_user_id, invited_user_id, assignment_id)
can_add_member = false
users_teams = TeamsUser.where(['user_id = ?', invitee_user_id])
users_teams.each do |team|
new_team = AssignmentTeam.where(['id = ? and parent_id = ?', team.team_id, assignment_id]).first
unless new_team.nil?
can_add_member = new_team.add_member(User.find(invited_user_id), assignment_id)
end
end
can_add_member
end

# 2015-5-27 [zhewei]:
# We just remove the topic_id field from the participants table.
def self.team_id(assignment_id, user_id)
# team_id variable represents the team_id for this user in this assignment
team_id = nil
teams_users = TeamsUser.where(user_id: user_id)
teams_users.each do |teams_user|
if teams_user.team_id == nil
next
end
team = Team.find(teams_user.team_id)
if team.parent_id == assignment_id
team_id = teams_user.team_id
break
end
end
team_id
end
end
</pre>

====Controller====
The `TeamsUsersController` handles various actions related to team management within the application. It includes methods for authorization checks, auto-completion of user names, updating team member duties, listing team members, creating new team members, deleting individual team members, and bulk deletion of selected team members. The controller also interacts with models such as `Team`, `Assignment`, `User`, and `TeamsUser` to manage teams, assignments, and users. Notably, the `create` method involves adding new team members, performing checks on user participation in assignments or courses, and triggering additional actions such as mentor assignments. The code emphasizes error handling and provides flash messages to communicate issues or successful operations to users.

<pre>
class TeamsUsersController < ApplicationController
include AuthorizationHelper

def action_allowed?
# Allow duty updation for a team if current user is student, else require TA or above Privileges.
if %w[update_duties].include? params[:action]
current_user_has_student_privileges?
else
current_user_has_ta_privileges?
end
end

def auto_complete_for_user_name
team = Team.find(session[:team_id])
@users = team.get_possible_team_members(params[:user][:name])
render inline: "<%= auto_complete_result @users, 'name' %>", layout: false
end

# Example of duties: manager, designer, programmer, tester. Finds TeamsUser and save preferred Duty
def update_duties
team_user = TeamsUser.find(params[:teams_user_id])
team_user.update_attribute(:duty_id, params[:teams_user]['duty_id'])
redirect_to controller: 'student_teams', action: 'view', student_id: params[:participant_id]
end

def list
@team = Team.find(params[:id])
@assignment = Assignment.find(@team.parent_id)
@teams_users = TeamsUser.page(params[:page]).per_page(10).where(['team_id = ?', params[:id]])
end

def new
@team = Team.find(params[:id])
end

def create
user = User.find_by(name: params[:user][:name].strip)
unless user
urlCreate = url_for controller: 'users', action: 'new'
flash[:error] = "\"#{params[:user][:name].strip}\" is not defined. Please <a href=\"#{urlCreate}\">create</a> this user before continuing."
end

team = Team.find(params[:id])
unless user.nil?
if team.is_a?(AssignmentTeam)
assignment = Assignment.find(team.parent_id)
if assignment.user_on_team?(user)
flash[:error] = "This user is already assigned to a team for this assignment"
redirect_back fallback_location: root_path
return
end
if AssignmentParticipant.find_by(user_id: user.id, parent_id: assignment.id).nil?
urlAssignmentParticipantList = url_for controller: 'participants', action: 'list', id: assignment.id, model: 'Assignment', authorization: 'participant'
flash[:error] = "\"#{user.name}\" is not a participant of the current assignment. Please <a href=\"#{urlAssignmentParticipantList}\">add</a> this user before continuing."
else
begin
add_member_return = team.add_member(user, team.parent_id)
rescue
flash[:error] = "The user #{user.name} is already a member of the team #{team.name}"
redirect_back fallback_location: root_path
return
end
flash[:error] = 'This team already has the maximum number of members.' if add_member_return == false
# E2115 Mentor Management
# Kick off the Mentor Management workflow
# Note: this is _not_ supported for CourseTeams which is why the other
# half of this if block does not include the same code
if add_member_return
user = TeamsUser.last
undo_link("The team @teams_user \"#{user.name}\" has been successfully added to \"#{team.name}\".")
MentorManagement.assign_mentor(assignment.id, team.id)
end
end
else # CourseTeam
course = Course.find(team.parent_id)
if course.user_on_team?(user)
flash[:error] = "This user is already assigned to a team for this course"
redirect_back fallback_location: root_path
return
end
if CourseParticipant.find_by(user_id: user.id, parent_id: course.id).nil?
urlCourseParticipantList = url_for controller: 'participants', action: 'list', id: course.id, model: 'Course', authorization: 'participant'
flash[:error] = "\"#{user.name}\" is not a participant of the current course. Please <a href=\"#{urlCourseParticipantList}\">add</a> this user before continuing."
else
begin
add_member_return = team.add_member(user, team.parent_id)
rescue
flash[:error] = "The user #{user.name} is already a member of the team #{team.name}"
redirect_back fallback_location: root_path
return
end
flash[:error] = 'This team already has the maximum number of members.' if add_member_return == false
if add_member_return
@teams_user = TeamsUser.last
undo_link("The team user \"#{user.name}\" has been successfully added to \"#{team.name}\".")
end
end
end
end

redirect_to controller: 'teams', action: 'list', id: team.parent_id
end

def delete
@teams_user = TeamsUser.find(params[:id])
parent_id = Team.find(@teams_user.team_id).parent_id
@user = User.find(@teams_user.user_id)
@teams_user.destroy
undo_link("The team user \"#{@user.name}\" has been successfully removed. ")
redirect_to controller: 'teams', action: 'list', id: parent_id
end

def delete_selected
params[:item].each do |item_id|
team_user = TeamsUser.find(item_id).first
team_user.destroy
end

redirect_to action: 'list', id: params[:id]
end
end
</pre>

===Testing Plan===
The TeamsUsers model and controller will be tested using Rspec. FactoryBot will be utilized to create test fixtures and to build the required models. As the methods in the controller are defined as RESTful endpoints. The test take into consideration that the methods return the correct status codes for the output. Based on the current functionality of TeamsUsers model and controller we have defined the following test which are implemented to test the reimplemented code of teams_users model and controller.

{| class="wikitable" style="margin-left:40px"
|-
! Test No. !! Description
|-
| 1 || Tests if `#update_duties` updates duties for a participant successfully and redirects to '/student_teams/view?student_id=1'.
|-
| 2 || Tests if `#list` renders the list of users under Assignment team teams#users.
|-
| 3 || Tests if `#new` sets the Team object to an instance variable.
|-
| 4 || Tests if `#create` (User Not Defined) throws an error and redirects to 'http://test.host/teams/list?id=1' when a user is not defined.
|-
| 5 || Tests if `#create` (User Not a Participant) throws an error and redirects to 'http://test.host/teams/list?id=1' when the user added is not a participant of the current assignment.
|-
| 6 || Tests if `#create` (Assignment Team Full) throws an error 'This team already has the maximum number of members.' and redirects to 'http://test.host/teams/list?id=1'.
|-
| 7 || Tests if `#create` (User Successfully Added) new user gets successfully added to the assignment and redirects to 'http://test.host/teams/list?id=1'.
|-
| 8 || Tests if `#delete` deletes a user and redirects to 'http://test.host/teams/list?id=1'.
|-
| 9 || Tests if `#delete_selected` deletes selected users and redirects to 'http://test.host/teams_users/list'.
|}

===Relevant Links===
Github Repository: https://github.com/Kashika08/reimplementation-back-end

===Team Members===
*Jay Shah (github: jayjshah2000)

*Kashika Malick (github: kashika08)

*Riya Gori (github: riyagori1203)

===Mentor===
Kartiki Bhandakkar

CSC/ECE 517 Fall 2023 - E2386. Reimplement teams users backend

2023-11-16T02:26:14Z

Kmalick:

===Description of Project===

The focal point of the project is the Team_user model, capturing information about mentors, team members, and affiliations with other models such as Users and Teams. This model undertakes various responsibilities, including the formation of teams with enrolled students and the display of team members. Oversight of team management falls under the purview of the Team_user_controller, which orchestrates CRUD operations on the Team_user model. Its duties span the creation, modification, and deletion of teams, along with the administration of team members through additions or removals. Furthermore, the controller provides a list of mentors associated with Team_users.

===Problem Statement===

The project involves creating a backend system for seamless CRUD operations on a relational database, specifically focusing on interactions between teams and users. This requires defining "Team_Users" model with suitable attributes and relationships, establishing controllers to manage CRUD actions, and setting up corresponding routes. Emphasis is placed on rigorous testing, covering model validations and associations, as well as controller actions to ensure accurate execution of CRUD operations. A key project aspect involves refining code to produce precise JSON responses. Adhering to RESTful conventions, the re-implementation includes appropriate HTTP response codes. RSpec tests are mandatory for both the Team_Users model and TeamUsersController, covering all endpoints and incorporating HTTP response codes. These controller tests are designed to integrate seamlessly with RSwag for generating API documentation and testing REST APIs through the Swagger UI.

===Objectives===

*Craft RESTful endpoints for creating, displaying, and deleting invitations, along with approving new invitations. Additionally, provide functionality for listing pending invitations, creating new invitations, and notifying students about newly formed team invitations.

*Develop and integrate methods within the Team_usersController to facilitate invitation-related operations, including creating, accepting, declining, and canceling invitations. Ensure thorough checks of user and team statuses before initiating or accepting invitations.

*Establish a user-invitation system that empowers invited users to accept, decline, or cancel invitations, triggering corresponding updates to the associated Team_user records. This should seamlessly manage the addition or removal of users from teams.

*Implement an email notification system within the user-invitation framework, sending email notifications to invited users upon the issuance of new invitations.

*Enforce the use of proper status codes and robust validation mechanisms for all RESTful endpoints.

*Construct models and controllers for the Team_user model, incorporating contemporary approaches to writing Ruby code. This involves leveraging language features and adhering to best practices for object-oriented design.

*Compose comprehensive RSpec tests covering all APIs, models, and controllers to ensure the robustness and reliability of the entire system.

===Development Strategy===

Our development strategy adheres to the principles of Test-Driven Development (TDD) for the implementation of both the Invitation model and the Invitation Controller. The process begins with the creation of a failing test case, followed by the addition of code to address the identified issues and ensure the successful passage of the test.

Furthermore, we align with the Rails philosophy of "Fat models," aiming to migrate substantial business logic from the controller to the model. This approach is intended to maintain a clean and organized controller codebase while promoting code reusability throughout the application.

===Project Design and Implementation===

Considering the existing functionality of the Team_user model and controller, we have outlined a set of RESTful endpoints along with their corresponding request types for implementation. In the controller, we plan to adopt the Strategy Pattern, leveraging its ability to encapsulate controller actions and facilitate easy extensibility and usability. This pattern will enable a structured approach to defining and managing the various operations the controller can perform.

==== Functionality ====
In this project, we aim to add functions for the following:

1. Retrieve and display team members.

2. Add a new team member with checks for user existence and team limits.

3. Delete a specific team member.

4. Delete multiple selected team members based on item IDs.

5. Autocomplete functionality for user names within a team.

6. Updating duties of a team member.

===Testing Plan===
The TeamsUsers model and controller will be tested using Rspec. FactoryBot will be utilized to create test fixtures and to build the required models. As the methods in the controller are defined as RESTful endpoints. The test take into consideration that the methods return the correct status codes for the output. Based on the current functionality of TeamsUsers model and controller we have defined the following test which are implemented to test the reimplemented code of teams_users model and controller.

{| class="wikitable" style="margin-left:40px"
|-
! Test No. !! Description
|-
| 1 || Tests if `#update_duties` updates duties for a participant successfully and redirects to '/student_teams/view?student_id=1'.
|-
| 2 || Tests if `#list` renders the list of users under Assignment team teams#users.
|-
| 3 || Tests if `#new` sets the Team object to an instance variable.
|-
| 4 || Tests if `#create` (User Not Defined) throws an error and redirects to 'http://test.host/teams/list?id=1' when a user is not defined.
|-
| 5 || Tests if `#create` (User Not a Participant) throws an error and redirects to 'http://test.host/teams/list?id=1' when the user added is not a participant of the current assignment.
|-
| 6 || Tests if `#create` (Assignment Team Full) throws an error 'This team already has the maximum number of members.' and redirects to 'http://test.host/teams/list?id=1'.
|-
| 7 || Tests if `#create` (User Successfully Added) new user gets successfully added to the assignment and redirects to 'http://test.host/teams/list?id=1'.
|-
| 8 || Tests if `#delete` deletes a user and redirects to 'http://test.host/teams/list?id=1'.
|-
| 9 || Tests if `#delete_selected` deletes selected users and redirects to 'http://test.host/teams_users/list'.
|}

===Relevant Links===
Github Repository: https://github.com/Kashika08/reimplementation-back-end

===Team Members===
*Jay Shah (github: jayjshah2000)

*Kashika Malick (github: kashika08)

*Riya Gori (github: riyagori1203)

===Mentor===
Kartiki Bhandakkar

CSC/ECE 517 Fall 2023 - E2386. Reimplement teams users backend

2023-11-16T02:23:46Z

Kmalick:

===Description of Project===

The focal point of the project is the Team_user model, capturing information about mentors, team members, and affiliations with other models such as Users and Teams. This model undertakes various responsibilities, including the formation of teams with enrolled students and the display of team members. Oversight of team management falls under the purview of the Team_user_controller, which orchestrates CRUD operations on the Team_user model. Its duties span the creation, modification, and deletion of teams, along with the administration of team members through additions or removals. Furthermore, the controller provides a list of mentors associated with Team_users.

===Problem Statement===

The project involves creating a backend system for seamless CRUD operations on a relational database, specifically focusing on interactions between teams and users. This requires defining "Team_Users" model with suitable attributes and relationships, establishing controllers to manage CRUD actions, and setting up corresponding routes. Emphasis is placed on rigorous testing, covering model validations and associations, as well as controller actions to ensure accurate execution of CRUD operations. A key project aspect involves refining code to produce precise JSON responses. Adhering to RESTful conventions, the re-implementation includes appropriate HTTP response codes. RSpec tests are mandatory for both the Team_Users model and TeamUsersController, covering all endpoints and incorporating HTTP response codes. These controller tests are designed to integrate seamlessly with RSwag for generating API documentation and testing REST APIs through the Swagger UI.

===Objectives===

*Craft RESTful endpoints for creating, displaying, and deleting invitations, along with approving new invitations. Additionally, provide functionality for listing pending invitations, creating new invitations, and notifying students about newly formed team invitations.

*Develop and integrate methods within the Team_usersController to facilitate invitation-related operations, including creating, accepting, declining, and canceling invitations. Ensure thorough checks of user and team statuses before initiating or accepting invitations.

*Establish a user-invitation system that empowers invited users to accept, decline, or cancel invitations, triggering corresponding updates to the associated Team_user records. This should seamlessly manage the addition or removal of users from teams.

*Implement an email notification system within the user-invitation framework, sending email notifications to invited users upon the issuance of new invitations.

*Enforce the use of proper status codes and robust validation mechanisms for all RESTful endpoints.

*Construct models and controllers for the Team_user model, incorporating contemporary approaches to writing Ruby code. This involves leveraging language features and adhering to best practices for object-oriented design.

*Compose comprehensive RSpec tests covering all APIs, models, and controllers to ensure the robustness and reliability of the entire system.

===Development Strategy===

Our development strategy adheres to the principles of Test-Driven Development (TDD) for the implementation of both the Invitation model and the Invitation Controller. The process begins with the creation of a failing test case, followed by the addition of code to address the identified issues and ensure the successful passage of the test.

Furthermore, we align with the Rails philosophy of "Fat models," aiming to migrate substantial business logic from the controller to the model. This approach is intended to maintain a clean and organized controller codebase while promoting code reusability throughout the application.

===Project Design and Implementation===

Considering the existing functionality of the Team_user model and controller, we have outlined a set of RESTful endpoints along with their corresponding request types for implementation. In the controller, we plan to adopt the Strategy Pattern, leveraging its ability to encapsulate controller actions and facilitate easy extensibility and usability. This pattern will enable a structured approach to defining and managing the various operations the controller can perform.

==== Functionality ====
In this project, we aim to add functions for the following:

1. Retrieve and display team members.

2. Add a new team member with checks for user existence and team limits.

3. Delete a specific team member.

4. Delete multiple selected team members based on item IDs.

5. Autocomplete functionality for user names within a team.

6. Updating duties of a team member.

===Testing Plan===
The TeamsUsers model and controller will be tested using Rspec. FactoryBot will be utilized to create test fixtures and to build the required models. As the methods in the controller are defined as RESTful endpoints. The test take into consideration that the methods return the correct status codes for the output. Based on the current functionality of TeamsUsers model and controller we have defined the following test which are implemented to test the reimplemented code of teams_users model and controller.

|| Sr No || Test || Description ||
| 1 | `#update_duties` | Updates duties for a participant successfully and redirects to '/student_teams/view?student_id=1'. |
| 2 | `#list` | Renders the list of users under Assignment team teams#users. |
| 3 | `#new` | Sets the Team object to an instance variable. |
| 4 | `#create` (User Not Defined) | Throws an error and redirects to 'http://test.host/teams/list?id=1' when a user is not defined. |
| 5 | `#create` (User Not a Participant) | Throws an error and redirects to 'http://test.host/teams/list?id=1' when the user added is not a participant of the current assignment. |
| 6 | `#create` (Assignment Team Full) | Throws an error 'This team already has the maximum number of members.' and redirects to 'http://test.host/teams/list?id=1'. |
| 7 | `#create` (User Successfully Added) | New user gets successfully added to the assignment and redirects to 'http://test.host/teams/list?id=1'. |
| 8 | `#delete` | Deletes a user and redirects to 'http://test.host/teams/list?id=1'. |
| 9 | `#delete_selected` | Deletes selected users and redirects to 'http://test.host/teams_users/list'. |

===Relevant Links===
Github Repository: https://github.com/Kashika08/reimplementation-back-end

===Team Members===
*Jay Shah (github: jayjshah2000)

*Kashika Malick (github: kashika08)

*Riya Gori (github: riyagori1203)

===Mentor===
Kartiki Bhandakkar

CSC/ECE 517 Fall 2023 - E2386. Reimplement teams users backend

2023-11-16T00:02:33Z

Kmalick:

===Description of Project===

The focal point of the project is the Team_user model, capturing information about mentors, team members, and affiliations with other models such as Users and Teams. This model undertakes various responsibilities, including the formation of teams with enrolled students and the display of team members. Oversight of team management falls under the purview of the Team_user_controller, which orchestrates CRUD operations on the Team_user model. Its duties span the creation, modification, and deletion of teams, along with the administration of team members through additions or removals. Furthermore, the controller provides a list of mentors associated with Team_users.

===Problem Statement===

The project involves creating a backend system for seamless CRUD operations on a relational database, specifically focusing on interactions between teams and users. This requires defining "Team_Users" model with suitable attributes and relationships, establishing controllers to manage CRUD actions, and setting up corresponding routes. Emphasis is placed on rigorous testing, covering model validations and associations, as well as controller actions to ensure accurate execution of CRUD operations. A key project aspect involves refining code to produce precise JSON responses. Adhering to RESTful conventions, the re-implementation includes appropriate HTTP response codes. RSpec tests are mandatory for both the Team_Users model and TeamUsersController, covering all endpoints and incorporating HTTP response codes. These controller tests are designed to integrate seamlessly with RSwag for generating API documentation and testing REST APIs through the Swagger UI.

===Objectives===

*Craft RESTful endpoints for creating, displaying, and deleting invitations, along with approving new invitations. Additionally, provide functionality for listing pending invitations, creating new invitations, and notifying students about newly formed team invitations.

*Develop and integrate methods within the Team_usersController to facilitate invitation-related operations, including creating, accepting, declining, and canceling invitations. Ensure thorough checks of user and team statuses before initiating or accepting invitations.

*Establish a user-invitation system that empowers invited users to accept, decline, or cancel invitations, triggering corresponding updates to the associated Team_user records. This should seamlessly manage the addition or removal of users from teams.

*Implement an email notification system within the user-invitation framework, sending email notifications to invited users upon the issuance of new invitations.

*Enforce the use of proper status codes and robust validation mechanisms for all RESTful endpoints.

*Construct models and controllers for the Team_user model, incorporating contemporary approaches to writing Ruby code. This involves leveraging language features and adhering to best practices for object-oriented design.

*Compose comprehensive RSpec tests covering all APIs, models, and controllers to ensure the robustness and reliability of the entire system.

===Development Strategy===

Our development strategy adheres to the principles of Test-Driven Development (TDD) for the implementation of both the Invitation model and the Invitation Controller. The process begins with the creation of a failing test case, followed by the addition of code to address the identified issues and ensure the successful passage of the test.

Furthermore, we align with the Rails philosophy of "Fat models," aiming to migrate substantial business logic from the controller to the model. This approach is intended to maintain a clean and organized controller codebase while promoting code reusability throughout the application.

===Project Design and Implementation===

Considering the existing functionality of the Team_user model and controller, we have outlined a set of RESTful endpoints along with their corresponding request types for implementation. In the controller, we plan to adopt the Strategy Pattern, leveraging its ability to encapsulate controller actions and facilitate easy extensibility and usability. This pattern will enable a structured approach to defining and managing the various operations the controller can perform.

==== Functionality ====
In this project, we aim to add functions for the following:

1. Retrieve and display team members.

2. Add a new team member with checks for user existence and team limits.

3. Delete a specific team member.

4. Delete multiple selected team members based on item IDs.

5. Autocomplete functionality for user names within a team.

6. Updating duties of a team member.

===Testing Plan===
The TeamsUsers model and controller will be tested using Rspec. FactoryBot will be utilized to create test fixtures and to build the required models. As the methods in the controller are defined as RESTful endpoints. The test take into consideration that the methods return the correct status codes for the output. Based on the current functionality of TeamsUsers model and controller we have defined the following test which are implemented to test the reimplemented code of teams_users model and controller.

===Relevant Links===
Github Repository: https://github.com/Kashika08/reimplementation-back-end

===Team Members===
*Jay Shah (github: jayjshah2000)

*Kashika Malick (github: kashika08)

*Riya Gori (github: riyagori1203)

===Mentor===
Kartiki Bhandakkar

CSC/ECE 517 Fall 2023 - E2386. Reimplement teams users backend

2023-11-16T00:01:59Z

Kmalick: /* Team Members */

===Description of Project===

The focal point of the project is the Team_user model, capturing information about mentors, team members, and affiliations with other models such as Users and Teams. This model undertakes various responsibilities, including the formation of teams with enrolled students and the display of team members. Oversight of team management falls under the purview of the Team_user_controller, which orchestrates CRUD operations on the Team_user model. Its duties span the creation, modification, and deletion of teams, along with the administration of team members through additions or removals. Furthermore, the controller provides a list of mentors associated with Team_users.

===Problem Statement===

The project involves creating a backend system for seamless CRUD operations on a relational database, specifically focusing on interactions between teams and users. This requires defining "Team_Users" model with suitable attributes and relationships, establishing controllers to manage CRUD actions, and setting up corresponding routes. Emphasis is placed on rigorous testing, covering model validations and associations, as well as controller actions to ensure accurate execution of CRUD operations. A key project aspect involves refining code to produce precise JSON responses. Adhering to RESTful conventions, the re-implementation includes appropriate HTTP response codes. RSpec tests are mandatory for both the Team_Users model and TeamUsersController, covering all endpoints and incorporating HTTP response codes. These controller tests are designed to integrate seamlessly with RSwag for generating API documentation and testing REST APIs through the Swagger UI.

===Objectives===

*Craft RESTful endpoints for creating, displaying, and deleting invitations, along with approving new invitations. Additionally, provide functionality for listing pending invitations, creating new invitations, and notifying students about newly formed team invitations.

*Develop and integrate methods within the Team_usersController to facilitate invitation-related operations, including creating, accepting, declining, and canceling invitations. Ensure thorough checks of user and team statuses before initiating or accepting invitations.

*Establish a user-invitation system that empowers invited users to accept, decline, or cancel invitations, triggering corresponding updates to the associated Team_user records. This should seamlessly manage the addition or removal of users from teams.

*Implement an email notification system within the user-invitation framework, sending email notifications to invited users upon the issuance of new invitations.

*Enforce the use of proper status codes and robust validation mechanisms for all RESTful endpoints.

*Construct models and controllers for the Team_user model, incorporating contemporary approaches to writing Ruby code. This involves leveraging language features and adhering to best practices for object-oriented design.

*Compose comprehensive RSpec tests covering all APIs, models, and controllers to ensure the robustness and reliability of the entire system.

===Development Strategy===

Our development strategy adheres to the principles of Test-Driven Development (TDD) for the implementation of both the Invitation model and the Invitation Controller. The process begins with the creation of a failing test case, followed by the addition of code to address the identified issues and ensure the successful passage of the test.

Furthermore, we align with the Rails philosophy of "Fat models," aiming to migrate substantial business logic from the controller to the model. This approach is intended to maintain a clean and organized controller codebase while promoting code reusability throughout the application.

===Project Design and Implementation===

Considering the existing functionality of the Team_user model and controller, we have outlined a set of RESTful endpoints along with their corresponding request types for implementation. In the controller, we plan to adopt the Strategy Pattern, leveraging its ability to encapsulate controller actions and facilitate easy extensibility and usability. This pattern will enable a structured approach to defining and managing the various operations the controller can perform.

==== Functionality ====
In this project, we aim to add functions for the following:

1. Retrieve and display team members.

2. Add a new team member with checks for user existence and team limits.

3. Delete a specific team member.

4. Delete multiple selected team members based on item IDs.

5. Autocomplete functionality for user names within a team.

6. Updating duties of a team member.

===Testing Plan===
The TeamsUsers model and controller will be tested using Rspec. FactoryBot will be utilized to create test fixtures and to build the required models. As the methods in the controller are defined as RESTful endpoints. The test take into consideration that the methods return the correct status codes for the output. Based on the current functionality of TeamsUsers model and controller we have defined the following test which are implemented to test the reimplemented code of teams_users model and controller.

===Relevant Links===
Github Repository: https://github.com/Kashika08/reimplementation-back-end

===Team Members===
Jay Shah (github: jayjshah2000)

Kashika Malick (github: kashika08)

Riya Gori (github: riyagori1203)

===Mentor===
Kartiki Bhandakkar

CSC/ECE 517 Fall 2023 - E2386. Reimplement teams users backend

2023-11-16T00:01:20Z

Kmalick:

===Description of Project===

The focal point of the project is the Team_user model, capturing information about mentors, team members, and affiliations with other models such as Users and Teams. This model undertakes various responsibilities, including the formation of teams with enrolled students and the display of team members. Oversight of team management falls under the purview of the Team_user_controller, which orchestrates CRUD operations on the Team_user model. Its duties span the creation, modification, and deletion of teams, along with the administration of team members through additions or removals. Furthermore, the controller provides a list of mentors associated with Team_users.

===Problem Statement===

The project involves creating a backend system for seamless CRUD operations on a relational database, specifically focusing on interactions between teams and users. This requires defining "Team_Users" model with suitable attributes and relationships, establishing controllers to manage CRUD actions, and setting up corresponding routes. Emphasis is placed on rigorous testing, covering model validations and associations, as well as controller actions to ensure accurate execution of CRUD operations. A key project aspect involves refining code to produce precise JSON responses. Adhering to RESTful conventions, the re-implementation includes appropriate HTTP response codes. RSpec tests are mandatory for both the Team_Users model and TeamUsersController, covering all endpoints and incorporating HTTP response codes. These controller tests are designed to integrate seamlessly with RSwag for generating API documentation and testing REST APIs through the Swagger UI.

===Objectives===

*Craft RESTful endpoints for creating, displaying, and deleting invitations, along with approving new invitations. Additionally, provide functionality for listing pending invitations, creating new invitations, and notifying students about newly formed team invitations.

*Develop and integrate methods within the Team_usersController to facilitate invitation-related operations, including creating, accepting, declining, and canceling invitations. Ensure thorough checks of user and team statuses before initiating or accepting invitations.

*Establish a user-invitation system that empowers invited users to accept, decline, or cancel invitations, triggering corresponding updates to the associated Team_user records. This should seamlessly manage the addition or removal of users from teams.

*Implement an email notification system within the user-invitation framework, sending email notifications to invited users upon the issuance of new invitations.

*Enforce the use of proper status codes and robust validation mechanisms for all RESTful endpoints.

*Construct models and controllers for the Team_user model, incorporating contemporary approaches to writing Ruby code. This involves leveraging language features and adhering to best practices for object-oriented design.

*Compose comprehensive RSpec tests covering all APIs, models, and controllers to ensure the robustness and reliability of the entire system.

===Development Strategy===

Our development strategy adheres to the principles of Test-Driven Development (TDD) for the implementation of both the Invitation model and the Invitation Controller. The process begins with the creation of a failing test case, followed by the addition of code to address the identified issues and ensure the successful passage of the test.

Furthermore, we align with the Rails philosophy of "Fat models," aiming to migrate substantial business logic from the controller to the model. This approach is intended to maintain a clean and organized controller codebase while promoting code reusability throughout the application.

===Project Design and Implementation===

Considering the existing functionality of the Team_user model and controller, we have outlined a set of RESTful endpoints along with their corresponding request types for implementation. In the controller, we plan to adopt the Strategy Pattern, leveraging its ability to encapsulate controller actions and facilitate easy extensibility and usability. This pattern will enable a structured approach to defining and managing the various operations the controller can perform.

==== Functionality ====
In this project, we aim to add functions for the following:

1. Retrieve and display team members.

2. Add a new team member with checks for user existence and team limits.

3. Delete a specific team member.

4. Delete multiple selected team members based on item IDs.

5. Autocomplete functionality for user names within a team.

6. Updating duties of a team member.

===Testing Plan===
The TeamsUsers model and controller will be tested using Rspec. FactoryBot will be utilized to create test fixtures and to build the required models. As the methods in the controller are defined as RESTful endpoints. The test take into consideration that the methods return the correct status codes for the output. Based on the current functionality of TeamsUsers model and controller we have defined the following test which are implemented to test the reimplemented code of teams_users model and controller.

===Relevant Links===
Github Repository: https://github.com/Kashika08/reimplementation-back-end

===Team Members===
Jay Shah (github: jayjshah2000)
Kashika Malick (github: kashika08)
Riya Gori (github: riyagori1203)

===Mentor===
Kartiki Bhandakkar

CSC/ECE 517 Fall 2023 - E2386. Reimplement teams users backend

2023-11-15T23:52:51Z

Kmalick:

CSC/ECE 517 Fall 2023 - E2386. Reimplement teams users backend

2023-11-15T18:48:32Z

Kmalick: /* Description of Project */

CSC/ECE 517 Fall 2023 - E2386. Reimplement teams users backend

2023-11-15T18:48:15Z

Kmalick: