CSC/ECE 517 Spring 2022 - E2240. Re-write waitlist functionality

Problem Statement

Whenever a team requests for a topic, there are two things that can happen.

• The topic is available: In this case, the team will be assigned this topic ( Assuming that there is no bidding for the assignment ). This is pretty straightforward.

• The topic is unavailable: In this case, the team is waitlisted for the topic. When any other team drops this topic, a waitlisted team will be assigned for this topic.

Our task is to simplify the way we are handling the second case. For each topic, we will have to have a waitlist object associated with it. If a team has requested for a topic that is not available, the team would just be queued on to the waitlist for this topic. In the waitlist object, we will have to maintain the team_id and the topic id for which this team will be waitlisted. In the current implementation, the waitlisting functionality is scattered across multiple files. All this has to be consolidated and placed in fewer number of places ( model file and helper class ).

Issues with existing functionality

The current implementation has multiple models and controllers ( sign_up_topic.rb, waitlist.rb, invitation.rb, lottery_controller.rb, suggestion_controller.rb and signed_up_team.rb etc ) perform actions that indirectly affect the waitlist ( adding or removing teams from waitlist ). As a result, modifying the waitlist is being performed by multiple models and controllers. So, there is a lot of redundancy associated with basic waitlist operations in multiple files.

Overview of Major Changes

To simplify waitlist functionality and to reduce code redundancy, we will be moving all the functions present in multiple controllers and model files that manipulate waitlists to waitlist.rb. All these classes will now just invoke methods of waitlist.rb. The list of files and methods which will be modified are

1) signed_up_team.rb

2) waitlist.rb

3) sign_up_sheet_controller.rb

4) sign_up_sheet.rb

5) sign_up_topic.rb

6) suggestion_controller.rb

7) invitation.rb

Proposed design and Plan of action

General Design Goals

Since our goal is to fix existing functionalities we will not be updating the existing design patterns being employed in the code. Yet, we would like to discuss what makes these refactoring important. Refactoring is a systematic process of improving code without creating new functionality. Thus, a key to the success of our project is ensuring everything that was working before our changes work even after our changes have been added. To ensure this, we will continue to test the system after each issue has been fixed. This will allow us to ensure two things:

• We are only changing what we set out to change when fixing a particular issue.
• We are not breaking what was working before we deployed our fix.

We believe at the end our changes will increase the quality of Expertiza and improve the experience for users an developers alike.

UML Diagram

In this Unified Modeling Language (UML), we summarize the details of the system's users such as instructors and students and their interactions with the system.

Student Interactions
1. Student should be able to perform an action to add their own team to the waitlist.
2. Student should be able to drop their own team from the waitlist but not others team.

Instructor Interactions
1. Delete or purge on the waitlist items are those actions that have to be performed by the instructor/admin and student should not be given access to delete action.
2. Instructor should be able to add any team to the waitlist.
3. Instructor should be able to drop any team from the waitlist.
4. Instructor should be able to fetch the details of the teams in a waitlist for a particular topic.
5. Instructor should be able to fetch the details of the topics in which a team is waitlisted.

Class Diagram

Tables associated with waitlist_teams table:
1. teams
2. signed_up_teams

waitlist_teams table is referred by the signed_up_teams and teams table as Foreign Key Relationship.

team_id : foreign key in waitlists_team table referenced by teams table
topic_id : foreign key in waitlists_team table reference by signed_up_teams table

Changes to the signed_up_teams Table

signed_up_teams table consists of a mapping of team_id, topic_id, is_waitlisted. This table was being used for multiple purposes, one to store the signed up teams and also the waitlisted teams for a topic.
We plan on retiring/removing the waitlist flag from the signed_up_teams table and separating this functionality.
All existing references to the is_waitlisted flag will be rewritten to make use of the new table.

Files and methods to be refactored

1. signed_up_team.rb
   1. All references to is_waitlisted should be removed and waitlists must be determined by using the new waitlist_team table.
2. waitlist.rb
   1. This class must be scrapped away and we will use a separate helper class to add all the logic of waitlisting which will be called by other methods.
3. sign_up_sheet_controller.rb
   1. switch_original_topic_to_approved_suggested_topic
      1. Change usage of is_waitlisted attribute in the signed_up_teams table to use the new table
      2. Add additional checks and transactions to make sure perform operations in an atomic way in case of failures.
4. sign_up_sheet.rb
   1. cancel_all_wailists (typo in code) - This method currently does 2 things, it cancels waitlist and also updates the signed_up_team topic which needs to be split
   2. create_SignUpTeam
      1. It checks if topic has slots if yes it adds to signed up team, else creates a signup as waitlist
      2. This method should use the new table and call the helper functions of waitlist to perform actions on waitlists
5. sign_up_topic.rb
   1. users_on_waiting_list - Move method to fetch all users on waitlist for a topic to waitlist_teams method.
   2. assign_to_first_waiting_team - The same functionality is being called in multiple places, it should be made DRY and moved to the waitlist_teams model
   3. reassign_topic - Use methods that perform actions on waitlist that should be moved to waitlist_helper, also use transactions to make it atomic.
   4. update_waitlisted_users - Move method to waitlist_teams model and use the new table
   5. find_slots_waitlisted - Move method to waitlist_teams model
   6. find_waitlisted_topics - Move method to waitlist_teams model
6. suggestion_controller.rb
   1. notification
   2. Clean waitlist functionality should be moved to a method in waitlist_teams model. team id should be passed as a parameter to delete the waitlist for that team.
7. invitation.rb
   1. remove_waitlists_for_team
      1. Removing from waitlist and adding to team to sign up should be as a single transaction
      2. There should be additional checks to make sure that there is enough space left before adding team to signed_up_sheet
      3. All functionality should be moved to waitlist_helper and implemented in a robust and dry manner

Adding new waitlist_teams Table

We plan to add a new table waitlist_teams
The attributes for the table are team_id(refers to the teams table), topic_id (refers to the sign_up_topics table)
This table only stores the waitlisted teams for each topic.
The default timestamp in the table will be used to check the first team waitlisted instead of using queues to implement the functionality.
Having separated tables for signups and waitlists will help in managing entries and enforcing constraints and make it easier to implement and extend functionality if required.

The waitlist_helper class will perform the following operations

1. Delete all waitlists for team
2. Purge all waitlists for topic
3. Add team to waitlist
4. Delete specific team from waitlist
5. Get all waitlisted topics for team
6. Get all waitlisted teams for topic
7. Get first team in waitlist for topic
8. Check waitlist empty for topic
9. Check if team has any waitlists
10. Get the number of waitlisted teams for all topics in an assignment

Migrating existing waitlists to use new table

Since the signed_up_teams table will no longer be used to store the waitlists we will move all the entries for waitlisted teams to the new table so that all the existing waitlists don't get affected.
We plan on writing a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
This will ensure minimal regression breakages and retain existing functionalities.

Specific Tasks Completed

will be added for the final submission

Implementation

will be added for the final submission

Testing

Video Demonstration

will be added for the final submission

Testing Goals and Test Objects

Drawing from the project objectives:

1. Ways to get added to the waitlist for a topic
   1. Team requests a topic that has no slot available.
   2. When capacity/max choosers for a topic is increased
   3. When a student gets added to a team that already has a signed up topic
2. Ways to get off a waitlist
   1. team gets the topic they are waiting for ( all other waitlists are dropped for the team)
   2. team drops off the waitlist
   3. instructor drops team from the waitlist
   4. a drop-topic deadline passes
   5. team is deleted
   6. student gets added to a new team, then the old team's waitlist should be dropped

RSpec Unit Tests

Test cases provided here, will add RSpec code blocks for the final submission

• Student Waitlist

Scenario: Getting added to the waitlist for a topic 
 Given: Logged in as a Student
  When: The topic for an assignment has no available slots
   And: Student tries to signup for a topic
  Then: The team that the student is a part of should be added to the waitlist for the topic.

Scenario: Getting enrolled in a topic 
 Given: Logged in as a Student
  When: The topic for an assignment has available slots
   And: Student tries to signup for a topic
  Then: The team that the student is a part of should be enrolled for the topic.

Scenario: All waitlisted topics getting dropped
 Given: Logged in as a Student
  When: Student gets enrolled into a course for which he was waitlisted before.
  Then: The team that the student is a part of should be dropped from the remaining waitlisted topics.

Scenario: All waitlisted teams getting dropped
 Given: Logged in as a Student
  When: The deadline for a topic passes.
  Then: All the waitlisted teams for that particular topic must be dropped.

Scenario: Getting enrolled in a topic
 Given: Logged in as a Student
  When: The enrolled team for a topic drops
  Then: The team that was waitlisted earlier for the topics must be enrolled.

Manual Testing

Student's View

---

Instructor's View

---

Instructor's View With Waitlists

---

Test 1:
Student should be able to add their team to the waitlist by clicking on Check icon (see the image above) if the team has not signed up in any topic.

Test 2:
Student should be able to drop the team from the waitlist by clicking on Delete icon (see the image above) if they are no longer interested in it.

Test 3:
Instructor should be able to add a student to the topic by clicking on Check (see the image above) icon.

Test 4:
Instructor should be able to delete a student to the topic by clicking on Delete (see the image above) icon.

Test 5:
Instructor should be able to view all the students signup for a topic in the page displayed.

Test 6:
Instructor should be able to view all the topics available

Test 7:
Instructor should be able to view waitlisted and signed up teams for all the topics in the assignment

Test 8:
Instructor should be able to drop waitlisted team for a topics in the assignment

we will be adding more test cases as the project progress.

Regression Testing

In order to ensure complete coverage, testing of the changes done between the end of last semester and this project will be done to ensure that old test cases still pass.

1. Make sure all existing waitlist functionality still passes

Conclusions and Future Work

Comprehensive Testing and Scope

• will be added for final submission

Conclusion

will be added for final submission

Useful Links

Pull request

Deployed application with changes

Forked repository

Contributors

Students

• Krishna Saurabh Vankadaru (kvankad)
• Samson Reddy Mulkur (smulkur)
• Akhil Kumar Mengani (amengan)
• Sai Naga Vamshi Chidara (schidar)

Mentor

• Naman Shrimali (nshrima)