CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management: Difference between revisions
(Created page with "== Introduction == <nowiki>The User model is a crucial component of the Expertiza application, managing user data and authentication/authorization. It has 9 class methods, 23 instance methods, and is linked with other models for personalized user experience. The user controller is smaller but could benefit from refactoring and improved comments.</nowiki> ==Files Changes== #app/models/user.rb #app/models/instructor.rb #app/models/ta.rb #app/models/superadministrator.rb...") |
|||
| (58 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
== | __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<br/> | |||
- Add HTML partials for both the mentor-specific and student-specific emails<br/> | |||
<br> | - Add correct mailer function calls where users/mentors are added<br/> | ||
- Add tests<br/> | |||
<br> | |||
=== Mentor Meeting Management === | |||
- Create a new view that shows the team listing in a more intuitive and easy way.<br/> | |||
- Add input fields for each team where mentors and instructors can enter new, view, edit dates when mentor meetings were conducted.<br/> | |||
- Instructors can edit all dates for mentor meetings regardless of the team.<br/> | |||
- Mentors can also edit dates but only for the team they are mentoring.<br/> | |||
- Add more than three dates for the mentor meetings easily by pressing the + icon at the end of the view.<br/> | |||
- The meeting dates should not be editable for teams having capacity less than 50%.<br/> | |||
- Show user information in the view. | |||
== Implementation == | |||
=== Email Notifications === | |||
==== add_member ==== | |||
[[File:add_member_email.png | 900px]] | |||
[[File: | |||
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]] | |||
[[File: | |||
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]] | |||
[[File: | |||
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]] | |||
[[File: | |||
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]] | |||
[[File: | |||
==== Mentor HTML Partial ==== | |||
[[File:Mentor_Email.png | 888px]] | |||
=== Mentor Meeting Management === | |||
==== New Mentor Meeting Management View ==== | |||
As you can see in the Problem Statement section that the team listing view is not very intuitive. We have built a new view as shown in the screenshot below which has more functionality and is more easy to understand. This view also has input fields for the teams where the instructors or mentors can add the dates when the mentor meeting was conducted. | |||
This view also has a lot of the user and team information present in the same table such as team name, member names, member IDs, mentor names and member email IDs. | |||
You can also see that some dates are already present in the input fields. If meetings have already been conducted and fed to the system, they will show up in the appropriate rows as you can see in the screenshot. Only the instructors have the ability to edit any of these dates and the mentors can only edit the dates for their teams only. Apart from this, you can also see that the last row with team member capacity less than 50% is disabled for any kind of entry in the meeting date input fields. This is because only teams having capacity more than 50% can have mentor meetings. | |||
[[File:New Mentor Meeting Mangement View.png|900px]] | |||
==== Code changes in the views ==== | |||
We added a small code change the teams view where we have written code to render the new view. | |||
[[File:Team View.png|900px]] | |||
The actual code for the new view is written in the tree_display view where we have modified the table and also added JavaScript code for validations and calling controllers asynchronously. | |||
==Relevant Links== | [[File:New_Mentor_Meeting_View.png|900px]] | ||
==== Code changes in the controller ==== | |||
We added a new controller(mentor_meeting.rb) to perform the CRUD operations on the mentor meeting table. | |||
[[File:Mentor Meeting Controller.png|900px]] | |||
==== Helper code ==== | |||
We also wrote a helper code to map all the team IDs in the mentor meeting table to the appropriate meeting dates. | |||
[[File:Mentor Meeting Helper.png|900px]] | |||
== 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) | |||
Latest revision as of 00:29, 25 March 2024
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
Mentor Meeting Management
New Mentor Meeting Management View
As you can see in the Problem Statement section that the team listing view is not very intuitive. We have built a new view as shown in the screenshot below which has more functionality and is more easy to understand. This view also has input fields for the teams where the instructors or mentors can add the dates when the mentor meeting was conducted.
This view also has a lot of the user and team information present in the same table such as team name, member names, member IDs, mentor names and member email IDs.
You can also see that some dates are already present in the input fields. If meetings have already been conducted and fed to the system, they will show up in the appropriate rows as you can see in the screenshot. Only the instructors have the ability to edit any of these dates and the mentors can only edit the dates for their teams only. Apart from this, you can also see that the last row with team member capacity less than 50% is disabled for any kind of entry in the meeting date input fields. This is because only teams having capacity more than 50% can have mentor meetings.
Code changes in the views
We added a small code change the teams view where we have written code to render the new view.
The actual code for the new view is written in the tree_display view where we have modified the table and also added JavaScript code for validations and calling controllers asynchronously.
Code changes in the controller
We added a new controller(mentor_meeting.rb) to perform the CRUD operations on the mentor meeting table.
Helper code
We also wrote a helper code to map all the team IDs in the mentor meeting table to the appropriate meeting dates.
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)