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

Expertiza

Expertiza is a 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 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:

1. Enhancing Code Clarity: This involves renaming methods from Project 3 with ambiguous names, optimizing loops and adding comments for unclear lines of code
2. Reimplement Mentored teams: Reimplement the Mentored team delegate to the Assignment team to reduce complexity and to follow best principles of Object Oriented Design
3. 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
4. Writing tests for mentor meetings models: More tests have to be written for Mentor Meeting model
5. Writing tests for the mentor meetings controller: More tests should be written for Mentor meeting controller
6. 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

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

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

_topic.html.erb

• If we manually have to assign mentors to the topic, we have to include a input field to enter the mentor

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

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.

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.

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.

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

• The updated UI showing the topics with the mentors and teams that have chosen the topic
• The mentor is also displayed with the team

• The assignment teams page has the modified UI from the Phase 1 as the teams have a mentor

Implementation

Mailer Changes

Decorator

• To remove DRY violations, we transformed the MentoredTeam class into the MentoredTeamDecoratorClass.

--->

• 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.

--->

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

1. Log into Expertiza using the test credential and navigate to the home page
2. Go to Manage > Courses
3. Assuming you have created a course and added participants to it, proceed to create a team
4. Make sure "Auto assign mentors when team hits > 50% capacity?" option is checked

• Create team for the assignment and you can see that the team with more than 50% capacity gets a mentor assigned automatically

Scenario 2 - Adding, editing, deleting mentor meeting dates

1. Log into Expertiza using the test credential and navigate to the home page
2. Go to Manage > Assigments
3. Assuming you have created a mentored assignment and added participants to it, proceed to the teams page
4. Try entering dates into it teams row and the date should persist
5. You can edit and delete the dates from the rows
6. Team with less than 50% capacity will have the mentor meeting dates disabled

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

• Create a new topic for the assignment and enter a mentor name to the topic

• When a student is added to the topic, the team of the student along with the mentor will be displayed in the topic row

• When navigating to the teams page of that assignment, you can see a mentor assigned automatically

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.

Test Login Credentials

• UserId: instructor6
• Password: password

Demo Video

TODO:: This is our 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)