CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management

From Expertiza_Wiki
Jump to navigation Jump to search

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[1], or the GitHub page [2]. 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.

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

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

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

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

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

Mentor HTML Partial

Relevant Links

Team

Mentor

  • Ed Gehringer (efg)

Team Members

  • Samuel Kwiatkowski-Martin (slkwiatk)
  • Tanmay Pardeshi (tpardes)
  • Bala Logesh Sudalaimuthu Pandian (bsudala)
Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Spring_2024_-_E2403_Mentor-Meeting_Management&oldid=153934"