Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T02:37:14Z

Slkwiatk: /* Mailer Tests */

== Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project. Instructors have the ability to add new projects, assignments, etc., as well as edit existing ones. Later on, they can view student submissions and grade them. Students can also use Expertiza to organize into teams to work on different projects and assignments and submit their work. They can also review other students' submissions.

== Introduction ==
This project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management/ E2304] for the implementation of the Mentor-meeting management in the Expertiza system for mentored teams. We are now required to add functionality to add mentors to the topics and then assign them to the teams when they pick up that topic.

== Problem Statement ==
The following tasks are required for the project:
#Enhancing Code Clarity: This involves renaming methods from Project 3 with ambiguous names, optimizing loops and adding comments for unclear lines of code
#Reimplement Mentored teams: Reimplement the Mentored team delegate to the Assignment team to reduce complexity and to follow best principles of Object Oriented Design
#Reimplement Sign Up Sheet or Topics: Reimplement the SignUpSheet controller to automatically add the mentor to when a topic is created and automatically assign the same mentor to a team when they choose the topic
#Writing tests for mentor meetings models: More tests have to be written for Mentor Meeting model
#Writing tests for the mentor meetings controller: More tests should be written for Mentor meeting controller
#Writing tests for the signup sheet controller: Additional tests should be written for signup sheet controller to test the new functionality

== Objectives ==
We have 3 main objectives for this project.
* Refactoring of the Mentor-meeting model and controller created for the Project 3
* Reimplementation of Mentored Teams model and controller for the Project 4
* Reimplementation of SignUp Sheet controller for the Project 4 to automatically assign mentors to the topics

== Design Goal ==
While fulfilling all the objectives, the following design rules have to be ensured:
* Validate proper functioning of all existing and anticipated methods, making any required enhancements or adjustments.
* Establish loose coupling and tight cohesion for the model and controller to enhance code organization and maintainability.
* Refactor redundant code in the previous implementation's controller and model methods using DRY principle, eliminating functionality duplication already present in the Expertiza system.
* Confirm the continued effectiveness of existing test cases following the aforementioned modifications and generate additional test cases as per the need.

== Class UML Diagram ==
[[File:OODD Proj4 E2403 - Entity Diagram 2.png ‎| 610px]]

== Classes and Relationships ==
=== Existing Structure ===
* Every Assignment has a Node
* Every Assignment has many AssignmentTeam and MentoredTeam
* AssignmentTeam is inherited from Team
* MentoredTeam is inherited from AssignmentTeam
* Every MentoredTeam has many MentorMeeting
=== Proposed Structure Structure ===
* MentoredTeam to be delegated from AssignmentTeam instead of inheriting from it

== Implementation Plan ==
=== Modify newly created controller, model and view ===
==== mentor_meeting_controller.rb ====
* Edit function names to make them more descriptive
* Add more descriptive comments for the functions
==== mentor_meetings_helper.rb ====
* Move the "get_dates_for_team" function to the model
* Rename the function to make it more descriptive
==== _entry_assignments.html.erb ====
* Add more descriptive comments for the JavaScript functions
* Move the Ruby code from the template to a helper or the controller
==== mentored_team.rb --> mentored_team_decorator ====
* To reduce DRY violations, the mentored team class was changed to the mentored team decorator class.
*

=== Modify existing controller model and view ===
==== teams/_team.html.erb ====
* As the mentored team will now be delegated from the assignment team, we need to change the if condition on the top as we are changing MentoredTeam to be delegated from the AssignmentTeam
==== teams_controller.rb ====
* This file has to be modified to work with the delegated MentoredTeam
* These lines will not work as MentoredTeam will not be a model
[[File:Teams con1.png ‎| 600px]]
==== sign_up_sheet_controller.rb ====
* This controller has to be modified to automatically assign mentors or manually add mentors to the topics when they are created
* This will be followed by a change in schema
[[File:Signup con1.png | 600px]]
==== _topic.html.erb ====
* If we manually have to assign mentors to the topic, we have to include a input field to enter the mentor
[[File:Topic html.png | 600px]]
==== schema.rb ====
* As we are adding a new field to the table, we need to modify the schema
* We need to write 1 migration to add the field to the table to update the schema file
[[File:Schema E2403.png | 600px]]

=== Mailer Changes ===
====team.rb====
* The team model must be altered to use delegation for cases where a team would previously be a mentored team.
====add_member====
* The add member function must be altered such that the call to mail a user is better named, and that it calls directly to the mailer rather than the mailer helper.
[[File:add_member_email.png | 900px]]
====mailer_helper====
* The mailer_helper will be altered such that the send_team_confimration_to_user will be moved and renamed in the Mailer.rb class instead since using generic_message as such is leading to an unclear design.
[[File:team_confirm.png | 900px]]

====mailer.rb====
* A new function to specifically handle messaging users when added to teams will be built in the mailer, rather than just overusing the generic_message function.

== UI Changes ==
=== UI Changes before Phase 2 code changes ===
* The mentored assignment teams page has the modified UI from the Phase 1 as it is also a mentored assignment
* But the teams do not have a TA as the automated assignment of mentors has not been implemented.
[[File:UI1 E2403.png | 600px]]

=== UI Changes after Phase 2 code changes ===
The mentored assignment teams with topic now has the new UI and the automated mentor assignment
* The form to create a new topic has a new field to assign mentor to a topic
[[File:UI2 E2403.png | 600px]]
* The updated UI showing the topics with the mentors and teams that have chosen the topic
* The mentor is also displayed with the team
[[File:UI3 E2403.png | 600px]]
* The assignment teams page has the modified UI from the Phase 1 as the teams have a mentor
[[File:UI4 E2403.png | 600px]]

== Implementation ==
=== Mailer Changes ===
==== Decorator ====
* To remove DRY violations, we transformed the MentoredTeam class into the MentoredTeamDecoratorClass.
[[File:MentoredTeamClass.png | 600px]] ---> [[File:MentoredTeamDecorator.png | 600px]]
* In particular this required changing the MentoredTeam to have its own assignment team variable.
* The add_member function's DRY violations with the Team Class were able to be eliminated here, as now the Mentored Team Decorator calls to the assignment team's add member function on line 14, and then simply calls to assign the mentor on line 16.

==== MailerHelper to Mailer ====
* To increase understandability and consistency between classes, we removed the send_team_confirmation_mail function from the MailerHelper, and instead replaced its functionality with the team_addition_message function in the Mailer class. We found this to be the ideal location as the Mailer class houses many other specific message functions such as notify_grade_conflict_message, suggested_topic_approved_message and more.
[[File:team_confirm.png | 600px]] ---> [[File:Team_Addtion_Message.png | 600px]]

==== Team Add_Member ====
* The add_member function was altered in a couple of different ways. Firstly, we parameterized the partial_name in the call to the function that actually sends the mail, as in the original code we were violating the DRY principle by repeating the same MailerHelper call twice with very little change between them.
* Additionally we removed the type check for whether a user is a participant or not, as most users should be participants.
[[File:add_member_email.png | 600px]] ---> [[File:New_Add_Message.png | 600px]]

=== Automatic topic mentor assignment changes ===
==== Team creation using decorator ====
* As we have moved the mentored team from a subclass of assignment team to being a decorator, we have modified the team creation code to assign the right type of class to the team
* If the team is a mentored team, we use the MentoredTeamDecorator to create the object of the Assignment class
[[File:Team Creation.png | 600px]]

==== Team deletion ====
* We have added the functionality to delete the Mentor meetings when the team is deleted
* If the team is a mentored team, we will find all the instances of mentor meetings for the team and delete them
* We have also modified the function to work as a independent function that can be called from any where in the application by passing a parameter
* When the parameter is not passed, it is used as a controller function to handle calls to a specific route
[[File:Team Deletion.png | 600px]]

==== Adding a user to a team ====
* We have modified the function to add an user to the team
* The create function in TeamsUsersController is modified
[[File:Team User Creation.png | 600px]]

==== Adding a mentor to a topic - Form and table ====
* We have added a field in the topics form to add a mentor to the topic in _topic.html.erb
[[File:Topic Form.png | 600px]]
* The table displaying the topics is also modified to have a column for the mentors in _table_header.html.erb
[[File:Topic Header.png | 600px]]
* The topic row also displays the team members with the mentor included in it in the topics table in _table_line.html.erb 
[[File:Topic Row.png | 600px]]

==== Adding a mentor to a topic - Functions ====
* We have modified the function to setup a new topic to include the functionality to add mentor to the topic
* In case we try to add a mentor who is not in the assignment or course, we add the mentor to the assignment and course too
* In this way we handle cases of adding mentors outside the course into the topic
[[File:Add Topic Mentor.png | 600px]]
* We have created some helper functions to assist in adding the mentor to the assignment and course
[[File:Addition Helpers.png | 600px]]

==== Automatic Mentor Assignment ====
* We have added additional function to assign the mentor of the topic to be automatically assigned to the team that chooses the topic
[[File:Auto Assign Topic Mentor.png | 600px]]
* The signup_as_instructor_action function will automatically call the assignment function to add the topic's mentor to the team
[[File:Call_Assign_Mentor.png | 600px]]

== Files Modified/Added ==
* app/controllers/sign_up_sheet_controller.rb
* app/controllers/teams_controller.rb
* app/controllers/teams_users_controller.rb
* app/models/course.rb
* app/models/mentor_management.rb
* app/views/sign_up_sheet/_table_header.html.erb
* app/views/sign_up_sheet/_table_line.html.erb
* app/views/sign_up_sheet/_topic.html.erb
* app/views/teams/_team.html.erb
* app/views/tree_display/_page_footer_assignments.html.erb
* app/views/tree_display/_entry_assignments.html.erb
* app/models/mentored_team_decorator.rb
* app/models/team.rb
* app/views/mailer/team_addition_message.html.erb
* app/views/mailer/team_addition_message.text.erb
* app/helpers/mailer_helper.rb
* app/mailers/mailer.rb
* spec/models/team_spec.rb
* spec/models/mentor_management_spec.rb

== Test Plan ==
When the project was pulled from the main repository, there are not enough tests to cover the additional functionalities that we added. We are planning on using the test skeletons by Mustafa Olmez, as a reference to how and what kind of tests should be written. Test cases for mentor management were already written and we wrote new test cases for the new functionalities we added. Here are the four test case scenarios we covered and the actual ruby code for the Rspec tests

=== Automated Rspec Testing Scenarios===
1. Test scenario 1: Given an assignment_id, When there are multiple mentors with different team counts for the assignment, Then it should return the mentor with the lowest team count
it "returns the mentor with the lowest team count for the given assignment" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 2]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

2. Test scenario 2: Given an assignment_id, When there is only one mentor available for the assignment, Then it should return that mentor
it "should return that mentor if there's only one available" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 0]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

3. Test scenario 3: Given an assignment_id, When there are multiple mentors with the same lowest team count for the assignment, Then it should return the first mentor in the list
it "returns the first mentor in the list if there's a tie for lowest team count" do
# Arrange
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 1],])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

4. Test scenario 4: Given an assignment_id, When there are no mentors available for the assignment, Then it should return nil
it "returns nil" do
# Create a new assignment
a = FactoryBot.create(:assignment, id: 997, directory_path: 'OSS_project', auto_assign_mentor: true)
# Since there are no mentors associated with this assignment, should return nil
expect(MentorManagement.select_mentor(a.id)).to eq nil
end

=== Mailer Tests ===
5. Test scenario 5: Given a mentor is being added to a team, then the mailer should be called to send the mentor-specific mail to the mentor
it 'sends mail to mentor if user is a mentor' do
allow(MentorManagement).to receive(:user_a_mentor?).with(user).and_return(true)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
allow(Mailer).to receive(:team_addition_message).and_return(double('Mail', deliver: true))
expect(Mailer).to receive(:team_addition_message).with(
to: user.email,
subject: '[Expertiza] Added to a Team',
body: {
user: user,
first_name: ApplicationHelper.get_user_first_name(user),
partial_name: 'mentor_added_to_team',
team: team.name.to_s,
assignment: ''
}
).and_return(double('Mail', deliver: true))
expect(team.add_member(user)).to be true
end

6. Test scenario 6: Given a normal user is being added to a team, then the mailer should be called to send the general user addition mail to the user
it 'sends mail to user if user is a user' do
allow(MentorManagement).to receive(:user_a_mentor?).with(user).and_return(true)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
allow(Mailer).to receive(:team_addition_message).and_return(double('Mail', deliver: true))
expect(Mailer).to receive(:team_addition_message).with(
to: user.email,
subject: '[Expertiza] Added to a Team',
body: {
user: user,
first_name: ApplicationHelper.get_user_first_name(user),
partial_name: 'user_added_to_team',
team: team.name.to_s,
assignment: ''
}
).and_return(double('Mail', deliver: true))
expect(team.add_member(user)).to be true
end

=== Manual UI Testing ===
Apart from the automated Rspec tests, we are providing manual testing cases that can be used to verify the functioning of the website.

Refer to the demo video on the bottom of the page to find help on testing these cases

==== Scenario 1 - Creating an mentored team ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Courses
# Assuming you have created a course and added participants to it, proceed to create a team
# Make sure "Auto assign mentors when team hits > 50% capacity?" option is checked
[[File:MT 1-1.png | 600px]]
* Create team for the assignment and you can see that the team with more than 50% capacity gets a mentor assigned automatically
[[File:MT 1-2.png | 600px]]

==== Scenario 2 - Adding, editing, deleting mentor meeting dates ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Assigments
# Assuming you have created a mentored assignment and added participants to it, proceed to the teams page
# Try entering dates into it teams row and the date should persist
# You can edit and delete the dates from the rows
# Team with less than 50% capacity will have the mentor meeting dates disabled
[[File:MT 2.png | 600px]]

==== Scenario 3 - Creating a team with topic ====
* Log into Expertiza using the test credential and navigate to the home page
* Go to Manage > Courses
* Assuming you have created a course and added participants to it, proceed to create a team
* Make sure "Has topics?" option is checked and a topic is created using the Topics tab
[[File:MT 3-1.png | 600px]]
* Create a new topic for the assignment and enter a mentor name to the topic
[[File:UI2 E2403.png | 600px]]
* When a student is added to the topic, the team of the student along with the mentor will be displayed in the topic row
[[File:UI3 E2403.png | 600px]]
* When navigating to the teams page of that assignment, you can see a mentor assigned automatically
[[File:UI4 E2403.png | 600px]]

==== Scenario 4 - Creating Team -> Recieve Emails ====
* Step 1 is to change line 45 of app/mailers/mailer from "defn[:to] = 'expertiza.mailer@gmail.com'" to "defn[:to] = '{Your Email}'". This is so that you can test that the emails are being sent.
[[File:Team_addition_fix.png | 600px]]
* Now head to an existing assignment that assigns mentors when team capacity is above 50%. Delete a team if there are no students left to be added to a team. Make sure there are mentors on the student list, if not, add at least 1. Count how many mentors and students will be added to teams when you create a team (in our case this will be 2 students and 1 mentor).
[[File:t_listz.png| 600px]]
* Auto-create teams with max participants.
[[File:cre_teams.png | 600px]]
* Wait a couple of minutes and then check the email address you entered in step 1. You should expect to receive x number of student emails, and y number of mentor emails, where x is the number of students just assigned to a team, and y is the number of mentors assigned to mentor a team. In our example below you can see that there are 2 distinct student emails, and 1 mentor email, which is as expected in our case. Don't forget to check your spam mail if you don't see the mail in your inbox after a few minutes.
[[File:email_case.png | 600px]]

== Test Coverage ==
We used SimpleCov to generate a coverage report for the Rspec test cases implemented for the model and controllers.
The test coverage indicated 1730 lines of code was covered through the test cases.

[[File:Testing E2403.png ‎| 600px]]

== Test Login Credentials ==
* UserId: instructor6
* Password: password

== Demo Video ==
TODO:: 
This is our [https://www.youtube.com/ demo video] which explain how to create courses, assignments, mentored teams and mentored teams with topics. This video also show how to run the tests of our code changes.

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2789

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

File:Email case.png

2024-04-24T02:35:59Z

Slkwiatk:

File:Cre teams.png

2024-04-24T02:35:46Z

Slkwiatk:

File:T listz.png

2024-04-24T02:35:35Z

Slkwiatk:

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T02:35:05Z

Slkwiatk: /* Scenario 4 - Creating Team -> Recieve Emails */

== Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project. Instructors have the ability to add new projects, assignments, etc., as well as edit existing ones. Later on, they can view student submissions and grade them. Students can also use Expertiza to organize into teams to work on different projects and assignments and submit their work. They can also review other students' submissions.

== Introduction ==
This project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management/ E2304] for the implementation of the Mentor-meeting management in the Expertiza system for mentored teams. We are now required to add functionality to add mentors to the topics and then assign them to the teams when they pick up that topic.

== Problem Statement ==
The following tasks are required for the project:
#Enhancing Code Clarity: This involves renaming methods from Project 3 with ambiguous names, optimizing loops and adding comments for unclear lines of code
#Reimplement Mentored teams: Reimplement the Mentored team delegate to the Assignment team to reduce complexity and to follow best principles of Object Oriented Design
#Reimplement Sign Up Sheet or Topics: Reimplement the SignUpSheet controller to automatically add the mentor to when a topic is created and automatically assign the same mentor to a team when they choose the topic
#Writing tests for mentor meetings models: More tests have to be written for Mentor Meeting model
#Writing tests for the mentor meetings controller: More tests should be written for Mentor meeting controller
#Writing tests for the signup sheet controller: Additional tests should be written for signup sheet controller to test the new functionality

== Objectives ==
We have 3 main objectives for this project.
* Refactoring of the Mentor-meeting model and controller created for the Project 3
* Reimplementation of Mentored Teams model and controller for the Project 4
* Reimplementation of SignUp Sheet controller for the Project 4 to automatically assign mentors to the topics

== Design Goal ==
While fulfilling all the objectives, the following design rules have to be ensured:
* Validate proper functioning of all existing and anticipated methods, making any required enhancements or adjustments.
* Establish loose coupling and tight cohesion for the model and controller to enhance code organization and maintainability.
* Refactor redundant code in the previous implementation's controller and model methods using DRY principle, eliminating functionality duplication already present in the Expertiza system.
* Confirm the continued effectiveness of existing test cases following the aforementioned modifications and generate additional test cases as per the need.

== Class UML Diagram ==
[[File:OODD Proj4 E2403 - Entity Diagram 2.png ‎| 610px]]

== Classes and Relationships ==
=== Existing Structure ===
* Every Assignment has a Node
* Every Assignment has many AssignmentTeam and MentoredTeam
* AssignmentTeam is inherited from Team
* MentoredTeam is inherited from AssignmentTeam
* Every MentoredTeam has many MentorMeeting
=== Proposed Structure Structure ===
* MentoredTeam to be delegated from AssignmentTeam instead of inheriting from it

== Implementation Plan ==
=== Modify newly created controller, model and view ===
==== mentor_meeting_controller.rb ====
* Edit function names to make them more descriptive
* Add more descriptive comments for the functions
==== mentor_meetings_helper.rb ====
* Move the "get_dates_for_team" function to the model
* Rename the function to make it more descriptive
==== _entry_assignments.html.erb ====
* Add more descriptive comments for the JavaScript functions
* Move the Ruby code from the template to a helper or the controller
==== mentored_team.rb --> mentored_team_decorator ====
* To reduce DRY violations, the mentored team class was changed to the mentored team decorator class.
*

=== Modify existing controller model and view ===
==== teams/_team.html.erb ====
* As the mentored team will now be delegated from the assignment team, we need to change the if condition on the top as we are changing MentoredTeam to be delegated from the AssignmentTeam
==== teams_controller.rb ====
* This file has to be modified to work with the delegated MentoredTeam
* These lines will not work as MentoredTeam will not be a model
[[File:Teams con1.png ‎| 600px]]
==== sign_up_sheet_controller.rb ====
* This controller has to be modified to automatically assign mentors or manually add mentors to the topics when they are created
* This will be followed by a change in schema
[[File:Signup con1.png | 600px]]
==== _topic.html.erb ====
* If we manually have to assign mentors to the topic, we have to include a input field to enter the mentor
[[File:Topic html.png | 600px]]
==== schema.rb ====
* As we are adding a new field to the table, we need to modify the schema
* We need to write 1 migration to add the field to the table to update the schema file
[[File:Schema E2403.png | 600px]]

=== Mailer Changes ===
====team.rb====
* The team model must be altered to use delegation for cases where a team would previously be a mentored team.
====add_member====
* The add member function must be altered such that the call to mail a user is better named, and that it calls directly to the mailer rather than the mailer helper.
[[File:add_member_email.png | 900px]]
====mailer_helper====
* The mailer_helper will be altered such that the send_team_confimration_to_user will be moved and renamed in the Mailer.rb class instead since using generic_message as such is leading to an unclear design.
[[File:team_confirm.png | 900px]]

====mailer.rb====
* A new function to specifically handle messaging users when added to teams will be built in the mailer, rather than just overusing the generic_message function.

== UI Changes ==
=== UI Changes before Phase 2 code changes ===
* The mentored assignment teams page has the modified UI from the Phase 1 as it is also a mentored assignment
* But the teams do not have a TA as the automated assignment of mentors has not been implemented.
[[File:UI1 E2403.png | 600px]]

=== UI Changes after Phase 2 code changes ===
The mentored assignment teams with topic now has the new UI and the automated mentor assignment
* The form to create a new topic has a new field to assign mentor to a topic
[[File:UI2 E2403.png | 600px]]
* The updated UI showing the topics with the mentors and teams that have chosen the topic
* The mentor is also displayed with the team
[[File:UI3 E2403.png | 600px]]
* The assignment teams page has the modified UI from the Phase 1 as the teams have a mentor
[[File:UI4 E2403.png | 600px]]

== Implementation ==
=== Mailer Changes ===
==== Decorator ====
* To remove DRY violations, we transformed the MentoredTeam class into the MentoredTeamDecoratorClass.
[[File:MentoredTeamClass.png | 600px]] ---> [[File:MentoredTeamDecorator.png | 600px]]
* In particular this required changing the MentoredTeam to have its own assignment team variable.
* The add_member function's DRY violations with the Team Class were able to be eliminated here, as now the Mentored Team Decorator calls to the assignment team's add member function on line 14, and then simply calls to assign the mentor on line 16.

==== MailerHelper to Mailer ====
* To increase understandability and consistency between classes, we removed the send_team_confirmation_mail function from the MailerHelper, and instead replaced its functionality with the team_addition_message function in the Mailer class. We found this to be the ideal location as the Mailer class houses many other specific message functions such as notify_grade_conflict_message, suggested_topic_approved_message and more.
[[File:team_confirm.png | 600px]] ---> [[File:Team_Addtion_Message.png | 600px]]

==== Team Add_Member ====
* The add_member function was altered in a couple of different ways. Firstly, we parameterized the partial_name in the call to the function that actually sends the mail, as in the original code we were violating the DRY principle by repeating the same MailerHelper call twice with very little change between them.
* Additionally we removed the type check for whether a user is a participant or not, as most users should be participants.
[[File:add_member_email.png | 600px]] ---> [[File:New_Add_Message.png | 600px]]

=== Automatic topic mentor assignment changes ===
==== Team creation using decorator ====
* As we have moved the mentored team from a subclass of assignment team to being a decorator, we have modified the team creation code to assign the right type of class to the team
* If the team is a mentored team, we use the MentoredTeamDecorator to create the object of the Assignment class
[[File:Team Creation.png | 600px]]

==== Team deletion ====
* We have added the functionality to delete the Mentor meetings when the team is deleted
* If the team is a mentored team, we will find all the instances of mentor meetings for the team and delete them
* We have also modified the function to work as a independent function that can be called from any where in the application by passing a parameter
* When the parameter is not passed, it is used as a controller function to handle calls to a specific route
[[File:Team Deletion.png | 600px]]

==== Adding a user to a team ====
* We have modified the function to add an user to the team
* The create function in TeamsUsersController is modified
[[File:Team User Creation.png | 600px]]

==== Adding a mentor to a topic - Form and table ====
* We have added a field in the topics form to add a mentor to the topic in _topic.html.erb
[[File:Topic Form.png | 600px]]
* The table displaying the topics is also modified to have a column for the mentors in _table_header.html.erb
[[File:Topic Header.png | 600px]]
* The topic row also displays the team members with the mentor included in it in the topics table in _table_line.html.erb 
[[File:Topic Row.png | 600px]]

==== Adding a mentor to a topic - Functions ====
* We have modified the function to setup a new topic to include the functionality to add mentor to the topic
* In case we try to add a mentor who is not in the assignment or course, we add the mentor to the assignment and course too
* In this way we handle cases of adding mentors outside the course into the topic
[[File:Add Topic Mentor.png | 600px]]
* We have created some helper functions to assist in adding the mentor to the assignment and course
[[File:Addition Helpers.png | 600px]]

==== Automatic Mentor Assignment ====
* We have added additional function to assign the mentor of the topic to be automatically assigned to the team that chooses the topic
[[File:Auto Assign Topic Mentor.png | 600px]]
* The signup_as_instructor_action function will automatically call the assignment function to add the topic's mentor to the team
[[File:Call_Assign_Mentor.png | 600px]]

== Files Modified/Added ==
* app/controllers/sign_up_sheet_controller.rb
* app/controllers/teams_controller.rb
* app/controllers/teams_users_controller.rb
* app/models/course.rb
* app/models/mentor_management.rb
* app/views/sign_up_sheet/_table_header.html.erb
* app/views/sign_up_sheet/_table_line.html.erb
* app/views/sign_up_sheet/_topic.html.erb
* app/views/teams/_team.html.erb
* app/views/tree_display/_page_footer_assignments.html.erb
* app/views/tree_display/_entry_assignments.html.erb
* app/models/mentored_team_decorator.rb
* app/models/team.rb
* app/views/mailer/team_addition_message.html.erb
* app/views/mailer/team_addition_message.text.erb
* app/helpers/mailer_helper.rb
* app/mailers/mailer.rb
* spec/models/team_spec.rb
* spec/models/mentor_management_spec.rb

== Test Plan ==
When the project was pulled from the main repository, there are not enough tests to cover the additional functionalities that we added. We are planning on using the test skeletons by Mustafa Olmez, as a reference to how and what kind of tests should be written. Test cases for mentor management were already written and we wrote new test cases for the new functionalities we added. Here are the four test case scenarios we covered and the actual ruby code for the Rspec tests

=== Automated Rspec Testing Scenarios===
1. Test scenario 1: Given an assignment_id, When there are multiple mentors with different team counts for the assignment, Then it should return the mentor with the lowest team count
it "returns the mentor with the lowest team count for the given assignment" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 2]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

2. Test scenario 2: Given an assignment_id, When there is only one mentor available for the assignment, Then it should return that mentor
it "should return that mentor if there's only one available" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 0]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

3. Test scenario 3: Given an assignment_id, When there are multiple mentors with the same lowest team count for the assignment, Then it should return the first mentor in the list
it "returns the first mentor in the list if there's a tie for lowest team count" do
# Arrange
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 1],])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

4. Test scenario 4: Given an assignment_id, When there are no mentors available for the assignment, Then it should return nil
it "returns nil" do
# Create a new assignment
a = FactoryBot.create(:assignment, id: 997, directory_path: 'OSS_project', auto_assign_mentor: true)
# Since there are no mentors associated with this assignment, should return nil
expect(MentorManagement.select_mentor(a.id)).to eq nil
end

== Mailer Tests ==
5. Test scenario 5: Given a mentor is being added to a team, then the mailer should be called to send the mentor-specific mail to the mentor
it 'sends mail to mentor if user is a mentor' do
allow(MentorManagement).to receive(:user_a_mentor?).with(user).and_return(true)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
allow(Mailer).to receive(:team_addition_message).and_return(double('Mail', deliver: true))
expect(Mailer).to receive(:team_addition_message).with(
to: user.email,
subject: '[Expertiza] Added to a Team',
body: {
user: user,
first_name: ApplicationHelper.get_user_first_name(user),
partial_name: 'mentor_added_to_team',
team: team.name.to_s,
assignment: ''
}
).and_return(double('Mail', deliver: true))
expect(team.add_member(user)).to be true
end

6. Test scenario 6: Given a normal user is being added to a team, then the mailer should be called to send the general user addition mail to the user
it 'sends mail to user if user is a user' do
allow(MentorManagement).to receive(:user_a_mentor?).with(user).and_return(true)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
allow(Mailer).to receive(:team_addition_message).and_return(double('Mail', deliver: true))
expect(Mailer).to receive(:team_addition_message).with(
to: user.email,
subject: '[Expertiza] Added to a Team',
body: {
user: user,
first_name: ApplicationHelper.get_user_first_name(user),
partial_name: 'user_added_to_team',
team: team.name.to_s,
assignment: ''
}
).and_return(double('Mail', deliver: true))
expect(team.add_member(user)).to be true
end

=== Manual UI Testing ===
Apart from the automated Rspec tests, we are providing manual testing cases that can be used to verify the functioning of the website.

Refer to the demo video on the bottom of the page to find help on testing these cases

==== Scenario 1 - Creating an mentored team ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Courses
# Assuming you have created a course and added participants to it, proceed to create a team
# Make sure "Auto assign mentors when team hits > 50% capacity?" option is checked
[[File:MT 1-1.png | 600px]]
* Create team for the assignment and you can see that the team with more than 50% capacity gets a mentor assigned automatically
[[File:MT 1-2.png | 600px]]

==== Scenario 2 - Adding, editing, deleting mentor meeting dates ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Assigments
# Assuming you have created a mentored assignment and added participants to it, proceed to the teams page
# Try entering dates into it teams row and the date should persist
# You can edit and delete the dates from the rows
# Team with less than 50% capacity will have the mentor meeting dates disabled
[[File:MT 2.png | 600px]]

==== Scenario 3 - Creating a team with topic ====
* Log into Expertiza using the test credential and navigate to the home page
* Go to Manage > Courses
* Assuming you have created a course and added participants to it, proceed to create a team
* Make sure "Has topics?" option is checked and a topic is created using the Topics tab
[[File:MT 3-1.png | 600px]]
* Create a new topic for the assignment and enter a mentor name to the topic
[[File:UI2 E2403.png | 600px]]
* When a student is added to the topic, the team of the student along with the mentor will be displayed in the topic row
[[File:UI3 E2403.png | 600px]]
* When navigating to the teams page of that assignment, you can see a mentor assigned automatically
[[File:UI4 E2403.png | 600px]]

==== Scenario 4 - Creating Team -> Recieve Emails ====
* Step 1 is to change line 45 of app/mailers/mailer from "defn[:to] = 'expertiza.mailer@gmail.com'" to "defn[:to] = '{Your Email}'". This is so that you can test that the emails are being sent.
[[File:Team_addition_fix.png | 600px]]
* Now head to an existing assignment that assigns mentors when team capacity is above 50%. Delete a team if there are no students left to be added to a team. Make sure there are mentors on the student list, if not, add at least 1. Count how many mentors and students will be added to teams when you create a team (in our case this will be 2 students and 1 mentor).
[[File:t_listz.png| 600px]]
* Auto-create teams with max participants.
[[File:cre_teams.png | 600px]]
* Wait a couple of minutes and then check the email address you entered in step 1. You should expect to receive x number of student emails, and y number of mentor emails, where x is the number of students just assigned to a team, and y is the number of mentors assigned to mentor a team. In our example below you can see that there are 2 distinct student emails, and 1 mentor email, which is as expected in our case. Don't forget to check your spam mail if you don't see the mail in your inbox after a few minutes.
[[File:email_case.png | 600px]]

== Test Coverage ==
We used SimpleCov to generate a coverage report for the Rspec test cases implemented for the model and controllers.
The test coverage indicated 1730 lines of code was covered through the test cases.

[[File:Testing E2403.png ‎| 600px]]

== Test Login Credentials ==
* UserId: instructor6
* Password: password

== Demo Video ==
TODO:: 
This is our [https://www.youtube.com/ demo video] which explain how to create courses, assignments, mentored teams and mentored teams with topics. This video also show how to run the tests of our code changes.

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2789

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T02:32:57Z

Slkwiatk: /* Scenario 4 - Creating Team -> Recieve Emails */

== Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project. Instructors have the ability to add new projects, assignments, etc., as well as edit existing ones. Later on, they can view student submissions and grade them. Students can also use Expertiza to organize into teams to work on different projects and assignments and submit their work. They can also review other students' submissions.

== Introduction ==
This project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management/ E2304] for the implementation of the Mentor-meeting management in the Expertiza system for mentored teams. We are now required to add functionality to add mentors to the topics and then assign them to the teams when they pick up that topic.

== Problem Statement ==
The following tasks are required for the project:
#Enhancing Code Clarity: This involves renaming methods from Project 3 with ambiguous names, optimizing loops and adding comments for unclear lines of code
#Reimplement Mentored teams: Reimplement the Mentored team delegate to the Assignment team to reduce complexity and to follow best principles of Object Oriented Design
#Reimplement Sign Up Sheet or Topics: Reimplement the SignUpSheet controller to automatically add the mentor to when a topic is created and automatically assign the same mentor to a team when they choose the topic
#Writing tests for mentor meetings models: More tests have to be written for Mentor Meeting model
#Writing tests for the mentor meetings controller: More tests should be written for Mentor meeting controller
#Writing tests for the signup sheet controller: Additional tests should be written for signup sheet controller to test the new functionality

== Objectives ==
We have 3 main objectives for this project.
* Refactoring of the Mentor-meeting model and controller created for the Project 3
* Reimplementation of Mentored Teams model and controller for the Project 4
* Reimplementation of SignUp Sheet controller for the Project 4 to automatically assign mentors to the topics

== Design Goal ==
While fulfilling all the objectives, the following design rules have to be ensured:
* Validate proper functioning of all existing and anticipated methods, making any required enhancements or adjustments.
* Establish loose coupling and tight cohesion for the model and controller to enhance code organization and maintainability.
* Refactor redundant code in the previous implementation's controller and model methods using DRY principle, eliminating functionality duplication already present in the Expertiza system.
* Confirm the continued effectiveness of existing test cases following the aforementioned modifications and generate additional test cases as per the need.

== Class UML Diagram ==
[[File:OODD Proj4 E2403 - Entity Diagram 2.png ‎| 610px]]

== Classes and Relationships ==
=== Existing Structure ===
* Every Assignment has a Node
* Every Assignment has many AssignmentTeam and MentoredTeam
* AssignmentTeam is inherited from Team
* MentoredTeam is inherited from AssignmentTeam
* Every MentoredTeam has many MentorMeeting
=== Proposed Structure Structure ===
* MentoredTeam to be delegated from AssignmentTeam instead of inheriting from it

== Implementation Plan ==
=== Modify newly created controller, model and view ===
==== mentor_meeting_controller.rb ====
* Edit function names to make them more descriptive
* Add more descriptive comments for the functions
==== mentor_meetings_helper.rb ====
* Move the "get_dates_for_team" function to the model
* Rename the function to make it more descriptive
==== _entry_assignments.html.erb ====
* Add more descriptive comments for the JavaScript functions
* Move the Ruby code from the template to a helper or the controller
==== mentored_team.rb --> mentored_team_decorator ====
* To reduce DRY violations, the mentored team class was changed to the mentored team decorator class.
*

=== Modify existing controller model and view ===
==== teams/_team.html.erb ====
* As the mentored team will now be delegated from the assignment team, we need to change the if condition on the top as we are changing MentoredTeam to be delegated from the AssignmentTeam
==== teams_controller.rb ====
* This file has to be modified to work with the delegated MentoredTeam
* These lines will not work as MentoredTeam will not be a model
[[File:Teams con1.png ‎| 600px]]
==== sign_up_sheet_controller.rb ====
* This controller has to be modified to automatically assign mentors or manually add mentors to the topics when they are created
* This will be followed by a change in schema
[[File:Signup con1.png | 600px]]
==== _topic.html.erb ====
* If we manually have to assign mentors to the topic, we have to include a input field to enter the mentor
[[File:Topic html.png | 600px]]
==== schema.rb ====
* As we are adding a new field to the table, we need to modify the schema
* We need to write 1 migration to add the field to the table to update the schema file
[[File:Schema E2403.png | 600px]]

=== Mailer Changes ===
====team.rb====
* The team model must be altered to use delegation for cases where a team would previously be a mentored team.
====add_member====
* The add member function must be altered such that the call to mail a user is better named, and that it calls directly to the mailer rather than the mailer helper.
[[File:add_member_email.png | 900px]]
====mailer_helper====
* The mailer_helper will be altered such that the send_team_confimration_to_user will be moved and renamed in the Mailer.rb class instead since using generic_message as such is leading to an unclear design.
[[File:team_confirm.png | 900px]]

====mailer.rb====
* A new function to specifically handle messaging users when added to teams will be built in the mailer, rather than just overusing the generic_message function.

== UI Changes ==
=== UI Changes before Phase 2 code changes ===
* The mentored assignment teams page has the modified UI from the Phase 1 as it is also a mentored assignment
* But the teams do not have a TA as the automated assignment of mentors has not been implemented.
[[File:UI1 E2403.png | 600px]]

=== UI Changes after Phase 2 code changes ===
The mentored assignment teams with topic now has the new UI and the automated mentor assignment
* The form to create a new topic has a new field to assign mentor to a topic
[[File:UI2 E2403.png | 600px]]
* The updated UI showing the topics with the mentors and teams that have chosen the topic
* The mentor is also displayed with the team
[[File:UI3 E2403.png | 600px]]
* The assignment teams page has the modified UI from the Phase 1 as the teams have a mentor
[[File:UI4 E2403.png | 600px]]

== Implementation ==
=== Mailer Changes ===
==== Decorator ====
* To remove DRY violations, we transformed the MentoredTeam class into the MentoredTeamDecoratorClass.
[[File:MentoredTeamClass.png | 600px]] ---> [[File:MentoredTeamDecorator.png | 600px]]
* In particular this required changing the MentoredTeam to have its own assignment team variable.
* The add_member function's DRY violations with the Team Class were able to be eliminated here, as now the Mentored Team Decorator calls to the assignment team's add member function on line 14, and then simply calls to assign the mentor on line 16.

==== MailerHelper to Mailer ====
* To increase understandability and consistency between classes, we removed the send_team_confirmation_mail function from the MailerHelper, and instead replaced its functionality with the team_addition_message function in the Mailer class. We found this to be the ideal location as the Mailer class houses many other specific message functions such as notify_grade_conflict_message, suggested_topic_approved_message and more.
[[File:team_confirm.png | 600px]] ---> [[File:Team_Addtion_Message.png | 600px]]

==== Team Add_Member ====
* The add_member function was altered in a couple of different ways. Firstly, we parameterized the partial_name in the call to the function that actually sends the mail, as in the original code we were violating the DRY principle by repeating the same MailerHelper call twice with very little change between them.
* Additionally we removed the type check for whether a user is a participant or not, as most users should be participants.
[[File:add_member_email.png | 600px]] ---> [[File:New_Add_Message.png | 600px]]

=== Automatic topic mentor assignment changes ===
==== Team creation using decorator ====
* As we have moved the mentored team from a subclass of assignment team to being a decorator, we have modified the team creation code to assign the right type of class to the team
* If the team is a mentored team, we use the MentoredTeamDecorator to create the object of the Assignment class
[[File:Team Creation.png | 600px]]

==== Team deletion ====
* We have added the functionality to delete the Mentor meetings when the team is deleted
* If the team is a mentored team, we will find all the instances of mentor meetings for the team and delete them
* We have also modified the function to work as a independent function that can be called from any where in the application by passing a parameter
* When the parameter is not passed, it is used as a controller function to handle calls to a specific route
[[File:Team Deletion.png | 600px]]

==== Adding a user to a team ====
* We have modified the function to add an user to the team
* The create function in TeamsUsersController is modified
[[File:Team User Creation.png | 600px]]

==== Adding a mentor to a topic - Form and table ====
* We have added a field in the topics form to add a mentor to the topic in _topic.html.erb
[[File:Topic Form.png | 600px]]
* The table displaying the topics is also modified to have a column for the mentors in _table_header.html.erb
[[File:Topic Header.png | 600px]]
* The topic row also displays the team members with the mentor included in it in the topics table in _table_line.html.erb 
[[File:Topic Row.png | 600px]]

==== Adding a mentor to a topic - Functions ====
* We have modified the function to setup a new topic to include the functionality to add mentor to the topic
* In case we try to add a mentor who is not in the assignment or course, we add the mentor to the assignment and course too
* In this way we handle cases of adding mentors outside the course into the topic
[[File:Add Topic Mentor.png | 600px]]
* We have created some helper functions to assist in adding the mentor to the assignment and course
[[File:Addition Helpers.png | 600px]]

==== Automatic Mentor Assignment ====
* We have added additional function to assign the mentor of the topic to be automatically assigned to the team that chooses the topic
[[File:Auto Assign Topic Mentor.png | 600px]]
* The signup_as_instructor_action function will automatically call the assignment function to add the topic's mentor to the team
[[File:Call_Assign_Mentor.png | 600px]]

== Files Modified/Added ==
* app/controllers/sign_up_sheet_controller.rb
* app/controllers/teams_controller.rb
* app/controllers/teams_users_controller.rb
* app/models/course.rb
* app/models/mentor_management.rb
* app/views/sign_up_sheet/_table_header.html.erb
* app/views/sign_up_sheet/_table_line.html.erb
* app/views/sign_up_sheet/_topic.html.erb
* app/views/teams/_team.html.erb
* app/views/tree_display/_page_footer_assignments.html.erb
* app/views/tree_display/_entry_assignments.html.erb
* app/models/mentored_team_decorator.rb
* app/models/team.rb
* app/views/mailer/team_addition_message.html.erb
* app/views/mailer/team_addition_message.text.erb
* app/helpers/mailer_helper.rb
* app/mailers/mailer.rb
* spec/models/team_spec.rb
* spec/models/mentor_management_spec.rb

== Test Plan ==
When the project was pulled from the main repository, there are not enough tests to cover the additional functionalities that we added. We are planning on using the test skeletons by Mustafa Olmez, as a reference to how and what kind of tests should be written. Test cases for mentor management were already written and we wrote new test cases for the new functionalities we added. Here are the four test case scenarios we covered and the actual ruby code for the Rspec tests

=== Automated Rspec Testing Scenarios===
1. Test scenario 1: Given an assignment_id, When there are multiple mentors with different team counts for the assignment, Then it should return the mentor with the lowest team count
it "returns the mentor with the lowest team count for the given assignment" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 2]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

2. Test scenario 2: Given an assignment_id, When there is only one mentor available for the assignment, Then it should return that mentor
it "should return that mentor if there's only one available" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 0]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

3. Test scenario 3: Given an assignment_id, When there are multiple mentors with the same lowest team count for the assignment, Then it should return the first mentor in the list
it "returns the first mentor in the list if there's a tie for lowest team count" do
# Arrange
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 1],])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

4. Test scenario 4: Given an assignment_id, When there are no mentors available for the assignment, Then it should return nil
it "returns nil" do
# Create a new assignment
a = FactoryBot.create(:assignment, id: 997, directory_path: 'OSS_project', auto_assign_mentor: true)
# Since there are no mentors associated with this assignment, should return nil
expect(MentorManagement.select_mentor(a.id)).to eq nil
end

== Mailer Tests ==
5. Test scenario 5: Given a mentor is being added to a team, then the mailer should be called to send the mentor-specific mail to the mentor
it 'sends mail to mentor if user is a mentor' do
allow(MentorManagement).to receive(:user_a_mentor?).with(user).and_return(true)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
allow(Mailer).to receive(:team_addition_message).and_return(double('Mail', deliver: true))
expect(Mailer).to receive(:team_addition_message).with(
to: user.email,
subject: '[Expertiza] Added to a Team',
body: {
user: user,
first_name: ApplicationHelper.get_user_first_name(user),
partial_name: 'mentor_added_to_team',
team: team.name.to_s,
assignment: ''
}
).and_return(double('Mail', deliver: true))
expect(team.add_member(user)).to be true
end

6. Test scenario 6: Given a normal user is being added to a team, then the mailer should be called to send the general user addition mail to the user
it 'sends mail to user if user is a user' do
allow(MentorManagement).to receive(:user_a_mentor?).with(user).and_return(true)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
allow(Mailer).to receive(:team_addition_message).and_return(double('Mail', deliver: true))
expect(Mailer).to receive(:team_addition_message).with(
to: user.email,
subject: '[Expertiza] Added to a Team',
body: {
user: user,
first_name: ApplicationHelper.get_user_first_name(user),
partial_name: 'user_added_to_team',
team: team.name.to_s,
assignment: ''
}
).and_return(double('Mail', deliver: true))
expect(team.add_member(user)).to be true
end

=== Manual UI Testing ===
Apart from the automated Rspec tests, we are providing manual testing cases that can be used to verify the functioning of the website.

Refer to the demo video on the bottom of the page to find help on testing these cases

==== Scenario 1 - Creating an mentored team ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Courses
# Assuming you have created a course and added participants to it, proceed to create a team
# Make sure "Auto assign mentors when team hits > 50% capacity?" option is checked
[[File:MT 1-1.png | 600px]]
* Create team for the assignment and you can see that the team with more than 50% capacity gets a mentor assigned automatically
[[File:MT 1-2.png | 600px]]

==== Scenario 2 - Adding, editing, deleting mentor meeting dates ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Assigments
# Assuming you have created a mentored assignment and added participants to it, proceed to the teams page
# Try entering dates into it teams row and the date should persist
# You can edit and delete the dates from the rows
# Team with less than 50% capacity will have the mentor meeting dates disabled
[[File:MT 2.png | 600px]]

==== Scenario 3 - Creating a team with topic ====
* Log into Expertiza using the test credential and navigate to the home page
* Go to Manage > Courses
* Assuming you have created a course and added participants to it, proceed to create a team
* Make sure "Has topics?" option is checked and a topic is created using the Topics tab
[[File:MT 3-1.png | 600px]]
* Create a new topic for the assignment and enter a mentor name to the topic
[[File:UI2 E2403.png | 600px]]
* When a student is added to the topic, the team of the student along with the mentor will be displayed in the topic row
[[File:UI3 E2403.png | 600px]]
* When navigating to the teams page of that assignment, you can see a mentor assigned automatically
[[File:UI4 E2403.png | 600px]]

==== Scenario 4 - Creating Team -> Recieve Emails ====
* Step 1 is to change line 45 of app/mailers/mailer from "defn[:to] = 'expertiza.mailer@gmail.com'" to "defn[:to] = '{Your Email}'". This is so that you can test that the emails are being sent.
[[File:Team_addition_fix.png | 600px]]
* Now head to an existing assignment that assigns mentors when team capacity is above 50%. Delete a team if there are no students left to be added to a team. Make sure there are mentors on the student list, if not, add at least 1. Count how many mentors and students will be added to teams when you create a team (in our case this will be 2 students and 1 mentor).
[[File:t_listz.png| 600px]]
* Auto-create teams with max participants.
[[File:cre_teams.png | 600px]]
* Wait a couple of minutes and then check the email address you entered in step 1. You should expect to receive x number of student emails, and y number of mentor emails, where x is the number of students just assigned to a team, and y is the number of mentors assigned to mentor a team. In our example below you can see that there are 2 distinct student emails, and 1 mentor email, which is as expected in our case.
[[File:email_case.png | 600px]]

== Test Coverage ==
We used SimpleCov to generate a coverage report for the Rspec test cases implemented for the model and controllers.
The test coverage indicated 1730 lines of code was covered through the test cases.

[[File:Testing E2403.png ‎| 600px]]

== Test Login Credentials ==
* UserId: instructor6
* Password: password

== Demo Video ==
TODO:: 
This is our [https://www.youtube.com/ demo video] which explain how to create courses, assignments, mentored teams and mentored teams with topics. This video also show how to run the tests of our code changes.

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2789

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T02:31:51Z

Slkwiatk: /* Scenario 4 - Creating Team -> Recieve Emails */

== Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project. Instructors have the ability to add new projects, assignments, etc., as well as edit existing ones. Later on, they can view student submissions and grade them. Students can also use Expertiza to organize into teams to work on different projects and assignments and submit their work. They can also review other students' submissions.

== Introduction ==
This project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management/ E2304] for the implementation of the Mentor-meeting management in the Expertiza system for mentored teams. We are now required to add functionality to add mentors to the topics and then assign them to the teams when they pick up that topic.

== Problem Statement ==
The following tasks are required for the project:
#Enhancing Code Clarity: This involves renaming methods from Project 3 with ambiguous names, optimizing loops and adding comments for unclear lines of code
#Reimplement Mentored teams: Reimplement the Mentored team delegate to the Assignment team to reduce complexity and to follow best principles of Object Oriented Design
#Reimplement Sign Up Sheet or Topics: Reimplement the SignUpSheet controller to automatically add the mentor to when a topic is created and automatically assign the same mentor to a team when they choose the topic
#Writing tests for mentor meetings models: More tests have to be written for Mentor Meeting model
#Writing tests for the mentor meetings controller: More tests should be written for Mentor meeting controller
#Writing tests for the signup sheet controller: Additional tests should be written for signup sheet controller to test the new functionality

== Objectives ==
We have 3 main objectives for this project.
* Refactoring of the Mentor-meeting model and controller created for the Project 3
* Reimplementation of Mentored Teams model and controller for the Project 4
* Reimplementation of SignUp Sheet controller for the Project 4 to automatically assign mentors to the topics

== Design Goal ==
While fulfilling all the objectives, the following design rules have to be ensured:
* Validate proper functioning of all existing and anticipated methods, making any required enhancements or adjustments.
* Establish loose coupling and tight cohesion for the model and controller to enhance code organization and maintainability.
* Refactor redundant code in the previous implementation's controller and model methods using DRY principle, eliminating functionality duplication already present in the Expertiza system.
* Confirm the continued effectiveness of existing test cases following the aforementioned modifications and generate additional test cases as per the need.

== Class UML Diagram ==
[[File:OODD Proj4 E2403 - Entity Diagram 2.png ‎| 610px]]

== Classes and Relationships ==
=== Existing Structure ===
* Every Assignment has a Node
* Every Assignment has many AssignmentTeam and MentoredTeam
* AssignmentTeam is inherited from Team
* MentoredTeam is inherited from AssignmentTeam
* Every MentoredTeam has many MentorMeeting
=== Proposed Structure Structure ===
* MentoredTeam to be delegated from AssignmentTeam instead of inheriting from it

== Implementation Plan ==
=== Modify newly created controller, model and view ===
==== mentor_meeting_controller.rb ====
* Edit function names to make them more descriptive
* Add more descriptive comments for the functions
==== mentor_meetings_helper.rb ====
* Move the "get_dates_for_team" function to the model
* Rename the function to make it more descriptive
==== _entry_assignments.html.erb ====
* Add more descriptive comments for the JavaScript functions
* Move the Ruby code from the template to a helper or the controller
==== mentored_team.rb --> mentored_team_decorator ====
* To reduce DRY violations, the mentored team class was changed to the mentored team decorator class.
*

=== Modify existing controller model and view ===
==== teams/_team.html.erb ====
* As the mentored team will now be delegated from the assignment team, we need to change the if condition on the top as we are changing MentoredTeam to be delegated from the AssignmentTeam
==== teams_controller.rb ====
* This file has to be modified to work with the delegated MentoredTeam
* These lines will not work as MentoredTeam will not be a model
[[File:Teams con1.png ‎| 600px]]
==== sign_up_sheet_controller.rb ====
* This controller has to be modified to automatically assign mentors or manually add mentors to the topics when they are created
* This will be followed by a change in schema
[[File:Signup con1.png | 600px]]
==== _topic.html.erb ====
* If we manually have to assign mentors to the topic, we have to include a input field to enter the mentor
[[File:Topic html.png | 600px]]
==== schema.rb ====
* As we are adding a new field to the table, we need to modify the schema
* We need to write 1 migration to add the field to the table to update the schema file
[[File:Schema E2403.png | 600px]]

=== Mailer Changes ===
====team.rb====
* The team model must be altered to use delegation for cases where a team would previously be a mentored team.
====add_member====
* The add member function must be altered such that the call to mail a user is better named, and that it calls directly to the mailer rather than the mailer helper.
[[File:add_member_email.png | 900px]]
====mailer_helper====
* The mailer_helper will be altered such that the send_team_confimration_to_user will be moved and renamed in the Mailer.rb class instead since using generic_message as such is leading to an unclear design.
[[File:team_confirm.png | 900px]]

====mailer.rb====
* A new function to specifically handle messaging users when added to teams will be built in the mailer, rather than just overusing the generic_message function.

== UI Changes ==
=== UI Changes before Phase 2 code changes ===
* The mentored assignment teams page has the modified UI from the Phase 1 as it is also a mentored assignment
* But the teams do not have a TA as the automated assignment of mentors has not been implemented.
[[File:UI1 E2403.png | 600px]]

=== UI Changes after Phase 2 code changes ===
The mentored assignment teams with topic now has the new UI and the automated mentor assignment
* The form to create a new topic has a new field to assign mentor to a topic
[[File:UI2 E2403.png | 600px]]
* The updated UI showing the topics with the mentors and teams that have chosen the topic
* The mentor is also displayed with the team
[[File:UI3 E2403.png | 600px]]
* The assignment teams page has the modified UI from the Phase 1 as the teams have a mentor
[[File:UI4 E2403.png | 600px]]

== Implementation ==
=== Mailer Changes ===
==== Decorator ====
* To remove DRY violations, we transformed the MentoredTeam class into the MentoredTeamDecoratorClass.
[[File:MentoredTeamClass.png | 600px]] ---> [[File:MentoredTeamDecorator.png | 600px]]
* In particular this required changing the MentoredTeam to have its own assignment team variable.
* The add_member function's DRY violations with the Team Class were able to be eliminated here, as now the Mentored Team Decorator calls to the assignment team's add member function on line 14, and then simply calls to assign the mentor on line 16.

==== MailerHelper to Mailer ====
* To increase understandability and consistency between classes, we removed the send_team_confirmation_mail function from the MailerHelper, and instead replaced its functionality with the team_addition_message function in the Mailer class. We found this to be the ideal location as the Mailer class houses many other specific message functions such as notify_grade_conflict_message, suggested_topic_approved_message and more.
[[File:team_confirm.png | 600px]] ---> [[File:Team_Addtion_Message.png | 600px]]

==== Team Add_Member ====
* The add_member function was altered in a couple of different ways. Firstly, we parameterized the partial_name in the call to the function that actually sends the mail, as in the original code we were violating the DRY principle by repeating the same MailerHelper call twice with very little change between them.
* Additionally we removed the type check for whether a user is a participant or not, as most users should be participants.
[[File:add_member_email.png | 600px]] ---> [[File:New_Add_Message.png | 600px]]

=== Automatic topic mentor assignment changes ===
==== Team creation using decorator ====
* As we have moved the mentored team from a subclass of assignment team to being a decorator, we have modified the team creation code to assign the right type of class to the team
* If the team is a mentored team, we use the MentoredTeamDecorator to create the object of the Assignment class
[[File:Team Creation.png | 600px]]

==== Team deletion ====
* We have added the functionality to delete the Mentor meetings when the team is deleted
* If the team is a mentored team, we will find all the instances of mentor meetings for the team and delete them
* We have also modified the function to work as a independent function that can be called from any where in the application by passing a parameter
* When the parameter is not passed, it is used as a controller function to handle calls to a specific route
[[File:Team Deletion.png | 600px]]

==== Adding a user to a team ====
* We have modified the function to add an user to the team
* The create function in TeamsUsersController is modified
[[File:Team User Creation.png | 600px]]

==== Adding a mentor to a topic - Form and table ====
* We have added a field in the topics form to add a mentor to the topic in _topic.html.erb
[[File:Topic Form.png | 600px]]
* The table displaying the topics is also modified to have a column for the mentors in _table_header.html.erb
[[File:Topic Header.png | 600px]]
* The topic row also displays the team members with the mentor included in it in the topics table in _table_line.html.erb 
[[File:Topic Row.png | 600px]]

==== Adding a mentor to a topic - Functions ====
* We have modified the function to setup a new topic to include the functionality to add mentor to the topic
* In case we try to add a mentor who is not in the assignment or course, we add the mentor to the assignment and course too
* In this way we handle cases of adding mentors outside the course into the topic
[[File:Add Topic Mentor.png | 600px]]
* We have created some helper functions to assist in adding the mentor to the assignment and course
[[File:Addition Helpers.png | 600px]]

==== Automatic Mentor Assignment ====
* We have added additional function to assign the mentor of the topic to be automatically assigned to the team that chooses the topic
[[File:Auto Assign Topic Mentor.png | 600px]]
* The signup_as_instructor_action function will automatically call the assignment function to add the topic's mentor to the team
[[File:Call_Assign_Mentor.png | 600px]]

== Files Modified/Added ==
* app/controllers/sign_up_sheet_controller.rb
* app/controllers/teams_controller.rb
* app/controllers/teams_users_controller.rb
* app/models/course.rb
* app/models/mentor_management.rb
* app/views/sign_up_sheet/_table_header.html.erb
* app/views/sign_up_sheet/_table_line.html.erb
* app/views/sign_up_sheet/_topic.html.erb
* app/views/teams/_team.html.erb
* app/views/tree_display/_page_footer_assignments.html.erb
* app/views/tree_display/_entry_assignments.html.erb
* app/models/mentored_team_decorator.rb
* app/models/team.rb
* app/views/mailer/team_addition_message.html.erb
* app/views/mailer/team_addition_message.text.erb
* app/helpers/mailer_helper.rb
* app/mailers/mailer.rb
* spec/models/team_spec.rb
* spec/models/mentor_management_spec.rb

== Test Plan ==
When the project was pulled from the main repository, there are not enough tests to cover the additional functionalities that we added. We are planning on using the test skeletons by Mustafa Olmez, as a reference to how and what kind of tests should be written. Test cases for mentor management were already written and we wrote new test cases for the new functionalities we added. Here are the four test case scenarios we covered and the actual ruby code for the Rspec tests

=== Automated Rspec Testing Scenarios===
1. Test scenario 1: Given an assignment_id, When there are multiple mentors with different team counts for the assignment, Then it should return the mentor with the lowest team count
it "returns the mentor with the lowest team count for the given assignment" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 2]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

2. Test scenario 2: Given an assignment_id, When there is only one mentor available for the assignment, Then it should return that mentor
it "should return that mentor if there's only one available" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 0]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

3. Test scenario 3: Given an assignment_id, When there are multiple mentors with the same lowest team count for the assignment, Then it should return the first mentor in the list
it "returns the first mentor in the list if there's a tie for lowest team count" do
# Arrange
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 1],])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

4. Test scenario 4: Given an assignment_id, When there are no mentors available for the assignment, Then it should return nil
it "returns nil" do
# Create a new assignment
a = FactoryBot.create(:assignment, id: 997, directory_path: 'OSS_project', auto_assign_mentor: true)
# Since there are no mentors associated with this assignment, should return nil
expect(MentorManagement.select_mentor(a.id)).to eq nil
end

== Mailer Tests ==
5. Test scenario 5: Given a mentor is being added to a team, then the mailer should be called to send the mentor-specific mail to the mentor
it 'sends mail to mentor if user is a mentor' do
allow(MentorManagement).to receive(:user_a_mentor?).with(user).and_return(true)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
allow(Mailer).to receive(:team_addition_message).and_return(double('Mail', deliver: true))
expect(Mailer).to receive(:team_addition_message).with(
to: user.email,
subject: '[Expertiza] Added to a Team',
body: {
user: user,
first_name: ApplicationHelper.get_user_first_name(user),
partial_name: 'mentor_added_to_team',
team: team.name.to_s,
assignment: ''
}
).and_return(double('Mail', deliver: true))
expect(team.add_member(user)).to be true
end

6. Test scenario 6: Given a normal user is being added to a team, then the mailer should be called to send the general user addition mail to the user
it 'sends mail to user if user is a user' do
allow(MentorManagement).to receive(:user_a_mentor?).with(user).and_return(true)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
allow(Mailer).to receive(:team_addition_message).and_return(double('Mail', deliver: true))
expect(Mailer).to receive(:team_addition_message).with(
to: user.email,
subject: '[Expertiza] Added to a Team',
body: {
user: user,
first_name: ApplicationHelper.get_user_first_name(user),
partial_name: 'user_added_to_team',
team: team.name.to_s,
assignment: ''
}
).and_return(double('Mail', deliver: true))
expect(team.add_member(user)).to be true
end

=== Manual UI Testing ===
Apart from the automated Rspec tests, we are providing manual testing cases that can be used to verify the functioning of the website.

Refer to the demo video on the bottom of the page to find help on testing these cases

==== Scenario 1 - Creating an mentored team ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Courses
# Assuming you have created a course and added participants to it, proceed to create a team
# Make sure "Auto assign mentors when team hits > 50% capacity?" option is checked
[[File:MT 1-1.png | 600px]]
* Create team for the assignment and you can see that the team with more than 50% capacity gets a mentor assigned automatically
[[File:MT 1-2.png | 600px]]

==== Scenario 2 - Adding, editing, deleting mentor meeting dates ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Assigments
# Assuming you have created a mentored assignment and added participants to it, proceed to the teams page
# Try entering dates into it teams row and the date should persist
# You can edit and delete the dates from the rows
# Team with less than 50% capacity will have the mentor meeting dates disabled
[[File:MT 2.png | 600px]]

==== Scenario 3 - Creating a team with topic ====
* Log into Expertiza using the test credential and navigate to the home page
* Go to Manage > Courses
* Assuming you have created a course and added participants to it, proceed to create a team
* Make sure "Has topics?" option is checked and a topic is created using the Topics tab
[[File:MT 3-1.png | 600px]]
* Create a new topic for the assignment and enter a mentor name to the topic
[[File:UI2 E2403.png | 600px]]
* When a student is added to the topic, the team of the student along with the mentor will be displayed in the topic row
[[File:UI3 E2403.png | 600px]]
* When navigating to the teams page of that assignment, you can see a mentor assigned automatically
[[File:UI4 E2403.png | 600px]]

==== Scenario 4 - Creating Team -> Recieve Emails ====
* Step 1 is to change line 45 of app/mailers/mailer from "defn[:to] = 'expertiza.mailer@gmail.com'" to "defn[:to] = '{Your Email}'". This is so that you can test that the emails are being sent.
[[File:Team_addition_fix.png | 600px]]
* Now head to an existing assignment that assigns mentors when team capacity is above 50%. Delete a team if there are no students left to be added to a team. Make sure there are mentors on the student list, if not, add at least 1. Count how many mentors and students will be added to teams when you create a team (In our case this will be 2 students and 1 mentor).
[[File:t_listz.png| 600px]]
* Auto-create teams with max participants.
[[File:cre_teams.png | 600px]]
* Wait a couple of minutes and then check the email address you entered in step 1. You should expect to receive x number of student emails, and y number of mentor emails, where x is the number of students just assigned to a team, and y is the number of mentors assigned to mentor a team. In our example below you can see that there are 2 distinct student emails, and 1 mentor email, which is as expected in our case.
[[File:email_case.png | 600px]]

== Test Coverage ==
We used SimpleCov to generate a coverage report for the Rspec test cases implemented for the model and controllers.
The test coverage indicated 1730 lines of code was covered through the test cases.

[[File:Testing E2403.png ‎| 600px]]

== Test Login Credentials ==
* UserId: instructor6
* Password: password

== Demo Video ==
TODO:: 
This is our [https://www.youtube.com/ demo video] which explain how to create courses, assignments, mentored teams and mentored teams with topics. This video also show how to run the tests of our code changes.

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2789

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T02:31:22Z

Slkwiatk: /* Scenario 4 - Creating Team -> Recieve Emails */

== Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project. Instructors have the ability to add new projects, assignments, etc., as well as edit existing ones. Later on, they can view student submissions and grade them. Students can also use Expertiza to organize into teams to work on different projects and assignments and submit their work. They can also review other students' submissions.

== Introduction ==
This project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management/ E2304] for the implementation of the Mentor-meeting management in the Expertiza system for mentored teams. We are now required to add functionality to add mentors to the topics and then assign them to the teams when they pick up that topic.

== Problem Statement ==
The following tasks are required for the project:
#Enhancing Code Clarity: This involves renaming methods from Project 3 with ambiguous names, optimizing loops and adding comments for unclear lines of code
#Reimplement Mentored teams: Reimplement the Mentored team delegate to the Assignment team to reduce complexity and to follow best principles of Object Oriented Design
#Reimplement Sign Up Sheet or Topics: Reimplement the SignUpSheet controller to automatically add the mentor to when a topic is created and automatically assign the same mentor to a team when they choose the topic
#Writing tests for mentor meetings models: More tests have to be written for Mentor Meeting model
#Writing tests for the mentor meetings controller: More tests should be written for Mentor meeting controller
#Writing tests for the signup sheet controller: Additional tests should be written for signup sheet controller to test the new functionality

== Objectives ==
We have 3 main objectives for this project.
* Refactoring of the Mentor-meeting model and controller created for the Project 3
* Reimplementation of Mentored Teams model and controller for the Project 4
* Reimplementation of SignUp Sheet controller for the Project 4 to automatically assign mentors to the topics

== Design Goal ==
While fulfilling all the objectives, the following design rules have to be ensured:
* Validate proper functioning of all existing and anticipated methods, making any required enhancements or adjustments.
* Establish loose coupling and tight cohesion for the model and controller to enhance code organization and maintainability.
* Refactor redundant code in the previous implementation's controller and model methods using DRY principle, eliminating functionality duplication already present in the Expertiza system.
* Confirm the continued effectiveness of existing test cases following the aforementioned modifications and generate additional test cases as per the need.

== Class UML Diagram ==
[[File:OODD Proj4 E2403 - Entity Diagram 2.png ‎| 610px]]

== Classes and Relationships ==
=== Existing Structure ===
* Every Assignment has a Node
* Every Assignment has many AssignmentTeam and MentoredTeam
* AssignmentTeam is inherited from Team
* MentoredTeam is inherited from AssignmentTeam
* Every MentoredTeam has many MentorMeeting
=== Proposed Structure Structure ===
* MentoredTeam to be delegated from AssignmentTeam instead of inheriting from it

== Implementation Plan ==
=== Modify newly created controller, model and view ===
==== mentor_meeting_controller.rb ====
* Edit function names to make them more descriptive
* Add more descriptive comments for the functions
==== mentor_meetings_helper.rb ====
* Move the "get_dates_for_team" function to the model
* Rename the function to make it more descriptive
==== _entry_assignments.html.erb ====
* Add more descriptive comments for the JavaScript functions
* Move the Ruby code from the template to a helper or the controller
==== mentored_team.rb --> mentored_team_decorator ====
* To reduce DRY violations, the mentored team class was changed to the mentored team decorator class.
*

=== Modify existing controller model and view ===
==== teams/_team.html.erb ====
* As the mentored team will now be delegated from the assignment team, we need to change the if condition on the top as we are changing MentoredTeam to be delegated from the AssignmentTeam
==== teams_controller.rb ====
* This file has to be modified to work with the delegated MentoredTeam
* These lines will not work as MentoredTeam will not be a model
[[File:Teams con1.png ‎| 600px]]
==== sign_up_sheet_controller.rb ====
* This controller has to be modified to automatically assign mentors or manually add mentors to the topics when they are created
* This will be followed by a change in schema
[[File:Signup con1.png | 600px]]
==== _topic.html.erb ====
* If we manually have to assign mentors to the topic, we have to include a input field to enter the mentor
[[File:Topic html.png | 600px]]
==== schema.rb ====
* As we are adding a new field to the table, we need to modify the schema
* We need to write 1 migration to add the field to the table to update the schema file
[[File:Schema E2403.png | 600px]]

=== Mailer Changes ===
====team.rb====
* The team model must be altered to use delegation for cases where a team would previously be a mentored team.
====add_member====
* The add member function must be altered such that the call to mail a user is better named, and that it calls directly to the mailer rather than the mailer helper.
[[File:add_member_email.png | 900px]]
====mailer_helper====
* The mailer_helper will be altered such that the send_team_confimration_to_user will be moved and renamed in the Mailer.rb class instead since using generic_message as such is leading to an unclear design.
[[File:team_confirm.png | 900px]]

====mailer.rb====
* A new function to specifically handle messaging users when added to teams will be built in the mailer, rather than just overusing the generic_message function.

== UI Changes ==
=== UI Changes before Phase 2 code changes ===
* The mentored assignment teams page has the modified UI from the Phase 1 as it is also a mentored assignment
* But the teams do not have a TA as the automated assignment of mentors has not been implemented.
[[File:UI1 E2403.png | 600px]]

=== UI Changes after Phase 2 code changes ===
The mentored assignment teams with topic now has the new UI and the automated mentor assignment
* The form to create a new topic has a new field to assign mentor to a topic
[[File:UI2 E2403.png | 600px]]
* The updated UI showing the topics with the mentors and teams that have chosen the topic
* The mentor is also displayed with the team
[[File:UI3 E2403.png | 600px]]
* The assignment teams page has the modified UI from the Phase 1 as the teams have a mentor
[[File:UI4 E2403.png | 600px]]

== Implementation ==
=== Mailer Changes ===
==== Decorator ====
* To remove DRY violations, we transformed the MentoredTeam class into the MentoredTeamDecoratorClass.
[[File:MentoredTeamClass.png | 600px]] ---> [[File:MentoredTeamDecorator.png | 600px]]
* In particular this required changing the MentoredTeam to have its own assignment team variable.
* The add_member function's DRY violations with the Team Class were able to be eliminated here, as now the Mentored Team Decorator calls to the assignment team's add member function on line 14, and then simply calls to assign the mentor on line 16.

==== MailerHelper to Mailer ====
* To increase understandability and consistency between classes, we removed the send_team_confirmation_mail function from the MailerHelper, and instead replaced its functionality with the team_addition_message function in the Mailer class. We found this to be the ideal location as the Mailer class houses many other specific message functions such as notify_grade_conflict_message, suggested_topic_approved_message and more.
[[File:team_confirm.png | 600px]] ---> [[File:Team_Addtion_Message.png | 600px]]

==== Team Add_Member ====
* The add_member function was altered in a couple of different ways. Firstly, we parameterized the partial_name in the call to the function that actually sends the mail, as in the original code we were violating the DRY principle by repeating the same MailerHelper call twice with very little change between them.
* Additionally we removed the type check for whether a user is a participant or not, as most users should be participants.
[[File:add_member_email.png | 600px]] ---> [[File:New_Add_Message.png | 600px]]

=== Automatic topic mentor assignment changes ===
==== Team creation using decorator ====
* As we have moved the mentored team from a subclass of assignment team to being a decorator, we have modified the team creation code to assign the right type of class to the team
* If the team is a mentored team, we use the MentoredTeamDecorator to create the object of the Assignment class
[[File:Team Creation.png | 600px]]

==== Team deletion ====
* We have added the functionality to delete the Mentor meetings when the team is deleted
* If the team is a mentored team, we will find all the instances of mentor meetings for the team and delete them
* We have also modified the function to work as a independent function that can be called from any where in the application by passing a parameter
* When the parameter is not passed, it is used as a controller function to handle calls to a specific route
[[File:Team Deletion.png | 600px]]

==== Adding a user to a team ====
* We have modified the function to add an user to the team
* The create function in TeamsUsersController is modified
[[File:Team User Creation.png | 600px]]

==== Adding a mentor to a topic - Form and table ====
* We have added a field in the topics form to add a mentor to the topic in _topic.html.erb
[[File:Topic Form.png | 600px]]
* The table displaying the topics is also modified to have a column for the mentors in _table_header.html.erb
[[File:Topic Header.png | 600px]]
* The topic row also displays the team members with the mentor included in it in the topics table in _table_line.html.erb 
[[File:Topic Row.png | 600px]]

==== Adding a mentor to a topic - Functions ====
* We have modified the function to setup a new topic to include the functionality to add mentor to the topic
* In case we try to add a mentor who is not in the assignment or course, we add the mentor to the assignment and course too
* In this way we handle cases of adding mentors outside the course into the topic
[[File:Add Topic Mentor.png | 600px]]
* We have created some helper functions to assist in adding the mentor to the assignment and course
[[File:Addition Helpers.png | 600px]]

==== Automatic Mentor Assignment ====
* We have added additional function to assign the mentor of the topic to be automatically assigned to the team that chooses the topic
[[File:Auto Assign Topic Mentor.png | 600px]]
* The signup_as_instructor_action function will automatically call the assignment function to add the topic's mentor to the team
[[File:Call_Assign_Mentor.png | 600px]]

== Files Modified/Added ==
* app/controllers/sign_up_sheet_controller.rb
* app/controllers/teams_controller.rb
* app/controllers/teams_users_controller.rb
* app/models/course.rb
* app/models/mentor_management.rb
* app/views/sign_up_sheet/_table_header.html.erb
* app/views/sign_up_sheet/_table_line.html.erb
* app/views/sign_up_sheet/_topic.html.erb
* app/views/teams/_team.html.erb
* app/views/tree_display/_page_footer_assignments.html.erb
* app/views/tree_display/_entry_assignments.html.erb
* app/models/mentored_team_decorator.rb
* app/models/team.rb
* app/views/mailer/team_addition_message.html.erb
* app/views/mailer/team_addition_message.text.erb
* app/helpers/mailer_helper.rb
* app/mailers/mailer.rb
* spec/models/team_spec.rb
* spec/models/mentor_management_spec.rb

== Test Plan ==
When the project was pulled from the main repository, there are not enough tests to cover the additional functionalities that we added. We are planning on using the test skeletons by Mustafa Olmez, as a reference to how and what kind of tests should be written. Test cases for mentor management were already written and we wrote new test cases for the new functionalities we added. Here are the four test case scenarios we covered and the actual ruby code for the Rspec tests

=== Automated Rspec Testing Scenarios===
1. Test scenario 1: Given an assignment_id, When there are multiple mentors with different team counts for the assignment, Then it should return the mentor with the lowest team count
it "returns the mentor with the lowest team count for the given assignment" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 2]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

2. Test scenario 2: Given an assignment_id, When there is only one mentor available for the assignment, Then it should return that mentor
it "should return that mentor if there's only one available" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 0]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

3. Test scenario 3: Given an assignment_id, When there are multiple mentors with the same lowest team count for the assignment, Then it should return the first mentor in the list
it "returns the first mentor in the list if there's a tie for lowest team count" do
# Arrange
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 1],])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

4. Test scenario 4: Given an assignment_id, When there are no mentors available for the assignment, Then it should return nil
it "returns nil" do
# Create a new assignment
a = FactoryBot.create(:assignment, id: 997, directory_path: 'OSS_project', auto_assign_mentor: true)
# Since there are no mentors associated with this assignment, should return nil
expect(MentorManagement.select_mentor(a.id)).to eq nil
end

== Mailer Tests ==
5. Test scenario 5: Given a mentor is being added to a team, then the mailer should be called to send the mentor-specific mail to the mentor
it 'sends mail to mentor if user is a mentor' do
allow(MentorManagement).to receive(:user_a_mentor?).with(user).and_return(true)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
allow(Mailer).to receive(:team_addition_message).and_return(double('Mail', deliver: true))
expect(Mailer).to receive(:team_addition_message).with(
to: user.email,
subject: '[Expertiza] Added to a Team',
body: {
user: user,
first_name: ApplicationHelper.get_user_first_name(user),
partial_name: 'mentor_added_to_team',
team: team.name.to_s,
assignment: ''
}
).and_return(double('Mail', deliver: true))
expect(team.add_member(user)).to be true
end

6. Test scenario 6: Given a normal user is being added to a team, then the mailer should be called to send the general user addition mail to the user
it 'sends mail to user if user is a user' do
allow(MentorManagement).to receive(:user_a_mentor?).with(user).and_return(true)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
allow(Mailer).to receive(:team_addition_message).and_return(double('Mail', deliver: true))
expect(Mailer).to receive(:team_addition_message).with(
to: user.email,
subject: '[Expertiza] Added to a Team',
body: {
user: user,
first_name: ApplicationHelper.get_user_first_name(user),
partial_name: 'user_added_to_team',
team: team.name.to_s,
assignment: ''
}
).and_return(double('Mail', deliver: true))
expect(team.add_member(user)).to be true
end

=== Manual UI Testing ===
Apart from the automated Rspec tests, we are providing manual testing cases that can be used to verify the functioning of the website.

Refer to the demo video on the bottom of the page to find help on testing these cases

==== Scenario 1 - Creating an mentored team ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Courses
# Assuming you have created a course and added participants to it, proceed to create a team
# Make sure "Auto assign mentors when team hits > 50% capacity?" option is checked
[[File:MT 1-1.png | 600px]]
* Create team for the assignment and you can see that the team with more than 50% capacity gets a mentor assigned automatically
[[File:MT 1-2.png | 600px]]

==== Scenario 2 - Adding, editing, deleting mentor meeting dates ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Assigments
# Assuming you have created a mentored assignment and added participants to it, proceed to the teams page
# Try entering dates into it teams row and the date should persist
# You can edit and delete the dates from the rows
# Team with less than 50% capacity will have the mentor meeting dates disabled
[[File:MT 2.png | 600px]]

==== Scenario 3 - Creating a team with topic ====
* Log into Expertiza using the test credential and navigate to the home page
* Go to Manage > Courses
* Assuming you have created a course and added participants to it, proceed to create a team
* Make sure "Has topics?" option is checked and a topic is created using the Topics tab
[[File:MT 3-1.png | 600px]]
* Create a new topic for the assignment and enter a mentor name to the topic
[[File:UI2 E2403.png | 600px]]
* When a student is added to the topic, the team of the student along with the mentor will be displayed in the topic row
[[File:UI3 E2403.png | 600px]]
* When navigating to the teams page of that assignment, you can see a mentor assigned automatically
[[File:UI4 E2403.png | 600px]]

==== Scenario 4 - Creating Team -> Recieve Emails ====
* Step 1 is to change line 45 of app/mailers/mailer from "defn[:to] = 'expertiza.mailer@gmail.com'" to "defn[:to] = '{Your Email}'". This is so that you can test that the emails are being sent.
[[File:Team_addition_fix | 600px]]
* Now head to an existing assignment that assigns mentors when team capacity is above 50%. Delete a team if there are no students left to be added to a team. Make sure there are mentors on the student list, if not, add at least 1. Count how many mentors and students will be added to teams when you create a team (In our case this will be 2 students and 1 mentor).
[[File:t_listz.png| 600px]]
* Auto-create teams with max participants.
[[File:cre_teams.png | 600px]]
* Wait a couple of minutes and then check the email address you entered in step 1. You should expect to receive x number of student emails, and y number of mentor emails, where x is the number of students just assigned to a team, and y is the number of mentors assigned to mentor a team. In our example below you can see that there are 2 distinct student emails, and 1 mentor email, which is as expected in our case.
[[File:email_case.png | 600px]]

== Test Coverage ==
We used SimpleCov to generate a coverage report for the Rspec test cases implemented for the model and controllers.
The test coverage indicated 1730 lines of code was covered through the test cases.

[[File:Testing E2403.png ‎| 600px]]

== Test Login Credentials ==
* UserId: instructor6
* Password: password

== Demo Video ==
TODO:: 
This is our [https://www.youtube.com/ demo video] which explain how to create courses, assignments, mentored teams and mentored teams with topics. This video also show how to run the tests of our code changes.

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2789

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T02:16:21Z

Slkwiatk: /* Scenario 4 - Creating Team -> Recieve Emails */

== Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project. Instructors have the ability to add new projects, assignments, etc., as well as edit existing ones. Later on, they can view student submissions and grade them. Students can also use Expertiza to organize into teams to work on different projects and assignments and submit their work. They can also review other students' submissions.

== Introduction ==
This project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management/ E2304] for the implementation of the Mentor-meeting management in the Expertiza system for mentored teams. We are now required to add functionality to add mentors to the topics and then assign them to the teams when they pick up that topic.

== Problem Statement ==
The following tasks are required for the project:
#Enhancing Code Clarity: This involves renaming methods from Project 3 with ambiguous names, optimizing loops and adding comments for unclear lines of code
#Reimplement Mentored teams: Reimplement the Mentored team delegate to the Assignment team to reduce complexity and to follow best principles of Object Oriented Design
#Reimplement Sign Up Sheet or Topics: Reimplement the SignUpSheet controller to automatically add the mentor to when a topic is created and automatically assign the same mentor to a team when they choose the topic
#Writing tests for mentor meetings models: More tests have to be written for Mentor Meeting model
#Writing tests for the mentor meetings controller: More tests should be written for Mentor meeting controller
#Writing tests for the signup sheet controller: Additional tests should be written for signup sheet controller to test the new functionality

== Objectives ==
We have 3 main objectives for this project.
* Refactoring of the Mentor-meeting model and controller created for the Project 3
* Reimplementation of Mentored Teams model and controller for the Project 4
* Reimplementation of SignUp Sheet controller for the Project 4 to automatically assign mentors to the topics

== Design Goal ==
While fulfilling all the objectives, the following design rules have to be ensured:
* Validate proper functioning of all existing and anticipated methods, making any required enhancements or adjustments.
* Establish loose coupling and tight cohesion for the model and controller to enhance code organization and maintainability.
* Refactor redundant code in the previous implementation's controller and model methods using DRY principle, eliminating functionality duplication already present in the Expertiza system.
* Confirm the continued effectiveness of existing test cases following the aforementioned modifications and generate additional test cases as per the need.

== Class UML Diagram ==
[[File:OODD Proj4 E2403 - Entity Diagram 2.png ‎| 610px]]

== Classes and Relationships ==
=== Existing Structure ===
* Every Assignment has a Node
* Every Assignment has many AssignmentTeam and MentoredTeam
* AssignmentTeam is inherited from Team
* MentoredTeam is inherited from AssignmentTeam
* Every MentoredTeam has many MentorMeeting
=== Proposed Structure Structure ===
* MentoredTeam to be delegated from AssignmentTeam instead of inheriting from it

== Implementation Plan ==
=== Modify newly created controller, model and view ===
==== mentor_meeting_controller.rb ====
* Edit function names to make them more descriptive
* Add more descriptive comments for the functions
==== mentor_meetings_helper.rb ====
* Move the "get_dates_for_team" function to the model
* Rename the function to make it more descriptive
==== _entry_assignments.html.erb ====
* Add more descriptive comments for the JavaScript functions
* Move the Ruby code from the template to a helper or the controller
==== mentored_team.rb --> mentored_team_decorator ====
* To reduce DRY violations, the mentored team class was changed to the mentored team decorator class.
*

=== Modify existing controller model and view ===
==== teams/_team.html.erb ====
* As the mentored team will now be delegated from the assignment team, we need to change the if condition on the top as we are changing MentoredTeam to be delegated from the AssignmentTeam
==== teams_controller.rb ====
* This file has to be modified to work with the delegated MentoredTeam
* These lines will not work as MentoredTeam will not be a model
[[File:Teams con1.png ‎| 600px]]
==== sign_up_sheet_controller.rb ====
* This controller has to be modified to automatically assign mentors or manually add mentors to the topics when they are created
* This will be followed by a change in schema
[[File:Signup con1.png | 600px]]
==== _topic.html.erb ====
* If we manually have to assign mentors to the topic, we have to include a input field to enter the mentor
[[File:Topic html.png | 600px]]
==== schema.rb ====
* As we are adding a new field to the table, we need to modify the schema
* We need to write 1 migration to add the field to the table to update the schema file
[[File:Schema E2403.png | 600px]]

=== Mailer Changes ===
====team.rb====
* The team model must be altered to use delegation for cases where a team would previously be a mentored team.
====add_member====
* The add member function must be altered such that the call to mail a user is better named, and that it calls directly to the mailer rather than the mailer helper.
[[File:add_member_email.png | 900px]]
====mailer_helper====
* The mailer_helper will be altered such that the send_team_confimration_to_user will be moved and renamed in the Mailer.rb class instead since using generic_message as such is leading to an unclear design.
[[File:team_confirm.png | 900px]]

====mailer.rb====
* A new function to specifically handle messaging users when added to teams will be built in the mailer, rather than just overusing the generic_message function.

== UI Changes ==
=== UI Changes before Phase 2 code changes ===
* The mentored assignment teams page has the modified UI from the Phase 1 as it is also a mentored assignment
* But the teams do not have a TA as the automated assignment of mentors has not been implemented.
[[File:UI1 E2403.png | 600px]]

=== UI Changes after Phase 2 code changes ===
The mentored assignment teams with topic now has the new UI and the automated mentor assignment
* The form to create a new topic has a new field to assign mentor to a topic
[[File:UI2 E2403.png | 600px]]
* The updated UI showing the topics with the mentors and teams that have chosen the topic
* The mentor is also displayed with the team
[[File:UI3 E2403.png | 600px]]
* The assignment teams page has the modified UI from the Phase 1 as the teams have a mentor
[[File:UI4 E2403.png | 600px]]

== Implementation ==
=== Mailer Changes ===
==== Decorator ====
* To remove DRY violations, we transformed the MentoredTeam class into the MentoredTeamDecoratorClass.
[[File:MentoredTeamClass.png | 600px]] ---> [[File:MentoredTeamDecorator.png | 600px]]
* In particular this required changing the MentoredTeam to have its own assignment team variable.
* The add_member function's DRY violations with the Team Class were able to be eliminated here, as now the Mentored Team Decorator calls to the assignment team's add member function on line 14, and then simply calls to assign the mentor on line 16.

==== MailerHelper to Mailer ====
* To increase understandability and consistency between classes, we removed the send_team_confirmation_mail function from the MailerHelper, and instead replaced its functionality with the team_addition_message function in the Mailer class. We found this to be the ideal location as the Mailer class houses many other specific message functions such as notify_grade_conflict_message, suggested_topic_approved_message and more.
[[File:team_confirm.png | 600px]] ---> [[File:Team_Addtion_Message.png | 600px]]

==== Team Add_Member ====
* The add_member function was altered in a couple of different ways. Firstly, we parameterized the partial_name in the call to the function that actually sends the mail, as in the original code we were violating the DRY principle by repeating the same MailerHelper call twice with very little change between them.
* Additionally we removed the type check for whether a user is a participant or not, as most users should be participants.
[[File:add_member_email.png | 600px]] ---> [[File:New_Add_Message.png | 600px]]

=== Automatic topic mentor assignment changes ===
==== Team creation using decorator ====
* As we have moved the mentored team from a subclass of assignment team to being a decorator, we have modified the team creation code to assign the right type of class to the team
* If the team is a mentored team, we use the MentoredTeamDecorator to create the object of the Assignment class
[[File:Team Creation.png | 600px]]

==== Team deletion ====
* We have added the functionality to delete the Mentor meetings when the team is deleted
* If the team is a mentored team, we will find all the instances of mentor meetings for the team and delete them
* We have also modified the function to work as a independent function that can be called from any where in the application by passing a parameter
* When the parameter is not passed, it is used as a controller function to handle calls to a specific route
[[File:Team Deletion.png | 600px]]

==== Adding a user to a team ====
* We have modified the function to add an user to the team
* The create function in TeamsUsersController is modified
[[File:Team User Creation.png | 600px]]

==== Adding a mentor to a topic - Form and table ====
* We have added a field in the topics form to add a mentor to the topic in _topic.html.erb
[[File:Topic Form.png | 600px]]
* The table displaying the topics is also modified to have a column for the mentors in _table_header.html.erb
[[File:Topic Header.png | 600px]]
* The topic row also displays the team members with the mentor included in it in the topics table in _table_line.html.erb 
[[File:Topic Row.png | 600px]]

==== Adding a mentor to a topic - Functions ====
* We have modified the function to setup a new topic to include the functionality to add mentor to the topic
* In case we try to add a mentor who is not in the assignment or course, we add the mentor to the assignment and course too
* In this way we handle cases of adding mentors outside the course into the topic
[[File:Add Topic Mentor.png | 600px]]
* We have created some helper functions to assist in adding the mentor to the assignment and course
[[File:Addition Helpers.png | 600px]]

==== Automatic Mentor Assignment ====
* We have added additional function to assign the mentor of the topic to be automatically assigned to the team that chooses the topic
[[File:Auto Assign Topic Mentor.png | 600px]]
* The signup_as_instructor_action function will automatically call the assignment function to add the topic's mentor to the team
[[File:Call_Assign_Mentor.png | 600px]]

== Files Modified/Added ==
* app/controllers/sign_up_sheet_controller.rb
* app/controllers/teams_controller.rb
* app/controllers/teams_users_controller.rb
* app/models/course.rb
* app/models/mentor_management.rb
* app/views/sign_up_sheet/_table_header.html.erb
* app/views/sign_up_sheet/_table_line.html.erb
* app/views/sign_up_sheet/_topic.html.erb
* app/views/teams/_team.html.erb
* app/views/tree_display/_page_footer_assignments.html.erb
* app/views/tree_display/_entry_assignments.html.erb
* app/models/mentored_team_decorator.rb
* app/models/team.rb
* app/views/mailer/team_addition_message.html.erb
* app/views/mailer/team_addition_message.text.erb
* app/helpers/mailer_helper.rb
* app/mailers/mailer.rb
* spec/models/team_spec.rb
* spec/models/mentor_management_spec.rb

== Test Plan ==
When the project was pulled from the main repository, there are not enough tests to cover the additional functionalities that we added. We are planning on using the test skeletons by Mustafa Olmez, as a reference to how and what kind of tests should be written. Test cases for mentor management were already written and we wrote new test cases for the new functionalities we added. Here are the four test case scenarios we covered and the actual ruby code for the Rspec tests

=== Automated Rspec Testing Scenarios===
1. Test scenario 1: Given an assignment_id, When there are multiple mentors with different team counts for the assignment, Then it should return the mentor with the lowest team count
it "returns the mentor with the lowest team count for the given assignment" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 2]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

2. Test scenario 2: Given an assignment_id, When there is only one mentor available for the assignment, Then it should return that mentor
it "should return that mentor if there's only one available" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 0]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

3. Test scenario 3: Given an assignment_id, When there are multiple mentors with the same lowest team count for the assignment, Then it should return the first mentor in the list
it "returns the first mentor in the list if there's a tie for lowest team count" do
# Arrange
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 1],])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

4. Test scenario 4: Given an assignment_id, When there are no mentors available for the assignment, Then it should return nil
it "returns nil" do
# Create a new assignment
a = FactoryBot.create(:assignment, id: 997, directory_path: 'OSS_project', auto_assign_mentor: true)
# Since there are no mentors associated with this assignment, should return nil
expect(MentorManagement.select_mentor(a.id)).to eq nil
end

== Mailer Tests ==
5. Test scenario 5: Given a mentor is being added to a team, then the mailer should be called to send the mentor-specific mail to the mentor
it 'sends mail to mentor if user is a mentor' do
allow(MentorManagement).to receive(:user_a_mentor?).with(user).and_return(true)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
allow(Mailer).to receive(:team_addition_message).and_return(double('Mail', deliver: true))
expect(Mailer).to receive(:team_addition_message).with(
to: user.email,
subject: '[Expertiza] Added to a Team',
body: {
user: user,
first_name: ApplicationHelper.get_user_first_name(user),
partial_name: 'mentor_added_to_team',
team: team.name.to_s,
assignment: ''
}
).and_return(double('Mail', deliver: true))
expect(team.add_member(user)).to be true
end

6. Test scenario 6: Given a normal user is being added to a team, then the mailer should be called to send the general user addition mail to the user
it 'sends mail to user if user is a user' do
allow(MentorManagement).to receive(:user_a_mentor?).with(user).and_return(true)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
allow(Mailer).to receive(:team_addition_message).and_return(double('Mail', deliver: true))
expect(Mailer).to receive(:team_addition_message).with(
to: user.email,
subject: '[Expertiza] Added to a Team',
body: {
user: user,
first_name: ApplicationHelper.get_user_first_name(user),
partial_name: 'user_added_to_team',
team: team.name.to_s,
assignment: ''
}
).and_return(double('Mail', deliver: true))
expect(team.add_member(user)).to be true
end

=== Manual UI Testing ===
Apart from the automated Rspec tests, we are providing manual testing cases that can be used to verify the functioning of the website.

Refer to the demo video on the bottom of the page to find help on testing these cases

==== Scenario 1 - Creating an mentored team ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Courses
# Assuming you have created a course and added participants to it, proceed to create a team
# Make sure "Auto assign mentors when team hits > 50% capacity?" option is checked
[[File:MT 1-1.png | 600px]]
* Create team for the assignment and you can see that the team with more than 50% capacity gets a mentor assigned automatically
[[File:MT 1-2.png | 600px]]

==== Scenario 2 - Adding, editing, deleting mentor meeting dates ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Assigments
# Assuming you have created a mentored assignment and added participants to it, proceed to the teams page
# Try entering dates into it teams row and the date should persist
# You can edit and delete the dates from the rows
# Team with less than 50% capacity will have the mentor meeting dates disabled
[[File:MT 2.png | 600px]]

==== Scenario 3 - Creating a team with topic ====
* Log into Expertiza using the test credential and navigate to the home page
* Go to Manage > Courses
* Assuming you have created a course and added participants to it, proceed to create a team
* Make sure "Has topics?" option is checked and a topic is created using the Topics tab
[[File:MT 3-1.png | 600px]]
* Create a new topic for the assignment and enter a mentor name to the topic
[[File:UI2 E2403.png | 600px]]
* When a student is added to the topic, the team of the student along with the mentor will be displayed in the topic row
[[File:UI3 E2403.png | 600px]]
* When navigating to the teams page of that assignment, you can see a mentor assigned automatically
[[File:UI4 E2403.png | 600px]]

==== Scenario 4 - Creating Team -> Recieve Emails ====
* Step 1 is to change line 45 of app/mailers/mailer from "defn[:to] = 'expertiza.mailer@gmail.com'" to "defn[:to] = '{Your Email}'". This is so that you can test that the emails are being sent.
[[

== Test Coverage ==
We used SimpleCov to generate a coverage report for the Rspec test cases implemented for the model and controllers.
The test coverage indicated 1730 lines of code was covered through the test cases.

[[File:Testing E2403.png ‎| 600px]]

== Test Login Credentials ==
* UserId: instructor6
* Password: password

== Demo Video ==
TODO:: 
This is our [https://www.youtube.com/ demo video] which explain how to create courses, assignments, mentored teams and mentored teams with topics. This video also show how to run the tests of our code changes.

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2789

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T02:15:49Z

Slkwiatk: /* Test Coverage */

== Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project. Instructors have the ability to add new projects, assignments, etc., as well as edit existing ones. Later on, they can view student submissions and grade them. Students can also use Expertiza to organize into teams to work on different projects and assignments and submit their work. They can also review other students' submissions.

== Introduction ==
This project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management/ E2304] for the implementation of the Mentor-meeting management in the Expertiza system for mentored teams. We are now required to add functionality to add mentors to the topics and then assign them to the teams when they pick up that topic.

== Problem Statement ==
The following tasks are required for the project:
#Enhancing Code Clarity: This involves renaming methods from Project 3 with ambiguous names, optimizing loops and adding comments for unclear lines of code
#Reimplement Mentored teams: Reimplement the Mentored team delegate to the Assignment team to reduce complexity and to follow best principles of Object Oriented Design
#Reimplement Sign Up Sheet or Topics: Reimplement the SignUpSheet controller to automatically add the mentor to when a topic is created and automatically assign the same mentor to a team when they choose the topic
#Writing tests for mentor meetings models: More tests have to be written for Mentor Meeting model
#Writing tests for the mentor meetings controller: More tests should be written for Mentor meeting controller
#Writing tests for the signup sheet controller: Additional tests should be written for signup sheet controller to test the new functionality

== Objectives ==
We have 3 main objectives for this project.
* Refactoring of the Mentor-meeting model and controller created for the Project 3
* Reimplementation of Mentored Teams model and controller for the Project 4
* Reimplementation of SignUp Sheet controller for the Project 4 to automatically assign mentors to the topics

== Design Goal ==
While fulfilling all the objectives, the following design rules have to be ensured:
* Validate proper functioning of all existing and anticipated methods, making any required enhancements or adjustments.
* Establish loose coupling and tight cohesion for the model and controller to enhance code organization and maintainability.
* Refactor redundant code in the previous implementation's controller and model methods using DRY principle, eliminating functionality duplication already present in the Expertiza system.
* Confirm the continued effectiveness of existing test cases following the aforementioned modifications and generate additional test cases as per the need.

== Class UML Diagram ==
[[File:OODD Proj4 E2403 - Entity Diagram 2.png ‎| 610px]]

== Classes and Relationships ==
=== Existing Structure ===
* Every Assignment has a Node
* Every Assignment has many AssignmentTeam and MentoredTeam
* AssignmentTeam is inherited from Team
* MentoredTeam is inherited from AssignmentTeam
* Every MentoredTeam has many MentorMeeting
=== Proposed Structure Structure ===
* MentoredTeam to be delegated from AssignmentTeam instead of inheriting from it

== Implementation Plan ==
=== Modify newly created controller, model and view ===
==== mentor_meeting_controller.rb ====
* Edit function names to make them more descriptive
* Add more descriptive comments for the functions
==== mentor_meetings_helper.rb ====
* Move the "get_dates_for_team" function to the model
* Rename the function to make it more descriptive
==== _entry_assignments.html.erb ====
* Add more descriptive comments for the JavaScript functions
* Move the Ruby code from the template to a helper or the controller
==== mentored_team.rb --> mentored_team_decorator ====
* To reduce DRY violations, the mentored team class was changed to the mentored team decorator class.
*

=== Modify existing controller model and view ===
==== teams/_team.html.erb ====
* As the mentored team will now be delegated from the assignment team, we need to change the if condition on the top as we are changing MentoredTeam to be delegated from the AssignmentTeam
==== teams_controller.rb ====
* This file has to be modified to work with the delegated MentoredTeam
* These lines will not work as MentoredTeam will not be a model
[[File:Teams con1.png ‎| 600px]]
==== sign_up_sheet_controller.rb ====
* This controller has to be modified to automatically assign mentors or manually add mentors to the topics when they are created
* This will be followed by a change in schema
[[File:Signup con1.png | 600px]]
==== _topic.html.erb ====
* If we manually have to assign mentors to the topic, we have to include a input field to enter the mentor
[[File:Topic html.png | 600px]]
==== schema.rb ====
* As we are adding a new field to the table, we need to modify the schema
* We need to write 1 migration to add the field to the table to update the schema file
[[File:Schema E2403.png | 600px]]

=== Mailer Changes ===
====team.rb====
* The team model must be altered to use delegation for cases where a team would previously be a mentored team.
====add_member====
* The add member function must be altered such that the call to mail a user is better named, and that it calls directly to the mailer rather than the mailer helper.
[[File:add_member_email.png | 900px]]
====mailer_helper====
* The mailer_helper will be altered such that the send_team_confimration_to_user will be moved and renamed in the Mailer.rb class instead since using generic_message as such is leading to an unclear design.
[[File:team_confirm.png | 900px]]

====mailer.rb====
* A new function to specifically handle messaging users when added to teams will be built in the mailer, rather than just overusing the generic_message function.

== UI Changes ==
=== UI Changes before Phase 2 code changes ===
* The mentored assignment teams page has the modified UI from the Phase 1 as it is also a mentored assignment
* But the teams do not have a TA as the automated assignment of mentors has not been implemented.
[[File:UI1 E2403.png | 600px]]

=== UI Changes after Phase 2 code changes ===
The mentored assignment teams with topic now has the new UI and the automated mentor assignment
* The form to create a new topic has a new field to assign mentor to a topic
[[File:UI2 E2403.png | 600px]]
* The updated UI showing the topics with the mentors and teams that have chosen the topic
* The mentor is also displayed with the team
[[File:UI3 E2403.png | 600px]]
* The assignment teams page has the modified UI from the Phase 1 as the teams have a mentor
[[File:UI4 E2403.png | 600px]]

== Implementation ==
=== Mailer Changes ===
==== Decorator ====
* To remove DRY violations, we transformed the MentoredTeam class into the MentoredTeamDecoratorClass.
[[File:MentoredTeamClass.png | 600px]] ---> [[File:MentoredTeamDecorator.png | 600px]]
* In particular this required changing the MentoredTeam to have its own assignment team variable.
* The add_member function's DRY violations with the Team Class were able to be eliminated here, as now the Mentored Team Decorator calls to the assignment team's add member function on line 14, and then simply calls to assign the mentor on line 16.

==== MailerHelper to Mailer ====
* To increase understandability and consistency between classes, we removed the send_team_confirmation_mail function from the MailerHelper, and instead replaced its functionality with the team_addition_message function in the Mailer class. We found this to be the ideal location as the Mailer class houses many other specific message functions such as notify_grade_conflict_message, suggested_topic_approved_message and more.
[[File:team_confirm.png | 600px]] ---> [[File:Team_Addtion_Message.png | 600px]]

==== Team Add_Member ====
* The add_member function was altered in a couple of different ways. Firstly, we parameterized the partial_name in the call to the function that actually sends the mail, as in the original code we were violating the DRY principle by repeating the same MailerHelper call twice with very little change between them.
* Additionally we removed the type check for whether a user is a participant or not, as most users should be participants.
[[File:add_member_email.png | 600px]] ---> [[File:New_Add_Message.png | 600px]]

=== Automatic topic mentor assignment changes ===
==== Team creation using decorator ====
* As we have moved the mentored team from a subclass of assignment team to being a decorator, we have modified the team creation code to assign the right type of class to the team
* If the team is a mentored team, we use the MentoredTeamDecorator to create the object of the Assignment class
[[File:Team Creation.png | 600px]]

==== Team deletion ====
* We have added the functionality to delete the Mentor meetings when the team is deleted
* If the team is a mentored team, we will find all the instances of mentor meetings for the team and delete them
* We have also modified the function to work as a independent function that can be called from any where in the application by passing a parameter
* When the parameter is not passed, it is used as a controller function to handle calls to a specific route
[[File:Team Deletion.png | 600px]]

==== Adding a user to a team ====
* We have modified the function to add an user to the team
* The create function in TeamsUsersController is modified
[[File:Team User Creation.png | 600px]]

==== Adding a mentor to a topic - Form and table ====
* We have added a field in the topics form to add a mentor to the topic in _topic.html.erb
[[File:Topic Form.png | 600px]]
* The table displaying the topics is also modified to have a column for the mentors in _table_header.html.erb
[[File:Topic Header.png | 600px]]
* The topic row also displays the team members with the mentor included in it in the topics table in _table_line.html.erb 
[[File:Topic Row.png | 600px]]

==== Adding a mentor to a topic - Functions ====
* We have modified the function to setup a new topic to include the functionality to add mentor to the topic
* In case we try to add a mentor who is not in the assignment or course, we add the mentor to the assignment and course too
* In this way we handle cases of adding mentors outside the course into the topic
[[File:Add Topic Mentor.png | 600px]]
* We have created some helper functions to assist in adding the mentor to the assignment and course
[[File:Addition Helpers.png | 600px]]

==== Automatic Mentor Assignment ====
* We have added additional function to assign the mentor of the topic to be automatically assigned to the team that chooses the topic
[[File:Auto Assign Topic Mentor.png | 600px]]
* The signup_as_instructor_action function will automatically call the assignment function to add the topic's mentor to the team
[[File:Call_Assign_Mentor.png | 600px]]

== Files Modified/Added ==
* app/controllers/sign_up_sheet_controller.rb
* app/controllers/teams_controller.rb
* app/controllers/teams_users_controller.rb
* app/models/course.rb
* app/models/mentor_management.rb
* app/views/sign_up_sheet/_table_header.html.erb
* app/views/sign_up_sheet/_table_line.html.erb
* app/views/sign_up_sheet/_topic.html.erb
* app/views/teams/_team.html.erb
* app/views/tree_display/_page_footer_assignments.html.erb
* app/views/tree_display/_entry_assignments.html.erb
* app/models/mentored_team_decorator.rb
* app/models/team.rb
* app/views/mailer/team_addition_message.html.erb
* app/views/mailer/team_addition_message.text.erb
* app/helpers/mailer_helper.rb
* app/mailers/mailer.rb
* spec/models/team_spec.rb
* spec/models/mentor_management_spec.rb

== Test Plan ==
When the project was pulled from the main repository, there are not enough tests to cover the additional functionalities that we added. We are planning on using the test skeletons by Mustafa Olmez, as a reference to how and what kind of tests should be written. Test cases for mentor management were already written and we wrote new test cases for the new functionalities we added. Here are the four test case scenarios we covered and the actual ruby code for the Rspec tests

=== Automated Rspec Testing Scenarios===
1. Test scenario 1: Given an assignment_id, When there are multiple mentors with different team counts for the assignment, Then it should return the mentor with the lowest team count
it "returns the mentor with the lowest team count for the given assignment" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 2]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

2. Test scenario 2: Given an assignment_id, When there is only one mentor available for the assignment, Then it should return that mentor
it "should return that mentor if there's only one available" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 0]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

3. Test scenario 3: Given an assignment_id, When there are multiple mentors with the same lowest team count for the assignment, Then it should return the first mentor in the list
it "returns the first mentor in the list if there's a tie for lowest team count" do
# Arrange
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 1],])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

4. Test scenario 4: Given an assignment_id, When there are no mentors available for the assignment, Then it should return nil
it "returns nil" do
# Create a new assignment
a = FactoryBot.create(:assignment, id: 997, directory_path: 'OSS_project', auto_assign_mentor: true)
# Since there are no mentors associated with this assignment, should return nil
expect(MentorManagement.select_mentor(a.id)).to eq nil
end

== Mailer Tests ==
5. Test scenario 5: Given a mentor is being added to a team, then the mailer should be called to send the mentor-specific mail to the mentor
it 'sends mail to mentor if user is a mentor' do
allow(MentorManagement).to receive(:user_a_mentor?).with(user).and_return(true)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
allow(Mailer).to receive(:team_addition_message).and_return(double('Mail', deliver: true))
expect(Mailer).to receive(:team_addition_message).with(
to: user.email,
subject: '[Expertiza] Added to a Team',
body: {
user: user,
first_name: ApplicationHelper.get_user_first_name(user),
partial_name: 'mentor_added_to_team',
team: team.name.to_s,
assignment: ''
}
).and_return(double('Mail', deliver: true))
expect(team.add_member(user)).to be true
end

6. Test scenario 6: Given a normal user is being added to a team, then the mailer should be called to send the general user addition mail to the user
it 'sends mail to user if user is a user' do
allow(MentorManagement).to receive(:user_a_mentor?).with(user).and_return(true)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
allow(Mailer).to receive(:team_addition_message).and_return(double('Mail', deliver: true))
expect(Mailer).to receive(:team_addition_message).with(
to: user.email,
subject: '[Expertiza] Added to a Team',
body: {
user: user,
first_name: ApplicationHelper.get_user_first_name(user),
partial_name: 'user_added_to_team',
team: team.name.to_s,
assignment: ''
}
).and_return(double('Mail', deliver: true))
expect(team.add_member(user)).to be true
end

=== Manual UI Testing ===
Apart from the automated Rspec tests, we are providing manual testing cases that can be used to verify the functioning of the website.

Refer to the demo video on the bottom of the page to find help on testing these cases

==== Scenario 1 - Creating an mentored team ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Courses
# Assuming you have created a course and added participants to it, proceed to create a team
# Make sure "Auto assign mentors when team hits > 50% capacity?" option is checked
[[File:MT 1-1.png | 600px]]
* Create team for the assignment and you can see that the team with more than 50% capacity gets a mentor assigned automatically
[[File:MT 1-2.png | 600px]]

==== Scenario 2 - Adding, editing, deleting mentor meeting dates ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Assigments
# Assuming you have created a mentored assignment and added participants to it, proceed to the teams page
# Try entering dates into it teams row and the date should persist
# You can edit and delete the dates from the rows
# Team with less than 50% capacity will have the mentor meeting dates disabled
[[File:MT 2.png | 600px]]

==== Scenario 3 - Creating a team with topic ====
* Log into Expertiza using the test credential and navigate to the home page
* Go to Manage > Courses
* Assuming you have created a course and added participants to it, proceed to create a team
* Make sure "Has topics?" option is checked and a topic is created using the Topics tab
[[File:MT 3-1.png | 600px]]
* Create a new topic for the assignment and enter a mentor name to the topic
[[File:UI2 E2403.png | 600px]]
* When a student is added to the topic, the team of the student along with the mentor will be displayed in the topic row
[[File:UI3 E2403.png | 600px]]
* When navigating to the teams page of that assignment, you can see a mentor assigned automatically
[[File:UI4 E2403.png | 600px]]

==== Scenario 4 - Creating Team -> Recieve Emails ====
* Step 1 is to change line 45 of app/mailers/mailer from "defn[:to] = 'expertiza.mailer@gmail.com'" to "defn[:to] = '{Your Email}'". This is so that you can test that the emails are being sent.

== Test Coverage ==
We used SimpleCov to generate a coverage report for the Rspec test cases implemented for the model and controllers.
The test coverage indicated 1730 lines of code was covered through the test cases.

[[File:Testing E2403.png ‎| 600px]]

== Test Login Credentials ==
* UserId: instructor6
* Password: password

== Demo Video ==
TODO:: 
This is our [https://www.youtube.com/ demo video] which explain how to create courses, assignments, mentored teams and mentored teams with topics. This video also show how to run the tests of our code changes.

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2789

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

File:Team addition fix.png

2024-04-24T02:13:41Z

Slkwiatk:

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T02:13:08Z

Slkwiatk: /* Scenario 4 - Creating Team -> Recieve Emails */

== Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project. Instructors have the ability to add new projects, assignments, etc., as well as edit existing ones. Later on, they can view student submissions and grade them. Students can also use Expertiza to organize into teams to work on different projects and assignments and submit their work. They can also review other students' submissions.

== Introduction ==
This project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management/ E2304] for the implementation of the Mentor-meeting management in the Expertiza system for mentored teams. We are now required to add functionality to add mentors to the topics and then assign them to the teams when they pick up that topic.

== Problem Statement ==
The following tasks are required for the project:
#Enhancing Code Clarity: This involves renaming methods from Project 3 with ambiguous names, optimizing loops and adding comments for unclear lines of code
#Reimplement Mentored teams: Reimplement the Mentored team delegate to the Assignment team to reduce complexity and to follow best principles of Object Oriented Design
#Reimplement Sign Up Sheet or Topics: Reimplement the SignUpSheet controller to automatically add the mentor to when a topic is created and automatically assign the same mentor to a team when they choose the topic
#Writing tests for mentor meetings models: More tests have to be written for Mentor Meeting model
#Writing tests for the mentor meetings controller: More tests should be written for Mentor meeting controller
#Writing tests for the signup sheet controller: Additional tests should be written for signup sheet controller to test the new functionality

== Objectives ==
We have 3 main objectives for this project.
* Refactoring of the Mentor-meeting model and controller created for the Project 3
* Reimplementation of Mentored Teams model and controller for the Project 4
* Reimplementation of SignUp Sheet controller for the Project 4 to automatically assign mentors to the topics

== Design Goal ==
While fulfilling all the objectives, the following design rules have to be ensured:
* Validate proper functioning of all existing and anticipated methods, making any required enhancements or adjustments.
* Establish loose coupling and tight cohesion for the model and controller to enhance code organization and maintainability.
* Refactor redundant code in the previous implementation's controller and model methods using DRY principle, eliminating functionality duplication already present in the Expertiza system.
* Confirm the continued effectiveness of existing test cases following the aforementioned modifications and generate additional test cases as per the need.

== Class UML Diagram ==
[[File:OODD Proj4 E2403 - Entity Diagram 2.png ‎| 610px]]

== Classes and Relationships ==
=== Existing Structure ===
* Every Assignment has a Node
* Every Assignment has many AssignmentTeam and MentoredTeam
* AssignmentTeam is inherited from Team
* MentoredTeam is inherited from AssignmentTeam
* Every MentoredTeam has many MentorMeeting
=== Proposed Structure Structure ===
* MentoredTeam to be delegated from AssignmentTeam instead of inheriting from it

== Implementation Plan ==
=== Modify newly created controller, model and view ===
==== mentor_meeting_controller.rb ====
* Edit function names to make them more descriptive
* Add more descriptive comments for the functions
==== mentor_meetings_helper.rb ====
* Move the "get_dates_for_team" function to the model
* Rename the function to make it more descriptive
==== _entry_assignments.html.erb ====
* Add more descriptive comments for the JavaScript functions
* Move the Ruby code from the template to a helper or the controller
==== mentored_team.rb --> mentored_team_decorator ====
* To reduce DRY violations, the mentored team class was changed to the mentored team decorator class.
*

=== Modify existing controller model and view ===
==== teams/_team.html.erb ====
* As the mentored team will now be delegated from the assignment team, we need to change the if condition on the top as we are changing MentoredTeam to be delegated from the AssignmentTeam
==== teams_controller.rb ====
* This file has to be modified to work with the delegated MentoredTeam
* These lines will not work as MentoredTeam will not be a model
[[File:Teams con1.png ‎| 600px]]
==== sign_up_sheet_controller.rb ====
* This controller has to be modified to automatically assign mentors or manually add mentors to the topics when they are created
* This will be followed by a change in schema
[[File:Signup con1.png | 600px]]
==== _topic.html.erb ====
* If we manually have to assign mentors to the topic, we have to include a input field to enter the mentor
[[File:Topic html.png | 600px]]
==== schema.rb ====
* As we are adding a new field to the table, we need to modify the schema
* We need to write 1 migration to add the field to the table to update the schema file
[[File:Schema E2403.png | 600px]]

=== Mailer Changes ===
====team.rb====
* The team model must be altered to use delegation for cases where a team would previously be a mentored team.
====add_member====
* The add member function must be altered such that the call to mail a user is better named, and that it calls directly to the mailer rather than the mailer helper.
[[File:add_member_email.png | 900px]]
====mailer_helper====
* The mailer_helper will be altered such that the send_team_confimration_to_user will be moved and renamed in the Mailer.rb class instead since using generic_message as such is leading to an unclear design.
[[File:team_confirm.png | 900px]]

====mailer.rb====
* A new function to specifically handle messaging users when added to teams will be built in the mailer, rather than just overusing the generic_message function.

== UI Changes ==
=== UI Changes before Phase 2 code changes ===
* The mentored assignment teams page has the modified UI from the Phase 1 as it is also a mentored assignment
* But the teams do not have a TA as the automated assignment of mentors has not been implemented.
[[File:UI1 E2403.png | 600px]]

=== UI Changes after Phase 2 code changes ===
The mentored assignment teams with topic now has the new UI and the automated mentor assignment
* The form to create a new topic has a new field to assign mentor to a topic
[[File:UI2 E2403.png | 600px]]
* The updated UI showing the topics with the mentors and teams that have chosen the topic
* The mentor is also displayed with the team
[[File:UI3 E2403.png | 600px]]
* The assignment teams page has the modified UI from the Phase 1 as the teams have a mentor
[[File:UI4 E2403.png | 600px]]

== Implementation ==
=== Mailer Changes ===
==== Decorator ====
* To remove DRY violations, we transformed the MentoredTeam class into the MentoredTeamDecoratorClass.
[[File:MentoredTeamClass.png | 600px]] ---> [[File:MentoredTeamDecorator.png | 600px]]
* In particular this required changing the MentoredTeam to have its own assignment team variable.
* The add_member function's DRY violations with the Team Class were able to be eliminated here, as now the Mentored Team Decorator calls to the assignment team's add member function on line 14, and then simply calls to assign the mentor on line 16.

==== MailerHelper to Mailer ====
* To increase understandability and consistency between classes, we removed the send_team_confirmation_mail function from the MailerHelper, and instead replaced its functionality with the team_addition_message function in the Mailer class. We found this to be the ideal location as the Mailer class houses many other specific message functions such as notify_grade_conflict_message, suggested_topic_approved_message and more.
[[File:team_confirm.png | 600px]] ---> [[File:Team_Addtion_Message.png | 600px]]

==== Team Add_Member ====
* The add_member function was altered in a couple of different ways. Firstly, we parameterized the partial_name in the call to the function that actually sends the mail, as in the original code we were violating the DRY principle by repeating the same MailerHelper call twice with very little change between them.
* Additionally we removed the type check for whether a user is a participant or not, as most users should be participants.
[[File:add_member_email.png | 600px]] ---> [[File:New_Add_Message.png | 600px]]

=== Automatic topic mentor assignment changes ===
==== Team creation using decorator ====
* As we have moved the mentored team from a subclass of assignment team to being a decorator, we have modified the team creation code to assign the right type of class to the team
* If the team is a mentored team, we use the MentoredTeamDecorator to create the object of the Assignment class
[[File:Team Creation.png | 600px]]

==== Team deletion ====
* We have added the functionality to delete the Mentor meetings when the team is deleted
* If the team is a mentored team, we will find all the instances of mentor meetings for the team and delete them
* We have also modified the function to work as a independent function that can be called from any where in the application by passing a parameter
* When the parameter is not passed, it is used as a controller function to handle calls to a specific route
[[File:Team Deletion.png | 600px]]

==== Adding a user to a team ====
* We have modified the function to add an user to the team
* The create function in TeamsUsersController is modified
[[File:Team User Creation.png | 600px]]

==== Adding a mentor to a topic - Form and table ====
* We have added a field in the topics form to add a mentor to the topic in _topic.html.erb
[[File:Topic Form.png | 600px]]
* The table displaying the topics is also modified to have a column for the mentors in _table_header.html.erb
[[File:Topic Header.png | 600px]]
* The topic row also displays the team members with the mentor included in it in the topics table in _table_line.html.erb 
[[File:Topic Row.png | 600px]]

==== Adding a mentor to a topic - Functions ====
* We have modified the function to setup a new topic to include the functionality to add mentor to the topic
* In case we try to add a mentor who is not in the assignment or course, we add the mentor to the assignment and course too
* In this way we handle cases of adding mentors outside the course into the topic
[[File:Add Topic Mentor.png | 600px]]
* We have created some helper functions to assist in adding the mentor to the assignment and course
[[File:Addition Helpers.png | 600px]]

==== Automatic Mentor Assignment ====
* We have added additional function to assign the mentor of the topic to be automatically assigned to the team that chooses the topic
[[File:Auto Assign Topic Mentor.png | 600px]]
* The signup_as_instructor_action function will automatically call the assignment function to add the topic's mentor to the team
[[File:Call_Assign_Mentor.png | 600px]]

== Implementation - To delete later ==
TODO:: 

== Files Modified/Added ==
* app/controllers/sign_up_sheet_controller.rb
* app/controllers/teams_controller.rb
* app/controllers/teams_users_controller.rb
* app/models/course.rb
* app/models/mentor_management.rb
* app/views/sign_up_sheet/_table_header.html.erb
* app/views/sign_up_sheet/_table_line.html.erb
* app/views/sign_up_sheet/_topic.html.erb
* app/views/teams/_team.html.erb
* app/views/tree_display/_page_footer_assignments.html.erb
* app/views/tree_display/_entry_assignments.html.erb
* app/models/mentored_team_decorator.rb
* app/models/team.rb
* app/views/mailer/team_addition_message.html.erb
* app/views/mailer/team_addition_message.text.erb
* app/helpers/mailer_helper.rb
* app/mailers/mailer.rb
* spec/models/team_spec.rb
* spec/models/mentor_management_spec.rb

== Test Plan ==
When the project was pulled from the main repository, there are not enough tests to cover the additional functionalities that we added. We are planning on using the test skeletons by Mustafa Olmez, as a reference to how and what kind of tests should be written. Test cases for mentor management were already written and we wrote new test cases for the new functionalities we added. Here are the four test case scenarios we covered and the actual ruby code for the Rspec tests

=== Automated Rspec Testing Scenarios===
1. Test scenario 1: Given an assignment_id, When there are multiple mentors with different team counts for the assignment, Then it should return the mentor with the lowest team count
it "returns the mentor with the lowest team count for the given assignment" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 2]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

2. Test scenario 2: Given an assignment_id, When there is only one mentor available for the assignment, Then it should return that mentor
it "should return that mentor if there's only one available" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 0]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

3. Test scenario 3: Given an assignment_id, When there are multiple mentors with the same lowest team count for the assignment, Then it should return the first mentor in the list
it "returns the first mentor in the list if there's a tie for lowest team count" do
# Arrange
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 1],])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

4. Test scenario 4: Given an assignment_id, When there are no mentors available for the assignment, Then it should return nil
it "returns nil" do
# Create a new assignment
a = FactoryBot.create(:assignment, id: 997, directory_path: 'OSS_project', auto_assign_mentor: true)
# Since there are no mentors associated with this assignment, should return nil
expect(MentorManagement.select_mentor(a.id)).to eq nil
end

== Mailer Tests ==
5. Test scenario 5: Given a mentor is being added to a team, then the mailer should be called to send the mentor-specific mail to the mentor
it 'sends mail to mentor if user is a mentor' do
allow(MentorManagement).to receive(:user_a_mentor?).with(user).and_return(true)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
allow(Mailer).to receive(:team_addition_message).and_return(double('Mail', deliver: true))
expect(Mailer).to receive(:team_addition_message).with(
to: user.email,
subject: '[Expertiza] Added to a Team',
body: {
user: user,
first_name: ApplicationHelper.get_user_first_name(user),
partial_name: 'mentor_added_to_team',
team: team.name.to_s,
assignment: ''
}
).and_return(double('Mail', deliver: true))
expect(team.add_member(user)).to be true
end

6. Test scenario 6: Given a normal user is being added to a team, then the mailer should be called to send the general user addition mail to the user
it 'sends mail to user if user is a user' do
allow(MentorManagement).to receive(:user_a_mentor?).with(user).and_return(true)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
allow(Mailer).to receive(:team_addition_message).and_return(double('Mail', deliver: true))
expect(Mailer).to receive(:team_addition_message).with(
to: user.email,
subject: '[Expertiza] Added to a Team',
body: {
user: user,
first_name: ApplicationHelper.get_user_first_name(user),
partial_name: 'user_added_to_team',
team: team.name.to_s,
assignment: ''
}
).and_return(double('Mail', deliver: true))
expect(team.add_member(user)).to be true
end

=== Manual UI Testing ===
Apart from the automated Rspec tests, we are providing manual testing cases that can be used to verify the functioning of the website.

Refer to the demo video on the bottom of the page to find help on testing these cases

==== Scenario 1 - Creating an mentored team ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Courses
# Assuming you have created a course and added participants to it, proceed to create a team
# Make sure "Auto assign mentors when team hits > 50% capacity?" option is checked
[[File:MT 1-1.png | 600px]]
* Create team for the assignment and you can see that the team with more than 50% capacity gets a mentor assigned automatically
[[File:MT 1-2.png | 600px]]

==== Scenario 2 - Adding, editing, deleting mentor meeting dates ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Assigments
# Assuming you have created a mentored assignment and added participants to it, proceed to the teams page
# Try entering dates into it teams row and the date should persist
# You can edit and delete the dates from the rows
# Team with less than 50% capacity will have the mentor meeting dates disabled
[[File:MT 2.png | 600px]]

==== Scenario 3 - Creating a team with topic ====
* Log into Expertiza using the test credential and navigate to the home page
* Go to Manage > Courses
* Assuming you have created a course and added participants to it, proceed to create a team
* Make sure "Has topics?" option is checked and a topic is created using the Topics tab
[[File:MT 3-1.png | 600px]]
* Create a new topic for the assignment and enter a mentor name to the topic
[[File:UI2 E2403.png | 600px]]
* When a student is added to the topic, the team of the student along with the mentor will be displayed in the topic row
[[File:UI3 E2403.png | 600px]]
* When navigating to the teams page of that assignment, you can see a mentor assigned automatically
[[File:UI4 E2403.png | 600px]]

==== Scenario 4 - Creating Team -> Recieve Emails ====
* Step 1 is to change line 45 of app/mailers/mailer from "defn[:to] = 'expertiza.mailer@gmail.com'" to "defn[:to] = '{Your Email}'". This is so that you can test that the emails are being sent.

== Test Coverage ==
We used SimpleCov to generate a coverage report for the Rspec test cases implemeted for the model and controllers.
The test coverage indicated 1730 lines of code was covered through the testcases.

[[File:Testing E2403.png ‎| 600px]]

== Test Login Credentials ==
* UserId: instructor6
* Password: password

== Demo Video ==
TODO:: 
This is our [https://www.youtube.com/ demo video] which explain how to create courses, assignments, mentored teams and mentored teams with topics. This video also show how to run the tests of our code changes.

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2789

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T02:10:32Z

Slkwiatk: /* Manual UI Testing */

== Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project. Instructors have the ability to add new projects, assignments, etc., as well as edit existing ones. Later on, they can view student submissions and grade them. Students can also use Expertiza to organize into teams to work on different projects and assignments and submit their work. They can also review other students' submissions.

== Introduction ==
This project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management/ E2304] for the implementation of the Mentor-meeting management in the Expertiza system for mentored teams. We are now required to add functionality to add mentors to the topics and then assign them to the teams when they pick up that topic.

== Problem Statement ==
The following tasks are required for the project:
#Enhancing Code Clarity: This involves renaming methods from Project 3 with ambiguous names, optimizing loops and adding comments for unclear lines of code
#Reimplement Mentored teams: Reimplement the Mentored team delegate to the Assignment team to reduce complexity and to follow best principles of Object Oriented Design
#Reimplement Sign Up Sheet or Topics: Reimplement the SignUpSheet controller to automatically add the mentor to when a topic is created and automatically assign the same mentor to a team when they choose the topic
#Writing tests for mentor meetings models: More tests have to be written for Mentor Meeting model
#Writing tests for the mentor meetings controller: More tests should be written for Mentor meeting controller
#Writing tests for the signup sheet controller: Additional tests should be written for signup sheet controller to test the new functionality

== Objectives ==
We have 3 main objectives for this project.
* Refactoring of the Mentor-meeting model and controller created for the Project 3
* Reimplementation of Mentored Teams model and controller for the Project 4
* Reimplementation of SignUp Sheet controller for the Project 4 to automatically assign mentors to the topics

== Design Goal ==
While fulfilling all the objectives, the following design rules have to be ensured:
* Validate proper functioning of all existing and anticipated methods, making any required enhancements or adjustments.
* Establish loose coupling and tight cohesion for the model and controller to enhance code organization and maintainability.
* Refactor redundant code in the previous implementation's controller and model methods using DRY principle, eliminating functionality duplication already present in the Expertiza system.
* Confirm the continued effectiveness of existing test cases following the aforementioned modifications and generate additional test cases as per the need.

== Class UML Diagram ==
[[File:OODD Proj4 E2403 - Entity Diagram 2.png ‎| 610px]]

== Classes and Relationships ==
=== Existing Structure ===
* Every Assignment has a Node
* Every Assignment has many AssignmentTeam and MentoredTeam
* AssignmentTeam is inherited from Team
* MentoredTeam is inherited from AssignmentTeam
* Every MentoredTeam has many MentorMeeting
=== Proposed Structure Structure ===
* MentoredTeam to be delegated from AssignmentTeam instead of inheriting from it

== Implementation Plan ==
=== Modify newly created controller, model and view ===
==== mentor_meeting_controller.rb ====
* Edit function names to make them more descriptive
* Add more descriptive comments for the functions
==== mentor_meetings_helper.rb ====
* Move the "get_dates_for_team" function to the model
* Rename the function to make it more descriptive
==== _entry_assignments.html.erb ====
* Add more descriptive comments for the JavaScript functions
* Move the Ruby code from the template to a helper or the controller
==== mentored_team.rb --> mentored_team_decorator ====
* To reduce DRY violations, the mentored team class was changed to the mentored team decorator class.
*

=== Modify existing controller model and view ===
==== teams/_team.html.erb ====
* As the mentored team will now be delegated from the assignment team, we need to change the if condition on the top as we are changing MentoredTeam to be delegated from the AssignmentTeam
==== teams_controller.rb ====
* This file has to be modified to work with the delegated MentoredTeam
* These lines will not work as MentoredTeam will not be a model
[[File:Teams con1.png ‎| 600px]]
==== sign_up_sheet_controller.rb ====
* This controller has to be modified to automatically assign mentors or manually add mentors to the topics when they are created
* This will be followed by a change in schema
[[File:Signup con1.png | 600px]]
==== _topic.html.erb ====
* If we manually have to assign mentors to the topic, we have to include a input field to enter the mentor
[[File:Topic html.png | 600px]]
==== schema.rb ====
* As we are adding a new field to the table, we need to modify the schema
* We need to write 1 migration to add the field to the table to update the schema file
[[File:Schema E2403.png | 600px]]

=== Mailer Changes ===
====team.rb====
* The team model must be altered to use delegation for cases where a team would previously be a mentored team.
====add_member====
* The add member function must be altered such that the call to mail a user is better named, and that it calls directly to the mailer rather than the mailer helper.
[[File:add_member_email.png | 900px]]
====mailer_helper====
* The mailer_helper will be altered such that the send_team_confimration_to_user will be moved and renamed in the Mailer.rb class instead since using generic_message as such is leading to an unclear design.
[[File:team_confirm.png | 900px]]

====mailer.rb====
* A new function to specifically handle messaging users when added to teams will be built in the mailer, rather than just overusing the generic_message function.

== UI Changes ==
=== UI Changes before Phase 2 code changes ===
* The mentored assignment teams page has the modified UI from the Phase 1 as it is also a mentored assignment
* But the teams do not have a TA as the automated assignment of mentors has not been implemented.
[[File:UI1 E2403.png | 600px]]

=== UI Changes after Phase 2 code changes ===
The mentored assignment teams with topic now has the new UI and the automated mentor assignment
* The form to create a new topic has a new field to assign mentor to a topic
[[File:UI2 E2403.png | 600px]]
* The updated UI showing the topics with the mentors and teams that have chosen the topic
* The mentor is also displayed with the team
[[File:UI3 E2403.png | 600px]]
* The assignment teams page has the modified UI from the Phase 1 as the teams have a mentor
[[File:UI4 E2403.png | 600px]]

== Implementation ==
=== Mailer Changes ===
==== Decorator ====
* To remove DRY violations, we transformed the MentoredTeam class into the MentoredTeamDecoratorClass.
[[File:MentoredTeamClass.png | 600px]] ---> [[File:MentoredTeamDecorator.png | 600px]]
* In particular this required changing the MentoredTeam to have its own assignment team variable.
* The add_member function's DRY violations with the Team Class were able to be eliminated here, as now the Mentored Team Decorator calls to the assignment team's add member function on line 14, and then simply calls to assign the mentor on line 16.

==== MailerHelper to Mailer ====
* To increase understandability and consistency between classes, we removed the send_team_confirmation_mail function from the MailerHelper, and instead replaced its functionality with the team_addition_message function in the Mailer class. We found this to be the ideal location as the Mailer class houses many other specific message functions such as notify_grade_conflict_message, suggested_topic_approved_message and more.
[[File:team_confirm.png | 600px]] ---> [[File:Team_Addtion_Message.png | 600px]]

==== Team Add_Member ====
* The add_member function was altered in a couple of different ways. Firstly, we parameterized the partial_name in the call to the function that actually sends the mail, as in the original code we were violating the DRY principle by repeating the same MailerHelper call twice with very little change between them.
* Additionally we removed the type check for whether a user is a participant or not, as most users should be participants.
[[File:add_member_email.png | 600px]] ---> [[File:New_Add_Message.png | 600px]]

=== Automatic topic mentor assignment changes ===
==== Team creation using decorator ====
* As we have moved the mentored team from a subclass of assignment team to being a decorator, we have modified the team creation code to assign the right type of class to the team
* If the team is a mentored team, we use the MentoredTeamDecorator to create the object of the Assignment class
[[File:Team Creation.png | 600px]]

==== Team deletion ====
* We have added the functionality to delete the Mentor meetings when the team is deleted
* If the team is a mentored team, we will find all the instances of mentor meetings for the team and delete them
* We have also modified the function to work as a independent function that can be called from any where in the application by passing a parameter
* When the parameter is not passed, it is used as a controller function to handle calls to a specific route
[[File:Team Deletion.png | 600px]]

==== Adding a user to a team ====
* We have modified the function to add an user to the team
* The create function in TeamsUsersController is modified
[[File:Team User Creation.png | 600px]]

==== Adding a mentor to a topic - Form and table ====
* We have added a field in the topics form to add a mentor to the topic in _topic.html.erb
[[File:Topic Form.png | 600px]]
* The table displaying the topics is also modified to have a column for the mentors in _table_header.html.erb
[[File:Topic Header.png | 600px]]
* The topic row also displays the team members with the mentor included in it in the topics table in _table_line.html.erb 
[[File:Topic Row.png | 600px]]

==== Adding a mentor to a topic - Functions ====
* We have modified the function to setup a new topic to include the functionality to add mentor to the topic
* In case we try to add a mentor who is not in the assignment or course, we add the mentor to the assignment and course too
* In this way we handle cases of adding mentors outside the course into the topic
[[File:Add Topic Mentor.png | 600px]]
* We have created some helper functions to assist in adding the mentor to the assignment and course
[[File:Addition Helpers.png | 600px]]

== Implementation - To delete later ==
TODO:: 

== Files Modified/Added ==
* app/controllers/sign_up_sheet_controller.rb
* app/controllers/teams_controller.rb
* app/controllers/teams_users_controller.rb
* app/models/course.rb
* app/models/mentor_management.rb
* app/views/sign_up_sheet/_table_header.html.erb
* app/views/sign_up_sheet/_table_line.html.erb
* app/views/sign_up_sheet/_topic.html.erb
* app/views/teams/_team.html.erb
* app/views/tree_display/_page_footer_assignments.html.erb
* app/views/tree_display/_entry_assignments.html.erb
* app/models/mentored_team_decorator.rb
* app/models/team.rb
* app/views/mailer/team_addition_message.html.erb
* app/views/mailer/team_addition_message.text.erb
* app/helpers/mailer_helper.rb
* app/mailers/mailer.rb
* spec/models/team_spec.rb
* spec/models/mentor_management_spec.rb

== Test Plan ==
When the project was pulled from the main repository, there are not enough tests to cover the additional functionalities that we added. We are planning on using the test skeletons by Mustafa Olmez, as a reference to how and what kind of tests should be written. Test cases for mentor management were already written and we wrote new test cases for the new functionalities we added. Here are the four test case scenarios we covered and the actual ruby code for the Rspec tests

=== Automated Rspec Testing Scenarios===
1. Test scenario 1: Given an assignment_id, When there are multiple mentors with different team counts for the assignment, Then it should return the mentor with the lowest team count
it "returns the mentor with the lowest team count for the given assignment" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 2]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

2. Test scenario 2: Given an assignment_id, When there is only one mentor available for the assignment, Then it should return that mentor
it "should return that mentor if there's only one available" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 0]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

3. Test scenario 3: Given an assignment_id, When there are multiple mentors with the same lowest team count for the assignment, Then it should return the first mentor in the list
it "returns the first mentor in the list if there's a tie for lowest team count" do
# Arrange
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 1],])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

4. Test scenario 4: Given an assignment_id, When there are no mentors available for the assignment, Then it should return nil
it "returns nil" do
# Create a new assignment
a = FactoryBot.create(:assignment, id: 997, directory_path: 'OSS_project', auto_assign_mentor: true)
# Since there are no mentors associated with this assignment, should return nil
expect(MentorManagement.select_mentor(a.id)).to eq nil
end

== Mailer Tests ==
5. Test scenario 5: Given a mentor is being added to a team, then the mailer should be called to send the mentor-specific mail to the mentor
it 'sends mail to mentor if user is a mentor' do
allow(MentorManagement).to receive(:user_a_mentor?).with(user).and_return(true)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
allow(Mailer).to receive(:team_addition_message).and_return(double('Mail', deliver: true))
expect(Mailer).to receive(:team_addition_message).with(
to: user.email,
subject: '[Expertiza] Added to a Team',
body: {
user: user,
first_name: ApplicationHelper.get_user_first_name(user),
partial_name: 'mentor_added_to_team',
team: team.name.to_s,
assignment: ''
}
).and_return(double('Mail', deliver: true))
expect(team.add_member(user)).to be true
end

6. Test scenario 6: Given a normal user is being added to a team, then the mailer should be called to send the general user addition mail to the user
it 'sends mail to user if user is a user' do
allow(MentorManagement).to receive(:user_a_mentor?).with(user).and_return(true)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
allow(Mailer).to receive(:team_addition_message).and_return(double('Mail', deliver: true))
expect(Mailer).to receive(:team_addition_message).with(
to: user.email,
subject: '[Expertiza] Added to a Team',
body: {
user: user,
first_name: ApplicationHelper.get_user_first_name(user),
partial_name: 'user_added_to_team',
team: team.name.to_s,
assignment: ''
}
).and_return(double('Mail', deliver: true))
expect(team.add_member(user)).to be true
end

=== Manual UI Testing ===
Apart from the automated Rspec tests, we are providing manual testing cases that can be used to verify the functioning of the website.

Refer to the demo video on the bottom of the page to find help on testing these cases

==== Scenario 1 - Creating an mentored team ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Courses
# Assuming you have created a course and added participants to it, proceed to create a team
# Make sure "Auto assign mentors when team hits > 50% capacity?" option is checked
[[File:MT 1-1.png | 600px]]
* Create team for the assignment and you can see that the team with more than 50% capacity gets a mentor assigned automatically
[[File:MT 1-2.png | 600px]]

==== Scenario 2 - Adding, editing, deleting mentor meeting dates ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Assigments
# Assuming you have created a mentored assignment and added participants to it, proceed to the teams page
# Try entering dates into it teams row and the date should persist
# You can edit and delete the dates from the rows
# Team with less than 50% capacity will have the mentor meeting dates disabled
[[File:MT 2.png | 600px]]

==== Scenario 3 - Creating a team with topic ====
* Log into Expertiza using the test credential and navigate to the home page
* Go to Manage > Courses
* Assuming you have created a course and added participants to it, proceed to create a team
* Make sure "Has topics?" option is checked and a topic is created using the Topics tab
[[File:MT 3-1.png | 600px]]
* Create a new topic for the assignment and enter a mentor name to the topic
[[File:UI2 E2403.png | 600px]]
* When a student is added to the topic, the team of the student along with the mentor will be displayed in the topic row
[[File:UI3 E2403.png | 600px]]
* When navigating to the teams page of that assignment, you can see a mentor assigned automatically
[[File:UI4 E2403.png | 600px]]

==== Scenario 4 - Creating Team -> Recieve Emails ====
* Step 1 is to change the line

== Test Coverage ==
We used SimpleCov to generate a coverage report for the Rspec test cases implemeted for the model and controllers.
The test coverage indicated 1730 lines of code was covered through the testcases.

[[File:Testing E2403.png ‎| 600px]]

== Test Login Credentials ==
* UserId: instructor6
* Password: password

== Demo Video ==
TODO:: 
This is our [https://www.youtube.com/ demo video] which explain how to create courses, assignments, mentored teams and mentored teams with topics. This video also show how to run the tests of our code changes.

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2789

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T01:58:10Z

Slkwiatk: /* Mailer Tests */

== Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project. Instructors have the ability to add new projects, assignments, etc., as well as edit existing ones. Later on, they can view student submissions and grade them. Students can also use Expertiza to organize into teams to work on different projects and assignments and submit their work. They can also review other students' submissions.

== Introduction ==
This project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management/ E2304] for the implementation of the Mentor-meeting management in the Expertiza system for mentored teams. We are now required to add functionality to add mentors to the topics and then assign them to the teams when they pick up that topic.

== Problem Statement ==
The following tasks are required for the project:
#Enhancing Code Clarity: This involves renaming methods from Project 3 with ambiguous names, optimizing loops and adding comments for unclear lines of code
#Reimplement Mentored teams: Reimplement the Mentored team delegate to the Assignment team to reduce complexity and to follow best principles of Object Oriented Design
#Reimplement Sign Up Sheet or Topics: Reimplement the SignUpSheet controller to automatically add the mentor to when a topic is created and automatically assign the same mentor to a team when they choose the topic
#Writing tests for mentor meetings models: More tests have to be written for Mentor Meeting model
#Writing tests for the mentor meetings controller: More tests should be written for Mentor meeting controller
#Writing tests for the signup sheet controller: Additional tests should be written for signup sheet controller to test the new functionality

== Objectives ==
We have 3 main objectives for this project.
* Refactoring of the Mentor-meeting model and controller created for the Project 3
* Reimplementation of Mentored Teams model and controller for the Project 4
* Reimplementation of SignUp Sheet controller for the Project 4 to automatically assign mentors to the topics

== Design Goal ==
While fulfilling all the objectives, the following design rules have to be ensured:
* Validate proper functioning of all existing and anticipated methods, making any required enhancements or adjustments.
* Establish loose coupling and tight cohesion for the model and controller to enhance code organization and maintainability.
* Refactor redundant code in the previous implementation's controller and model methods using DRY principle, eliminating functionality duplication already present in the Expertiza system.
* Confirm the continued effectiveness of existing test cases following the aforementioned modifications and generate additional test cases as per the need.

== Class UML Diagram ==
[[File:OODD Proj4 E2403 - Entity Diagram 2.png ‎| 610px]]

== Classes and Relationships ==
=== Existing Structure ===
* Every Assignment has a Node
* Every Assignment has many AssignmentTeam and MentoredTeam
* AssignmentTeam is inherited from Team
* MentoredTeam is inherited from AssignmentTeam
* Every MentoredTeam has many MentorMeeting
=== Proposed Structure Structure ===
* MentoredTeam to be delegated from AssignmentTeam instead of inheriting from it

== Implementation Plan ==
=== Modify newly created controller, model and view ===
==== mentor_meeting_controller.rb ====
* Edit function names to make them more descriptive
* Add more descriptive comments for the functions
==== mentor_meetings_helper.rb ====
* Move the "get_dates_for_team" function to the model
* Rename the function to make it more descriptive
==== _entry_assignments.html.erb ====
* Add more descriptive comments for the JavaScript functions
* Move the Ruby code from the template to a helper or the controller
==== mentored_team.rb --> mentored_team_decorator ====
* To reduce DRY violations, the mentored team class was changed to the mentored team decorator class.
*

=== Modify existing controller model and view ===
==== teams/_team.html.erb ====
* As the mentored team will now be delegated from the assignment team, we need to change the if condition on the top as we are changing MentoredTeam to be delegated from the AssignmentTeam
==== teams_controller.rb ====
* This file has to be modified to work with the delegated MentoredTeam
* These lines will not work as MentoredTeam will not be a model
[[File:Teams con1.png ‎| 600px]]
==== sign_up_sheet_controller.rb ====
* This controller has to be modified to automatically assign mentors or manually add mentors to the topics when they are created
* This will be followed by a change in schema
[[File:Signup con1.png | 600px]]
==== _topic.html.erb ====
* If we manually have to assign mentors to the topic, we have to include a input field to enter the mentor
[[File:Topic html.png | 600px]]
==== schema.rb ====
* As we are adding a new field to the table, we need to modify the schema
* We need to write 1 migration to add the field to the table to update the schema file
[[File:Schema E2403.png | 600px]]

=== Mailer Changes ===
====team.rb====
* The team model must be altered to use delegation for cases where a team would previously be a mentored team.
====add_member====
* The add member function must be altered such that the call to mail a user is better named, and that it calls directly to the mailer rather than the mailer helper.
[[File:add_member_email.png | 900px]]
====mailer_helper====
* The mailer_helper will be altered such that the send_team_confimration_to_user will be moved and renamed in the Mailer.rb class instead since using generic_message as such is leading to an unclear design.
[[File:team_confirm.png | 900px]]

====mailer.rb====
* A new function to specifically handle messaging users when added to teams will be built in the mailer, rather than just overusing the generic_message function.

== UI Changes ==
=== UI Changes before Phase 2 code changes ===
* The mentored assignment teams page has the modified UI from the Phase 1 as it is also a mentored assignment
* But the teams do not have a TA as the automated assignment of mentors has not been implemented.
[[File:UI1 E2403.png | 600px]]

=== UI Changes after Phase 2 code changes ===
The mentored assignment teams with topic now has the new UI and the automated mentor assignment
* The form to create a new topic has a new field to assign mentor to a topic
[[File:UI2 E2403.png | 600px]]
* The updated UI showing the topics with the mentors and teams that have chosen the topic
* The mentor is also displayed with the team
[[File:UI3 E2403.png | 600px]]
* The assignment teams page has the modified UI from the Phase 1 as the teams have a mentor
[[File:UI4 E2403.png | 600px]]

== Implementation ==
=== Mailer Changes ===
==== Decorator ====
* To remove DRY violations, we transformed the MentoredTeam class into the MentoredTeamDecoratorClass.
[[File:MentoredTeamClass.png | 600px]] ---> [[File:MentoredTeamDecorator.png | 600px]]
* In particular this required changing the MentoredTeam to have its own assignment team variable.
* The add_member function's DRY violations with the Team Class were able to be eliminated here, as now the Mentored Team Decorator calls to the assignment team's add member function on line 14, and then simply calls to assign the mentor on line 16.
==== MailerHelper to Mailer ====
* To increase understandability and consistency between classes, we removed the send_team_confirmation_mail function from the MailerHelper, and instead replaced its functionality with the team_addition_message function in the Mailer class. We found this to be the ideal location as the Mailer class houses many other specific message functions such as notify_grade_conflict_message, suggested_topic_approved_message and more.
[[File:team_confirm.png | 600px]] ---> [[File:Team_Addtion_Message.png | 600px]]
==== Team Add_Member ====
* The add_member function was altered in a couple of different ways. Firstly, we parameterized the partial_name in the call to the function that actually sends the mail, as in the original code we were violating the DRY principle by repeating the same MailerHelper call twice with very little change between them.
* Additionally we removed the type check for whether a user is a participant or not, as most users should be participants.
[[File:add_member_email.png | 600px]] ---> [[File:New_Add_Message.png | 600px]]

== Implementation - To delete later ==
TODO:: 

== Files Modified/Added ==
* app/controllers/sign_up_sheet_controller.rb
* app/controllers/teams_controller.rb
* app/controllers/teams_users_controller.rb
* app/models/course.rb
* app/models/mentor_management.rb
* app/views/sign_up_sheet/_table_header.html.erb
* app/views/sign_up_sheet/_table_line.html.erb
* app/views/sign_up_sheet/_topic.html.erb
* app/views/teams/_team.html.erb
* app/views/tree_display/_page_footer_assignments.html.erb
* app/views/tree_display/_entry_assignments.html.erb
* app/models/mentored_team_decorator.rb
* app/models/team.rb
* app/views/mailer/team_addition_message.html.erb
* app/views/mailer/team_addition_message.text.erb
* app/helpers/mailer_helper.rb
* app/mailers/mailer.rb
* spec/models/team_spec.rb
* spec/models/mentor_management_spec.rb

== Test Plan ==
When the project was pulled from the main repository, there are not enough tests to cover the additional functionalities that we added. We are planning on using the test skeletons by Mustafa Olmez, as a reference to how and what kind of tests should be written. Test cases for mentor management were already written and we wrote new test cases for the new functionalities we added. Here are the four test case scenarios we covered and the actual ruby code for the Rspec tests

=== Automated Rspec Testing Scenarios===
1. Test scenario 1: Given an assignment_id, When there are multiple mentors with different team counts for the assignment, Then it should return the mentor with the lowest team count
it "returns the mentor with the lowest team count for the given assignment" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 2]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

2. Test scenario 2: Given an assignment_id, When there is only one mentor available for the assignment, Then it should return that mentor
it "should return that mentor if there's only one available" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 0]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

3. Test scenario 3: Given an assignment_id, When there are multiple mentors with the same lowest team count for the assignment, Then it should return the first mentor in the list
it "returns the first mentor in the list if there's a tie for lowest team count" do
# Arrange
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 1],])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

4. Test scenario 4: Given an assignment_id, When there are no mentors available for the assignment, Then it should return nil
it "returns nil" do
# Create a new assignment
a = FactoryBot.create(:assignment, id: 997, directory_path: 'OSS_project', auto_assign_mentor: true)
# Since there are no mentors associated with this assignment, should return nil
expect(MentorManagement.select_mentor(a.id)).to eq nil
end

== Mailer Tests ==
5. Test scenario 5: Given a mentor is being added to a team, then the mailer should be called to send the mentor-specific mail to the mentor
it 'sends mail to mentor if user is a mentor' do
allow(MentorManagement).to receive(:user_a_mentor?).with(user).and_return(true)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
allow(Mailer).to receive(:team_addition_message).and_return(double('Mail', deliver: true))
expect(Mailer).to receive(:team_addition_message).with(
to: user.email,
subject: '[Expertiza] Added to a Team',
body: {
user: user,
first_name: ApplicationHelper.get_user_first_name(user),
partial_name: 'mentor_added_to_team',
team: team.name.to_s,
assignment: ''
}
).and_return(double('Mail', deliver: true))
expect(team.add_member(user)).to be true
end

6. Test scenario 6: Given a normal user is being added to a team, then the mailer should be called to send the general user addition mail to the user
it 'sends mail to user if user is a user' do
allow(MentorManagement).to receive(:user_a_mentor?).with(user).and_return(true)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
allow(Mailer).to receive(:team_addition_message).and_return(double('Mail', deliver: true))
expect(Mailer).to receive(:team_addition_message).with(
to: user.email,
subject: '[Expertiza] Added to a Team',
body: {
user: user,
first_name: ApplicationHelper.get_user_first_name(user),
partial_name: 'user_added_to_team',
team: team.name.to_s,
assignment: ''
}
).and_return(double('Mail', deliver: true))
expect(team.add_member(user)).to be true
end

=== Manual UI Testing ===
Apart from the automated Rspec tests, we are providing manual testing cases that can be used to verify the functioning of the website.

Refer to the demo video on the bottom of the page to find help on testing these cases

==== Scenario 1 - Creating an mentored team ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Courses
# Assuming you have created a course and added participants to it, proceed to create a team
# Make sure "Auto assign mentors when team hits > 50% capacity?" option is checked
[[File:MT 1-1.png | 600px]]
* Create team for the assignment and you can see that the team with more than 50% capacity gets a mentor assigned automatically
[[File:MT 1-2.png | 600px]]

==== Scenario 2 - Adding, editing, deleting mentor meeting dates ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Assigments
# Assuming you have created a mentored assignment and added participants to it, proceed to the teams page
# Try entering dates into it teams row and the date should persist
# You can edit and delete the dates from the rows
# Team with less than 50% capacity will have the mentor meeting dates disabled
[[File:MT 2.png | 600px]]

==== Scenario 3 - Creating a team with topic ====
* Log into Expertiza using the test credential and navigate to the home page
* Go to Manage > Courses
* Assuming you have created a course and added participants to it, proceed to create a team
* Make sure "Has topics?" option is checked and a topic is created using the Topics tab
[[File:MT 3-1.png | 600px]]
* Create a new topic for the assignment and enter a mentor name to the topic
[[File:UI2 E2403.png | 600px]]
* When a student is added to the topic, the team of the student along with the mentor will be displayed in the topic row
[[File:UI3 E2403.png | 600px]]
* When navigating to the teams page of that assignment, you can see a mentor assigned automatically
[[File:UI4 E2403.png | 600px]]

== Test Coverage ==
We used SimpleCov to generate a coverage report for the Rspec test cases implemeted for the model and controllers.
The test coverage indicated 1730 lines of code was covered through the testcases.

[[File:Testing E2403.png ‎| 600px]]

== Test Login Credentials ==
* UserId: instructor6
* Password: password

== Demo Video ==
TODO:: 
This is our [https://www.youtube.com/ demo video] which explain how to create courses, assignments, mentored teams and mentored teams with topics. This video also show how to run the tests of our code changes.

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2789

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T01:57:49Z

Slkwiatk: /* Mailer Tests */

== Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project. Instructors have the ability to add new projects, assignments, etc., as well as edit existing ones. Later on, they can view student submissions and grade them. Students can also use Expertiza to organize into teams to work on different projects and assignments and submit their work. They can also review other students' submissions.

== Introduction ==
This project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management/ E2304] for the implementation of the Mentor-meeting management in the Expertiza system for mentored teams. We are now required to add functionality to add mentors to the topics and then assign them to the teams when they pick up that topic.

== Problem Statement ==
The following tasks are required for the project:
#Enhancing Code Clarity: This involves renaming methods from Project 3 with ambiguous names, optimizing loops and adding comments for unclear lines of code
#Reimplement Mentored teams: Reimplement the Mentored team delegate to the Assignment team to reduce complexity and to follow best principles of Object Oriented Design
#Reimplement Sign Up Sheet or Topics: Reimplement the SignUpSheet controller to automatically add the mentor to when a topic is created and automatically assign the same mentor to a team when they choose the topic
#Writing tests for mentor meetings models: More tests have to be written for Mentor Meeting model
#Writing tests for the mentor meetings controller: More tests should be written for Mentor meeting controller
#Writing tests for the signup sheet controller: Additional tests should be written for signup sheet controller to test the new functionality

== Objectives ==
We have 3 main objectives for this project.
* Refactoring of the Mentor-meeting model and controller created for the Project 3
* Reimplementation of Mentored Teams model and controller for the Project 4
* Reimplementation of SignUp Sheet controller for the Project 4 to automatically assign mentors to the topics

== Design Goal ==
While fulfilling all the objectives, the following design rules have to be ensured:
* Validate proper functioning of all existing and anticipated methods, making any required enhancements or adjustments.
* Establish loose coupling and tight cohesion for the model and controller to enhance code organization and maintainability.
* Refactor redundant code in the previous implementation's controller and model methods using DRY principle, eliminating functionality duplication already present in the Expertiza system.
* Confirm the continued effectiveness of existing test cases following the aforementioned modifications and generate additional test cases as per the need.

== Class UML Diagram ==
[[File:OODD Proj4 E2403 - Entity Diagram 2.png ‎| 610px]]

== Classes and Relationships ==
=== Existing Structure ===
* Every Assignment has a Node
* Every Assignment has many AssignmentTeam and MentoredTeam
* AssignmentTeam is inherited from Team
* MentoredTeam is inherited from AssignmentTeam
* Every MentoredTeam has many MentorMeeting
=== Proposed Structure Structure ===
* MentoredTeam to be delegated from AssignmentTeam instead of inheriting from it

== Implementation Plan ==
=== Modify newly created controller, model and view ===
==== mentor_meeting_controller.rb ====
* Edit function names to make them more descriptive
* Add more descriptive comments for the functions
==== mentor_meetings_helper.rb ====
* Move the "get_dates_for_team" function to the model
* Rename the function to make it more descriptive
==== _entry_assignments.html.erb ====
* Add more descriptive comments for the JavaScript functions
* Move the Ruby code from the template to a helper or the controller
==== mentored_team.rb --> mentored_team_decorator ====
* To reduce DRY violations, the mentored team class was changed to the mentored team decorator class.
*

=== Modify existing controller model and view ===
==== teams/_team.html.erb ====
* As the mentored team will now be delegated from the assignment team, we need to change the if condition on the top as we are changing MentoredTeam to be delegated from the AssignmentTeam
==== teams_controller.rb ====
* This file has to be modified to work with the delegated MentoredTeam
* These lines will not work as MentoredTeam will not be a model
[[File:Teams con1.png ‎| 600px]]
==== sign_up_sheet_controller.rb ====
* This controller has to be modified to automatically assign mentors or manually add mentors to the topics when they are created
* This will be followed by a change in schema
[[File:Signup con1.png | 600px]]
==== _topic.html.erb ====
* If we manually have to assign mentors to the topic, we have to include a input field to enter the mentor
[[File:Topic html.png | 600px]]
==== schema.rb ====
* As we are adding a new field to the table, we need to modify the schema
* We need to write 1 migration to add the field to the table to update the schema file
[[File:Schema E2403.png | 600px]]

=== Mailer Changes ===
====team.rb====
* The team model must be altered to use delegation for cases where a team would previously be a mentored team.
====add_member====
* The add member function must be altered such that the call to mail a user is better named, and that it calls directly to the mailer rather than the mailer helper.
[[File:add_member_email.png | 900px]]
====mailer_helper====
* The mailer_helper will be altered such that the send_team_confimration_to_user will be moved and renamed in the Mailer.rb class instead since using generic_message as such is leading to an unclear design.
[[File:team_confirm.png | 900px]]

====mailer.rb====
* A new function to specifically handle messaging users when added to teams will be built in the mailer, rather than just overusing the generic_message function.

== UI Changes ==
=== UI Changes before Phase 2 code changes ===
* The mentored assignment teams page has the modified UI from the Phase 1 as it is also a mentored assignment
* But the teams do not have a TA as the automated assignment of mentors has not been implemented.
[[File:UI1 E2403.png | 600px]]

=== UI Changes after Phase 2 code changes ===
The mentored assignment teams with topic now has the new UI and the automated mentor assignment
* The form to create a new topic has a new field to assign mentor to a topic
[[File:UI2 E2403.png | 600px]]
* The updated UI showing the topics with the mentors and teams that have chosen the topic
* The mentor is also displayed with the team
[[File:UI3 E2403.png | 600px]]
* The assignment teams page has the modified UI from the Phase 1 as the teams have a mentor
[[File:UI4 E2403.png | 600px]]

== Implementation ==
=== Mailer Changes ===
==== Decorator ====
* To remove DRY violations, we transformed the MentoredTeam class into the MentoredTeamDecoratorClass.
[[File:MentoredTeamClass.png | 600px]] ---> [[File:MentoredTeamDecorator.png | 600px]]
* In particular this required changing the MentoredTeam to have its own assignment team variable.
* The add_member function's DRY violations with the Team Class were able to be eliminated here, as now the Mentored Team Decorator calls to the assignment team's add member function on line 14, and then simply calls to assign the mentor on line 16.
==== MailerHelper to Mailer ====
* To increase understandability and consistency between classes, we removed the send_team_confirmation_mail function from the MailerHelper, and instead replaced its functionality with the team_addition_message function in the Mailer class. We found this to be the ideal location as the Mailer class houses many other specific message functions such as notify_grade_conflict_message, suggested_topic_approved_message and more.
[[File:team_confirm.png | 600px]] ---> [[File:Team_Addtion_Message.png | 600px]]
==== Team Add_Member ====
* The add_member function was altered in a couple of different ways. Firstly, we parameterized the partial_name in the call to the function that actually sends the mail, as in the original code we were violating the DRY principle by repeating the same MailerHelper call twice with very little change between them.
* Additionally we removed the type check for whether a user is a participant or not, as most users should be participants.
[[File:add_member_email.png | 600px]] ---> [[File:New_Add_Message.png | 600px]]

== Implementation - To delete later ==
TODO:: 

== Files Modified/Added ==
* app/controllers/sign_up_sheet_controller.rb
* app/controllers/teams_controller.rb
* app/controllers/teams_users_controller.rb
* app/models/course.rb
* app/models/mentor_management.rb
* app/views/sign_up_sheet/_table_header.html.erb
* app/views/sign_up_sheet/_table_line.html.erb
* app/views/sign_up_sheet/_topic.html.erb
* app/views/teams/_team.html.erb
* app/views/tree_display/_page_footer_assignments.html.erb
* app/views/tree_display/_entry_assignments.html.erb
* app/models/mentored_team_decorator.rb
* app/models/team.rb
* app/views/mailer/team_addition_message.html.erb
* app/views/mailer/team_addition_message.text.erb
* app/helpers/mailer_helper.rb
* app/mailers/mailer.rb
* spec/models/team_spec.rb
* spec/models/mentor_management_spec.rb

== Test Plan ==
When the project was pulled from the main repository, there are not enough tests to cover the additional functionalities that we added. We are planning on using the test skeletons by Mustafa Olmez, as a reference to how and what kind of tests should be written. Test cases for mentor management were already written and we wrote new test cases for the new functionalities we added. Here are the four test case scenarios we covered and the actual ruby code for the Rspec tests

=== Automated Rspec Testing Scenarios===
1. Test scenario 1: Given an assignment_id, When there are multiple mentors with different team counts for the assignment, Then it should return the mentor with the lowest team count
it "returns the mentor with the lowest team count for the given assignment" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 2]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

2. Test scenario 2: Given an assignment_id, When there is only one mentor available for the assignment, Then it should return that mentor
it "should return that mentor if there's only one available" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 0]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

3. Test scenario 3: Given an assignment_id, When there are multiple mentors with the same lowest team count for the assignment, Then it should return the first mentor in the list
it "returns the first mentor in the list if there's a tie for lowest team count" do
# Arrange
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 1],])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

4. Test scenario 4: Given an assignment_id, When there are no mentors available for the assignment, Then it should return nil
it "returns nil" do
# Create a new assignment
a = FactoryBot.create(:assignment, id: 997, directory_path: 'OSS_project', auto_assign_mentor: true)
# Since there are no mentors associated with this assignment, should return nil
expect(MentorManagement.select_mentor(a.id)).to eq nil
end

== Mailer Tests ==
5. Test scenario 5: Given a mentor is being added to a team, then the mailer should be called to send the mentor-specific mail to the mentor
it 'sends mail to mentor if user is a mentor' do
allow(MentorManagement).to receive(:user_a_mentor?).with(user).and_return(true)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
allow(Mailer).to receive(:team_addition_message).and_return(double('Mail', deliver: true))

expect(Mailer).to receive(:team_addition_message).with(
to: user.email,
subject: '[Expertiza] Added to a Team',
body: {
user: user,
first_name: ApplicationHelper.get_user_first_name(user),
partial_name: 'mentor_added_to_team',
team: team.name.to_s,
assignment: ''
}
).and_return(double('Mail', deliver: true))
expect(team.add_member(user)).to be true
end

6. Test scenario 6: Given a normal user is being added to a team, then the mailer should be called to send the general user addition mail to the user
it 'sends mail to user if user is a user' do
allow(MentorManagement).to receive(:user_a_mentor?).with(user).and_return(true)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
allow(Mailer).to receive(:team_addition_message).and_return(double('Mail', deliver: true))

expect(Mailer).to receive(:team_addition_message).with(
to: user.email,
subject: '[Expertiza] Added to a Team',
body: {
user: user,
first_name: ApplicationHelper.get_user_first_name(user),
partial_name: 'user_added_to_team',
team: team.name.to_s,
assignment: ''
}
).and_return(double('Mail', deliver: true))
expect(team.add_member(user)).to be true
end

=== Manual UI Testing ===
Apart from the automated Rspec tests, we are providing manual testing cases that can be used to verify the functioning of the website.

Refer to the demo video on the bottom of the page to find help on testing these cases

==== Scenario 1 - Creating an mentored team ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Courses
# Assuming you have created a course and added participants to it, proceed to create a team
# Make sure "Auto assign mentors when team hits > 50% capacity?" option is checked
[[File:MT 1-1.png | 600px]]
* Create team for the assignment and you can see that the team with more than 50% capacity gets a mentor assigned automatically
[[File:MT 1-2.png | 600px]]

==== Scenario 2 - Adding, editing, deleting mentor meeting dates ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Assigments
# Assuming you have created a mentored assignment and added participants to it, proceed to the teams page
# Try entering dates into it teams row and the date should persist
# You can edit and delete the dates from the rows
# Team with less than 50% capacity will have the mentor meeting dates disabled
[[File:MT 2.png | 600px]]

==== Scenario 3 - Creating a team with topic ====
* Log into Expertiza using the test credential and navigate to the home page
* Go to Manage > Courses
* Assuming you have created a course and added participants to it, proceed to create a team
* Make sure "Has topics?" option is checked and a topic is created using the Topics tab
[[File:MT 3-1.png | 600px]]
* Create a new topic for the assignment and enter a mentor name to the topic
[[File:UI2 E2403.png | 600px]]
* When a student is added to the topic, the team of the student along with the mentor will be displayed in the topic row
[[File:UI3 E2403.png | 600px]]
* When navigating to the teams page of that assignment, you can see a mentor assigned automatically
[[File:UI4 E2403.png | 600px]]

== Test Coverage ==
We used SimpleCov to generate a coverage report for the Rspec test cases implemeted for the model and controllers.
The test coverage indicated 1730 lines of code was covered through the testcases.

[[File:Testing E2403.png ‎| 600px]]

== Test Login Credentials ==
* UserId: instructor6
* Password: password

== Demo Video ==
TODO:: 
This is our [https://www.youtube.com/ demo video] which explain how to create courses, assignments, mentored teams and mentored teams with topics. This video also show how to run the tests of our code changes.

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2789

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T01:57:33Z

Slkwiatk: /* Automated Rspec Testing Scenarios */

== Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project. Instructors have the ability to add new projects, assignments, etc., as well as edit existing ones. Later on, they can view student submissions and grade them. Students can also use Expertiza to organize into teams to work on different projects and assignments and submit their work. They can also review other students' submissions.

== Introduction ==
This project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management/ E2304] for the implementation of the Mentor-meeting management in the Expertiza system for mentored teams. We are now required to add functionality to add mentors to the topics and then assign them to the teams when they pick up that topic.

== Problem Statement ==
The following tasks are required for the project:
#Enhancing Code Clarity: This involves renaming methods from Project 3 with ambiguous names, optimizing loops and adding comments for unclear lines of code
#Reimplement Mentored teams: Reimplement the Mentored team delegate to the Assignment team to reduce complexity and to follow best principles of Object Oriented Design
#Reimplement Sign Up Sheet or Topics: Reimplement the SignUpSheet controller to automatically add the mentor to when a topic is created and automatically assign the same mentor to a team when they choose the topic
#Writing tests for mentor meetings models: More tests have to be written for Mentor Meeting model
#Writing tests for the mentor meetings controller: More tests should be written for Mentor meeting controller
#Writing tests for the signup sheet controller: Additional tests should be written for signup sheet controller to test the new functionality

== Objectives ==
We have 3 main objectives for this project.
* Refactoring of the Mentor-meeting model and controller created for the Project 3
* Reimplementation of Mentored Teams model and controller for the Project 4
* Reimplementation of SignUp Sheet controller for the Project 4 to automatically assign mentors to the topics

== Design Goal ==
While fulfilling all the objectives, the following design rules have to be ensured:
* Validate proper functioning of all existing and anticipated methods, making any required enhancements or adjustments.
* Establish loose coupling and tight cohesion for the model and controller to enhance code organization and maintainability.
* Refactor redundant code in the previous implementation's controller and model methods using DRY principle, eliminating functionality duplication already present in the Expertiza system.
* Confirm the continued effectiveness of existing test cases following the aforementioned modifications and generate additional test cases as per the need.

== Class UML Diagram ==
[[File:OODD Proj4 E2403 - Entity Diagram 2.png ‎| 610px]]

== Classes and Relationships ==
=== Existing Structure ===
* Every Assignment has a Node
* Every Assignment has many AssignmentTeam and MentoredTeam
* AssignmentTeam is inherited from Team
* MentoredTeam is inherited from AssignmentTeam
* Every MentoredTeam has many MentorMeeting
=== Proposed Structure Structure ===
* MentoredTeam to be delegated from AssignmentTeam instead of inheriting from it

== Implementation Plan ==
=== Modify newly created controller, model and view ===
==== mentor_meeting_controller.rb ====
* Edit function names to make them more descriptive
* Add more descriptive comments for the functions
==== mentor_meetings_helper.rb ====
* Move the "get_dates_for_team" function to the model
* Rename the function to make it more descriptive
==== _entry_assignments.html.erb ====
* Add more descriptive comments for the JavaScript functions
* Move the Ruby code from the template to a helper or the controller
==== mentored_team.rb --> mentored_team_decorator ====
* To reduce DRY violations, the mentored team class was changed to the mentored team decorator class.
*

=== Modify existing controller model and view ===
==== teams/_team.html.erb ====
* As the mentored team will now be delegated from the assignment team, we need to change the if condition on the top as we are changing MentoredTeam to be delegated from the AssignmentTeam
==== teams_controller.rb ====
* This file has to be modified to work with the delegated MentoredTeam
* These lines will not work as MentoredTeam will not be a model
[[File:Teams con1.png ‎| 600px]]
==== sign_up_sheet_controller.rb ====
* This controller has to be modified to automatically assign mentors or manually add mentors to the topics when they are created
* This will be followed by a change in schema
[[File:Signup con1.png | 600px]]
==== _topic.html.erb ====
* If we manually have to assign mentors to the topic, we have to include a input field to enter the mentor
[[File:Topic html.png | 600px]]
==== schema.rb ====
* As we are adding a new field to the table, we need to modify the schema
* We need to write 1 migration to add the field to the table to update the schema file
[[File:Schema E2403.png | 600px]]

=== Mailer Changes ===
====team.rb====
* The team model must be altered to use delegation for cases where a team would previously be a mentored team.
====add_member====
* The add member function must be altered such that the call to mail a user is better named, and that it calls directly to the mailer rather than the mailer helper.
[[File:add_member_email.png | 900px]]
====mailer_helper====
* The mailer_helper will be altered such that the send_team_confimration_to_user will be moved and renamed in the Mailer.rb class instead since using generic_message as such is leading to an unclear design.
[[File:team_confirm.png | 900px]]

====mailer.rb====
* A new function to specifically handle messaging users when added to teams will be built in the mailer, rather than just overusing the generic_message function.

== UI Changes ==
=== UI Changes before Phase 2 code changes ===
* The mentored assignment teams page has the modified UI from the Phase 1 as it is also a mentored assignment
* But the teams do not have a TA as the automated assignment of mentors has not been implemented.
[[File:UI1 E2403.png | 600px]]

=== UI Changes after Phase 2 code changes ===
The mentored assignment teams with topic now has the new UI and the automated mentor assignment
* The form to create a new topic has a new field to assign mentor to a topic
[[File:UI2 E2403.png | 600px]]
* The updated UI showing the topics with the mentors and teams that have chosen the topic
* The mentor is also displayed with the team
[[File:UI3 E2403.png | 600px]]
* The assignment teams page has the modified UI from the Phase 1 as the teams have a mentor
[[File:UI4 E2403.png | 600px]]

== Implementation ==
=== Mailer Changes ===
==== Decorator ====
* To remove DRY violations, we transformed the MentoredTeam class into the MentoredTeamDecoratorClass.
[[File:MentoredTeamClass.png | 600px]] ---> [[File:MentoredTeamDecorator.png | 600px]]
* In particular this required changing the MentoredTeam to have its own assignment team variable.
* The add_member function's DRY violations with the Team Class were able to be eliminated here, as now the Mentored Team Decorator calls to the assignment team's add member function on line 14, and then simply calls to assign the mentor on line 16.
==== MailerHelper to Mailer ====
* To increase understandability and consistency between classes, we removed the send_team_confirmation_mail function from the MailerHelper, and instead replaced its functionality with the team_addition_message function in the Mailer class. We found this to be the ideal location as the Mailer class houses many other specific message functions such as notify_grade_conflict_message, suggested_topic_approved_message and more.
[[File:team_confirm.png | 600px]] ---> [[File:Team_Addtion_Message.png | 600px]]
==== Team Add_Member ====
* The add_member function was altered in a couple of different ways. Firstly, we parameterized the partial_name in the call to the function that actually sends the mail, as in the original code we were violating the DRY principle by repeating the same MailerHelper call twice with very little change between them.
* Additionally we removed the type check for whether a user is a participant or not, as most users should be participants.
[[File:add_member_email.png | 600px]] ---> [[File:New_Add_Message.png | 600px]]

== Implementation - To delete later ==
TODO:: 

== Files Modified/Added ==
* app/controllers/sign_up_sheet_controller.rb
* app/controllers/teams_controller.rb
* app/controllers/teams_users_controller.rb
* app/models/course.rb
* app/models/mentor_management.rb
* app/views/sign_up_sheet/_table_header.html.erb
* app/views/sign_up_sheet/_table_line.html.erb
* app/views/sign_up_sheet/_topic.html.erb
* app/views/teams/_team.html.erb
* app/views/tree_display/_page_footer_assignments.html.erb
* app/views/tree_display/_entry_assignments.html.erb
* app/models/mentored_team_decorator.rb
* app/models/team.rb
* app/views/mailer/team_addition_message.html.erb
* app/views/mailer/team_addition_message.text.erb
* app/helpers/mailer_helper.rb
* app/mailers/mailer.rb
* spec/models/team_spec.rb
* spec/models/mentor_management_spec.rb

== Test Plan ==
When the project was pulled from the main repository, there are not enough tests to cover the additional functionalities that we added. We are planning on using the test skeletons by Mustafa Olmez, as a reference to how and what kind of tests should be written. Test cases for mentor management were already written and we wrote new test cases for the new functionalities we added. Here are the four test case scenarios we covered and the actual ruby code for the Rspec tests

=== Automated Rspec Testing Scenarios===
1. Test scenario 1: Given an assignment_id, When there are multiple mentors with different team counts for the assignment, Then it should return the mentor with the lowest team count
it "returns the mentor with the lowest team count for the given assignment" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 2]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

2. Test scenario 2: Given an assignment_id, When there is only one mentor available for the assignment, Then it should return that mentor
it "should return that mentor if there's only one available" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 0]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

3. Test scenario 3: Given an assignment_id, When there are multiple mentors with the same lowest team count for the assignment, Then it should return the first mentor in the list
it "returns the first mentor in the list if there's a tie for lowest team count" do
# Arrange
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 1],])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

4. Test scenario 4: Given an assignment_id, When there are no mentors available for the assignment, Then it should return nil
it "returns nil" do
# Create a new assignment
a = FactoryBot.create(:assignment, id: 997, directory_path: 'OSS_project', auto_assign_mentor: true)
# Since there are no mentors associated with this assignment, should return nil
expect(MentorManagement.select_mentor(a.id)).to eq nil
end

== Mailer Tests ==
5. Test scenario 4: Given a mentor is being added to a team, then the mailer should be called to send the mentor-specific mail to the mentor
it 'sends mail to mentor if user is a mentor' do
allow(MentorManagement).to receive(:user_a_mentor?).with(user).and_return(true)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
allow(Mailer).to receive(:team_addition_message).and_return(double('Mail', deliver: true))

expect(Mailer).to receive(:team_addition_message).with(
to: user.email,
subject: '[Expertiza] Added to a Team',
body: {
user: user,
first_name: ApplicationHelper.get_user_first_name(user),
partial_name: 'mentor_added_to_team',
team: team.name.to_s,
assignment: ''
}
).and_return(double('Mail', deliver: true))
expect(team.add_member(user)).to be true
end

6. Test scenario 4: Given a normal user is being added to a team, then the mailer should be called to send the general user addition mail to the user
it 'sends mail to user if user is a user' do
allow(MentorManagement).to receive(:user_a_mentor?).with(user).and_return(true)
allow(Assignment).to receive(:find).with(1).and_return(assignment)
allow(Mailer).to receive(:team_addition_message).and_return(double('Mail', deliver: true))

expect(Mailer).to receive(:team_addition_message).with(
to: user.email,
subject: '[Expertiza] Added to a Team',
body: {
user: user,
first_name: ApplicationHelper.get_user_first_name(user),
partial_name: 'user_added_to_team',
team: team.name.to_s,
assignment: ''
}
).and_return(double('Mail', deliver: true))
expect(team.add_member(user)).to be true
end

=== Manual UI Testing ===
Apart from the automated Rspec tests, we are providing manual testing cases that can be used to verify the functioning of the website.

Refer to the demo video on the bottom of the page to find help on testing these cases

==== Scenario 1 - Creating an mentored team ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Courses
# Assuming you have created a course and added participants to it, proceed to create a team
# Make sure "Auto assign mentors when team hits > 50% capacity?" option is checked
[[File:MT 1-1.png | 600px]]
* Create team for the assignment and you can see that the team with more than 50% capacity gets a mentor assigned automatically
[[File:MT 1-2.png | 600px]]

==== Scenario 2 - Adding, editing, deleting mentor meeting dates ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Assigments
# Assuming you have created a mentored assignment and added participants to it, proceed to the teams page
# Try entering dates into it teams row and the date should persist
# You can edit and delete the dates from the rows
# Team with less than 50% capacity will have the mentor meeting dates disabled
[[File:MT 2.png | 600px]]

==== Scenario 3 - Creating a team with topic ====
* Log into Expertiza using the test credential and navigate to the home page
* Go to Manage > Courses
* Assuming you have created a course and added participants to it, proceed to create a team
* Make sure "Has topics?" option is checked and a topic is created using the Topics tab
[[File:MT 3-1.png | 600px]]
* Create a new topic for the assignment and enter a mentor name to the topic
[[File:UI2 E2403.png | 600px]]
* When a student is added to the topic, the team of the student along with the mentor will be displayed in the topic row
[[File:UI3 E2403.png | 600px]]
* When navigating to the teams page of that assignment, you can see a mentor assigned automatically
[[File:UI4 E2403.png | 600px]]

== Test Coverage ==
We used SimpleCov to generate a coverage report for the Rspec test cases implemeted for the model and controllers.
The test coverage indicated 1730 lines of code was covered through the testcases.

[[File:Testing E2403.png ‎| 600px]]

== Test Login Credentials ==
* UserId: instructor6
* Password: password

== Demo Video ==
TODO:: 
This is our [https://www.youtube.com/ demo video] which explain how to create courses, assignments, mentored teams and mentored teams with topics. This video also show how to run the tests of our code changes.

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2789

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T01:45:49Z

Slkwiatk: /* Team Add_Member */

== Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project. Instructors have the ability to add new projects, assignments, etc., as well as edit existing ones. Later on, they can view student submissions and grade them. Students can also use Expertiza to organize into teams to work on different projects and assignments and submit their work. They can also review other students' submissions.

== Introduction ==
This project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management/ E2304] for the implementation of the Mentor-meeting management in the Expertiza system for mentored teams. We are now required to add functionality to add mentors to the topics and then assign them to the teams when they pick up that topic.

== Problem Statement ==
The following tasks are required for the project:
#Enhancing Code Clarity: This involves renaming methods from Project 3 with ambiguous names, optimizing loops and adding comments for unclear lines of code
#Reimplement Mentored teams: Reimplement the Mentored team delegate to the Assignment team to reduce complexity and to follow best principles of Object Oriented Design
#Reimplement Sign Up Sheet or Topics: Reimplement the SignUpSheet controller to automatically add the mentor to when a topic is created and automatically assign the same mentor to a team when they choose the topic
#Writing tests for mentor meetings models: More tests have to be written for Mentor Meeting model
#Writing tests for the mentor meetings controller: More tests should be written for Mentor meeting controller
#Writing tests for the signup sheet controller: Additional tests should be written for signup sheet controller to test the new functionality

== Objectives ==
We have 3 main objectives for this project.
* Refactoring of the Mentor-meeting model and controller created for the Project 3
* Reimplementation of Mentored Teams model and controller for the Project 4
* Reimplementation of SignUp Sheet controller for the Project 4 to automatically assign mentors to the topics

== Design Goal ==
While fulfilling all the objectives, the following design rules have to be ensured:
* Validate proper functioning of all existing and anticipated methods, making any required enhancements or adjustments.
* Establish loose coupling and tight cohesion for the model and controller to enhance code organization and maintainability.
* Refactor redundant code in the previous implementation's controller and model methods using DRY principle, eliminating functionality duplication already present in the Expertiza system.
* Confirm the continued effectiveness of existing test cases following the aforementioned modifications and generate additional test cases as per the need.

== Class UML Diagram ==
[[File:OODD Proj4 E2403 - Entity Diagram 2.png ‎| 610px]]

== Classes and Relationships ==
=== Existing Structure ===
* Every Assignment has a Node
* Every Assignment has many AssignmentTeam and MentoredTeam
* AssignmentTeam is inherited from Team
* MentoredTeam is inherited from AssignmentTeam
* Every MentoredTeam has many MentorMeeting
=== Proposed Structure Structure ===
* MentoredTeam to be delegated from AssignmentTeam instead of inheriting from it

== Implementation Plan ==
=== Modify newly created controller, model and view ===
==== mentor_meeting_controller.rb ====
* Edit function names to make them more descriptive
* Add more descriptive comments for the functions
==== mentor_meetings_helper.rb ====
* Move the "get_dates_for_team" function to the model
* Rename the function to make it more descriptive
==== _entry_assignments.html.erb ====
* Add more descriptive comments for the JavaScript functions
* Move the Ruby code from the template to a helper or the controller
==== mentored_team.rb --> mentored_team_decorator ====
* To reduce DRY violations, the mentored team class was changed to the mentored team decorator class.
*

=== Modify existing controller model and view ===
==== teams/_team.html.erb ====
* As the mentored team will now be delegated from the assignment team, we need to change the if condition on the top as we are changing MentoredTeam to be delegated from the AssignmentTeam
==== teams_controller.rb ====
* This file has to be modified to work with the delegated MentoredTeam
* These lines will not work as MentoredTeam will not be a model
[[File:Teams con1.png ‎| 600px]]
==== sign_up_sheet_controller.rb ====
* This controller has to be modified to automatically assign mentors or manually add mentors to the topics when they are created
* This will be followed by a change in schema
[[File:Signup con1.png | 600px]]
==== _topic.html.erb ====
* If we manually have to assign mentors to the topic, we have to include a input field to enter the mentor
[[File:Topic html.png | 600px]]
==== schema.rb ====
* As we are adding a new field to the table, we need to modify the schema
* We need to write 1 migration to add the field to the table to update the schema file
[[File:Schema E2403.png | 600px]]

=== Mailer Changes ===
====team.rb====
* The team model must be altered to use delegation for cases where a team would previously be a mentored team.
====add_member====
* The add member function must be altered such that the call to mail a user is better named, and that it calls directly to the mailer rather than the mailer helper.
[[File:add_member_email.png | 900px]]
====mailer_helper====
* The mailer_helper will be altered such that the send_team_confimration_to_user will be moved and renamed in the Mailer.rb class instead since using generic_message as such is leading to an unclear design.
[[File:team_confirm.png | 900px]]

====mailer.rb====
* A new function to specifically handle messaging users when added to teams will be built in the mailer, rather than just overusing the generic_message function.

== UI Changes ==
=== UI Changes before Phase 2 code changes ===
* The mentored assignment teams page has the modified UI from the Phase 1 as it is also a mentored assignment
* But the teams do not have a TA as the automated assignment of mentors has not been implemented.
[[File:UI1 E2403.png | 600px]]

=== UI Changes after Phase 2 code changes ===
The mentored assignment teams with topic now has the new UI and the automated mentor assignment
* The form to create a new topic has a new field to assign mentor to a topic
[[File:UI2 E2403.png | 600px]]
* The updated UI showing the topics with the mentors and teams that have chosen the topic
* The mentor is also displayed with the team
[[File:UI3 E2403.png | 600px]]
* The assignment teams page has the modified UI from the Phase 1 as the teams have a mentor
[[File:UI4 E2403.png | 600px]]

== Implementation ==
=== Mailer Changes ===
==== Decorator ====
* To remove DRY violations, we transformed the MentoredTeam class into the MentoredTeamDecoratorClass.
[[File:MentoredTeamClass.png | 600px]] ---> [[File:MentoredTeamDecorator.png | 600px]]
* In particular this required changing the MentoredTeam to have its own assignment team variable.
* The add_member function's DRY violations with the Team Class were able to be eliminated here, as now the Mentored Team Decorator calls to the assignment team's add member function on line 14, and then simply calls to assign the mentor on line 16.
==== MailerHelper to Mailer ====
* To increase understandability and consistency between classes, we removed the send_team_confirmation_mail function from the MailerHelper, and instead replaced its functionality with the team_addition_message function in the Mailer class. We found this to be the ideal location as the Mailer class houses many other specific message functions such as notify_grade_conflict_message, suggested_topic_approved_message and more.
[[File:team_confirm.png | 600px]] ---> [[File:Team_Addtion_Message.png | 600px]]
==== Team Add_Member ====
* The add_member function was altered in a couple of different ways. Firstly, we parameterized the partial_name in the call to the function that actually sends the mail, as in the original code we were violating the DRY principle by repeating the same MailerHelper call twice with very little change between them.
* Additionally we removed the type check for whether a user is a participant or not, as most users should be participants.
[[File:add_member_email.png | 600px]] ---> [[File:New_Add_Message.png | 600px]]

== Implementation - To delete later ==
TODO:: 

== Files Modified/Added ==
* app/controllers/sign_up_sheet_controller.rb
* app/controllers/teams_controller.rb
* app/controllers/teams_users_controller.rb
* app/models/course.rb
* app/models/mentor_management.rb
* app/views/sign_up_sheet/_table_header.html.erb
* app/views/sign_up_sheet/_table_line.html.erb
* app/views/sign_up_sheet/_topic.html.erb
* app/views/teams/_team.html.erb
* app/views/tree_display/_page_footer_assignments.html.erb
* app/views/tree_display/_entry_assignments.html.erb
* app/models/mentored_team_decorator.rb
* app/models/team.rb
* app/views/mailer/team_addition_message.html.erb
* app/views/mailer/team_addition_message.text.erb
* app/helpers/mailer_helper.rb
* app/mailers/mailer.rb
* spec/models/team_spec.rb
* spec/models/mentor_management_spec.rb

== Test Plan ==
When the project was pulled from the main repository, there are not enough tests to cover the additional functionalities that we added. We are planning on using the test skeletons by Mustafa Olmez, as a reference to how and what kind of tests should be written. Test cases for mentor management were already written and we wrote new test cases for the new functionalities we added. Here are the four test case scenarios we covered and the actual ruby code for the Rspec tests

=== Automated Rspec Testing Scenarios===
1. Test scenario 1: Given an assignment_id, When there are multiple mentors with different team counts for the assignment, Then it should return the mentor with the lowest team count
it "returns the mentor with the lowest team count for the given assignment" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 2]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

2. Test scenario 2: Given an assignment_id, When there is only one mentor available for the assignment, Then it should return that mentor
it "should return that mentor if there's only one available" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 0]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

3. Test scenario 3: Given an assignment_id, When there are multiple mentors with the same lowest team count for the assignment, Then it should return the first mentor in the list
it "returns the first mentor in the list if there's a tie for lowest team count" do
# Arrange
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 1],])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

4. Test scenario 4: Given an assignment_id, When there are no mentors available for the assignment, Then it should return nil
it "returns nil" do
# Create a new assignment
a = FactoryBot.create(:assignment, id: 997, directory_path: 'OSS_project', auto_assign_mentor: true)
# Since there are no mentors associated with this assignment, should return nil
expect(MentorManagement.select_mentor(a.id)).to eq nil
end

=== Manual UI Testing ===
Apart from the automated Rspec tests, we are providing manual testing cases that can be used to verify the functioning of the website.

Refer to the demo video on the bottom of the page to find help on testing these cases

==== Scenario 1 - Creating an mentored team ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Courses
# Assuming you have created a course and added participants to it, proceed to create a team
# Make sure "Auto assign mentors when team hits > 50% capacity?" option is checked
[[File:MT 1-1.png | 600px]]
* Create team for the assignment and you can see that the team with more than 50% capacity gets a mentor assigned automatically
[[File:MT 1-2.png | 600px]]

==== Scenario 2 - Adding, editing, deleting mentor meeting dates ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Assigments
# Assuming you have created a mentored assignment and added participants to it, proceed to the teams page
# Try entering dates into it teams row and the date should persist
# You can edit and delete the dates from the rows
# Team with less than 50% capacity will have the mentor meeting dates disabled
[[File:MT 2.png | 600px]]

==== Scenario 3 - Creating a team with topic ====
* Log into Expertiza using the test credential and navigate to the home page
* Go to Manage > Courses
* Assuming you have created a course and added participants to it, proceed to create a team
* Make sure "Has topics?" option is checked and a topic is created using the Topics tab
[[File:MT 3-1.png | 600px]]
* Create a new topic for the assignment and enter a mentor name to the topic
[[File:UI2 E2403.png | 600px]]
* When a student is added to the topic, the team of the student along with the mentor will be displayed in the topic row
[[File:UI3 E2403.png | 600px]]
* When navigating to the teams page of that assignment, you can see a mentor assigned automatically
[[File:UI4 E2403.png | 600px]]

== Test Coverage ==
We used SimpleCov to generate a coverage report for the Rspec test cases implemeted for the model and controllers.
The test coverage indicated 1730 lines of code was covered through the testcases.

[[File:Testing E2403.png ‎| 600px]]

== Test Login Credentials ==
* UserId: instructor6
* Password: password

== Demo Video ==
TODO:: 
This is our [https://www.youtube.com/ demo video] which explain how to create courses, assignments, mentored teams and mentored teams with topics. This video also show how to run the tests of our code changes.

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2789

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T01:45:34Z

Slkwiatk: /* Mailer Changes */

== Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project. Instructors have the ability to add new projects, assignments, etc., as well as edit existing ones. Later on, they can view student submissions and grade them. Students can also use Expertiza to organize into teams to work on different projects and assignments and submit their work. They can also review other students' submissions.

== Introduction ==
This project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management/ E2304] for the implementation of the Mentor-meeting management in the Expertiza system for mentored teams. We are now required to add functionality to add mentors to the topics and then assign them to the teams when they pick up that topic.

== Problem Statement ==
The following tasks are required for the project:
#Enhancing Code Clarity: This involves renaming methods from Project 3 with ambiguous names, optimizing loops and adding comments for unclear lines of code
#Reimplement Mentored teams: Reimplement the Mentored team delegate to the Assignment team to reduce complexity and to follow best principles of Object Oriented Design
#Reimplement Sign Up Sheet or Topics: Reimplement the SignUpSheet controller to automatically add the mentor to when a topic is created and automatically assign the same mentor to a team when they choose the topic
#Writing tests for mentor meetings models: More tests have to be written for Mentor Meeting model
#Writing tests for the mentor meetings controller: More tests should be written for Mentor meeting controller
#Writing tests for the signup sheet controller: Additional tests should be written for signup sheet controller to test the new functionality

== Objectives ==
We have 3 main objectives for this project.
* Refactoring of the Mentor-meeting model and controller created for the Project 3
* Reimplementation of Mentored Teams model and controller for the Project 4
* Reimplementation of SignUp Sheet controller for the Project 4 to automatically assign mentors to the topics

== Design Goal ==
While fulfilling all the objectives, the following design rules have to be ensured:
* Validate proper functioning of all existing and anticipated methods, making any required enhancements or adjustments.
* Establish loose coupling and tight cohesion for the model and controller to enhance code organization and maintainability.
* Refactor redundant code in the previous implementation's controller and model methods using DRY principle, eliminating functionality duplication already present in the Expertiza system.
* Confirm the continued effectiveness of existing test cases following the aforementioned modifications and generate additional test cases as per the need.

== Class UML Diagram ==
[[File:OODD Proj4 E2403 - Entity Diagram 2.png ‎| 610px]]

== Classes and Relationships ==
=== Existing Structure ===
* Every Assignment has a Node
* Every Assignment has many AssignmentTeam and MentoredTeam
* AssignmentTeam is inherited from Team
* MentoredTeam is inherited from AssignmentTeam
* Every MentoredTeam has many MentorMeeting
=== Proposed Structure Structure ===
* MentoredTeam to be delegated from AssignmentTeam instead of inheriting from it

== Implementation Plan ==
=== Modify newly created controller, model and view ===
==== mentor_meeting_controller.rb ====
* Edit function names to make them more descriptive
* Add more descriptive comments for the functions
==== mentor_meetings_helper.rb ====
* Move the "get_dates_for_team" function to the model
* Rename the function to make it more descriptive
==== _entry_assignments.html.erb ====
* Add more descriptive comments for the JavaScript functions
* Move the Ruby code from the template to a helper or the controller
==== mentored_team.rb --> mentored_team_decorator ====
* To reduce DRY violations, the mentored team class was changed to the mentored team decorator class.
*

=== Modify existing controller model and view ===
==== teams/_team.html.erb ====
* As the mentored team will now be delegated from the assignment team, we need to change the if condition on the top as we are changing MentoredTeam to be delegated from the AssignmentTeam
==== teams_controller.rb ====
* This file has to be modified to work with the delegated MentoredTeam
* These lines will not work as MentoredTeam will not be a model
[[File:Teams con1.png ‎| 600px]]
==== sign_up_sheet_controller.rb ====
* This controller has to be modified to automatically assign mentors or manually add mentors to the topics when they are created
* This will be followed by a change in schema
[[File:Signup con1.png | 600px]]
==== _topic.html.erb ====
* If we manually have to assign mentors to the topic, we have to include a input field to enter the mentor
[[File:Topic html.png | 600px]]
==== schema.rb ====
* As we are adding a new field to the table, we need to modify the schema
* We need to write 1 migration to add the field to the table to update the schema file
[[File:Schema E2403.png | 600px]]

=== Mailer Changes ===
====team.rb====
* The team model must be altered to use delegation for cases where a team would previously be a mentored team.
====add_member====
* The add member function must be altered such that the call to mail a user is better named, and that it calls directly to the mailer rather than the mailer helper.
[[File:add_member_email.png | 900px]]
====mailer_helper====
* The mailer_helper will be altered such that the send_team_confimration_to_user will be moved and renamed in the Mailer.rb class instead since using generic_message as such is leading to an unclear design.
[[File:team_confirm.png | 900px]]

====mailer.rb====
* A new function to specifically handle messaging users when added to teams will be built in the mailer, rather than just overusing the generic_message function.

== UI Changes ==
=== UI Changes before Phase 2 code changes ===
* The mentored assignment teams page has the modified UI from the Phase 1 as it is also a mentored assignment
* But the teams do not have a TA as the automated assignment of mentors has not been implemented.
[[File:UI1 E2403.png | 600px]]

=== UI Changes after Phase 2 code changes ===
The mentored assignment teams with topic now has the new UI and the automated mentor assignment
* The form to create a new topic has a new field to assign mentor to a topic
[[File:UI2 E2403.png | 600px]]
* The updated UI showing the topics with the mentors and teams that have chosen the topic
* The mentor is also displayed with the team
[[File:UI3 E2403.png | 600px]]
* The assignment teams page has the modified UI from the Phase 1 as the teams have a mentor
[[File:UI4 E2403.png | 600px]]

== Implementation ==
=== Mailer Changes ===
==== Decorator ====
* To remove DRY violations, we transformed the MentoredTeam class into the MentoredTeamDecoratorClass.
[[File:MentoredTeamClass.png | 600px]] ---> [[File:MentoredTeamDecorator.png | 600px]]
* In particular this required changing the MentoredTeam to have its own assignment team variable.
* The add_member function's DRY violations with the Team Class were able to be eliminated here, as now the Mentored Team Decorator calls to the assignment team's add member function on line 14, and then simply calls to assign the mentor on line 16.
==== MailerHelper to Mailer ====
* To increase understandability and consistency between classes, we removed the send_team_confirmation_mail function from the MailerHelper, and instead replaced its functionality with the team_addition_message function in the Mailer class. We found this to be the ideal location as the Mailer class houses many other specific message functions such as notify_grade_conflict_message, suggested_topic_approved_message and more.
[[File:team_confirm.png | 600px]] ---> [[File:Team_Addtion_Message.png | 600px]]
==== Team Add_Member ====
* The add_member function was altered in a couple of different ways. Firstly, we parameterized the partial_name in the call to the function that actually sends the mail, as in the original code we were violating the DRY principle by repeating the same MailerHelper call twice with very little change between them.
* Additionally we removed the type check for whether a user is a participant or not, as most users should be participants.
*[[File:add_member_email.png | 600px]] ---> [[File:New_Add_Message.png | 600px]]

== Implementation - To delete later ==
TODO:: 

== Files Modified/Added ==
* app/controllers/sign_up_sheet_controller.rb
* app/controllers/teams_controller.rb
* app/controllers/teams_users_controller.rb
* app/models/course.rb
* app/models/mentor_management.rb
* app/views/sign_up_sheet/_table_header.html.erb
* app/views/sign_up_sheet/_table_line.html.erb
* app/views/sign_up_sheet/_topic.html.erb
* app/views/teams/_team.html.erb
* app/views/tree_display/_page_footer_assignments.html.erb
* app/views/tree_display/_entry_assignments.html.erb
* app/models/mentored_team_decorator.rb
* app/models/team.rb
* app/views/mailer/team_addition_message.html.erb
* app/views/mailer/team_addition_message.text.erb
* app/helpers/mailer_helper.rb
* app/mailers/mailer.rb
* spec/models/team_spec.rb
* spec/models/mentor_management_spec.rb

== Test Plan ==
When the project was pulled from the main repository, there are not enough tests to cover the additional functionalities that we added. We are planning on using the test skeletons by Mustafa Olmez, as a reference to how and what kind of tests should be written. Test cases for mentor management were already written and we wrote new test cases for the new functionalities we added. Here are the four test case scenarios we covered and the actual ruby code for the Rspec tests

=== Automated Rspec Testing Scenarios===
1. Test scenario 1: Given an assignment_id, When there are multiple mentors with different team counts for the assignment, Then it should return the mentor with the lowest team count
it "returns the mentor with the lowest team count for the given assignment" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 2]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

2. Test scenario 2: Given an assignment_id, When there is only one mentor available for the assignment, Then it should return that mentor
it "should return that mentor if there's only one available" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 0]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

3. Test scenario 3: Given an assignment_id, When there are multiple mentors with the same lowest team count for the assignment, Then it should return the first mentor in the list
it "returns the first mentor in the list if there's a tie for lowest team count" do
# Arrange
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 1],])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

4. Test scenario 4: Given an assignment_id, When there are no mentors available for the assignment, Then it should return nil
it "returns nil" do
# Create a new assignment
a = FactoryBot.create(:assignment, id: 997, directory_path: 'OSS_project', auto_assign_mentor: true)
# Since there are no mentors associated with this assignment, should return nil
expect(MentorManagement.select_mentor(a.id)).to eq nil
end

=== Manual UI Testing ===
Apart from the automated Rspec tests, we are providing manual testing cases that can be used to verify the functioning of the website.

Refer to the demo video on the bottom of the page to find help on testing these cases

==== Scenario 1 - Creating an mentored team ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Courses
# Assuming you have created a course and added participants to it, proceed to create a team
# Make sure "Auto assign mentors when team hits > 50% capacity?" option is checked
[[File:MT 1-1.png | 600px]]
* Create team for the assignment and you can see that the team with more than 50% capacity gets a mentor assigned automatically
[[File:MT 1-2.png | 600px]]

==== Scenario 2 - Adding, editing, deleting mentor meeting dates ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Assigments
# Assuming you have created a mentored assignment and added participants to it, proceed to the teams page
# Try entering dates into it teams row and the date should persist
# You can edit and delete the dates from the rows
# Team with less than 50% capacity will have the mentor meeting dates disabled
[[File:MT 2.png | 600px]]

==== Scenario 3 - Creating a team with topic ====
* Log into Expertiza using the test credential and navigate to the home page
* Go to Manage > Courses
* Assuming you have created a course and added participants to it, proceed to create a team
* Make sure "Has topics?" option is checked and a topic is created using the Topics tab
[[File:MT 3-1.png | 600px]]
* Create a new topic for the assignment and enter a mentor name to the topic
[[File:UI2 E2403.png | 600px]]
* When a student is added to the topic, the team of the student along with the mentor will be displayed in the topic row
[[File:UI3 E2403.png | 600px]]
* When navigating to the teams page of that assignment, you can see a mentor assigned automatically
[[File:UI4 E2403.png | 600px]]

== Test Coverage ==
We used SimpleCov to generate a coverage report for the Rspec test cases implemeted for the model and controllers.
The test coverage indicated 1730 lines of code was covered through the testcases.

[[File:Testing E2403.png ‎| 600px]]

== Test Login Credentials ==
* UserId: instructor6
* Password: password

== Demo Video ==
TODO:: 
This is our [https://www.youtube.com/ demo video] which explain how to create courses, assignments, mentored teams and mentored teams with topics. This video also show how to run the tests of our code changes.

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2789

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

File:New Add Message.png

2024-04-24T01:44:53Z

Slkwiatk:

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T01:41:32Z

Slkwiatk: /* Mailer Changes */

== Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project. Instructors have the ability to add new projects, assignments, etc., as well as edit existing ones. Later on, they can view student submissions and grade them. Students can also use Expertiza to organize into teams to work on different projects and assignments and submit their work. They can also review other students' submissions.

== Introduction ==
This project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management/ E2304] for the implementation of the Mentor-meeting management in the Expertiza system for mentored teams. We are now required to add functionality to add mentors to the topics and then assign them to the teams when they pick up that topic.

== Problem Statement ==
The following tasks are required for the project:
#Enhancing Code Clarity: This involves renaming methods from Project 3 with ambiguous names, optimizing loops and adding comments for unclear lines of code
#Reimplement Mentored teams: Reimplement the Mentored team delegate to the Assignment team to reduce complexity and to follow best principles of Object Oriented Design
#Reimplement Sign Up Sheet or Topics: Reimplement the SignUpSheet controller to automatically add the mentor to when a topic is created and automatically assign the same mentor to a team when they choose the topic
#Writing tests for mentor meetings models: More tests have to be written for Mentor Meeting model
#Writing tests for the mentor meetings controller: More tests should be written for Mentor meeting controller
#Writing tests for the signup sheet controller: Additional tests should be written for signup sheet controller to test the new functionality

== Objectives ==
We have 3 main objectives for this project.
* Refactoring of the Mentor-meeting model and controller created for the Project 3
* Reimplementation of Mentored Teams model and controller for the Project 4
* Reimplementation of SignUp Sheet controller for the Project 4 to automatically assign mentors to the topics

== Design Goal ==
While fulfilling all the objectives, the following design rules have to be ensured:
* Validate proper functioning of all existing and anticipated methods, making any required enhancements or adjustments.
* Establish loose coupling and tight cohesion for the model and controller to enhance code organization and maintainability.
* Refactor redundant code in the previous implementation's controller and model methods using DRY principle, eliminating functionality duplication already present in the Expertiza system.
* Confirm the continued effectiveness of existing test cases following the aforementioned modifications and generate additional test cases as per the need.

== Class UML Diagram ==
[[File:OODD Proj4 E2403 - Entity Diagram 2.png ‎| 610px]]

== Classes and Relationships ==
=== Existing Structure ===
* Every Assignment has a Node
* Every Assignment has many AssignmentTeam and MentoredTeam
* AssignmentTeam is inherited from Team
* MentoredTeam is inherited from AssignmentTeam
* Every MentoredTeam has many MentorMeeting
=== Proposed Structure Structure ===
* MentoredTeam to be delegated from AssignmentTeam instead of inheriting from it

== Implementation Plan ==
=== Modify newly created controller, model and view ===
==== mentor_meeting_controller.rb ====
* Edit function names to make them more descriptive
* Add more descriptive comments for the functions
==== mentor_meetings_helper.rb ====
* Move the "get_dates_for_team" function to the model
* Rename the function to make it more descriptive
==== _entry_assignments.html.erb ====
* Add more descriptive comments for the JavaScript functions
* Move the Ruby code from the template to a helper or the controller
==== mentored_team.rb --> mentored_team_decorator ====
* To reduce DRY violations, the mentored team class was changed to the mentored team decorator class.
*

=== Modify existing controller model and view ===
==== teams/_team.html.erb ====
* As the mentored team will now be delegated from the assignment team, we need to change the if condition on the top as we are changing MentoredTeam to be delegated from the AssignmentTeam
==== teams_controller.rb ====
* This file has to be modified to work with the delegated MentoredTeam
* These lines will not work as MentoredTeam will not be a model
[[File:Teams con1.png ‎| 600px]]
==== sign_up_sheet_controller.rb ====
* This controller has to be modified to automatically assign mentors or manually add mentors to the topics when they are created
* This will be followed by a change in schema
[[File:Signup con1.png | 600px]]
==== _topic.html.erb ====
* If we manually have to assign mentors to the topic, we have to include a input field to enter the mentor
[[File:Topic html.png | 600px]]
==== schema.rb ====
* As we are adding a new field to the table, we need to modify the schema
* We need to write 1 migration to add the field to the table to update the schema file
[[File:Schema E2403.png | 600px]]

=== Mailer Changes ===
====team.rb====
* The team model must be altered to use delegation for cases where a team would previously be a mentored team.
====add_member====
* The add member function must be altered such that the call to mail a user is better named, and that it calls directly to the mailer rather than the mailer helper.
[[File:add_member_email.png | 900px]]
====mailer_helper====
* The mailer_helper will be altered such that the send_team_confimration_to_user will be moved and renamed in the Mailer.rb class instead since using generic_message as such is leading to an unclear design.
[[File:team_confirm.png | 900px]]

====mailer.rb====
* A new function to specifically handle messaging users when added to teams will be built in the mailer, rather than just overusing the generic_message function.

== UI Changes ==
=== UI Changes before Phase 2 code changes ===
* The mentored assignment teams page has the modified UI from the Phase 1 as it is also a mentored assignment
* But the teams do not have a TA as the automated assignment of mentors has not been implemented.
[[File:UI1 E2403.png | 600px]]

=== UI Changes after Phase 2 code changes ===
The mentored assignment teams with topic now has the new UI and the automated mentor assignment
* The form to create a new topic has a new field to assign mentor to a topic
[[File:UI2 E2403.png | 600px]]
* The updated UI showing the topics with the mentors and teams that have chosen the topic
* The mentor is also displayed with the team
[[File:UI3 E2403.png | 600px]]
* The assignment teams page has the modified UI from the Phase 1 as the teams have a mentor
[[File:UI4 E2403.png | 600px]]

== Implementation ==
=== Mailer Changes ===
==== Decorator ====
* To remove DRY violations, we transformed the MentoredTeam class into the MentoredTeamDecoratorClass.
[[File:MentoredTeamClass.png | 600px]] ---> [[File:MentoredTeamDecorator.png | 600px]]
* In particular this required changing the MentoredTeam to have its own assignment team variable.
* The add_member function's DRY violations with the Team Class were able to be eliminated here, as now the Mentored Team Decorator calls to the assignment team's add member function on line 14, and then simply calls to assign the mentor on line 16.
==== MailerHelper to Mailer ====
* To increase understandability and consistency between classes, we removed the send_team_confirmation_mail function from the MailerHelper, and instead replaced its functionality with the team_addition_message function in the Mailer class. We found this to be the ideal location as the Mailer class houses many other specific message functions such as notify_grade_conflict_message, suggested_topic_approved_message and more.
[[File:team_confirm.png | 600px]] ---> [[File:Team_Addtion_Message.png | 600px]]
==== Team Add_Member ====
* The add_member function was altered in a couple of different ways. Firstly, we parameterized the partial_name in the call to the function that actually sends the mail, as in the original code we were violating the DRY principle by repeating the same MailerHelper call twice with very little change between them.
* Additionally we removed the type check for whether a user is a participant or not, as most users should be participants.
*[[File:add_member_email.png | 600px]] ---> [[File:add_member_email.png | 600px]]

== Implementation - To delete later ==
TODO:: 

== Files Modified/Added ==
* app/controllers/sign_up_sheet_controller.rb
* app/controllers/teams_controller.rb
* app/controllers/teams_users_controller.rb
* app/models/course.rb
* app/models/mentor_management.rb
* app/views/sign_up_sheet/_table_header.html.erb
* app/views/sign_up_sheet/_table_line.html.erb
* app/views/sign_up_sheet/_topic.html.erb
* app/views/teams/_team.html.erb
* app/views/tree_display/_page_footer_assignments.html.erb
* app/views/tree_display/_entry_assignments.html.erb
* app/models/mentored_team_decorator.rb
* app/models/team.rb
* app/views/mailer/team_addition_message.html.erb
* app/views/mailer/team_addition_message.text.erb
* app/helpers/mailer_helper.rb
* app/mailers/mailer.rb
* spec/models/team_spec.rb
* spec/models/mentor_management_spec.rb

== Test Plan ==
When the project was pulled from the main repository, there are not enough tests to cover the additional functionalities that we added. We are planning on using the test skeletons by Mustafa Olmez, as a reference to how and what kind of tests should be written. Test cases for mentor management were already written and we wrote new test cases for the new functionalities we added. Here are the four test case scenarios we covered and the actual ruby code for the Rspec tests

=== Automated Rspec Testing Scenarios===
1. Test scenario 1: Given an assignment_id, When there are multiple mentors with different team counts for the assignment, Then it should return the mentor with the lowest team count
it "returns the mentor with the lowest team count for the given assignment" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 2]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

2. Test scenario 2: Given an assignment_id, When there is only one mentor available for the assignment, Then it should return that mentor
it "should return that mentor if there's only one available" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 0]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

3. Test scenario 3: Given an assignment_id, When there are multiple mentors with the same lowest team count for the assignment, Then it should return the first mentor in the list
it "returns the first mentor in the list if there's a tie for lowest team count" do
# Arrange
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 1],])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

4. Test scenario 4: Given an assignment_id, When there are no mentors available for the assignment, Then it should return nil
it "returns nil" do
# Create a new assignment
a = FactoryBot.create(:assignment, id: 997, directory_path: 'OSS_project', auto_assign_mentor: true)
# Since there are no mentors associated with this assignment, should return nil
expect(MentorManagement.select_mentor(a.id)).to eq nil
end

=== Manual UI Testing ===
Apart from the automated Rspec tests, we are providing manual testing cases that can be used to verify the functioning of the website.

Refer to the demo video on the bottom of the page to find help on testing these cases

==== Scenario 1 - Creating an mentored team ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Courses
# Assuming you have created a course and added participants to it, proceed to create a team
# Make sure "Auto assign mentors when team hits > 50% capacity?" option is checked
[[File:MT 1-1.png | 600px]]
* Create team for the assignment and you can see that the team with more than 50% capacity gets a mentor assigned automatically
[[File:MT 1-2.png | 600px]]

==== Scenario 2 - Adding, editing, deleting mentor meeting dates ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Assigments
# Assuming you have created a mentored assignment and added participants to it, proceed to the teams page
# Try entering dates into it teams row and the date should persist
# You can edit and delete the dates from the rows
# Team with less than 50% capacity will have the mentor meeting dates disabled
[[File:MT 2.png | 600px]]

==== Scenario 3 - Creating a team with topic ====
* Log into Expertiza using the test credential and navigate to the home page
* Go to Manage > Courses
* Assuming you have created a course and added participants to it, proceed to create a team
* Make sure "Has topics?" option is checked and a topic is created using the Topics tab
[[File:MT 3-1.png | 600px]]
* Create a new topic for the assignment and enter a mentor name to the topic
[[File:UI2 E2403.png | 600px]]
* When a student is added to the topic, the team of the student along with the mentor will be displayed in the topic row
[[File:UI3 E2403.png | 600px]]
* When navigating to the teams page of that assignment, you can see a mentor assigned automatically
[[File:UI4 E2403.png | 600px]]

== Test Coverage ==
We used SimpleCov to generate a coverage report for the Rspec test cases implemeted for the model and controllers.
The test coverage indicated 1730 lines of code was covered through the testcases.

[[File:Testing E2403.png ‎| 600px]]

== Test Login Credentials ==
* UserId: instructor6
* Password: password

== Demo Video ==
TODO:: 
This is our [https://www.youtube.com/ demo video] which explain how to create courses, assignments, mentored teams and mentored teams with topics. This video also show how to run the tests of our code changes.

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2789

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T01:39:05Z

Slkwiatk: /* Team Add_Member */

== Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project. Instructors have the ability to add new projects, assignments, etc., as well as edit existing ones. Later on, they can view student submissions and grade them. Students can also use Expertiza to organize into teams to work on different projects and assignments and submit their work. They can also review other students' submissions.

== Introduction ==
This project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management/ E2304] for the implementation of the Mentor-meeting management in the Expertiza system for mentored teams. We are now required to add functionality to add mentors to the topics and then assign them to the teams when they pick up that topic.

== Problem Statement ==
The following tasks are required for the project:
#Enhancing Code Clarity: This involves renaming methods from Project 3 with ambiguous names, optimizing loops and adding comments for unclear lines of code
#Reimplement Mentored teams: Reimplement the Mentored team delegate to the Assignment team to reduce complexity and to follow best principles of Object Oriented Design
#Reimplement Sign Up Sheet or Topics: Reimplement the SignUpSheet controller to automatically add the mentor to when a topic is created and automatically assign the same mentor to a team when they choose the topic
#Writing tests for mentor meetings models: More tests have to be written for Mentor Meeting model
#Writing tests for the mentor meetings controller: More tests should be written for Mentor meeting controller
#Writing tests for the signup sheet controller: Additional tests should be written for signup sheet controller to test the new functionality

== Objectives ==
We have 3 main objectives for this project.
* Refactoring of the Mentor-meeting model and controller created for the Project 3
* Reimplementation of Mentored Teams model and controller for the Project 4
* Reimplementation of SignUp Sheet controller for the Project 4 to automatically assign mentors to the topics

== Design Goal ==
While fulfilling all the objectives, the following design rules have to be ensured:
* Validate proper functioning of all existing and anticipated methods, making any required enhancements or adjustments.
* Establish loose coupling and tight cohesion for the model and controller to enhance code organization and maintainability.
* Refactor redundant code in the previous implementation's controller and model methods using DRY principle, eliminating functionality duplication already present in the Expertiza system.
* Confirm the continued effectiveness of existing test cases following the aforementioned modifications and generate additional test cases as per the need.

== Class UML Diagram ==
[[File:OODD Proj4 E2403 - Entity Diagram 2.png ‎| 610px]]

== Classes and Relationships ==
=== Existing Structure ===
* Every Assignment has a Node
* Every Assignment has many AssignmentTeam and MentoredTeam
* AssignmentTeam is inherited from Team
* MentoredTeam is inherited from AssignmentTeam
* Every MentoredTeam has many MentorMeeting
=== Proposed Structure Structure ===
* MentoredTeam to be delegated from AssignmentTeam instead of inheriting from it

== Implementation Plan ==
=== Modify newly created controller, model and view ===
==== mentor_meeting_controller.rb ====
* Edit function names to make them more descriptive
* Add more descriptive comments for the functions
==== mentor_meetings_helper.rb ====
* Move the "get_dates_for_team" function to the model
* Rename the function to make it more descriptive
==== _entry_assignments.html.erb ====
* Add more descriptive comments for the JavaScript functions
* Move the Ruby code from the template to a helper or the controller
==== mentored_team.rb --> mentored_team_decorator ====
* To reduce DRY violations, the mentored team class was changed to the mentored team decorator class.
*

=== Modify existing controller model and view ===
==== teams/_team.html.erb ====
* As the mentored team will now be delegated from the assignment team, we need to change the if condition on the top as we are changing MentoredTeam to be delegated from the AssignmentTeam
==== teams_controller.rb ====
* This file has to be modified to work with the delegated MentoredTeam
* These lines will not work as MentoredTeam will not be a model
[[File:Teams con1.png ‎| 600px]]
==== sign_up_sheet_controller.rb ====
* This controller has to be modified to automatically assign mentors or manually add mentors to the topics when they are created
* This will be followed by a change in schema
[[File:Signup con1.png | 600px]]
==== _topic.html.erb ====
* If we manually have to assign mentors to the topic, we have to include a input field to enter the mentor
[[File:Topic html.png | 600px]]
==== schema.rb ====
* As we are adding a new field to the table, we need to modify the schema
* We need to write 1 migration to add the field to the table to update the schema file
[[File:Schema E2403.png | 600px]]

=== Mailer Changes ===
====team.rb====
* The team model must be altered to use delegation for cases where a team would previously be a mentored team.
====add_member====
* The add member function must be altered such that the call to mail a user is better named, and that it calls directly to the mailer rather than the mailer helper.
[[File:add_member_email.png | 900px]]
====mailer_helper====
* The mailer_helper will be altered such that the send_team_confimration_to_user will be moved and renamed in the Mailer.rb class instead since using generic_message as such is leading to an unclear design.
[[File:team_confirm.png | 900px]]

====mailer.rb====
* A new function to specifically handle messaging users when added to teams will be built in the mailer, rather than just overusing the generic_message function.

== UI Changes ==
=== UI Changes before Phase 2 code changes ===
* The mentored assignment teams page has the modified UI from the Phase 1 as it is also a mentored assignment
* But the teams do not have a TA as the automated assignment of mentors has not been implemented.
[[File:UI1 E2403.png | 600px]]

=== UI Changes after Phase 2 code changes ===
The mentored assignment teams with topic now has the new UI and the automated mentor assignment
* The form to create a new topic has a new field to assign mentor to a topic
[[File:UI2 E2403.png | 600px]]
* The updated UI showing the topics with the mentors and teams that have chosen the topic
* The mentor is also displayed with the team
[[File:UI3 E2403.png | 600px]]
* The assignment teams page has the modified UI from the Phase 1 as the teams have a mentor
[[File:UI4 E2403.png | 600px]]

== Implementation ==
=== Mailer Changes ===
==== Decorator ====
* To remove DRY violations, we transformed the MentoredTeam class into the MentoredTeamDecoratorClass.
[[File:MentoredTeamClass.png | 600px]] ---> [[File:MentoredTeamDecorator.png | 600px]]
* In particular this required changing the MentoredTeam to have its own assignment team variable.
* The add_member function's DRY violations with the Team Class were able to be eliminated here, as now the Mentored Team Decorator calls to the assignment team's add member function on line 14, and then simply calls to assign the mentor on line 16.
==== MailerHelper to Mailer ====
* To increase understandability and consistency between classes, we removed the send_team_confirmation_mail function from the MailerHelper, and instead replaced its functionality with the team_addition_message function in the Mailer class. We found this to be the ideal location as the Mailer class houses many other specific message functions such as notify_grade_conflict_message, suggested_topic_approved_message and more.
[[File:team_confirm.png | 600px]] ---> [[File:Team_Addtion_Message.png | 600px]]
==== Team Add_Member ====
* The add_member function was altered in a couple of different ways. Firstly, we parameterized the partial_name in the call to the function that actually sends the mail, as in the original code we were violating the DRY principle by repeating the same MailerHelper call twice with very little change between them.

== Implementation - To delete later ==
TODO:: 

== Files Modified/Added ==
* app/controllers/sign_up_sheet_controller.rb
* app/controllers/teams_controller.rb
* app/controllers/teams_users_controller.rb
* app/models/course.rb
* app/models/mentor_management.rb
* app/views/sign_up_sheet/_table_header.html.erb
* app/views/sign_up_sheet/_table_line.html.erb
* app/views/sign_up_sheet/_topic.html.erb
* app/views/teams/_team.html.erb
* app/views/tree_display/_page_footer_assignments.html.erb
* app/views/tree_display/_entry_assignments.html.erb
* app/models/mentored_team_decorator.rb
* app/models/team.rb
* app/views/mailer/team_addition_message.html.erb
* app/views/mailer/team_addition_message.text.erb
* app/helpers/mailer_helper.rb
* app/mailers/mailer.rb
* spec/models/team_spec.rb
* spec/models/mentor_management_spec.rb

== Test Plan ==
When the project was pulled from the main repository, there are not enough tests to cover the additional functionalities that we added. We are planning on using the test skeletons by Mustafa Olmez, as a reference to how and what kind of tests should be written. Test cases for mentor management were already written and we wrote new test cases for the new functionalities we added. Here are the four test case scenarios we covered and the actual ruby code for the Rspec tests

=== Automated Rspec Testing Scenarios===
1. Test scenario 1: Given an assignment_id, When there are multiple mentors with different team counts for the assignment, Then it should return the mentor with the lowest team count
it "returns the mentor with the lowest team count for the given assignment" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 2]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

2. Test scenario 2: Given an assignment_id, When there is only one mentor available for the assignment, Then it should return that mentor
it "should return that mentor if there's only one available" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 0]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

3. Test scenario 3: Given an assignment_id, When there are multiple mentors with the same lowest team count for the assignment, Then it should return the first mentor in the list
it "returns the first mentor in the list if there's a tie for lowest team count" do
# Arrange
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 1],])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

4. Test scenario 4: Given an assignment_id, When there are no mentors available for the assignment, Then it should return nil
it "returns nil" do
# Create a new assignment
a = FactoryBot.create(:assignment, id: 997, directory_path: 'OSS_project', auto_assign_mentor: true)
# Since there are no mentors associated with this assignment, should return nil
expect(MentorManagement.select_mentor(a.id)).to eq nil
end

=== Manual UI Testing ===
Apart from the automated Rspec tests, we are providing manual testing cases that can be used to verify the functioning of the website.

Refer to the demo video on the bottom of the page to find help on testing these cases

==== Scenario 1 - Creating an mentored team ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Courses
# Assuming you have created a course and added participants to it, proceed to create a team
# Make sure "Auto assign mentors when team hits > 50% capacity?" option is checked
[[File:MT 1-1.png | 600px]]
* Create team for the assignment and you can see that the team with more than 50% capacity gets a mentor assigned automatically
[[File:MT 1-2.png | 600px]]

==== Scenario 2 - Adding, editing, deleting mentor meeting dates ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Assigments
# Assuming you have created a mentored assignment and added participants to it, proceed to the teams page
# Try entering dates into it teams row and the date should persist
# You can edit and delete the dates from the rows
# Team with less than 50% capacity will have the mentor meeting dates disabled
[[File:MT 2.png | 600px]]

==== Scenario 3 - Creating a team with topic ====
* Log into Expertiza using the test credential and navigate to the home page
* Go to Manage > Courses
* Assuming you have created a course and added participants to it, proceed to create a team
* Make sure "Has topics?" option is checked and a topic is created using the Topics tab
[[File:MT 3-1.png | 600px]]
* Create a new topic for the assignment and enter a mentor name to the topic
[[File:UI2 E2403.png | 600px]]
* When a student is added to the topic, the team of the student along with the mentor will be displayed in the topic row
[[File:UI3 E2403.png | 600px]]
* When navigating to the teams page of that assignment, you can see a mentor assigned automatically
[[File:UI4 E2403.png | 600px]]

== Test Coverage ==
We used SimpleCov to generate a coverage report for the Rspec test cases implemeted for the model and controllers.
The test coverage indicated 1730 lines of code was covered through the testcases.

[[File:Testing E2403.png ‎| 600px]]

== Test Login Credentials ==
* UserId: instructor6
* Password: password

== Demo Video ==
TODO:: 
This is our [https://www.youtube.com/ demo video] which explain how to create courses, assignments, mentored teams and mentored teams with topics. This video also show how to run the tests of our code changes.

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2789

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T01:37:11Z

Slkwiatk: /* Team Add_Member */

== Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project. Instructors have the ability to add new projects, assignments, etc., as well as edit existing ones. Later on, they can view student submissions and grade them. Students can also use Expertiza to organize into teams to work on different projects and assignments and submit their work. They can also review other students' submissions.

== Introduction ==
This project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management/ E2304] for the implementation of the Mentor-meeting management in the Expertiza system for mentored teams. We are now required to add functionality to add mentors to the topics and then assign them to the teams when they pick up that topic.

== Problem Statement ==
The following tasks are required for the project:
#Enhancing Code Clarity: This involves renaming methods from Project 3 with ambiguous names, optimizing loops and adding comments for unclear lines of code
#Reimplement Mentored teams: Reimplement the Mentored team delegate to the Assignment team to reduce complexity and to follow best principles of Object Oriented Design
#Reimplement Sign Up Sheet or Topics: Reimplement the SignUpSheet controller to automatically add the mentor to when a topic is created and automatically assign the same mentor to a team when they choose the topic
#Writing tests for mentor meetings models: More tests have to be written for Mentor Meeting model
#Writing tests for the mentor meetings controller: More tests should be written for Mentor meeting controller
#Writing tests for the signup sheet controller: Additional tests should be written for signup sheet controller to test the new functionality

== Objectives ==
We have 3 main objectives for this project.
* Refactoring of the Mentor-meeting model and controller created for the Project 3
* Reimplementation of Mentored Teams model and controller for the Project 4
* Reimplementation of SignUp Sheet controller for the Project 4 to automatically assign mentors to the topics

== Design Goal ==
While fulfilling all the objectives, the following design rules have to be ensured:
* Validate proper functioning of all existing and anticipated methods, making any required enhancements or adjustments.
* Establish loose coupling and tight cohesion for the model and controller to enhance code organization and maintainability.
* Refactor redundant code in the previous implementation's controller and model methods using DRY principle, eliminating functionality duplication already present in the Expertiza system.
* Confirm the continued effectiveness of existing test cases following the aforementioned modifications and generate additional test cases as per the need.

== Class UML Diagram ==
[[File:OODD Proj4 E2403 - Entity Diagram 2.png ‎| 610px]]

== Classes and Relationships ==
=== Existing Structure ===
* Every Assignment has a Node
* Every Assignment has many AssignmentTeam and MentoredTeam
* AssignmentTeam is inherited from Team
* MentoredTeam is inherited from AssignmentTeam
* Every MentoredTeam has many MentorMeeting
=== Proposed Structure Structure ===
* MentoredTeam to be delegated from AssignmentTeam instead of inheriting from it

== Implementation Plan ==
=== Modify newly created controller, model and view ===
==== mentor_meeting_controller.rb ====
* Edit function names to make them more descriptive
* Add more descriptive comments for the functions
==== mentor_meetings_helper.rb ====
* Move the "get_dates_for_team" function to the model
* Rename the function to make it more descriptive
==== _entry_assignments.html.erb ====
* Add more descriptive comments for the JavaScript functions
* Move the Ruby code from the template to a helper or the controller
==== mentored_team.rb --> mentored_team_decorator ====
* To reduce DRY violations, the mentored team class was changed to the mentored team decorator class.
*

=== Modify existing controller model and view ===
==== teams/_team.html.erb ====
* As the mentored team will now be delegated from the assignment team, we need to change the if condition on the top as we are changing MentoredTeam to be delegated from the AssignmentTeam
==== teams_controller.rb ====
* This file has to be modified to work with the delegated MentoredTeam
* These lines will not work as MentoredTeam will not be a model
[[File:Teams con1.png ‎| 600px]]
==== sign_up_sheet_controller.rb ====
* This controller has to be modified to automatically assign mentors or manually add mentors to the topics when they are created
* This will be followed by a change in schema
[[File:Signup con1.png | 600px]]
==== _topic.html.erb ====
* If we manually have to assign mentors to the topic, we have to include a input field to enter the mentor
[[File:Topic html.png | 600px]]
==== schema.rb ====
* As we are adding a new field to the table, we need to modify the schema
* We need to write 1 migration to add the field to the table to update the schema file
[[File:Schema E2403.png | 600px]]

=== Mailer Changes ===
====team.rb====
* The team model must be altered to use delegation for cases where a team would previously be a mentored team.
====add_member====
* The add member function must be altered such that the call to mail a user is better named, and that it calls directly to the mailer rather than the mailer helper.
[[File:add_member_email.png | 900px]]
====mailer_helper====
* The mailer_helper will be altered such that the send_team_confimration_to_user will be moved and renamed in the Mailer.rb class instead since using generic_message as such is leading to an unclear design.
[[File:team_confirm.png | 900px]]

====mailer.rb====
* A new function to specifically handle messaging users when added to teams will be built in the mailer, rather than just overusing the generic_message function.

== UI Changes ==
=== UI Changes before Phase 2 code changes ===
* The mentored assignment teams page has the modified UI from the Phase 1 as it is also a mentored assignment
* But the teams do not have a TA as the automated assignment of mentors has not been implemented.
[[File:UI1 E2403.png | 600px]]

=== UI Changes after Phase 2 code changes ===
The mentored assignment teams with topic now has the new UI and the automated mentor assignment
* The form to create a new topic has a new field to assign mentor to a topic
[[File:UI2 E2403.png | 600px]]
* The updated UI showing the topics with the mentors and teams that have chosen the topic
* The mentor is also displayed with the team
[[File:UI3 E2403.png | 600px]]
* The assignment teams page has the modified UI from the Phase 1 as the teams have a mentor
[[File:UI4 E2403.png | 600px]]

== Implementation ==
=== Mailer Changes ===
==== Decorator ====
* To remove DRY violations, we transformed the MentoredTeam class into the MentoredTeamDecoratorClass.
[[File:MentoredTeamClass.png | 600px]] ---> [[File:MentoredTeamDecorator.png | 600px]]
* In particular this required changing the MentoredTeam to have its own assignment team variable.
* The add_member function's DRY violations with the Team Class were able to be eliminated here, as now the Mentored Team Decorator calls to the assignment team's add member function on line 14, and then simply calls to assign the mentor on line 16.
==== MailerHelper to Mailer ====
* To increase understandability and consistency between classes, we removed the send_team_confirmation_mail function from the MailerHelper, and instead replaced its functionality with the team_addition_message function in the Mailer class. We found this to be the ideal location as the Mailer class houses many other specific message functions such as notify_grade_conflict_message, suggested_topic_approved_message and more.
[[File:team_confirm.png | 600px]] ---> [[File:Team_Addtion_Message.png | 600px]]
==== Team Add_Member ====
* The add_member function was altered in a couple of different ways. Firstly,

== Implementation - To delete later ==
TODO:: 

== Files Modified/Added ==
* app/controllers/sign_up_sheet_controller.rb
* app/controllers/teams_controller.rb
* app/controllers/teams_users_controller.rb
* app/models/course.rb
* app/models/mentor_management.rb
* app/views/sign_up_sheet/_table_header.html.erb
* app/views/sign_up_sheet/_table_line.html.erb
* app/views/sign_up_sheet/_topic.html.erb
* app/views/teams/_team.html.erb
* app/views/tree_display/_page_footer_assignments.html.erb
* app/views/tree_display/_entry_assignments.html.erb
* app/models/mentored_team_decorator.rb
* app/models/team.rb
* app/views/mailer/team_addition_message.html.erb
* app/views/mailer/team_addition_message.text.erb
* app/helpers/mailer_helper.rb
* app/mailers/mailer.rb
* spec/models/team_spec.rb
* spec/models/mentor_management_spec.rb

== Test Plan ==
When the project was pulled from the main repository, there are not enough tests to cover the additional functionalities that we added. We are planning on using the test skeletons by Mustafa Olmez, as a reference to how and what kind of tests should be written. Test cases for mentor management were already written and we wrote new test cases for the new functionalities we added. Here are the four test case scenarios we covered and the actual ruby code for the Rspec tests

=== Automated Rspec Testing Scenarios===
1. Test scenario 1: Given an assignment_id, When there are multiple mentors with different team counts for the assignment, Then it should return the mentor with the lowest team count
it "returns the mentor with the lowest team count for the given assignment" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 2]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

2. Test scenario 2: Given an assignment_id, When there is only one mentor available for the assignment, Then it should return that mentor
it "should return that mentor if there's only one available" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 0]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

3. Test scenario 3: Given an assignment_id, When there are multiple mentors with the same lowest team count for the assignment, Then it should return the first mentor in the list
it "returns the first mentor in the list if there's a tie for lowest team count" do
# Arrange
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 1],])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

4. Test scenario 4: Given an assignment_id, When there are no mentors available for the assignment, Then it should return nil
it "returns nil" do
# Create a new assignment
a = FactoryBot.create(:assignment, id: 997, directory_path: 'OSS_project', auto_assign_mentor: true)
# Since there are no mentors associated with this assignment, should return nil
expect(MentorManagement.select_mentor(a.id)).to eq nil
end

=== Manual UI Testing ===
Apart from the automated Rspec tests, we are providing manual testing cases that can be used to verify the functioning of the website.

Refer to the demo video on the bottom of the page to find help on testing these cases

==== Scenario 1 - Creating an mentored team ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Courses
# Assuming you have created a course and added participants to it, proceed to create a team
# Make sure "Auto assign mentors when team hits > 50% capacity?" option is checked
[[File:MT 1-1.png | 600px]]
* Create team for the assignment and you can see that the team with more than 50% capacity gets a mentor assigned automatically
[[File:MT 1-2.png | 600px]]

==== Scenario 2 - Adding, editing, deleting mentor meeting dates ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Assigments
# Assuming you have created a mentored assignment and added participants to it, proceed to the teams page
# Try entering dates into it teams row and the date should persist
# You can edit and delete the dates from the rows
# Team with less than 50% capacity will have the mentor meeting dates disabled
[[File:MT 2.png | 600px]]

==== Scenario 3 - Creating a team with topic ====
* Log into Expertiza using the test credential and navigate to the home page
* Go to Manage > Courses
* Assuming you have created a course and added participants to it, proceed to create a team
* Make sure "Has topics?" option is checked and a topic is created using the Topics tab
[[File:MT 3-1.png | 600px]]
* Create a new topic for the assignment and enter a mentor name to the topic
[[File:UI2 E2403.png | 600px]]
* When a student is added to the topic, the team of the student along with the mentor will be displayed in the topic row
[[File:UI3 E2403.png | 600px]]
* When navigating to the teams page of that assignment, you can see a mentor assigned automatically
[[File:UI4 E2403.png | 600px]]

== Test Coverage ==
We used SimpleCov to generate a coverage report for the Rspec test cases implemeted for the model and controllers.
The test coverage indicated 1730 lines of code was covered through the testcases.

[[File:Testing E2403.png ‎| 600px]]

== Test Login Credentials ==
* UserId: instructor6
* Password: password

== Demo Video ==
TODO:: 
This is our [https://www.youtube.com/ demo video] which explain how to create courses, assignments, mentored teams and mentored teams with topics. This video also show how to run the tests of our code changes.

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2789

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T01:36:28Z

Slkwiatk: /* Mailer Changes */

== Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project. Instructors have the ability to add new projects, assignments, etc., as well as edit existing ones. Later on, they can view student submissions and grade them. Students can also use Expertiza to organize into teams to work on different projects and assignments and submit their work. They can also review other students' submissions.

== Introduction ==
This project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management/ E2304] for the implementation of the Mentor-meeting management in the Expertiza system for mentored teams. We are now required to add functionality to add mentors to the topics and then assign them to the teams when they pick up that topic.

== Problem Statement ==
The following tasks are required for the project:
#Enhancing Code Clarity: This involves renaming methods from Project 3 with ambiguous names, optimizing loops and adding comments for unclear lines of code
#Reimplement Mentored teams: Reimplement the Mentored team delegate to the Assignment team to reduce complexity and to follow best principles of Object Oriented Design
#Reimplement Sign Up Sheet or Topics: Reimplement the SignUpSheet controller to automatically add the mentor to when a topic is created and automatically assign the same mentor to a team when they choose the topic
#Writing tests for mentor meetings models: More tests have to be written for Mentor Meeting model
#Writing tests for the mentor meetings controller: More tests should be written for Mentor meeting controller
#Writing tests for the signup sheet controller: Additional tests should be written for signup sheet controller to test the new functionality

== Objectives ==
We have 3 main objectives for this project.
* Refactoring of the Mentor-meeting model and controller created for the Project 3
* Reimplementation of Mentored Teams model and controller for the Project 4
* Reimplementation of SignUp Sheet controller for the Project 4 to automatically assign mentors to the topics

== Design Goal ==
While fulfilling all the objectives, the following design rules have to be ensured:
* Validate proper functioning of all existing and anticipated methods, making any required enhancements or adjustments.
* Establish loose coupling and tight cohesion for the model and controller to enhance code organization and maintainability.
* Refactor redundant code in the previous implementation's controller and model methods using DRY principle, eliminating functionality duplication already present in the Expertiza system.
* Confirm the continued effectiveness of existing test cases following the aforementioned modifications and generate additional test cases as per the need.

== Class UML Diagram ==
[[File:OODD Proj4 E2403 - Entity Diagram 2.png ‎| 610px]]

== Classes and Relationships ==
=== Existing Structure ===
* Every Assignment has a Node
* Every Assignment has many AssignmentTeam and MentoredTeam
* AssignmentTeam is inherited from Team
* MentoredTeam is inherited from AssignmentTeam
* Every MentoredTeam has many MentorMeeting
=== Proposed Structure Structure ===
* MentoredTeam to be delegated from AssignmentTeam instead of inheriting from it

== Implementation Plan ==
=== Modify newly created controller, model and view ===
==== mentor_meeting_controller.rb ====
* Edit function names to make them more descriptive
* Add more descriptive comments for the functions
==== mentor_meetings_helper.rb ====
* Move the "get_dates_for_team" function to the model
* Rename the function to make it more descriptive
==== _entry_assignments.html.erb ====
* Add more descriptive comments for the JavaScript functions
* Move the Ruby code from the template to a helper or the controller
==== mentored_team.rb --> mentored_team_decorator ====
* To reduce DRY violations, the mentored team class was changed to the mentored team decorator class.
*

=== Modify existing controller model and view ===
==== teams/_team.html.erb ====
* As the mentored team will now be delegated from the assignment team, we need to change the if condition on the top as we are changing MentoredTeam to be delegated from the AssignmentTeam
==== teams_controller.rb ====
* This file has to be modified to work with the delegated MentoredTeam
* These lines will not work as MentoredTeam will not be a model
[[File:Teams con1.png ‎| 600px]]
==== sign_up_sheet_controller.rb ====
* This controller has to be modified to automatically assign mentors or manually add mentors to the topics when they are created
* This will be followed by a change in schema
[[File:Signup con1.png | 600px]]
==== _topic.html.erb ====
* If we manually have to assign mentors to the topic, we have to include a input field to enter the mentor
[[File:Topic html.png | 600px]]
==== schema.rb ====
* As we are adding a new field to the table, we need to modify the schema
* We need to write 1 migration to add the field to the table to update the schema file
[[File:Schema E2403.png | 600px]]

=== Mailer Changes ===
====team.rb====
* The team model must be altered to use delegation for cases where a team would previously be a mentored team.
====add_member====
* The add member function must be altered such that the call to mail a user is better named, and that it calls directly to the mailer rather than the mailer helper.
[[File:add_member_email.png | 900px]]
====mailer_helper====
* The mailer_helper will be altered such that the send_team_confimration_to_user will be moved and renamed in the Mailer.rb class instead since using generic_message as such is leading to an unclear design.
[[File:team_confirm.png | 900px]]

====mailer.rb====
* A new function to specifically handle messaging users when added to teams will be built in the mailer, rather than just overusing the generic_message function.

== UI Changes ==
=== UI Changes before Phase 2 code changes ===
* The mentored assignment teams page has the modified UI from the Phase 1 as it is also a mentored assignment
* But the teams do not have a TA as the automated assignment of mentors has not been implemented.
[[File:UI1 E2403.png | 600px]]

=== UI Changes after Phase 2 code changes ===
The mentored assignment teams with topic now has the new UI and the automated mentor assignment
* The form to create a new topic has a new field to assign mentor to a topic
[[File:UI2 E2403.png | 600px]]
* The updated UI showing the topics with the mentors and teams that have chosen the topic
* The mentor is also displayed with the team
[[File:UI3 E2403.png | 600px]]
* The assignment teams page has the modified UI from the Phase 1 as the teams have a mentor
[[File:UI4 E2403.png | 600px]]

== Implementation ==
=== Mailer Changes ===
==== Decorator ====
* To remove DRY violations, we transformed the MentoredTeam class into the MentoredTeamDecoratorClass.
[[File:MentoredTeamClass.png | 600px]] ---> [[File:MentoredTeamDecorator.png | 600px]]
* In particular this required changing the MentoredTeam to have its own assignment team variable.
* The add_member function's DRY violations with the Team Class were able to be eliminated here, as now the Mentored Team Decorator calls to the assignment team's add member function on line 14, and then simply calls to assign the mentor on line 16.
==== MailerHelper to Mailer ====
* To increase understandability and consistency between classes, we removed the send_team_confirmation_mail function from the MailerHelper, and instead replaced its functionality with the team_addition_message function in the Mailer class. We found this to be the ideal location as the Mailer class houses many other specific message functions such as notify_grade_conflict_message, suggested_topic_approved_message and more.
[[File:team_confirm.png | 600px]] ---> [[File:Team_Addtion_Message.png | 600px]]
==== Team Add_Member ====
*

== Implementation - To delete later ==
TODO:: 

== Files Modified/Added ==
* app/controllers/sign_up_sheet_controller.rb
* app/controllers/teams_controller.rb
* app/controllers/teams_users_controller.rb
* app/models/course.rb
* app/models/mentor_management.rb
* app/views/sign_up_sheet/_table_header.html.erb
* app/views/sign_up_sheet/_table_line.html.erb
* app/views/sign_up_sheet/_topic.html.erb
* app/views/teams/_team.html.erb
* app/views/tree_display/_page_footer_assignments.html.erb
* app/views/tree_display/_entry_assignments.html.erb
* app/models/mentored_team_decorator.rb
* app/models/team.rb
* app/views/mailer/team_addition_message.html.erb
* app/views/mailer/team_addition_message.text.erb
* app/helpers/mailer_helper.rb
* app/mailers/mailer.rb
* spec/models/team_spec.rb
* spec/models/mentor_management_spec.rb

== Test Plan ==
When the project was pulled from the main repository, there are not enough tests to cover the additional functionalities that we added. We are planning on using the test skeletons by Mustafa Olmez, as a reference to how and what kind of tests should be written. Test cases for mentor management were already written and we wrote new test cases for the new functionalities we added. Here are the four test case scenarios we covered and the actual ruby code for the Rspec tests

=== Automated Rspec Testing Scenarios===
1. Test scenario 1: Given an assignment_id, When there are multiple mentors with different team counts for the assignment, Then it should return the mentor with the lowest team count
it "returns the mentor with the lowest team count for the given assignment" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 2]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

2. Test scenario 2: Given an assignment_id, When there is only one mentor available for the assignment, Then it should return that mentor
it "should return that mentor if there's only one available" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 0]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

3. Test scenario 3: Given an assignment_id, When there are multiple mentors with the same lowest team count for the assignment, Then it should return the first mentor in the list
it "returns the first mentor in the list if there's a tie for lowest team count" do
# Arrange
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 1],])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

4. Test scenario 4: Given an assignment_id, When there are no mentors available for the assignment, Then it should return nil
it "returns nil" do
# Create a new assignment
a = FactoryBot.create(:assignment, id: 997, directory_path: 'OSS_project', auto_assign_mentor: true)
# Since there are no mentors associated with this assignment, should return nil
expect(MentorManagement.select_mentor(a.id)).to eq nil
end

=== Manual UI Testing ===
Apart from the automated Rspec tests, we are providing manual testing cases that can be used to verify the functioning of the website.

Refer to the demo video on the bottom of the page to find help on testing these cases

==== Scenario 1 - Creating an mentored team ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Courses
# Assuming you have created a course and added participants to it, proceed to create a team
# Make sure "Auto assign mentors when team hits > 50% capacity?" option is checked
[[File:MT 1-1.png | 600px]]
* Create team for the assignment and you can see that the team with more than 50% capacity gets a mentor assigned automatically
[[File:MT 1-2.png | 600px]]

==== Scenario 2 - Adding, editing, deleting mentor meeting dates ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Assigments
# Assuming you have created a mentored assignment and added participants to it, proceed to the teams page
# Try entering dates into it teams row and the date should persist
# You can edit and delete the dates from the rows
# Team with less than 50% capacity will have the mentor meeting dates disabled
[[File:MT 2.png | 600px]]

==== Scenario 3 - Creating a team with topic ====
* Log into Expertiza using the test credential and navigate to the home page
* Go to Manage > Courses
* Assuming you have created a course and added participants to it, proceed to create a team
* Make sure "Has topics?" option is checked and a topic is created using the Topics tab
[[File:MT 3-1.png | 600px]]
* Create a new topic for the assignment and enter a mentor name to the topic
[[File:UI2 E2403.png | 600px]]
* When a student is added to the topic, the team of the student along with the mentor will be displayed in the topic row
[[File:UI3 E2403.png | 600px]]
* When navigating to the teams page of that assignment, you can see a mentor assigned automatically
[[File:UI4 E2403.png | 600px]]

== Test Coverage ==
We used SimpleCov to generate a coverage report for the Rspec test cases implemeted for the model and controllers.
The test coverage indicated 1730 lines of code was covered through the testcases.

[[File:Testing E2403.png ‎| 600px]]

== Test Login Credentials ==
* UserId: instructor6
* Password: password

== Demo Video ==
TODO:: 
This is our [https://www.youtube.com/ demo video] which explain how to create courses, assignments, mentored teams and mentored teams with topics. This video also show how to run the tests of our code changes.

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2789

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T01:34:59Z

Slkwiatk: /* MailerHelper to Mailer */

== Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project. Instructors have the ability to add new projects, assignments, etc., as well as edit existing ones. Later on, they can view student submissions and grade them. Students can also use Expertiza to organize into teams to work on different projects and assignments and submit their work. They can also review other students' submissions.

== Introduction ==
This project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management/ E2304] for the implementation of the Mentor-meeting management in the Expertiza system for mentored teams. We are now required to add functionality to add mentors to the topics and then assign them to the teams when they pick up that topic.

== Problem Statement ==
The following tasks are required for the project:
#Enhancing Code Clarity: This involves renaming methods from Project 3 with ambiguous names, optimizing loops and adding comments for unclear lines of code
#Reimplement Mentored teams: Reimplement the Mentored team delegate to the Assignment team to reduce complexity and to follow best principles of Object Oriented Design
#Reimplement Sign Up Sheet or Topics: Reimplement the SignUpSheet controller to automatically add the mentor to when a topic is created and automatically assign the same mentor to a team when they choose the topic
#Writing tests for mentor meetings models: More tests have to be written for Mentor Meeting model
#Writing tests for the mentor meetings controller: More tests should be written for Mentor meeting controller
#Writing tests for the signup sheet controller: Additional tests should be written for signup sheet controller to test the new functionality

== Objectives ==
We have 3 main objectives for this project.
* Refactoring of the Mentor-meeting model and controller created for the Project 3
* Reimplementation of Mentored Teams model and controller for the Project 4
* Reimplementation of SignUp Sheet controller for the Project 4 to automatically assign mentors to the topics

== Design Goal ==
While fulfilling all the objectives, the following design rules have to be ensured:
* Validate proper functioning of all existing and anticipated methods, making any required enhancements or adjustments.
* Establish loose coupling and tight cohesion for the model and controller to enhance code organization and maintainability.
* Refactor redundant code in the previous implementation's controller and model methods using DRY principle, eliminating functionality duplication already present in the Expertiza system.
* Confirm the continued effectiveness of existing test cases following the aforementioned modifications and generate additional test cases as per the need.

== Class UML Diagram ==
[[File:OODD Proj4 E2403 - Entity Diagram 2.png ‎| 610px]]

== Classes and Relationships ==
=== Existing Structure ===
* Every Assignment has a Node
* Every Assignment has many AssignmentTeam and MentoredTeam
* AssignmentTeam is inherited from Team
* MentoredTeam is inherited from AssignmentTeam
* Every MentoredTeam has many MentorMeeting
=== Proposed Structure Structure ===
* MentoredTeam to be delegated from AssignmentTeam instead of inheriting from it

== Implementation Plan ==
=== Modify newly created controller, model and view ===
==== mentor_meeting_controller.rb ====
* Edit function names to make them more descriptive
* Add more descriptive comments for the functions
==== mentor_meetings_helper.rb ====
* Move the "get_dates_for_team" function to the model
* Rename the function to make it more descriptive
==== _entry_assignments.html.erb ====
* Add more descriptive comments for the JavaScript functions
* Move the Ruby code from the template to a helper or the controller
==== mentored_team.rb --> mentored_team_decorator ====
* To reduce DRY violations, the mentored team class was changed to the mentored team decorator class.
*

=== Modify existing controller model and view ===
==== teams/_team.html.erb ====
* As the mentored team will now be delegated from the assignment team, we need to change the if condition on the top as we are changing MentoredTeam to be delegated from the AssignmentTeam
==== teams_controller.rb ====
* This file has to be modified to work with the delegated MentoredTeam
* These lines will not work as MentoredTeam will not be a model
[[File:Teams con1.png ‎| 600px]]
==== sign_up_sheet_controller.rb ====
* This controller has to be modified to automatically assign mentors or manually add mentors to the topics when they are created
* This will be followed by a change in schema
[[File:Signup con1.png | 600px]]
==== _topic.html.erb ====
* If we manually have to assign mentors to the topic, we have to include a input field to enter the mentor
[[File:Topic html.png | 600px]]
==== schema.rb ====
* As we are adding a new field to the table, we need to modify the schema
* We need to write 1 migration to add the field to the table to update the schema file
[[File:Schema E2403.png | 600px]]

=== Mailer Changes ===
====team.rb====
* The team model must be altered to use delegation for cases where a team would previously be a mentored team.
====add_member====
* The add member function must be altered such that the call to mail a user is better named, and that it calls directly to the mailer rather than the mailer helper.
[[File:add_member_email.png | 900px]]
====mailer_helper====
* The mailer_helper will be altered such that the send_team_confimration_to_user will be moved and renamed in the Mailer.rb class instead since using generic_message as such is leading to an unclear design.
[[File:team_confirm.png | 900px]]

====mailer.rb====
* A new function to specifically handle messaging users when added to teams will be built in the mailer, rather than just overusing the generic_message function.

== UI Changes ==
=== UI Changes before Phase 2 code changes ===
* The mentored assignment teams page has the modified UI from the Phase 1 as it is also a mentored assignment
* But the teams do not have a TA as the automated assignment of mentors has not been implemented.
[[File:UI1 E2403.png | 600px]]

=== UI Changes after Phase 2 code changes ===
The mentored assignment teams with topic now has the new UI and the automated mentor assignment
* The form to create a new topic has a new field to assign mentor to a topic
[[File:UI2 E2403.png | 600px]]
* The updated UI showing the topics with the mentors and teams that have chosen the topic
* The mentor is also displayed with the team
[[File:UI3 E2403.png | 600px]]
* The assignment teams page has the modified UI from the Phase 1 as the teams have a mentor
[[File:UI4 E2403.png | 600px]]

== Implementation ==
=== Mailer Changes ===
==== Decorator ====
* To remove DRY violations, we transformed the MentoredTeam class into the MentoredTeamDecoratorClass.
[[File:MentoredTeamClass.png | 600px]] ---> [[File:MentoredTeamDecorator.png | 600px]]
* In particular this required changing the MentoredTeam to have its own assignment team variable.
* The add_member function's DRY violations with the Team Class were able to be eliminated here, as now the Mentored Team Decorator calls to the assignment team's add member function on line 14, and then simply calls to assign the mentor on line 16.
==== MailerHelper to Mailer ====
* To increase understandability and consistency between classes, we removed the send_team_confirmation_mail function from the MailerHelper, and instead replaced its functionality with the team_addition_message function in the Mailer class. We found this to be the ideal location as the Mailer class houses many other specific message functions such as notify_grade_conflict_message, suggested_topic_approved_message and more.
[[File:team_confirm.png | 600px]] ---> [[File:Team_Addtion_Message.png | 600px]]

== Implementation - To delete later ==
TODO:: 

== Files Modified/Added ==
* app/controllers/sign_up_sheet_controller.rb
* app/controllers/teams_controller.rb
* app/controllers/teams_users_controller.rb
* app/models/course.rb
* app/models/mentor_management.rb
* app/views/sign_up_sheet/_table_header.html.erb
* app/views/sign_up_sheet/_table_line.html.erb
* app/views/sign_up_sheet/_topic.html.erb
* app/views/teams/_team.html.erb
* app/views/tree_display/_page_footer_assignments.html.erb
* app/views/tree_display/_entry_assignments.html.erb
* app/models/mentored_team_decorator.rb
* app/models/team.rb
* app/views/mailer/team_addition_message.html.erb
* app/views/mailer/team_addition_message.text.erb
* app/helpers/mailer_helper.rb
* app/mailers/mailer.rb
* spec/models/team_spec.rb
* spec/models/mentor_management_spec.rb

== Test Plan ==
When the project was pulled from the main repository, there are not enough tests to cover the additional functionalities that we added. We are planning on using the test skeletons by Mustafa Olmez, as a reference to how and what kind of tests should be written. Test cases for mentor management were already written and we wrote new test cases for the new functionalities we added. Here are the four test case scenarios we covered and the actual ruby code for the Rspec tests

=== Automated Rspec Testing Scenarios===
1. Test scenario 1: Given an assignment_id, When there are multiple mentors with different team counts for the assignment, Then it should return the mentor with the lowest team count
it "returns the mentor with the lowest team count for the given assignment" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 2]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

2. Test scenario 2: Given an assignment_id, When there is only one mentor available for the assignment, Then it should return that mentor
it "should return that mentor if there's only one available" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 0]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

3. Test scenario 3: Given an assignment_id, When there are multiple mentors with the same lowest team count for the assignment, Then it should return the first mentor in the list
it "returns the first mentor in the list if there's a tie for lowest team count" do
# Arrange
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 1],])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

4. Test scenario 4: Given an assignment_id, When there are no mentors available for the assignment, Then it should return nil
it "returns nil" do
# Create a new assignment
a = FactoryBot.create(:assignment, id: 997, directory_path: 'OSS_project', auto_assign_mentor: true)
# Since there are no mentors associated with this assignment, should return nil
expect(MentorManagement.select_mentor(a.id)).to eq nil
end

=== Manual UI Testing ===
Apart from the automated Rspec tests, we are providing manual testing cases that can be used to verify the functioning of the website.

Refer to the demo video on the bottom of the page to find help on testing these cases

==== Scenario 1 - Creating an mentored team ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Courses
# Assuming you have created a course and added participants to it, proceed to create a team
# Make sure "Auto assign mentors when team hits > 50% capacity?" option is checked
[[File:MT 1-1.png | 600px]]
* Create team for the assignment and you can see that the team with more than 50% capacity gets a mentor assigned automatically
[[File:MT 1-2.png | 600px]]

==== Scenario 2 - Adding, editing, deleting mentor meeting dates ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Assigments
# Assuming you have created a mentored assignment and added participants to it, proceed to the teams page
# Try entering dates into it teams row and the date should persist
# You can edit and delete the dates from the rows
# Team with less than 50% capacity will have the mentor meeting dates disabled
[[File:MT 2.png | 600px]]

==== Scenario 3 - Creating a team with topic ====
* Log into Expertiza using the test credential and navigate to the home page
* Go to Manage > Courses
* Assuming you have created a course and added participants to it, proceed to create a team
* Make sure "Has topics?" option is checked and a topic is created using the Topics tab
[[File:MT 3-1.png | 600px]]
* Create a new topic for the assignment and enter a mentor name to the topic
[[File:UI2 E2403.png | 600px]]
* When a student is added to the topic, the team of the student along with the mentor will be displayed in the topic row
[[File:UI3 E2403.png | 600px]]
* When navigating to the teams page of that assignment, you can see a mentor assigned automatically
[[File:UI4 E2403.png | 600px]]

== Test Coverage ==
We used SimpleCov to generate a coverage report for the Rspec test cases implemeted for the model and controllers.
The test coverage indicated 1730 lines of code was covered through the testcases.

[[File:Testing E2403.png ‎| 600px]]

== Test Login Credentials ==
* UserId: instructor6
* Password: password

== Demo Video ==
TODO:: 
This is our [https://www.youtube.com/ demo video] which explain how to create courses, assignments, mentored teams and mentored teams with topics. This video also show how to run the tests of our code changes.

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2789

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T01:34:14Z

Slkwiatk: /* MailerHelper to Mailer */

== Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project. Instructors have the ability to add new projects, assignments, etc., as well as edit existing ones. Later on, they can view student submissions and grade them. Students can also use Expertiza to organize into teams to work on different projects and assignments and submit their work. They can also review other students' submissions.

== Introduction ==
This project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management/ E2304] for the implementation of the Mentor-meeting management in the Expertiza system for mentored teams. We are now required to add functionality to add mentors to the topics and then assign them to the teams when they pick up that topic.

== Problem Statement ==
The following tasks are required for the project:
#Enhancing Code Clarity: This involves renaming methods from Project 3 with ambiguous names, optimizing loops and adding comments for unclear lines of code
#Reimplement Mentored teams: Reimplement the Mentored team delegate to the Assignment team to reduce complexity and to follow best principles of Object Oriented Design
#Reimplement Sign Up Sheet or Topics: Reimplement the SignUpSheet controller to automatically add the mentor to when a topic is created and automatically assign the same mentor to a team when they choose the topic
#Writing tests for mentor meetings models: More tests have to be written for Mentor Meeting model
#Writing tests for the mentor meetings controller: More tests should be written for Mentor meeting controller
#Writing tests for the signup sheet controller: Additional tests should be written for signup sheet controller to test the new functionality

== Objectives ==
We have 3 main objectives for this project.
* Refactoring of the Mentor-meeting model and controller created for the Project 3
* Reimplementation of Mentored Teams model and controller for the Project 4
* Reimplementation of SignUp Sheet controller for the Project 4 to automatically assign mentors to the topics

== Design Goal ==
While fulfilling all the objectives, the following design rules have to be ensured:
* Validate proper functioning of all existing and anticipated methods, making any required enhancements or adjustments.
* Establish loose coupling and tight cohesion for the model and controller to enhance code organization and maintainability.
* Refactor redundant code in the previous implementation's controller and model methods using DRY principle, eliminating functionality duplication already present in the Expertiza system.
* Confirm the continued effectiveness of existing test cases following the aforementioned modifications and generate additional test cases as per the need.

== Class UML Diagram ==
[[File:OODD Proj4 E2403 - Entity Diagram 2.png ‎| 610px]]

== Classes and Relationships ==
=== Existing Structure ===
* Every Assignment has a Node
* Every Assignment has many AssignmentTeam and MentoredTeam
* AssignmentTeam is inherited from Team
* MentoredTeam is inherited from AssignmentTeam
* Every MentoredTeam has many MentorMeeting
=== Proposed Structure Structure ===
* MentoredTeam to be delegated from AssignmentTeam instead of inheriting from it

== Implementation Plan ==
=== Modify newly created controller, model and view ===
==== mentor_meeting_controller.rb ====
* Edit function names to make them more descriptive
* Add more descriptive comments for the functions
==== mentor_meetings_helper.rb ====
* Move the "get_dates_for_team" function to the model
* Rename the function to make it more descriptive
==== _entry_assignments.html.erb ====
* Add more descriptive comments for the JavaScript functions
* Move the Ruby code from the template to a helper or the controller
==== mentored_team.rb --> mentored_team_decorator ====
* To reduce DRY violations, the mentored team class was changed to the mentored team decorator class.
*

=== Modify existing controller model and view ===
==== teams/_team.html.erb ====
* As the mentored team will now be delegated from the assignment team, we need to change the if condition on the top as we are changing MentoredTeam to be delegated from the AssignmentTeam
==== teams_controller.rb ====
* This file has to be modified to work with the delegated MentoredTeam
* These lines will not work as MentoredTeam will not be a model
[[File:Teams con1.png ‎| 600px]]
==== sign_up_sheet_controller.rb ====
* This controller has to be modified to automatically assign mentors or manually add mentors to the topics when they are created
* This will be followed by a change in schema
[[File:Signup con1.png | 600px]]
==== _topic.html.erb ====
* If we manually have to assign mentors to the topic, we have to include a input field to enter the mentor
[[File:Topic html.png | 600px]]
==== schema.rb ====
* As we are adding a new field to the table, we need to modify the schema
* We need to write 1 migration to add the field to the table to update the schema file
[[File:Schema E2403.png | 600px]]

=== Mailer Changes ===
====team.rb====
* The team model must be altered to use delegation for cases where a team would previously be a mentored team.
====add_member====
* The add member function must be altered such that the call to mail a user is better named, and that it calls directly to the mailer rather than the mailer helper.
[[File:add_member_email.png | 900px]]
====mailer_helper====
* The mailer_helper will be altered such that the send_team_confimration_to_user will be moved and renamed in the Mailer.rb class instead since using generic_message as such is leading to an unclear design.
[[File:team_confirm.png | 900px]]

====mailer.rb====
* A new function to specifically handle messaging users when added to teams will be built in the mailer, rather than just overusing the generic_message function.

== UI Changes ==
=== UI Changes before Phase 2 code changes ===
* The mentored assignment teams page has the modified UI from the Phase 1 as it is also a mentored assignment
* But the teams do not have a TA as the automated assignment of mentors has not been implemented.
[[File:UI1 E2403.png | 600px]]

=== UI Changes after Phase 2 code changes ===
The mentored assignment teams with topic now has the new UI and the automated mentor assignment
* The form to create a new topic has a new field to assign mentor to a topic
[[File:UI2 E2403.png | 600px]]
* The updated UI showing the topics with the mentors and teams that have chosen the topic
* The mentor is also displayed with the team
[[File:UI3 E2403.png | 600px]]
* The assignment teams page has the modified UI from the Phase 1 as the teams have a mentor
[[File:UI4 E2403.png | 600px]]

== Implementation ==
=== Mailer Changes ===
==== Decorator ====
* To remove DRY violations, we transformed the MentoredTeam class into the MentoredTeamDecoratorClass.
[[File:MentoredTeamClass.png | 600px]] ---> [[File:MentoredTeamDecorator.png | 600px]]
* In particular this required changing the MentoredTeam to have its own assignment team variable.
* The add_member function's DRY violations with the Team Class were able to be eliminated here, as now the Mentored Team Decorator calls to the assignment team's add member function on line 14, and then simply calls to assign the mentor on line 16.
==== MailerHelper to Mailer ====
* To increase understandability and consistency between classes, we removed the send_team_confirmation_mail function from the MailerHelper, and instead replaced its functionality with the team_addition_message function in the Mailer class. We found this to be the ideal location as the Mailer class houses many other specific message functions such as notify_grade_conflict_message, suggested_topic_approved_message and more.
[[File:team_confirm.png | 600px]] ---> [[File:Team_Addition_Message.png | 600px]]

== Implementation - To delete later ==
TODO:: 

== Files Modified/Added ==
* app/controllers/sign_up_sheet_controller.rb
* app/controllers/teams_controller.rb
* app/controllers/teams_users_controller.rb
* app/models/course.rb
* app/models/mentor_management.rb
* app/views/sign_up_sheet/_table_header.html.erb
* app/views/sign_up_sheet/_table_line.html.erb
* app/views/sign_up_sheet/_topic.html.erb
* app/views/teams/_team.html.erb
* app/views/tree_display/_page_footer_assignments.html.erb
* app/views/tree_display/_entry_assignments.html.erb
* app/models/mentored_team_decorator.rb
* app/models/team.rb
* app/views/mailer/team_addition_message.html.erb
* app/views/mailer/team_addition_message.text.erb
* app/helpers/mailer_helper.rb
* app/mailers/mailer.rb
* spec/models/team_spec.rb
* spec/models/mentor_management_spec.rb

== Test Plan ==
When the project was pulled from the main repository, there are not enough tests to cover the additional functionalities that we added. We are planning on using the test skeletons by Mustafa Olmez, as a reference to how and what kind of tests should be written. Test cases for mentor management were already written and we wrote new test cases for the new functionalities we added. Here are the four test case scenarios we covered and the actual ruby code for the Rspec tests

=== Automated Rspec Testing Scenarios===
1. Test scenario 1: Given an assignment_id, When there are multiple mentors with different team counts for the assignment, Then it should return the mentor with the lowest team count
it "returns the mentor with the lowest team count for the given assignment" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 2]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

2. Test scenario 2: Given an assignment_id, When there is only one mentor available for the assignment, Then it should return that mentor
it "should return that mentor if there's only one available" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 0]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

3. Test scenario 3: Given an assignment_id, When there are multiple mentors with the same lowest team count for the assignment, Then it should return the first mentor in the list
it "returns the first mentor in the list if there's a tie for lowest team count" do
# Arrange
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 1],])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

4. Test scenario 4: Given an assignment_id, When there are no mentors available for the assignment, Then it should return nil
it "returns nil" do
# Create a new assignment
a = FactoryBot.create(:assignment, id: 997, directory_path: 'OSS_project', auto_assign_mentor: true)
# Since there are no mentors associated with this assignment, should return nil
expect(MentorManagement.select_mentor(a.id)).to eq nil
end

=== Manual UI Testing ===
Apart from the automated Rspec tests, we are providing manual testing cases that can be used to verify the functioning of the website.

Refer to the demo video on the bottom of the page to find help on testing these cases

==== Scenario 1 - Creating an mentored team ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Courses
# Assuming you have created a course and added participants to it, proceed to create a team
# Make sure "Auto assign mentors when team hits > 50% capacity?" option is checked
[[File:MT 1-1.png | 600px]]
* Create team for the assignment and you can see that the team with more than 50% capacity gets a mentor assigned automatically
[[File:MT 1-2.png | 600px]]

==== Scenario 2 - Adding, editing, deleting mentor meeting dates ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Assigments
# Assuming you have created a mentored assignment and added participants to it, proceed to the teams page
# Try entering dates into it teams row and the date should persist
# You can edit and delete the dates from the rows
# Team with less than 50% capacity will have the mentor meeting dates disabled
[[File:MT 2.png | 600px]]

==== Scenario 3 - Creating a team with topic ====
* Log into Expertiza using the test credential and navigate to the home page
* Go to Manage > Courses
* Assuming you have created a course and added participants to it, proceed to create a team
* Make sure "Has topics?" option is checked and a topic is created using the Topics tab
[[File:MT 3-1.png | 600px]]
* Create a new topic for the assignment and enter a mentor name to the topic
[[File:UI2 E2403.png | 600px]]
* When a student is added to the topic, the team of the student along with the mentor will be displayed in the topic row
[[File:UI3 E2403.png | 600px]]
* When navigating to the teams page of that assignment, you can see a mentor assigned automatically
[[File:UI4 E2403.png | 600px]]

== Test Coverage ==
We used SimpleCov to generate a coverage report for the Rspec test cases implemeted for the model and controllers.
The test coverage indicated 1730 lines of code was covered through the testcases.

[[File:Testing E2403.png ‎| 600px]]

== Test Login Credentials ==
* UserId: instructor6
* Password: password

== Demo Video ==
TODO:: 
This is our [https://www.youtube.com/ demo video] which explain how to create courses, assignments, mentored teams and mentored teams with topics. This video also show how to run the tests of our code changes.

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2789

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

File:Team Addtion Message.png

2024-04-24T01:33:42Z

Slkwiatk:

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T01:33:15Z

Slkwiatk: /* MailerHelper to Mailer */

== Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project. Instructors have the ability to add new projects, assignments, etc., as well as edit existing ones. Later on, they can view student submissions and grade them. Students can also use Expertiza to organize into teams to work on different projects and assignments and submit their work. They can also review other students' submissions.

== Introduction ==
This project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management/ E2304] for the implementation of the Mentor-meeting management in the Expertiza system for mentored teams. We are now required to add functionality to add mentors to the topics and then assign them to the teams when they pick up that topic.

== Problem Statement ==
The following tasks are required for the project:
#Enhancing Code Clarity: This involves renaming methods from Project 3 with ambiguous names, optimizing loops and adding comments for unclear lines of code
#Reimplement Mentored teams: Reimplement the Mentored team delegate to the Assignment team to reduce complexity and to follow best principles of Object Oriented Design
#Reimplement Sign Up Sheet or Topics: Reimplement the SignUpSheet controller to automatically add the mentor to when a topic is created and automatically assign the same mentor to a team when they choose the topic
#Writing tests for mentor meetings models: More tests have to be written for Mentor Meeting model
#Writing tests for the mentor meetings controller: More tests should be written for Mentor meeting controller
#Writing tests for the signup sheet controller: Additional tests should be written for signup sheet controller to test the new functionality

== Objectives ==
We have 3 main objectives for this project.
* Refactoring of the Mentor-meeting model and controller created for the Project 3
* Reimplementation of Mentored Teams model and controller for the Project 4
* Reimplementation of SignUp Sheet controller for the Project 4 to automatically assign mentors to the topics

== Design Goal ==
While fulfilling all the objectives, the following design rules have to be ensured:
* Validate proper functioning of all existing and anticipated methods, making any required enhancements or adjustments.
* Establish loose coupling and tight cohesion for the model and controller to enhance code organization and maintainability.
* Refactor redundant code in the previous implementation's controller and model methods using DRY principle, eliminating functionality duplication already present in the Expertiza system.
* Confirm the continued effectiveness of existing test cases following the aforementioned modifications and generate additional test cases as per the need.

== Class UML Diagram ==
[[File:OODD Proj4 E2403 - Entity Diagram 2.png ‎| 610px]]

== Classes and Relationships ==
=== Existing Structure ===
* Every Assignment has a Node
* Every Assignment has many AssignmentTeam and MentoredTeam
* AssignmentTeam is inherited from Team
* MentoredTeam is inherited from AssignmentTeam
* Every MentoredTeam has many MentorMeeting
=== Proposed Structure Structure ===
* MentoredTeam to be delegated from AssignmentTeam instead of inheriting from it

== Implementation Plan ==
=== Modify newly created controller, model and view ===
==== mentor_meeting_controller.rb ====
* Edit function names to make them more descriptive
* Add more descriptive comments for the functions
==== mentor_meetings_helper.rb ====
* Move the "get_dates_for_team" function to the model
* Rename the function to make it more descriptive
==== _entry_assignments.html.erb ====
* Add more descriptive comments for the JavaScript functions
* Move the Ruby code from the template to a helper or the controller
==== mentored_team.rb --> mentored_team_decorator ====
* To reduce DRY violations, the mentored team class was changed to the mentored team decorator class.
*

=== Modify existing controller model and view ===
==== teams/_team.html.erb ====
* As the mentored team will now be delegated from the assignment team, we need to change the if condition on the top as we are changing MentoredTeam to be delegated from the AssignmentTeam
==== teams_controller.rb ====
* This file has to be modified to work with the delegated MentoredTeam
* These lines will not work as MentoredTeam will not be a model
[[File:Teams con1.png ‎| 600px]]
==== sign_up_sheet_controller.rb ====
* This controller has to be modified to automatically assign mentors or manually add mentors to the topics when they are created
* This will be followed by a change in schema
[[File:Signup con1.png | 600px]]
==== _topic.html.erb ====
* If we manually have to assign mentors to the topic, we have to include a input field to enter the mentor
[[File:Topic html.png | 600px]]
==== schema.rb ====
* As we are adding a new field to the table, we need to modify the schema
* We need to write 1 migration to add the field to the table to update the schema file
[[File:Schema E2403.png | 600px]]

=== Mailer Changes ===
====team.rb====
* The team model must be altered to use delegation for cases where a team would previously be a mentored team.
====add_member====
* The add member function must be altered such that the call to mail a user is better named, and that it calls directly to the mailer rather than the mailer helper.
[[File:add_member_email.png | 900px]]
====mailer_helper====
* The mailer_helper will be altered such that the send_team_confimration_to_user will be moved and renamed in the Mailer.rb class instead since using generic_message as such is leading to an unclear design.
[[File:team_confirm.png | 900px]]

====mailer.rb====
* A new function to specifically handle messaging users when added to teams will be built in the mailer, rather than just overusing the generic_message function.

== UI Changes ==
=== UI Changes before Phase 2 code changes ===
* The mentored assignment teams page has the modified UI from the Phase 1 as it is also a mentored assignment
* But the teams do not have a TA as the automated assignment of mentors has not been implemented.
[[File:UI1 E2403.png | 600px]]

=== UI Changes after Phase 2 code changes ===
The mentored assignment teams with topic now has the new UI and the automated mentor assignment
* The form to create a new topic has a new field to assign mentor to a topic
[[File:UI2 E2403.png | 600px]]
* The updated UI showing the topics with the mentors and teams that have chosen the topic
* The mentor is also displayed with the team
[[File:UI3 E2403.png | 600px]]
* The assignment teams page has the modified UI from the Phase 1 as the teams have a mentor
[[File:UI4 E2403.png | 600px]]

== Implementation ==
=== Mailer Changes ===
==== Decorator ====
* To remove DRY violations, we transformed the MentoredTeam class into the MentoredTeamDecoratorClass.
[[File:MentoredTeamClass.png | 600px]] ---> [[File:MentoredTeamDecorator.png | 600px]]
* In particular this required changing the MentoredTeam to have its own assignment team variable.
* The add_member function's DRY violations with the Team Class were able to be eliminated here, as now the Mentored Team Decorator calls to the assignment team's add member function on line 14, and then simply calls to assign the mentor on line 16.
==== MailerHelper to Mailer ====
* To increase understandability and consistency between classes, we removed the send_team_confirmation_mail function from the MailerHelper, and instead replaced its functionality with the team_addition_message function in the Mailer class. We found this to be the ideal location as the Mailer class houses many other specific message functions such as notify_grade_conflict_message, suggested_topic_approved_message and more.
[[File:team_confirm.png | 600px]] ---> [[File:Team_Addition_Message | 600px]]

== Implementation - To delete later ==
TODO:: 

== Files Modified/Added ==
* app/controllers/sign_up_sheet_controller.rb
* app/controllers/teams_controller.rb
* app/controllers/teams_users_controller.rb
* app/models/course.rb
* app/models/mentor_management.rb
* app/views/sign_up_sheet/_table_header.html.erb
* app/views/sign_up_sheet/_table_line.html.erb
* app/views/sign_up_sheet/_topic.html.erb
* app/views/teams/_team.html.erb
* app/views/tree_display/_page_footer_assignments.html.erb
* app/views/tree_display/_entry_assignments.html.erb
* app/models/mentored_team_decorator.rb
* app/models/team.rb
* app/views/mailer/team_addition_message.html.erb
* app/views/mailer/team_addition_message.text.erb
* app/helpers/mailer_helper.rb
* app/mailers/mailer.rb
* spec/models/team_spec.rb
* spec/models/mentor_management_spec.rb

== Test Plan ==
When the project was pulled from the main repository, there are not enough tests to cover the additional functionalities that we added. We are planning on using the test skeletons by Mustafa Olmez, as a reference to how and what kind of tests should be written. Test cases for mentor management were already written and we wrote new test cases for the new functionalities we added. Here are the four test case scenarios we covered and the actual ruby code for the Rspec tests

=== Automated Rspec Testing Scenarios===
1. Test scenario 1: Given an assignment_id, When there are multiple mentors with different team counts for the assignment, Then it should return the mentor with the lowest team count
it "returns the mentor with the lowest team count for the given assignment" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 2]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

2. Test scenario 2: Given an assignment_id, When there is only one mentor available for the assignment, Then it should return that mentor
it "should return that mentor if there's only one available" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 0]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

3. Test scenario 3: Given an assignment_id, When there are multiple mentors with the same lowest team count for the assignment, Then it should return the first mentor in the list
it "returns the first mentor in the list if there's a tie for lowest team count" do
# Arrange
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 1],])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

4. Test scenario 4: Given an assignment_id, When there are no mentors available for the assignment, Then it should return nil
it "returns nil" do
# Create a new assignment
a = FactoryBot.create(:assignment, id: 997, directory_path: 'OSS_project', auto_assign_mentor: true)
# Since there are no mentors associated with this assignment, should return nil
expect(MentorManagement.select_mentor(a.id)).to eq nil
end

=== Manual UI Testing ===
Apart from the automated Rspec tests, we are providing manual testing cases that can be used to verify the functioning of the website.

Refer to the demo video on the bottom of the page to find help on testing these cases

==== Scenario 1 - Creating an mentored team ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Courses
# Assuming you have created a course and added participants to it, proceed to create a team
# Make sure "Auto assign mentors when team hits > 50% capacity?" option is checked
[[File:MT 1-1.png | 600px]]
* Create team for the assignment and you can see that the team with more than 50% capacity gets a mentor assigned automatically
[[File:MT 1-2.png | 600px]]

==== Scenario 2 - Adding, editing, deleting mentor meeting dates ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Assigments
# Assuming you have created a mentored assignment and added participants to it, proceed to the teams page
# Try entering dates into it teams row and the date should persist
# You can edit and delete the dates from the rows
# Team with less than 50% capacity will have the mentor meeting dates disabled
[[File:MT 2.png | 600px]]

==== Scenario 3 - Creating a team with topic ====
* Log into Expertiza using the test credential and navigate to the home page
* Go to Manage > Courses
* Assuming you have created a course and added participants to it, proceed to create a team
* Make sure "Has topics?" option is checked and a topic is created using the Topics tab
[[File:MT 3-1.png | 600px]]
* Create a new topic for the assignment and enter a mentor name to the topic
[[File:UI2 E2403.png | 600px]]
* When a student is added to the topic, the team of the student along with the mentor will be displayed in the topic row
[[File:UI3 E2403.png | 600px]]
* When navigating to the teams page of that assignment, you can see a mentor assigned automatically
[[File:UI4 E2403.png | 600px]]

== Test Coverage ==
We used SimpleCov to generate a coverage report for the Rspec test cases implemeted for the model and controllers.
The test coverage indicated 1730 lines of code was covered through the testcases.

[[File:Testing E2403.png ‎| 600px]]

== Test Login Credentials ==
* UserId: instructor6
* Password: password

== Demo Video ==
TODO:: 
This is our [https://www.youtube.com/ demo video] which explain how to create courses, assignments, mentored teams and mentored teams with topics. This video also show how to run the tests of our code changes.

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2789

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T01:29:46Z

Slkwiatk: /* Mailer Changes */

== Expertiza ==

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project. Instructors have the ability to add new projects, assignments, etc., as well as edit existing ones. Later on, they can view student submissions and grade them. Students can also use Expertiza to organize into teams to work on different projects and assignments and submit their work. They can also review other students' submissions.

== Introduction ==
This project is the continuation of [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management/ E2304] for the implementation of the Mentor-meeting management in the Expertiza system for mentored teams. We are now required to add functionality to add mentors to the topics and then assign them to the teams when they pick up that topic.

== Problem Statement ==
The following tasks are required for the project:
#Enhancing Code Clarity: This involves renaming methods from Project 3 with ambiguous names, optimizing loops and adding comments for unclear lines of code
#Reimplement Mentored teams: Reimplement the Mentored team delegate to the Assignment team to reduce complexity and to follow best principles of Object Oriented Design
#Reimplement Sign Up Sheet or Topics: Reimplement the SignUpSheet controller to automatically add the mentor to when a topic is created and automatically assign the same mentor to a team when they choose the topic
#Writing tests for mentor meetings models: More tests have to be written for Mentor Meeting model
#Writing tests for the mentor meetings controller: More tests should be written for Mentor meeting controller
#Writing tests for the signup sheet controller: Additional tests should be written for signup sheet controller to test the new functionality

== Objectives ==
We have 3 main objectives for this project.
* Refactoring of the Mentor-meeting model and controller created for the Project 3
* Reimplementation of Mentored Teams model and controller for the Project 4
* Reimplementation of SignUp Sheet controller for the Project 4 to automatically assign mentors to the topics

== Design Goal ==
While fulfilling all the objectives, the following design rules have to be ensured:
* Validate proper functioning of all existing and anticipated methods, making any required enhancements or adjustments.
* Establish loose coupling and tight cohesion for the model and controller to enhance code organization and maintainability.
* Refactor redundant code in the previous implementation's controller and model methods using DRY principle, eliminating functionality duplication already present in the Expertiza system.
* Confirm the continued effectiveness of existing test cases following the aforementioned modifications and generate additional test cases as per the need.

== Class UML Diagram ==
[[File:OODD Proj4 E2403 - Entity Diagram 2.png ‎| 610px]]

== Classes and Relationships ==
=== Existing Structure ===
* Every Assignment has a Node
* Every Assignment has many AssignmentTeam and MentoredTeam
* AssignmentTeam is inherited from Team
* MentoredTeam is inherited from AssignmentTeam
* Every MentoredTeam has many MentorMeeting
=== Proposed Structure Structure ===
* MentoredTeam to be delegated from AssignmentTeam instead of inheriting from it

== Implementation Plan ==
=== Modify newly created controller, model and view ===
==== mentor_meeting_controller.rb ====
* Edit function names to make them more descriptive
* Add more descriptive comments for the functions
==== mentor_meetings_helper.rb ====
* Move the "get_dates_for_team" function to the model
* Rename the function to make it more descriptive
==== _entry_assignments.html.erb ====
* Add more descriptive comments for the JavaScript functions
* Move the Ruby code from the template to a helper or the controller
==== mentored_team.rb --> mentored_team_decorator ====
* To reduce DRY violations, the mentored team class was changed to the mentored team decorator class.
*

=== Modify existing controller model and view ===
==== teams/_team.html.erb ====
* As the mentored team will now be delegated from the assignment team, we need to change the if condition on the top as we are changing MentoredTeam to be delegated from the AssignmentTeam
==== teams_controller.rb ====
* This file has to be modified to work with the delegated MentoredTeam
* These lines will not work as MentoredTeam will not be a model
[[File:Teams con1.png ‎| 600px]]
==== sign_up_sheet_controller.rb ====
* This controller has to be modified to automatically assign mentors or manually add mentors to the topics when they are created
* This will be followed by a change in schema
[[File:Signup con1.png | 600px]]
==== _topic.html.erb ====
* If we manually have to assign mentors to the topic, we have to include a input field to enter the mentor
[[File:Topic html.png | 600px]]
==== schema.rb ====
* As we are adding a new field to the table, we need to modify the schema
* We need to write 1 migration to add the field to the table to update the schema file
[[File:Schema E2403.png | 600px]]

=== Mailer Changes ===
====team.rb====
* The team model must be altered to use delegation for cases where a team would previously be a mentored team.
====add_member====
* The add member function must be altered such that the call to mail a user is better named, and that it calls directly to the mailer rather than the mailer helper.
[[File:add_member_email.png | 900px]]
====mailer_helper====
* The mailer_helper will be altered such that the send_team_confimration_to_user will be moved and renamed in the Mailer.rb class instead since using generic_message as such is leading to an unclear design.
[[File:team_confirm.png | 900px]]

====mailer.rb====
* A new function to specifically handle messaging users when added to teams will be built in the mailer, rather than just overusing the generic_message function.

== UI Changes ==
=== UI Changes before Phase 2 code changes ===
* The mentored assignment teams page has the modified UI from the Phase 1 as it is also a mentored assignment
* But the teams do not have a TA as the automated assignment of mentors has not been implemented.
[[File:UI1 E2403.png | 600px]]

=== UI Changes after Phase 2 code changes ===
The mentored assignment teams with topic now has the new UI and the automated mentor assignment
* The form to create a new topic has a new field to assign mentor to a topic
[[File:UI2 E2403.png | 600px]]
* The updated UI showing the topics with the mentors and teams that have chosen the topic
* The mentor is also displayed with the team
[[File:UI3 E2403.png | 600px]]
* The assignment teams page has the modified UI from the Phase 1 as the teams have a mentor
[[File:UI4 E2403.png | 600px]]

== Implementation ==
=== Mailer Changes ===
==== Decorator ====
* To remove DRY violations, we transformed the MentoredTeam class into the MentoredTeamDecoratorClass.
[[File:MentoredTeamClass.png | 600px]] ---> [[File:MentoredTeamDecorator.png | 600px]]
* In particular this required changing the MentoredTeam to have its own assignment team variable.
* The add_member function's DRY violations with the Team Class were able to be eliminated here, as now the Mentored Team Decorator calls to the assignment team's add member function on line 14, and then simply calls to assign the mentor on line 16.
==== MailerHelper to Mailer ====
* To increase understandability and consistency between classes, we removed the send_team_confirmation_mail function from the MailerHelper, and instead replaced its functionality with the team_addition_message function in the Mailer class. We found this to be the ideal location as the Mailer class houses many other specific message functions such as notify_grade_conflict_message, suggested_topic_approved_message and more.
[[File:team_confirm.png | 900px]]

== Implementation - To delete later ==
TODO:: 

== Files Modified/Added ==
* app/controllers/sign_up_sheet_controller.rb
* app/controllers/teams_controller.rb
* app/controllers/teams_users_controller.rb
* app/models/course.rb
* app/models/mentor_management.rb
* app/views/sign_up_sheet/_table_header.html.erb
* app/views/sign_up_sheet/_table_line.html.erb
* app/views/sign_up_sheet/_topic.html.erb
* app/views/teams/_team.html.erb
* app/views/tree_display/_page_footer_assignments.html.erb
* app/views/tree_display/_entry_assignments.html.erb
* app/models/mentored_team_decorator.rb
* app/models/team.rb
* app/views/mailer/team_addition_message.html.erb
* app/views/mailer/team_addition_message.text.erb
* app/helpers/mailer_helper.rb
* app/mailers/mailer.rb
* spec/models/team_spec.rb
* spec/models/mentor_management_spec.rb

== Test Plan ==
When the project was pulled from the main repository, there are not enough tests to cover the additional functionalities that we added. We are planning on using the test skeletons by Mustafa Olmez, as a reference to how and what kind of tests should be written. Test cases for mentor management were already written and we wrote new test cases for the new functionalities we added. Here are the four test case scenarios we covered and the actual ruby code for the Rspec tests

=== Automated Rspec Testing Scenarios===
1. Test scenario 1: Given an assignment_id, When there are multiple mentors with different team counts for the assignment, Then it should return the mentor with the lowest team count
it "returns the mentor with the lowest team count for the given assignment" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 2]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

2. Test scenario 2: Given an assignment_id, When there is only one mentor available for the assignment, Then it should return that mentor
it "should return that mentor if there's only one available" do
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 0]])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

3. Test scenario 3: Given an assignment_id, When there are multiple mentors with the same lowest team count for the assignment, Then it should return the first mentor in the list
it "returns the first mentor in the list if there's a tie for lowest team count" do
# Arrange
allow(MentorManagement).to receive(:zip_mentors_with_team_count)
.with(assignment.id)
.and_return([[mentor.id, 1], [998, 1],])
allow(User).to receive(:where).with(id: mentor.id).and_return([mentor])
selected_mentor = MentorManagement.select_mentor(assignment.id)
expect(selected_mentor).to eq mentor
end

4. Test scenario 4: Given an assignment_id, When there are no mentors available for the assignment, Then it should return nil
it "returns nil" do
# Create a new assignment
a = FactoryBot.create(:assignment, id: 997, directory_path: 'OSS_project', auto_assign_mentor: true)
# Since there are no mentors associated with this assignment, should return nil
expect(MentorManagement.select_mentor(a.id)).to eq nil
end

=== Manual UI Testing ===
Apart from the automated Rspec tests, we are providing manual testing cases that can be used to verify the functioning of the website.

Refer to the demo video on the bottom of the page to find help on testing these cases

==== Scenario 1 - Creating an mentored team ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Courses
# Assuming you have created a course and added participants to it, proceed to create a team
# Make sure "Auto assign mentors when team hits > 50% capacity?" option is checked
[[File:MT 1-1.png | 600px]]
* Create team for the assignment and you can see that the team with more than 50% capacity gets a mentor assigned automatically
[[File:MT 1-2.png | 600px]]

==== Scenario 2 - Adding, editing, deleting mentor meeting dates ====
# Log into Expertiza using the test credential and navigate to the home page
# Go to Manage > Assigments
# Assuming you have created a mentored assignment and added participants to it, proceed to the teams page
# Try entering dates into it teams row and the date should persist
# You can edit and delete the dates from the rows
# Team with less than 50% capacity will have the mentor meeting dates disabled
[[File:MT 2.png | 600px]]

==== Scenario 3 - Creating a team with topic ====
* Log into Expertiza using the test credential and navigate to the home page
* Go to Manage > Courses
* Assuming you have created a course and added participants to it, proceed to create a team
* Make sure "Has topics?" option is checked and a topic is created using the Topics tab
[[File:MT 3-1.png | 600px]]
* Create a new topic for the assignment and enter a mentor name to the topic
[[File:UI2 E2403.png | 600px]]
* When a student is added to the topic, the team of the student along with the mentor will be displayed in the topic row
[[File:UI3 E2403.png | 600px]]
* When navigating to the teams page of that assignment, you can see a mentor assigned automatically
[[File:UI4 E2403.png | 600px]]

== Test Coverage ==
We used SimpleCov to generate a coverage report for the Rspec test cases implemeted for the model and controllers.
The test coverage indicated 1730 lines of code was covered through the testcases.

[[File:Testing E2403.png ‎| 600px]]

== Test Login Credentials ==
* UserId: instructor6
* Password: password

== Demo Video ==
TODO:: 
This is our [https://www.youtube.com/ demo video] which explain how to create courses, assignments, mentored teams and mentored teams with topics. This video also show how to run the tests of our code changes.

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2789

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T01:17:20Z

Slkwiatk: /* Mailer Changes */

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T01:16:54Z

Slkwiatk: /* Mailer Changes */

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T01:16:21Z

Slkwiatk: /* Mailer Changes */

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T01:14:54Z

Slkwiatk: /* Mailer Changes */

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T01:11:14Z

Slkwiatk: /* Mailer Changes */

File:MentoredTeamClass.png

2024-04-24T01:10:20Z

Slkwiatk:

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T00:58:45Z

Slkwiatk: /* Mailer Changes */

File:MentoredTeamDecorator.png

2024-04-24T00:56:02Z

Slkwiatk:

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T00:44:44Z

Slkwiatk: /* Mailer Changes */

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T00:43:46Z

Slkwiatk: /* Implementation */

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T00:40:54Z

Slkwiatk: /* Implementation */

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T00:29:59Z

Slkwiatk: /* mentored_team.rb --> mentored_team_decorator */

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T00:28:41Z

Slkwiatk: /* mentored_team.rb */

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-24T00:21:32Z

Slkwiatk: /* Implementation Plan */

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-09T02:43:45Z

Slkwiatk: /* mailer_helper */

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-09T02:43:23Z

Slkwiatk: /* Mailer Changes */

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management (Phase 2)

2024-04-09T02:38:40Z

Slkwiatk: /* Implementation Plan */

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management

2024-03-24T23:06:07Z

Slkwiatk: /* Relevant Links */

__TOC__
==Background==
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page], or the GitHub page [https://github.com/expertiza]. For our project in particular, we were tasked with improving the mentor management system on Expertiza.

== What is a Mentor? ==
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

== Problem Statement ==
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team.

The other problem we have fixed as part of this project is improving the view displaying the listing of the teams. The only listing of teams is on the “Create Teams” page for the assignment. It shows each team member on a separate line, with the mentor in an arbitrary place on the team.

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

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course intructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

== Tasks ==

=== Email Notifications ===

- Add new mailer function for team addition confirmation 
- Add HTML partials for both the mentor-specific and student-specific emails 
- Add correct mailer function calls where users/mentors are added 
- Add tests 

=== Mentor Meeting Management ===

- Create a new view that shows the team listing in a more intuitive and easy way. 
- Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted. 
- Instructors can edit all dates for mentor meetings regardless of the team. 
- Mentors can also edit dates but only for the team they are mentoring. 
- Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view. 
- The meeting dates should not be editable for teams having capacity less than 50%. 
- Show user information in the view.

== Implementation ==

=== Email Notifications ===

==== add_member ====
[[File:add_member_email.png | 900px]]

First, we added to the add_member functions in both the Team and MentoredTeam models. This is because, as has already been stated, when a member is added, that is when we want the notification to be sent.

==== New Code in add_member ====
[[File:new_add_member_email.png | 900px]]

We added a check for the assignment_id parameter since there are some cases where add_member is called without an assignment. Additionally, we checked whether a user was a mentor or not, as that will be the determining factor as to which email the user will receive. Of course, we didn't want to do a type check, however, we saw no better options unless we went outside the scope of the assignment and added a whole new mentor class (since mentor is not an actual class in the system). We also had to check that the user is not a participant, as there are some odd scenarios where participants are passed as the user parameter in add_member. Our assignment has nothing to do with the participant class, only the user class, so we simply did a type check to make sure we didn't send emails to participants. Again, we wouldn't normally choose to do a type check, but since it involves code completely outside the scope of this project "participants" we chose to simply check that users aren't participants.

==== send_team_confirmation_mail_to_user ====
[[File:team_confirm.png | 900px]]

Once we know what type of user we are working with, we call the MailerHelper.send_team_confirmation_mail_to_user to send the correct email to the student/mentor. This function discerns the user email, subject, name of user, team name, and assignment name before calling upon the generic_message function in the mailer class to send an actual email.

==== Modified generic_message ====
[[File:mod_generic_message.png | 900px]]

We modified the generic_message function to include the team name as that's something that would be included in most messages. This function then uses the partials seen below to build the exact message our students/mentors will receive in their inbox. (note: generic_message is in mailer.rb under the mailer folder)

==== Student HTML Partial ====

[[File:Student_Email.png | 888px]]

==== Mentor HTML Partial ====

[[File:Mentor_Email.png | 888px]]

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2769
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2772

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management

2024-03-24T23:04:09Z

Slkwiatk: /* Implementation */

__TOC__
==Background==
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page], or the GitHub page [https://github.com/expertiza]. For our project in particular, we were tasked with improving the mentor management system on Expertiza.

== What is a Mentor? ==
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

== Problem Statement ==
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team.

The other problem we have fixed as part of this project is improving the view displaying the listing of the teams. The only listing of teams is on the “Create Teams” page for the assignment. It shows each team member on a separate line, with the mentor in an arbitrary place on the team.

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

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course intructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

== Tasks ==

=== Email Notifications ===

- Add new mailer function for team addition confirmation 
- Add HTML partials for both the mentor-specific and student-specific emails 
- Add correct mailer function calls where users/mentors are added 
- Add tests 

=== Mentor Meeting Management ===

- Create a new view that shows the team listing in a more intuitive and easy way. 
- Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted. 
- Instructors can edit all dates for mentor meetings regardless of the team. 
- Mentors can also edit dates but only for the team they are mentoring. 
- Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view. 
- The meeting dates should not be editable for teams having capacity less than 50%. 
- Show user information in the view.

== Implementation ==

=== Email Notifications ===

==== add_member ====
[[File:add_member_email.png | 900px]]

First, we added to the add_member functions in both the Team and MentoredTeam models. This is because, as has already been stated, when a member is added, that is when we want the notification to be sent.

==== New Code in add_member ====
[[File:new_add_member_email.png | 900px]]

We added a check for the assignment_id parameter since there are some cases where add_member is called without an assignment. Additionally, we checked whether a user was a mentor or not, as that will be the determining factor as to which email the user will receive. Of course, we didn't want to do a type check, however, we saw no better options unless we went outside the scope of the assignment and added a whole new mentor class (since mentor is not an actual class in the system). We also had to check that the user is not a participant, as there are some odd scenarios where participants are passed as the user parameter in add_member. Our assignment has nothing to do with the participant class, only the user class, so we simply did a type check to make sure we didn't send emails to participants. Again, we wouldn't normally choose to do a type check, but since it involves code completely outside the scope of this project "participants" we chose to simply check that users aren't participants.

==== send_team_confirmation_mail_to_user ====
[[File:team_confirm.png | 900px]]

Once we know what type of user we are working with, we call the MailerHelper.send_team_confirmation_mail_to_user to send the correct email to the student/mentor. This function discerns the user email, subject, name of user, team name, and assignment name before calling upon the generic_message function in the mailer class to send an actual email.

==== Modified generic_message ====
[[File:mod_generic_message.png | 900px]]

We modified the generic_message function to include the team name as that's something that would be included in most messages. This function then uses the partials seen below to build the exact message our students/mentors will receive in their inbox. (note: generic_message is in mailer.rb under the mailer folder)

==== Student HTML Partial ====

[[File:Student_Email.png | 888px]]

==== Mentor HTML Partial ====

[[File:Mentor_Email.png | 888px]]

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2769
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

File:Mod generic message.png

2024-03-24T23:03:19Z

Slkwiatk:

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management

2024-03-24T23:02:26Z

Slkwiatk: /* Implementation */

__TOC__
==Background==
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page], or the GitHub page [https://github.com/expertiza]. For our project in particular, we were tasked with improving the mentor management system on Expertiza.

== What is a Mentor? ==
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

== Problem Statement ==
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team.

The other problem we have fixed as part of this project is improving the view displaying the listing of the teams. The only listing of teams is on the “Create Teams” page for the assignment. It shows each team member on a separate line, with the mentor in an arbitrary place on the team.

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

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course intructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

== Tasks ==

=== Email Notifications ===

- Add new mailer function for team addition confirmation 
- Add HTML partials for both the mentor-specific and student-specific emails 
- Add correct mailer function calls where users/mentors are added 
- Add tests 

=== Mentor Meeting Management ===

- Create a new view that shows the team listing in a more intuitive and easy way. 
- Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted. 
- Instructors can edit all dates for mentor meetings regardless of the team. 
- Mentors can also edit dates but only for the team they are mentoring. 
- Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view. 
- The meeting dates should not be editable for teams having capacity less than 50%. 
- Show user information in the view.

== Implementation ==

=== Email Notifications ===

==== add_member ====
[[File:add_member_email.png | 900px]]

First, we added to the add_member functions in both the Team and MentoredTeam models. This is because, as has already been stated, when a member is added, that is when we want the notification to be sent.

==== New Code in add_member ====
[[File:new_add_member_email.png | 900px]]

We added a check for the assignment_id parameter since there are some cases where add_member is called without an assignment. Additionally, we checked whether a user was a mentor or not, as that will be the determining factor as to which email the user will receive. Of course, we didn't want to do a type check, however, we saw no better options unless we went outside the scope of the assignment and added a whole new mentor class (since mentor is not an actual class in the system). We also had to check that the user is not a participant, as there are some odd scenarios where participants are passed as the user parameter in add_member. Our assignment has nothing to do with the participant class, only the user class, so we simply did a type check to make sure we didn't send emails to participants. Again, we wouldn't normally choose to do a type check, but since it involves code completely outside the scope of this project "participants" we chose to simply check that users aren't participants.

==== send_team_confirmation_mail_to_user ====
[[File:team_confirm.png | 900px]]

Once we know what type of user we are working with, we call the MailerHelper.send_team_confirmation_mail_to_user to send the correct email to the student/mentor. This function discerns the user email, subject, name of user, team name, and assignment name before calling upon the generic_message function in the mailer class to send an actual email.

==== Modified generic_message ====
[[File:team_confirm.png | 900px]]

We modified the generic_message function to include the team name as that's something that would be included in most messages. This function then uses the partials seen below to build the exact message our students/mentors will receive in their inbox. (note: generic_message is in mailer.rb under the mailer folder)

==== Student HTML Partial ====

Student emails are built with the following HTML partial:

[[File:Student_Email.png | 888px]]

==== Mentor HTML Partial ====
Mentors should also be emailed when added to a team, however, their email should look a bit different:

[[File:Mentor_Email.png | 888px]]

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2769
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)

CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management

2024-03-24T22:56:39Z

Slkwiatk: /* send_team_confirmation_mail_to_user */

__TOC__
==Background==
Expertiza is an open-source course management web application, that is maintained by students and teaching staff across NC State and other universities. Specifically, Expertiza is used as a platform to help students learn how to work collaboratively on large Object Oriented Programming Assignments. If you would like to learn more about Expertiza, please check the Expertiza wiki[https://wiki.expertiza.ncsu.edu/index.php?title=Main_Page], or the GitHub page [https://github.com/expertiza]. For our project in particular, we were tasked with improving the mentor management system on Expertiza.

== What is a Mentor? ==
On Expertiza some users are known as mentors. These mentors can both be added to teams manually and automatically assigned if the assignment moderator chooses to select an option where mentors are automatically assigned to teams above 50% capacity. In practice, this means that if you have a max team size of 3, and 2 teammates have been added to team X then team X will automatically be given a mentor.

== Problem Statement ==
The problem we have been faced with is multifaceted. First, we found that when teams are automatically built, students are not getting notified of when they are added to a team. Even more alarming is that when mentors are being added to teams, they aren't getting any type of specialized notification letting them know. Mentors should know when they are mentoring a new team, and students should know when they've been added to a team.

The other problem we have fixed as part of this project is improving the view displaying the listing of the teams. The only listing of teams is on the “Create Teams” page for the assignment. It shows each team member on a separate line, with the mentor in an arbitrary place on the team.

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

Expertiza doesn’t know when mentors met with teams, so there would have to be text fields where this information could be entered.

The page would have to be accessible to all mentors and course intructors, but a mentor could only enter meetings for the teams they mentored (except that the instructor could edit any of the meeting dates for any mentor).

Our project sought to fix these issues.

== Tasks ==

=== Email Notifications ===

- Add new mailer function for team addition confirmation 
- Add HTML partials for both the mentor-specific and student-specific emails 
- Add correct mailer function calls where users/mentors are added 
- Add tests 

=== Mentor Meeting Management ===

- 
- 
- 

== Implementation ==

=== Email Notifications ===

First, we added to the add_member functions in both the Team and MentoredTeam models. This is because, as has already been stated, when a member is added, that is when we want the notification to be sent.

==== add_member ====
[[File:add_member_email.png | 900px]]

We added a check for the assignment_id parameter since there are some cases where add_member is called without an assignment. Additionally, we checked whether a user was a mentor or not, as that will be the determining factor as to which email the user will receive. Of course, we didn't want to do a type check, however, we saw no better options unless we went outside the scope of the assignment and added a whole new mentor class (since mentor is not an actual class in the system). We also had to check that the user is not a participant, as there are some odd scenarios where participants are passed as the user parameter in add_member. Our assignment has nothing to do with the participant class, only the user class, so we simply did a type check to make sure we didn't send emails to participants. Again, we wouldn't normally choose to do a type check, but since it involves code completely outside the scope of this project "participants" we chose to simply check that users aren't participants.

==== New Code in add_member ====
[[File:new_add_member_email.png | 900px]]

Once we know what type of user we are working with, we call the MailerHelper.send_team_confirmation_mail_to_user to send the correct email to the student/mentor. This function discerns the user email, subject, name of user, team name, and assignment name before calling upon the generic_message function in the mailer class to send an actual email.

==== send_team_confirmation_mail_to_user ====
[[File:team_confirm.png | 900px]]

==== Student HTML Partial ====

Student emails are built with the following HTML partial:

[[File:Student_Email.png | 888px]]

==== Mentor HTML Partial ====
Mentors should also be emailed when added to a team, however, their email should look a bit different:

[[File:Mentor_Email.png | 888px]]

== Relevant Links ==
* '''Github Repository:''' https://github.com/ExtremeMachine12/expertiza
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/2769
* '''Pull Request:''' https://github.com/expertiza/expertiza/pull/

== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Samuel Kwiatkowski-Martin (slkwiatk)
* Tanmay Pardeshi (tpardes)
* Bala Logesh Sudalaimuthu Pandian (bsudala)