Expertiza_Wiki - User contributions [en]

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

2022-05-03T15:04:59Z

Schidar: /* Regression Testing */

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

We simplified the way we are handling the second case. For each topic, we have a waitlist object associated with it. If a team has requested for a topic that is not available, the team is queued on to the waitlist for this topic. In the waitlist table, we maintain the team id and the topic id for which this team is waitlisted. In the previous implementation, the waitlisting functionality is scattered across multiple files. All this is consolidated and placed in one model file ( waitlists.rb )
=== Issues with previous functionality ===
The previous implementation had 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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we have rewritten the methods in multiple controllers and model files that manipulate waitlists of a topic. All these classes now just invoke methods of waitlist_teams.rb. The following files contains the waitlist functionality which we have modified to refer to the new model file.

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''

== Design ==

=== Achieved Design Goals ===
Since our goal is to fix existing functionalities we did not update 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. We have eliminated the waitlist.rb file and moved all the references to this class to the new waitlist_teams.rb model file. We tested the existing features and ensured that we are not breaking what was working before we deployed our fix.
We can say that we achieved our goal of making experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Actions performed ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.Changes done 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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a commit] to view the changes.
#sign_up_sheet_controller.rb
##set_values_for_new_topic
###Added code to get waitlisted entries from new table instead of having all the entries from signed_up_teams table. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/15/commits/44a0f06761dfc681d6ed8e6d9ecd3017a816848d commit] to view the changes.
#sign_up_sheet.rb
##cancel_all_wailists
###This method previously has done 2 things, it cancelled waitlist and also updated the signed_up_team topic which needs to be split to comply with single responsibility principle. We ensured that is happening in the current implementation. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-f7b8fbeb82e3d7d5481ba3ed065d55838a21a82ebd055ac076ea36f222f88556 commit] to view the changes.
##create_SignUpTeam
### This method in the previous implementation checked if topic has slots. If yes, it added to signed up team, else created a signup as waitlist. We modified this in order to use the new table and call the functions of waitlist_teams.rb to perform actions on waitlists. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/12/commits/7194a53ec01e78ea0d95920624436da6fe9933e2 commit] to view the changes.
#sign_up_topic.rb
##users_on_waiting_list - Moved this method to fetch all users on waitlist for a topic to waitlist_teams model file.
##assign_to_first_waiting_team - The same functionality is being called in multiple places. This is modified to comply with DRY and is moved to the waitlist_teams model
##reassign_topic - Modified this method to use waitlist_teams.rb model file for actions on waitlisted teams.
##update_waitlisted_users - Moved this method to waitlist_teams model file.
##find_slots_waitlisted - Moved this method to waitlist_teams model file.
##find_waitlisted_topics - Moved this method to waitlist_teams model file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-e0df714a791bc6d36e6b27b82af71be36e8eac2cd21af5ea28a8bc5303953f5b diff] to view the changes.
#suggestion_controller.rb
##notification - Clean waitlist functionality is moved to a method in waitlist_teams model. team id is passed as a parameter to delete the waitlist for that team. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/14/files PR] to view the changes.
#invitation.rb
##remove_waitlists_for_team - Removed this method as we dont need it in this file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-c899291de1875b0c2483c0f132ed4503e6c33be63148d6e5d1f4235bfeb1c331 diff] to view the changes.

===3. Added new waitlist_teams Table ===
We added 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 is used to check the first team waitlisted instead of using queues to implement the functionality.
 
Having separated tables for signups and waitlists helps us in managing entries and enforcing constraints and makes it easier to implement and extend functionality if required.
 
The waitlist_teams.rb model class performs the following operations
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-0b3fc155270b76c5cdbf311acb356fbcd90873d2704bf87c44ee1d5ce111b9ca file] to view the waitlist_teams model.

=== 4. Migrated existing waitlists to use new table===
Since the signed_up_teams table will no longer be used to store the waitlists, we moved all the entries for waitlisted teams to the new table so that all the existing waitlists don't get affected.
 
We have written a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
 
This ensures minimal regression breakages and that all existing functionalities are retained. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-327e3874b03ef13dc2d75451388a63d2d28dd775df41e2d48389eb701667f5cb file] to view the migration script.

== Implementation ==
'''1. Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
Please watch this [https://www.youtube.com/watch?v=L6NntAvnzUo Video Demonstration] where we explain the bugs we rectified in this project.

=== Testing Goals and Test Objects ===

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

=== RSpec Unit Tests ===
*Student Waitlist
**Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-0e90ff1a02697a3552966c713b541746d6b1226088147dcfe333f9605ebeb576 diff] to view the RSpec unit tests for waitlist_teams.rb model file. Few of them are
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
Scenario: Drop team from the waitlist for a topic
Given: Logged in as a Student
When: The student is waitlisted for a topic
And: Student drops from the waitlist of this topic
Then: The team that the student is a part of should be dropped from the waitlist for the topic.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Regression Testing ===
In order to ensure complete coverage, testing of the changes done between the end of last semester and this project is done to ensure that old test cases still pass. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-41ff53070546cf68377a8592d16001af4558d9aa280bb65a21cf74cc2af33ceb PR] to view the changes to old test cases.

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

== Conclusions and Future Work ==
'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[https://go.ncsu.edu/fab_four_deployed_application Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T15:04:03Z

Schidar: /* Useful Links */

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

We simplified the way we are handling the second case. For each topic, we have a waitlist object associated with it. If a team has requested for a topic that is not available, the team is queued on to the waitlist for this topic. In the waitlist table, we maintain the team id and the topic id for which this team is waitlisted. In the previous implementation, the waitlisting functionality is scattered across multiple files. All this is consolidated and placed in one model file ( waitlists.rb )
=== Issues with previous functionality ===
The previous implementation had 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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we have rewritten the methods in multiple controllers and model files that manipulate waitlists of a topic. All these classes now just invoke methods of waitlist_teams.rb. The following files contains the waitlist functionality which we have modified to refer to the new model file.

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''

== Design ==

=== Achieved Design Goals ===
Since our goal is to fix existing functionalities we did not update 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. We have eliminated the waitlist.rb file and moved all the references to this class to the new waitlist_teams.rb model file. We tested the existing features and ensured that we are not breaking what was working before we deployed our fix.
We can say that we achieved our goal of making experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Actions performed ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.Changes done 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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a commit] to view the changes.
#sign_up_sheet_controller.rb
##set_values_for_new_topic
###Added code to get waitlisted entries from new table instead of having all the entries from signed_up_teams table. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/15/commits/44a0f06761dfc681d6ed8e6d9ecd3017a816848d commit] to view the changes.
#sign_up_sheet.rb
##cancel_all_wailists
###This method previously has done 2 things, it cancelled waitlist and also updated the signed_up_team topic which needs to be split to comply with single responsibility principle. We ensured that is happening in the current implementation. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-f7b8fbeb82e3d7d5481ba3ed065d55838a21a82ebd055ac076ea36f222f88556 commit] to view the changes.
##create_SignUpTeam
### This method in the previous implementation checked if topic has slots. If yes, it added to signed up team, else created a signup as waitlist. We modified this in order to use the new table and call the functions of waitlist_teams.rb to perform actions on waitlists. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/12/commits/7194a53ec01e78ea0d95920624436da6fe9933e2 commit] to view the changes.
#sign_up_topic.rb
##users_on_waiting_list - Moved this method to fetch all users on waitlist for a topic to waitlist_teams model file.
##assign_to_first_waiting_team - The same functionality is being called in multiple places. This is modified to comply with DRY and is moved to the waitlist_teams model
##reassign_topic - Modified this method to use waitlist_teams.rb model file for actions on waitlisted teams.
##update_waitlisted_users - Moved this method to waitlist_teams model file.
##find_slots_waitlisted - Moved this method to waitlist_teams model file.
##find_waitlisted_topics - Moved this method to waitlist_teams model file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-e0df714a791bc6d36e6b27b82af71be36e8eac2cd21af5ea28a8bc5303953f5b diff] to view the changes.
#suggestion_controller.rb
##notification - Clean waitlist functionality is moved to a method in waitlist_teams model. team id is passed as a parameter to delete the waitlist for that team. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/14/files PR] to view the changes.
#invitation.rb
##remove_waitlists_for_team - Removed this method as we dont need it in this file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-c899291de1875b0c2483c0f132ed4503e6c33be63148d6e5d1f4235bfeb1c331 diff] to view the changes.

===3. Added new waitlist_teams Table ===
We added 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 is used to check the first team waitlisted instead of using queues to implement the functionality.
 
Having separated tables for signups and waitlists helps us in managing entries and enforcing constraints and makes it easier to implement and extend functionality if required.
 
The waitlist_teams.rb model class performs the following operations
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-0b3fc155270b76c5cdbf311acb356fbcd90873d2704bf87c44ee1d5ce111b9ca file] to view the waitlist_teams model.

=== 4. Migrated existing waitlists to use new table===
Since the signed_up_teams table will no longer be used to store the waitlists, we moved all the entries for waitlisted teams to the new table so that all the existing waitlists don't get affected.
 
We have written a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
 
This ensures minimal regression breakages and that all existing functionalities are retained. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-327e3874b03ef13dc2d75451388a63d2d28dd775df41e2d48389eb701667f5cb file] to view the migration script.

== Implementation ==
'''1. Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
Please watch this [https://www.youtube.com/watch?v=L6NntAvnzUo Video Demonstration] where we explain the bugs we rectified in this project.

=== Testing Goals and Test Objects ===

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

=== RSpec Unit Tests ===
*Student Waitlist
**Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-0e90ff1a02697a3552966c713b541746d6b1226088147dcfe333f9605ebeb576 diff] to view the RSpec unit tests for waitlist_teams.rb model file. Few of them are
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
Scenario: Drop team from the waitlist for a topic
Given: Logged in as a Student
When: The student is waitlisted for a topic
And: Student drops from the waitlist of this topic
Then: The team that the student is a part of should be dropped from the waitlist for the topic.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project is done to ensure that ''
''old test cases still pass.'' Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-41ff53070546cf68377a8592d16001af4558d9aa280bb65a21cf74cc2af33ceb PR] to view the changes to old test cases.

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

== Conclusions and Future Work ==
'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[https://go.ncsu.edu/fab_four_deployed_application Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T15:03:02Z

Schidar: /* Video Demonstration */

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

We simplified the way we are handling the second case. For each topic, we have a waitlist object associated with it. If a team has requested for a topic that is not available, the team is queued on to the waitlist for this topic. In the waitlist table, we maintain the team id and the topic id for which this team is waitlisted. In the previous implementation, the waitlisting functionality is scattered across multiple files. All this is consolidated and placed in one model file ( waitlists.rb )
=== Issues with previous functionality ===
The previous implementation had 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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we have rewritten the methods in multiple controllers and model files that manipulate waitlists of a topic. All these classes now just invoke methods of waitlist_teams.rb. The following files contains the waitlist functionality which we have modified to refer to the new model file.

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''

== Design ==

=== Achieved Design Goals ===
Since our goal is to fix existing functionalities we did not update 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. We have eliminated the waitlist.rb file and moved all the references to this class to the new waitlist_teams.rb model file. We tested the existing features and ensured that we are not breaking what was working before we deployed our fix.
We can say that we achieved our goal of making experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Actions performed ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.Changes done 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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a commit] to view the changes.
#sign_up_sheet_controller.rb
##set_values_for_new_topic
###Added code to get waitlisted entries from new table instead of having all the entries from signed_up_teams table. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/15/commits/44a0f06761dfc681d6ed8e6d9ecd3017a816848d commit] to view the changes.
#sign_up_sheet.rb
##cancel_all_wailists
###This method previously has done 2 things, it cancelled waitlist and also updated the signed_up_team topic which needs to be split to comply with single responsibility principle. We ensured that is happening in the current implementation. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-f7b8fbeb82e3d7d5481ba3ed065d55838a21a82ebd055ac076ea36f222f88556 commit] to view the changes.
##create_SignUpTeam
### This method in the previous implementation checked if topic has slots. If yes, it added to signed up team, else created a signup as waitlist. We modified this in order to use the new table and call the functions of waitlist_teams.rb to perform actions on waitlists. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/12/commits/7194a53ec01e78ea0d95920624436da6fe9933e2 commit] to view the changes.
#sign_up_topic.rb
##users_on_waiting_list - Moved this method to fetch all users on waitlist for a topic to waitlist_teams model file.
##assign_to_first_waiting_team - The same functionality is being called in multiple places. This is modified to comply with DRY and is moved to the waitlist_teams model
##reassign_topic - Modified this method to use waitlist_teams.rb model file for actions on waitlisted teams.
##update_waitlisted_users - Moved this method to waitlist_teams model file.
##find_slots_waitlisted - Moved this method to waitlist_teams model file.
##find_waitlisted_topics - Moved this method to waitlist_teams model file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-e0df714a791bc6d36e6b27b82af71be36e8eac2cd21af5ea28a8bc5303953f5b diff] to view the changes.
#suggestion_controller.rb
##notification - Clean waitlist functionality is moved to a method in waitlist_teams model. team id is passed as a parameter to delete the waitlist for that team. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/14/files PR] to view the changes.
#invitation.rb
##remove_waitlists_for_team - Removed this method as we dont need it in this file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-c899291de1875b0c2483c0f132ed4503e6c33be63148d6e5d1f4235bfeb1c331 diff] to view the changes.

===3. Added new waitlist_teams Table ===
We added 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 is used to check the first team waitlisted instead of using queues to implement the functionality.
 
Having separated tables for signups and waitlists helps us in managing entries and enforcing constraints and makes it easier to implement and extend functionality if required.
 
The waitlist_teams.rb model class performs the following operations
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-0b3fc155270b76c5cdbf311acb356fbcd90873d2704bf87c44ee1d5ce111b9ca file] to view the waitlist_teams model.

=== 4. Migrated existing waitlists to use new table===
Since the signed_up_teams table will no longer be used to store the waitlists, we moved all the entries for waitlisted teams to the new table so that all the existing waitlists don't get affected.
 
We have written a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
 
This ensures minimal regression breakages and that all existing functionalities are retained. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-327e3874b03ef13dc2d75451388a63d2d28dd775df41e2d48389eb701667f5cb file] to view the migration script.

== Implementation ==
'''1. Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
Please watch this [https://www.youtube.com/watch?v=L6NntAvnzUo Video Demonstration] where we explain the bugs we rectified in this project.

=== Testing Goals and Test Objects ===

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

=== RSpec Unit Tests ===
*Student Waitlist
**Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-0e90ff1a02697a3552966c713b541746d6b1226088147dcfe333f9605ebeb576 diff] to view the RSpec unit tests for waitlist_teams.rb model file. Few of them are
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
Scenario: Drop team from the waitlist for a topic
Given: Logged in as a Student
When: The student is waitlisted for a topic
And: Student drops from the waitlist of this topic
Then: The team that the student is a part of should be dropped from the waitlist for the topic.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project is done to ensure that ''
''old test cases still pass.'' Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-41ff53070546cf68377a8592d16001af4558d9aa280bb65a21cf74cc2af33ceb PR] to view the changes to old test cases.

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

== Conclusions and Future Work ==
'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[http://152.7.98.216:8080/view Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T05:13:13Z

Schidar: /* Testing */

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

We simplified the way we are handling the second case. For each topic, we have a waitlist object associated with it. If a team has requested for a topic that is not available, the team is queued on to the waitlist for this topic. In the waitlist table, we maintain the team id and the topic id for which this team is waitlisted. In the previous implementation, the waitlisting functionality is scattered across multiple files. All this is consolidated and placed in one model file ( waitlists.rb )
=== Issues with previous functionality ===
The previous implementation had 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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we have rewritten the methods in multiple controllers and model files that manipulate waitlists of a topic. All these classes now just invoke methods of waitlist_teams.rb. The following files contains the waitlist functionality which we have modified to refer to the new model file.

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''

== Design ==

=== Achieved Design Goals ===
Since our goal is to fix existing functionalities we did not update 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. We have eliminated the waitlist.rb file and moved all the references to this class to the new waitlist_teams.rb model file. We tested the existing features and ensured that we are not breaking what was working before we deployed our fix.
We can say that we achieved our goal of making experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Actions performed ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.Changes done 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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a commit] to view the changes.
#sign_up_sheet_controller.rb
##set_values_for_new_topic
###Added code to get waitlisted entries from new table instead of having all the entries from signed_up_teams table. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/15/commits/44a0f06761dfc681d6ed8e6d9ecd3017a816848d commit] to view the changes.
#sign_up_sheet.rb
##cancel_all_wailists
###This method previously has done 2 things, it cancelled waitlist and also updated the signed_up_team topic which needs to be split to comply with single responsibility principle. We ensured that is happening in the current implementation. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-f7b8fbeb82e3d7d5481ba3ed065d55838a21a82ebd055ac076ea36f222f88556 commit] to view the changes.
##create_SignUpTeam
### This method in the previous implementation checked if topic has slots. If yes, it added to signed up team, else created a signup as waitlist. We modified this in order to use the new table and call the functions of waitlist_teams.rb to perform actions on waitlists. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/12/commits/7194a53ec01e78ea0d95920624436da6fe9933e2 commit] to view the changes.
#sign_up_topic.rb
##users_on_waiting_list - Moved this method to fetch all users on waitlist for a topic to waitlist_teams model file.
##assign_to_first_waiting_team - The same functionality is being called in multiple places. This is modified to comply with DRY and is moved to the waitlist_teams model
##reassign_topic - Modified this method to use waitlist_teams.rb model file for actions on waitlisted teams.
##update_waitlisted_users - Moved this method to waitlist_teams model file.
##find_slots_waitlisted - Moved this method to waitlist_teams model file.
##find_waitlisted_topics - Moved this method to waitlist_teams model file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-e0df714a791bc6d36e6b27b82af71be36e8eac2cd21af5ea28a8bc5303953f5b diff] to view the changes.
#suggestion_controller.rb
##notification - Clean waitlist functionality is moved to a method in waitlist_teams model. team id is passed as a parameter to delete the waitlist for that team. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/14/files PR] to view the changes.
#invitation.rb
##remove_waitlists_for_team - Removed this method as we dont need it in this file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-c899291de1875b0c2483c0f132ed4503e6c33be63148d6e5d1f4235bfeb1c331 diff] to view the changes.

===3. Added new waitlist_teams Table ===
We added 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 is used to check the first team waitlisted instead of using queues to implement the functionality.
 
Having separated tables for signups and waitlists helps us in managing entries and enforcing constraints and makes it easier to implement and extend functionality if required.
 
The waitlist_teams.rb model class performs the following operations
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-0b3fc155270b76c5cdbf311acb356fbcd90873d2704bf87c44ee1d5ce111b9ca file] to view the waitlist_teams model.

=== 4. Migrated existing waitlists to use new table===
Since the signed_up_teams table will no longer be used to store the waitlists, we moved all the entries for waitlisted teams to the new table so that all the existing waitlists don't get affected.
 
We have written a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
 
This ensures minimal regression breakages and that all existing functionalities are retained. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-327e3874b03ef13dc2d75451388a63d2d28dd775df41e2d48389eb701667f5cb file] to view the migration script.

== Implementation ==
'''1. Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

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

=== RSpec Unit Tests ===
*Student Waitlist
**Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-0e90ff1a02697a3552966c713b541746d6b1226088147dcfe333f9605ebeb576 diff] to view the RSpec unit tests for waitlist_teams.rb model file. Few of them are
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
Scenario: Drop team from the waitlist for a topic
Given: Logged in as a Student
When: The student is waitlisted for a topic
And: Student drops from the waitlist of this topic
Then: The team that the student is a part of should be dropped from the waitlist for the topic.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Regression Testing ===
''In order to ensure complete coverage, testing of the changes done between the end of last semester and this project is done to ensure that ''
''old test cases still pass.'' Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-41ff53070546cf68377a8592d16001af4558d9aa280bb65a21cf74cc2af33ceb PR] to view the changes to old test cases.

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

== Conclusions and Future Work ==
'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[http://152.7.98.216:8080/view Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T05:10:03Z

Schidar: /* Conclusions and Future Work */

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

We simplified the way we are handling the second case. For each topic, we have a waitlist object associated with it. If a team has requested for a topic that is not available, the team is queued on to the waitlist for this topic. In the waitlist table, we maintain the team id and the topic id for which this team is waitlisted. In the previous implementation, the waitlisting functionality is scattered across multiple files. All this is consolidated and placed in one model file ( waitlists.rb )
=== Issues with previous functionality ===
The previous implementation had 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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we have rewritten the methods in multiple controllers and model files that manipulate waitlists of a topic. All these classes now just invoke methods of waitlist_teams.rb. The following files contains the waitlist functionality which we have modified to refer to the new model file.

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''

== Design ==

=== Achieved Design Goals ===
Since our goal is to fix existing functionalities we did not update 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. We have eliminated the waitlist.rb file and moved all the references to this class to the new waitlist_teams.rb model file. We tested the existing features and ensured that we are not breaking what was working before we deployed our fix.
We can say that we achieved our goal of making experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Actions performed ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.Changes done 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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a commit] to view the changes.
#sign_up_sheet_controller.rb
##set_values_for_new_topic
###Added code to get waitlisted entries from new table instead of having all the entries from signed_up_teams table. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/15/commits/44a0f06761dfc681d6ed8e6d9ecd3017a816848d commit] to view the changes.
#sign_up_sheet.rb
##cancel_all_wailists
###This method previously has done 2 things, it cancelled waitlist and also updated the signed_up_team topic which needs to be split to comply with single responsibility principle. We ensured that is happening in the current implementation. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-f7b8fbeb82e3d7d5481ba3ed065d55838a21a82ebd055ac076ea36f222f88556 commit] to view the changes.
##create_SignUpTeam
### This method in the previous implementation checked if topic has slots. If yes, it added to signed up team, else created a signup as waitlist. We modified this in order to use the new table and call the functions of waitlist_teams.rb to perform actions on waitlists. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/12/commits/7194a53ec01e78ea0d95920624436da6fe9933e2 commit] to view the changes.
#sign_up_topic.rb
##users_on_waiting_list - Moved this method to fetch all users on waitlist for a topic to waitlist_teams model file.
##assign_to_first_waiting_team - The same functionality is being called in multiple places. This is modified to comply with DRY and is moved to the waitlist_teams model
##reassign_topic - Modified this method to use waitlist_teams.rb model file for actions on waitlisted teams.
##update_waitlisted_users - Moved this method to waitlist_teams model file.
##find_slots_waitlisted - Moved this method to waitlist_teams model file.
##find_waitlisted_topics - Moved this method to waitlist_teams model file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-e0df714a791bc6d36e6b27b82af71be36e8eac2cd21af5ea28a8bc5303953f5b diff] to view the changes.
#suggestion_controller.rb
##notification - Clean waitlist functionality is moved to a method in waitlist_teams model. team id is passed as a parameter to delete the waitlist for that team. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/14/files PR] to view the changes.
#invitation.rb
##remove_waitlists_for_team - Removed this method as we dont need it in this file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-c899291de1875b0c2483c0f132ed4503e6c33be63148d6e5d1f4235bfeb1c331 diff] to view the changes.

===3. Added new waitlist_teams Table ===
We added 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 is used to check the first team waitlisted instead of using queues to implement the functionality.
 
Having separated tables for signups and waitlists helps us in managing entries and enforcing constraints and makes it easier to implement and extend functionality if required.
 
The waitlist_teams.rb model class performs the following operations
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-0b3fc155270b76c5cdbf311acb356fbcd90873d2704bf87c44ee1d5ce111b9ca file] to view the waitlist_teams model.

=== 4. Migrated existing waitlists to use new table===
Since the signed_up_teams table will no longer be used to store the waitlists, we moved all the entries for waitlisted teams to the new table so that all the existing waitlists don't get affected.
 
We have written a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
 
This ensures minimal regression breakages and that all existing functionalities are retained. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-327e3874b03ef13dc2d75451388a63d2d28dd775df41e2d48389eb701667f5cb file] to view the migration script.

== Implementation ==
'''1. Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

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

=== RSpec Unit Tests ===
*Student Waitlist
**Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-0e90ff1a02697a3552966c713b541746d6b1226088147dcfe333f9605ebeb576 diff] to view the RSpec unit tests for waitlist_teams.rb model file. Few of them are
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
Scenario: Drop team from the waitlist for a topic
Given: Logged in as a Student
When: The student is waitlisted for a topic
And: Student drops from the waitlist of this topic
Then: The team that the student is a part of should be dropped from the waitlist for the topic.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

# Make sure all existing waitlist functionality still passes

== Conclusions and Future Work ==
'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[http://152.7.98.216:8080/view Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T05:09:27Z

Schidar: /* RSpec Unit Tests */

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

We simplified the way we are handling the second case. For each topic, we have a waitlist object associated with it. If a team has requested for a topic that is not available, the team is queued on to the waitlist for this topic. In the waitlist table, we maintain the team id and the topic id for which this team is waitlisted. In the previous implementation, the waitlisting functionality is scattered across multiple files. All this is consolidated and placed in one model file ( waitlists.rb )
=== Issues with previous functionality ===
The previous implementation had 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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we have rewritten the methods in multiple controllers and model files that manipulate waitlists of a topic. All these classes now just invoke methods of waitlist_teams.rb. The following files contains the waitlist functionality which we have modified to refer to the new model file.

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''

== Design ==

=== Achieved Design Goals ===
Since our goal is to fix existing functionalities we did not update 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. We have eliminated the waitlist.rb file and moved all the references to this class to the new waitlist_teams.rb model file. We tested the existing features and ensured that we are not breaking what was working before we deployed our fix.
We can say that we achieved our goal of making experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Actions performed ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.Changes done 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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a commit] to view the changes.
#sign_up_sheet_controller.rb
##set_values_for_new_topic
###Added code to get waitlisted entries from new table instead of having all the entries from signed_up_teams table. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/15/commits/44a0f06761dfc681d6ed8e6d9ecd3017a816848d commit] to view the changes.
#sign_up_sheet.rb
##cancel_all_wailists
###This method previously has done 2 things, it cancelled waitlist and also updated the signed_up_team topic which needs to be split to comply with single responsibility principle. We ensured that is happening in the current implementation. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-f7b8fbeb82e3d7d5481ba3ed065d55838a21a82ebd055ac076ea36f222f88556 commit] to view the changes.
##create_SignUpTeam
### This method in the previous implementation checked if topic has slots. If yes, it added to signed up team, else created a signup as waitlist. We modified this in order to use the new table and call the functions of waitlist_teams.rb to perform actions on waitlists. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/12/commits/7194a53ec01e78ea0d95920624436da6fe9933e2 commit] to view the changes.
#sign_up_topic.rb
##users_on_waiting_list - Moved this method to fetch all users on waitlist for a topic to waitlist_teams model file.
##assign_to_first_waiting_team - The same functionality is being called in multiple places. This is modified to comply with DRY and is moved to the waitlist_teams model
##reassign_topic - Modified this method to use waitlist_teams.rb model file for actions on waitlisted teams.
##update_waitlisted_users - Moved this method to waitlist_teams model file.
##find_slots_waitlisted - Moved this method to waitlist_teams model file.
##find_waitlisted_topics - Moved this method to waitlist_teams model file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-e0df714a791bc6d36e6b27b82af71be36e8eac2cd21af5ea28a8bc5303953f5b diff] to view the changes.
#suggestion_controller.rb
##notification - Clean waitlist functionality is moved to a method in waitlist_teams model. team id is passed as a parameter to delete the waitlist for that team. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/14/files PR] to view the changes.
#invitation.rb
##remove_waitlists_for_team - Removed this method as we dont need it in this file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-c899291de1875b0c2483c0f132ed4503e6c33be63148d6e5d1f4235bfeb1c331 diff] to view the changes.

===3. Added new waitlist_teams Table ===
We added 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 is used to check the first team waitlisted instead of using queues to implement the functionality.
 
Having separated tables for signups and waitlists helps us in managing entries and enforcing constraints and makes it easier to implement and extend functionality if required.
 
The waitlist_teams.rb model class performs the following operations
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-0b3fc155270b76c5cdbf311acb356fbcd90873d2704bf87c44ee1d5ce111b9ca file] to view the waitlist_teams model.

=== 4. Migrated existing waitlists to use new table===
Since the signed_up_teams table will no longer be used to store the waitlists, we moved all the entries for waitlisted teams to the new table so that all the existing waitlists don't get affected.
 
We have written a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
 
This ensures minimal regression breakages and that all existing functionalities are retained. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-327e3874b03ef13dc2d75451388a63d2d28dd775df41e2d48389eb701667f5cb file] to view the migration script.

== Implementation ==
'''1. Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

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

=== RSpec Unit Tests ===
*Student Waitlist
**Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-0e90ff1a02697a3552966c713b541746d6b1226088147dcfe333f9605ebeb576 diff] to view the RSpec unit tests for waitlist_teams.rb model file. Few of them are
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
Scenario: Drop team from the waitlist for a topic
Given: Logged in as a Student
When: The student is waitlisted for a topic
And: Student drops from the waitlist of this topic
Then: The team that the student is a part of should be dropped from the waitlist for the topic.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

# Make sure all existing waitlist functionality still passes

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* ''will be added for final submission''

'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[http://152.7.98.216:8080/view Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T05:08:54Z

Schidar: /* RSpec Unit Tests */

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

We simplified the way we are handling the second case. For each topic, we have a waitlist object associated with it. If a team has requested for a topic that is not available, the team is queued on to the waitlist for this topic. In the waitlist table, we maintain the team id and the topic id for which this team is waitlisted. In the previous implementation, the waitlisting functionality is scattered across multiple files. All this is consolidated and placed in one model file ( waitlists.rb )
=== Issues with previous functionality ===
The previous implementation had 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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we have rewritten the methods in multiple controllers and model files that manipulate waitlists of a topic. All these classes now just invoke methods of waitlist_teams.rb. The following files contains the waitlist functionality which we have modified to refer to the new model file.

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''

== Design ==

=== Achieved Design Goals ===
Since our goal is to fix existing functionalities we did not update 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. We have eliminated the waitlist.rb file and moved all the references to this class to the new waitlist_teams.rb model file. We tested the existing features and ensured that we are not breaking what was working before we deployed our fix.
We can say that we achieved our goal of making experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Actions performed ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.Changes done 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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a commit] to view the changes.
#sign_up_sheet_controller.rb
##set_values_for_new_topic
###Added code to get waitlisted entries from new table instead of having all the entries from signed_up_teams table. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/15/commits/44a0f06761dfc681d6ed8e6d9ecd3017a816848d commit] to view the changes.
#sign_up_sheet.rb
##cancel_all_wailists
###This method previously has done 2 things, it cancelled waitlist and also updated the signed_up_team topic which needs to be split to comply with single responsibility principle. We ensured that is happening in the current implementation. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-f7b8fbeb82e3d7d5481ba3ed065d55838a21a82ebd055ac076ea36f222f88556 commit] to view the changes.
##create_SignUpTeam
### This method in the previous implementation checked if topic has slots. If yes, it added to signed up team, else created a signup as waitlist. We modified this in order to use the new table and call the functions of waitlist_teams.rb to perform actions on waitlists. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/12/commits/7194a53ec01e78ea0d95920624436da6fe9933e2 commit] to view the changes.
#sign_up_topic.rb
##users_on_waiting_list - Moved this method to fetch all users on waitlist for a topic to waitlist_teams model file.
##assign_to_first_waiting_team - The same functionality is being called in multiple places. This is modified to comply with DRY and is moved to the waitlist_teams model
##reassign_topic - Modified this method to use waitlist_teams.rb model file for actions on waitlisted teams.
##update_waitlisted_users - Moved this method to waitlist_teams model file.
##find_slots_waitlisted - Moved this method to waitlist_teams model file.
##find_waitlisted_topics - Moved this method to waitlist_teams model file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-e0df714a791bc6d36e6b27b82af71be36e8eac2cd21af5ea28a8bc5303953f5b diff] to view the changes.
#suggestion_controller.rb
##notification - Clean waitlist functionality is moved to a method in waitlist_teams model. team id is passed as a parameter to delete the waitlist for that team. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/14/files PR] to view the changes.
#invitation.rb
##remove_waitlists_for_team - Removed this method as we dont need it in this file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-c899291de1875b0c2483c0f132ed4503e6c33be63148d6e5d1f4235bfeb1c331 diff] to view the changes.

===3. Added new waitlist_teams Table ===
We added 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 is used to check the first team waitlisted instead of using queues to implement the functionality.
 
Having separated tables for signups and waitlists helps us in managing entries and enforcing constraints and makes it easier to implement and extend functionality if required.
 
The waitlist_teams.rb model class performs the following operations
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-0b3fc155270b76c5cdbf311acb356fbcd90873d2704bf87c44ee1d5ce111b9ca file] to view the waitlist_teams model.

=== 4. Migrated existing waitlists to use new table===
Since the signed_up_teams table will no longer be used to store the waitlists, we moved all the entries for waitlisted teams to the new table so that all the existing waitlists don't get affected.
 
We have written a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
 
This ensures minimal regression breakages and that all existing functionalities are retained. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-327e3874b03ef13dc2d75451388a63d2d28dd775df41e2d48389eb701667f5cb file] to view the migration script.

== Implementation ==
'''1. Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

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

=== RSpec Unit Tests ===
*Student Waitlist
Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-0e90ff1a02697a3552966c713b541746d6b1226088147dcfe333f9605ebeb576 diff] to view the RSpec unit tests for waitlist_teams.rb model file. Few of them are
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
Scenario: Drop team from the waitlist for a topic
Given: Logged in as a Student
When: The student is waitlisted for a topic
And: Student drops from the waitlist of this topic
Then: The team that the student is a part of should be dropped from the waitlist for the topic.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

# Make sure all existing waitlist functionality still passes

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* ''will be added for final submission''

'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[http://152.7.98.216:8080/view Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T05:05:06Z

Schidar: /* RSpec Unit Tests */

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

We simplified the way we are handling the second case. For each topic, we have a waitlist object associated with it. If a team has requested for a topic that is not available, the team is queued on to the waitlist for this topic. In the waitlist table, we maintain the team id and the topic id for which this team is waitlisted. In the previous implementation, the waitlisting functionality is scattered across multiple files. All this is consolidated and placed in one model file ( waitlists.rb )
=== Issues with previous functionality ===
The previous implementation had 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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we have rewritten the methods in multiple controllers and model files that manipulate waitlists of a topic. All these classes now just invoke methods of waitlist_teams.rb. The following files contains the waitlist functionality which we have modified to refer to the new model file.

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''

== Design ==

=== Achieved Design Goals ===
Since our goal is to fix existing functionalities we did not update 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. We have eliminated the waitlist.rb file and moved all the references to this class to the new waitlist_teams.rb model file. We tested the existing features and ensured that we are not breaking what was working before we deployed our fix.
We can say that we achieved our goal of making experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Actions performed ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.Changes done 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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a commit] to view the changes.
#sign_up_sheet_controller.rb
##set_values_for_new_topic
###Added code to get waitlisted entries from new table instead of having all the entries from signed_up_teams table. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/15/commits/44a0f06761dfc681d6ed8e6d9ecd3017a816848d commit] to view the changes.
#sign_up_sheet.rb
##cancel_all_wailists
###This method previously has done 2 things, it cancelled waitlist and also updated the signed_up_team topic which needs to be split to comply with single responsibility principle. We ensured that is happening in the current implementation. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-f7b8fbeb82e3d7d5481ba3ed065d55838a21a82ebd055ac076ea36f222f88556 commit] to view the changes.
##create_SignUpTeam
### This method in the previous implementation checked if topic has slots. If yes, it added to signed up team, else created a signup as waitlist. We modified this in order to use the new table and call the functions of waitlist_teams.rb to perform actions on waitlists. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/12/commits/7194a53ec01e78ea0d95920624436da6fe9933e2 commit] to view the changes.
#sign_up_topic.rb
##users_on_waiting_list - Moved this method to fetch all users on waitlist for a topic to waitlist_teams model file.
##assign_to_first_waiting_team - The same functionality is being called in multiple places. This is modified to comply with DRY and is moved to the waitlist_teams model
##reassign_topic - Modified this method to use waitlist_teams.rb model file for actions on waitlisted teams.
##update_waitlisted_users - Moved this method to waitlist_teams model file.
##find_slots_waitlisted - Moved this method to waitlist_teams model file.
##find_waitlisted_topics - Moved this method to waitlist_teams model file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-e0df714a791bc6d36e6b27b82af71be36e8eac2cd21af5ea28a8bc5303953f5b diff] to view the changes.
#suggestion_controller.rb
##notification - Clean waitlist functionality is moved to a method in waitlist_teams model. team id is passed as a parameter to delete the waitlist for that team. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/14/files PR] to view the changes.
#invitation.rb
##remove_waitlists_for_team - Removed this method as we dont need it in this file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-c899291de1875b0c2483c0f132ed4503e6c33be63148d6e5d1f4235bfeb1c331 diff] to view the changes.

===3. Added new waitlist_teams Table ===
We added 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 is used to check the first team waitlisted instead of using queues to implement the functionality.
 
Having separated tables for signups and waitlists helps us in managing entries and enforcing constraints and makes it easier to implement and extend functionality if required.
 
The waitlist_teams.rb model class performs the following operations
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-0b3fc155270b76c5cdbf311acb356fbcd90873d2704bf87c44ee1d5ce111b9ca file] to view the waitlist_teams model.

=== 4. Migrated existing waitlists to use new table===
Since the signed_up_teams table will no longer be used to store the waitlists, we moved all the entries for waitlisted teams to the new table so that all the existing waitlists don't get affected.
 
We have written a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
 
This ensures minimal regression breakages and that all existing functionalities are retained. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-327e3874b03ef13dc2d75451388a63d2d28dd775df41e2d48389eb701667f5cb file] to view the migration script.

== Implementation ==
'''1. Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

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

=== RSpec Unit Tests ===
Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-0e90ff1a02697a3552966c713b541746d6b1226088147dcfe333f9605ebeb576 diff] to view the RSpec unit tests for waitlist_teams.rb model file.
*Student Waitlist
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
Scenario: Dropping from the waitlist for a topic
Given: Logged in as a Student
When: The student is waitlisted for a topic
And: Student drops from the waitlist of this topic
Then: The team that the student is a part of should be dropped from the waitlist for the topic.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

# Make sure all existing waitlist functionality still passes

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* ''will be added for final submission''

'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[http://152.7.98.216:8080/view Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T04:49:41Z

Schidar: /* Implementation */

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

We simplified the way we are handling the second case. For each topic, we have a waitlist object associated with it. If a team has requested for a topic that is not available, the team is queued on to the waitlist for this topic. In the waitlist table, we maintain the team id and the topic id for which this team is waitlisted. In the previous implementation, the waitlisting functionality is scattered across multiple files. All this is consolidated and placed in one model file ( waitlists.rb )
=== Issues with previous functionality ===
The previous implementation had 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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we have rewritten the methods in multiple controllers and model files that manipulate waitlists of a topic. All these classes now just invoke methods of waitlist_teams.rb. The following files contains the waitlist functionality which we have modified to refer to the new model file.

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''

== Design ==

=== Achieved Design Goals ===
Since our goal is to fix existing functionalities we did not update 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. We have eliminated the waitlist.rb file and moved all the references to this class to the new waitlist_teams.rb model file. We tested the existing features and ensured that we are not breaking what was working before we deployed our fix.
We can say that we achieved our goal of making experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Actions performed ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.Changes done 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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a commit] to view the changes.
#sign_up_sheet_controller.rb
##set_values_for_new_topic
###Added code to get waitlisted entries from new table instead of having all the entries from signed_up_teams table. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/15/commits/44a0f06761dfc681d6ed8e6d9ecd3017a816848d commit] to view the changes.
#sign_up_sheet.rb
##cancel_all_wailists
###This method previously has done 2 things, it cancelled waitlist and also updated the signed_up_team topic which needs to be split to comply with single responsibility principle. We ensured that is happening in the current implementation. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-f7b8fbeb82e3d7d5481ba3ed065d55838a21a82ebd055ac076ea36f222f88556 commit] to view the changes.
##create_SignUpTeam
### This method in the previous implementation checked if topic has slots. If yes, it added to signed up team, else created a signup as waitlist. We modified this in order to use the new table and call the functions of waitlist_teams.rb to perform actions on waitlists. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/12/commits/7194a53ec01e78ea0d95920624436da6fe9933e2 commit] to view the changes.
#sign_up_topic.rb
##users_on_waiting_list - Moved this method to fetch all users on waitlist for a topic to waitlist_teams model file.
##assign_to_first_waiting_team - The same functionality is being called in multiple places. This is modified to comply with DRY and is moved to the waitlist_teams model
##reassign_topic - Modified this method to use waitlist_teams.rb model file for actions on waitlisted teams.
##update_waitlisted_users - Moved this method to waitlist_teams model file.
##find_slots_waitlisted - Moved this method to waitlist_teams model file.
##find_waitlisted_topics - Moved this method to waitlist_teams model file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-e0df714a791bc6d36e6b27b82af71be36e8eac2cd21af5ea28a8bc5303953f5b diff] to view the changes.
#suggestion_controller.rb
##notification - Clean waitlist functionality is moved to a method in waitlist_teams model. team id is passed as a parameter to delete the waitlist for that team. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/14/files PR] to view the changes.
#invitation.rb
##remove_waitlists_for_team - Removed this method as we dont need it in this file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-c899291de1875b0c2483c0f132ed4503e6c33be63148d6e5d1f4235bfeb1c331 diff] to view the changes.

===3. Added new waitlist_teams Table ===
We added 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 is used to check the first team waitlisted instead of using queues to implement the functionality.
 
Having separated tables for signups and waitlists helps us in managing entries and enforcing constraints and makes it easier to implement and extend functionality if required.
 
The waitlist_teams.rb model class performs the following operations
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-0b3fc155270b76c5cdbf311acb356fbcd90873d2704bf87c44ee1d5ce111b9ca file] to view the waitlist_teams model.

=== 4. Migrated existing waitlists to use new table===
Since the signed_up_teams table will no longer be used to store the waitlists, we moved all the entries for waitlisted teams to the new table so that all the existing waitlists don't get affected.
 
We have written a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
 
This ensures minimal regression breakages and that all existing functionalities are retained. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-327e3874b03ef13dc2d75451388a63d2d28dd775df41e2d48389eb701667f5cb file] to view the migration script.

== Implementation ==
'''1. Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

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

=== RSpec Unit Tests ===
*Student Waitlist
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

# Make sure all existing waitlist functionality still passes

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* ''will be added for final submission''

'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[http://152.7.98.216:8080/view Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T04:49:18Z

Schidar: /* RSpec Unit Tests */

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

We simplified the way we are handling the second case. For each topic, we have a waitlist object associated with it. If a team has requested for a topic that is not available, the team is queued on to the waitlist for this topic. In the waitlist table, we maintain the team id and the topic id for which this team is waitlisted. In the previous implementation, the waitlisting functionality is scattered across multiple files. All this is consolidated and placed in one model file ( waitlists.rb )
=== Issues with previous functionality ===
The previous implementation had 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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we have rewritten the methods in multiple controllers and model files that manipulate waitlists of a topic. All these classes now just invoke methods of waitlist_teams.rb. The following files contains the waitlist functionality which we have modified to refer to the new model file.

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''

== Design ==

=== Achieved Design Goals ===
Since our goal is to fix existing functionalities we did not update 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. We have eliminated the waitlist.rb file and moved all the references to this class to the new waitlist_teams.rb model file. We tested the existing features and ensured that we are not breaking what was working before we deployed our fix.
We can say that we achieved our goal of making experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Actions performed ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.Changes done 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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a commit] to view the changes.
#sign_up_sheet_controller.rb
##set_values_for_new_topic
###Added code to get waitlisted entries from new table instead of having all the entries from signed_up_teams table. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/15/commits/44a0f06761dfc681d6ed8e6d9ecd3017a816848d commit] to view the changes.
#sign_up_sheet.rb
##cancel_all_wailists
###This method previously has done 2 things, it cancelled waitlist and also updated the signed_up_team topic which needs to be split to comply with single responsibility principle. We ensured that is happening in the current implementation. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-f7b8fbeb82e3d7d5481ba3ed065d55838a21a82ebd055ac076ea36f222f88556 commit] to view the changes.
##create_SignUpTeam
### This method in the previous implementation checked if topic has slots. If yes, it added to signed up team, else created a signup as waitlist. We modified this in order to use the new table and call the functions of waitlist_teams.rb to perform actions on waitlists. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/12/commits/7194a53ec01e78ea0d95920624436da6fe9933e2 commit] to view the changes.
#sign_up_topic.rb
##users_on_waiting_list - Moved this method to fetch all users on waitlist for a topic to waitlist_teams model file.
##assign_to_first_waiting_team - The same functionality is being called in multiple places. This is modified to comply with DRY and is moved to the waitlist_teams model
##reassign_topic - Modified this method to use waitlist_teams.rb model file for actions on waitlisted teams.
##update_waitlisted_users - Moved this method to waitlist_teams model file.
##find_slots_waitlisted - Moved this method to waitlist_teams model file.
##find_waitlisted_topics - Moved this method to waitlist_teams model file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-e0df714a791bc6d36e6b27b82af71be36e8eac2cd21af5ea28a8bc5303953f5b diff] to view the changes.
#suggestion_controller.rb
##notification - Clean waitlist functionality is moved to a method in waitlist_teams model. team id is passed as a parameter to delete the waitlist for that team. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/14/files PR] to view the changes.
#invitation.rb
##remove_waitlists_for_team - Removed this method as we dont need it in this file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-c899291de1875b0c2483c0f132ed4503e6c33be63148d6e5d1f4235bfeb1c331 diff] to view the changes.

===3. Added new waitlist_teams Table ===
We added 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 is used to check the first team waitlisted instead of using queues to implement the functionality.
 
Having separated tables for signups and waitlists helps us in managing entries and enforcing constraints and makes it easier to implement and extend functionality if required.
 
The waitlist_teams.rb model class performs the following operations
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-0b3fc155270b76c5cdbf311acb356fbcd90873d2704bf87c44ee1d5ce111b9ca file] to view the waitlist_teams model.

=== 4. Migrated existing waitlists to use new table===
Since the signed_up_teams table will no longer be used to store the waitlists, we moved all the entries for waitlisted teams to the new table so that all the existing waitlists don't get affected.
 
We have written a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
 
This ensures minimal regression breakages and that all existing functionalities are retained. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-327e3874b03ef13dc2d75451388a63d2d28dd775df41e2d48389eb701667f5cb file] to view the migration script.

== Implementation ==
'''1. Adding Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

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

=== RSpec Unit Tests ===
*Student Waitlist
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

# Make sure all existing waitlist functionality still passes

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* ''will be added for final submission''

'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[http://152.7.98.216:8080/view Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T04:15:56Z

Schidar: /* Actions performed */

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

We simplified the way we are handling the second case. For each topic, we have a waitlist object associated with it. If a team has requested for a topic that is not available, the team is queued on to the waitlist for this topic. In the waitlist table, we maintain the team id and the topic id for which this team is waitlisted. In the previous implementation, the waitlisting functionality is scattered across multiple files. All this is consolidated and placed in one model file ( waitlists.rb )
=== Issues with previous functionality ===
The previous implementation had 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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we have rewritten the methods in multiple controllers and model files that manipulate waitlists of a topic. All these classes now just invoke methods of waitlist_teams.rb. The following files contains the waitlist functionality which we have modified to refer to the new model file.

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''

== Design ==

=== Achieved Design Goals ===
Since our goal is to fix existing functionalities we did not update 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. We have eliminated the waitlist.rb file and moved all the references to this class to the new waitlist_teams.rb model file. We tested the existing features and ensured that we are not breaking what was working before we deployed our fix.
We can say that we achieved our goal of making experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Actions performed ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.Changes done 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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a commit] to view the changes.
#sign_up_sheet_controller.rb
##set_values_for_new_topic
###Added code to get waitlisted entries from new table instead of having all the entries from signed_up_teams table. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/15/commits/44a0f06761dfc681d6ed8e6d9ecd3017a816848d commit] to view the changes.
#sign_up_sheet.rb
##cancel_all_wailists
###This method previously has done 2 things, it cancelled waitlist and also updated the signed_up_team topic which needs to be split to comply with single responsibility principle. We ensured that is happening in the current implementation. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-f7b8fbeb82e3d7d5481ba3ed065d55838a21a82ebd055ac076ea36f222f88556 commit] to view the changes.
##create_SignUpTeam
### This method in the previous implementation checked if topic has slots. If yes, it added to signed up team, else created a signup as waitlist. We modified this in order to use the new table and call the functions of waitlist_teams.rb to perform actions on waitlists. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/12/commits/7194a53ec01e78ea0d95920624436da6fe9933e2 commit] to view the changes.
#sign_up_topic.rb
##users_on_waiting_list - Moved this method to fetch all users on waitlist for a topic to waitlist_teams model file.
##assign_to_first_waiting_team - The same functionality is being called in multiple places. This is modified to comply with DRY and is moved to the waitlist_teams model
##reassign_topic - Modified this method to use waitlist_teams.rb model file for actions on waitlisted teams.
##update_waitlisted_users - Moved this method to waitlist_teams model file.
##find_slots_waitlisted - Moved this method to waitlist_teams model file.
##find_waitlisted_topics - Moved this method to waitlist_teams model file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-e0df714a791bc6d36e6b27b82af71be36e8eac2cd21af5ea28a8bc5303953f5b diff] to view the changes.
#suggestion_controller.rb
##notification - Clean waitlist functionality is moved to a method in waitlist_teams model. team id is passed as a parameter to delete the waitlist for that team. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/14/files PR] to view the changes.
#invitation.rb
##remove_waitlists_for_team - Removed this method as we dont need it in this file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-c899291de1875b0c2483c0f132ed4503e6c33be63148d6e5d1f4235bfeb1c331 diff] to view the changes.

===3. Added new waitlist_teams Table ===
We added 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 is used to check the first team waitlisted instead of using queues to implement the functionality.
 
Having separated tables for signups and waitlists helps us in managing entries and enforcing constraints and makes it easier to implement and extend functionality if required.
 
The waitlist_teams.rb model class performs the following operations
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-0b3fc155270b76c5cdbf311acb356fbcd90873d2704bf87c44ee1d5ce111b9ca file] to view the waitlist_teams model.

=== 4. Migrated existing waitlists to use new table===
Since the signed_up_teams table will no longer be used to store the waitlists, we moved all the entries for waitlisted teams to the new table so that all the existing waitlists don't get affected.
 
We have written a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
 
This ensures minimal regression breakages and that all existing functionalities are retained. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-327e3874b03ef13dc2d75451388a63d2d28dd775df41e2d48389eb701667f5cb file] to view the migration script.

== Implementation ==
'''1. Adding Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
#Ways to get added to the waitlist for a topic
##Team requests a topic that has no slot available.
##When capacity/max choosers for a topic is increased
##When a student gets added to a team that already has a signed up topic
#Ways to get off a waitlist
##team gets the topic they are waiting for ( all other waitlists are dropped for the team)
##team drops off the waitlist
##instructor drops team from the waitlist
##a drop-topic deadline passes
##team is deleted
##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
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

# Make sure all existing waitlist functionality still passes

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* ''will be added for final submission''

'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[http://152.7.98.216:8080/view Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T04:14:35Z

Schidar: /* Actions performed */

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

We simplified the way we are handling the second case. For each topic, we have a waitlist object associated with it. If a team has requested for a topic that is not available, the team is queued on to the waitlist for this topic. In the waitlist table, we maintain the team id and the topic id for which this team is waitlisted. In the previous implementation, the waitlisting functionality is scattered across multiple files. All this is consolidated and placed in one model file ( waitlists.rb )
=== Issues with previous functionality ===
The previous implementation had 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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we have rewritten the methods in multiple controllers and model files that manipulate waitlists of a topic. All these classes now just invoke methods of waitlist_teams.rb. The following files contains the waitlist functionality which we have modified to refer to the new model file.

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''

== Design ==

=== Achieved Design Goals ===
Since our goal is to fix existing functionalities we did not update 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. We have eliminated the waitlist.rb file and moved all the references to this class to the new waitlist_teams.rb model file. We tested the existing features and ensured that we are not breaking what was working before we deployed our fix.
We can say that we achieved our goal of making experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Actions performed ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.Changes done 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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a commit] to view the changes.
#sign_up_sheet_controller.rb
##set_values_for_new_topic
###Added code to get waitlisted entries from new table instead of having all the entries from signed_up_teams table. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/15/commits/44a0f06761dfc681d6ed8e6d9ecd3017a816848d commit] to view the changes.
#sign_up_sheet.rb
##cancel_all_wailists
###This method previously has done 2 things, it cancelled waitlist and also updated the signed_up_team topic which needs to be split to comply with single responsibility principle. We ensured that is happening in the current implementation. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-f7b8fbeb82e3d7d5481ba3ed065d55838a21a82ebd055ac076ea36f222f88556 commit] to view the changes.
##create_SignUpTeam
### This method in the previous implementation checked if topic has slots. If yes, it added to signed up team, else created a signup as waitlist. We modified this in order to use the new table and call the functions of waitlist_teams.rb to perform actions on waitlists. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/12/commits/7194a53ec01e78ea0d95920624436da6fe9933e2 commit] to view the changes.
#sign_up_topic.rb
##users_on_waiting_list - Moved this method to fetch all users on waitlist for a topic to waitlist_teams model file.
##assign_to_first_waiting_team - The same functionality is being called in multiple places. This is modified to comply with DRY and is moved to the waitlist_teams model
##reassign_topic - Modified this method to use waitlist_teams.rb model file for actions on waitlisted teams.
##update_waitlisted_users - Moved this method to waitlist_teams model file.
##find_slots_waitlisted - Moved this method to waitlist_teams model file.
##find_waitlisted_topics - Moved this method to waitlist_teams model file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-e0df714a791bc6d36e6b27b82af71be36e8eac2cd21af5ea28a8bc5303953f5b diff] to view the changes.
#suggestion_controller.rb
##notification - Clean waitlist functionality is moved to a method in waitlist_teams model. team id is passed as a parameter to delete the waitlist for that team. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/14/files PR] to view the changes.
#invitation.rb
##remove_waitlists_for_team - Removed this method as we dont need it in this file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-c899291de1875b0c2483c0f132ed4503e6c33be63148d6e5d1f4235bfeb1c331 diff] to view the changes.

===3. Added new waitlist_teams Table ===
We added 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 is used to check the first team waitlisted instead of using queues to implement the functionality.
 
Having separated tables for signups and waitlists helps us in managing entries and enforcing constraints and makes it easier to implement and extend functionality if required.
 
The waitlist_teams.rb model class performs the following operations
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment

=== 4. Migrated existing waitlists to use new table===
Since the signed_up_teams table will no longer be used to store the waitlists, we moved all the entries for waitlisted teams to the new table so that all the existing waitlists don't get affected.
 
We have written a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
 
This ensures minimal regression breakages and that all existing functionalities are retained. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-327e3874b03ef13dc2d75451388a63d2d28dd775df41e2d48389eb701667f5cb file] to view the migration script.

== Implementation ==
'''1. Adding Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
#Ways to get added to the waitlist for a topic
##Team requests a topic that has no slot available.
##When capacity/max choosers for a topic is increased
##When a student gets added to a team that already has a signed up topic
#Ways to get off a waitlist
##team gets the topic they are waiting for ( all other waitlists are dropped for the team)
##team drops off the waitlist
##instructor drops team from the waitlist
##a drop-topic deadline passes
##team is deleted
##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
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

# Make sure all existing waitlist functionality still passes

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* ''will be added for final submission''

'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[http://152.7.98.216:8080/view Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T04:13:15Z

Schidar: /* Actions performed */

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

We simplified the way we are handling the second case. For each topic, we have a waitlist object associated with it. If a team has requested for a topic that is not available, the team is queued on to the waitlist for this topic. In the waitlist table, we maintain the team id and the topic id for which this team is waitlisted. In the previous implementation, the waitlisting functionality is scattered across multiple files. All this is consolidated and placed in one model file ( waitlists.rb )
=== Issues with previous functionality ===
The previous implementation had 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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we have rewritten the methods in multiple controllers and model files that manipulate waitlists of a topic. All these classes now just invoke methods of waitlist_teams.rb. The following files contains the waitlist functionality which we have modified to refer to the new model file.

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''

== Design ==

=== Achieved Design Goals ===
Since our goal is to fix existing functionalities we did not update 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. We have eliminated the waitlist.rb file and moved all the references to this class to the new waitlist_teams.rb model file. We tested the existing features and ensured that we are not breaking what was working before we deployed our fix.
We can say that we achieved our goal of making experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Actions performed ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.Changes done 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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a commit] to view the changes.
#sign_up_sheet_controller.rb
##set_values_for_new_topic
###Added code to get waitlisted entries from new table instead of having all the entries from signed_up_teams table. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/15/commits/44a0f06761dfc681d6ed8e6d9ecd3017a816848d commit] to view the changes.
#sign_up_sheet.rb
##cancel_all_wailists
###This method previously has done 2 things, it cancelled waitlist and also updated the signed_up_team topic which needs to be split to comply with single responsibility principle. We ensured that is happening in the current implementation. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-f7b8fbeb82e3d7d5481ba3ed065d55838a21a82ebd055ac076ea36f222f88556 commit] to view the changes.
##create_SignUpTeam
### This method in the previous implementation checked if topic has slots. If yes, it added to signed up team, else created a signup as waitlist. We modified this in order to use the new table and call the functions of waitlist_teams.rb to perform actions on waitlists. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/12/commits/7194a53ec01e78ea0d95920624436da6fe9933e2 commit] to view the changes.
#sign_up_topic.rb
##users_on_waiting_list - Moved this method to fetch all users on waitlist for a topic to waitlist_teams model file.
##assign_to_first_waiting_team - The same functionality is being called in multiple places. This is modified to comply with DRY and is moved to the waitlist_teams model
##reassign_topic - Modified this method to use waitlist_teams.rb model file for actions on waitlisted teams.
##update_waitlisted_users - Moved this method to waitlist_teams model file.
##find_slots_waitlisted - Moved this method to waitlist_teams model file.
##find_waitlisted_topics - Moved this method to waitlist_teams model file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-e0df714a791bc6d36e6b27b82af71be36e8eac2cd21af5ea28a8bc5303953f5b diff] to view the changes.
#suggestion_controller.rb
##notification - Clean waitlist functionality is moved to a method in waitlist_teams model. team id is passed as a parameter to delete the waitlist for that team. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/14/files PR] to view the changes.
#invitation.rb
##remove_waitlists_for_team - Removed this method as we dont need it in this file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-c899291de1875b0c2483c0f132ed4503e6c33be63148d6e5d1f4235bfeb1c331 diff] to view the changes.

===3. Added new waitlist_teams Table ===
We added 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 is used to check the first team waitlisted instead of using queues to implement the functionality.
 
Having separated tables for signups and waitlists helps us in managing entries and enforcing constraints and makes it easier to implement and extend functionality if required.
 
The waitlist_teams.rb model class performs the following operations
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment

=== 4. Migrated existing waitlists to use new table===
Since the signed_up_teams table will no longer be used to store the waitlists, we moved all the entries for waitlisted teams to the new table so that all the existing waitlists don't get affected.
 
We have written a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
 
This ensures minimal regression breakages and that all existing functionalities are retained.

== Implementation ==
'''1. Adding Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
#Ways to get added to the waitlist for a topic
##Team requests a topic that has no slot available.
##When capacity/max choosers for a topic is increased
##When a student gets added to a team that already has a signed up topic
#Ways to get off a waitlist
##team gets the topic they are waiting for ( all other waitlists are dropped for the team)
##team drops off the waitlist
##instructor drops team from the waitlist
##a drop-topic deadline passes
##team is deleted
##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
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

# Make sure all existing waitlist functionality still passes

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* ''will be added for final submission''

'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[http://152.7.98.216:8080/view Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T04:11:36Z

Schidar: /* 4. Migrating existing waitlists to use new table */

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

We simplified the way we are handling the second case. For each topic, we have a waitlist object associated with it. If a team has requested for a topic that is not available, the team is queued on to the waitlist for this topic. In the waitlist table, we maintain the team id and the topic id for which this team is waitlisted. In the previous implementation, the waitlisting functionality is scattered across multiple files. All this is consolidated and placed in one model file ( waitlists.rb )
=== Issues with previous functionality ===
The previous implementation had 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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we have rewritten the methods in multiple controllers and model files that manipulate waitlists of a topic. All these classes now just invoke methods of waitlist_teams.rb. The following files contains the waitlist functionality which we have modified to refer to the new model file.

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''

== Design ==

=== Achieved Design Goals ===
Since our goal is to fix existing functionalities we did not update 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. We have eliminated the waitlist.rb file and moved all the references to this class to the new waitlist_teams.rb model file. We tested the existing features and ensured that we are not breaking what was working before we deployed our fix.
We can say that we achieved our goal of making experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Actions performed ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.Changes done 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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a commit] to view the changes.
#sign_up_sheet_controller.rb
##set_values_for_new_topic
###Added code to get waitlisted entries from new table instead of having all the entries from signed_up_teams table. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/15/commits/44a0f06761dfc681d6ed8e6d9ecd3017a816848d commit] to view the changes.
#sign_up_sheet.rb
##cancel_all_wailists
###This method previously has done 2 things, it cancelled waitlist and also updated the signed_up_team topic which needs to be split to comply with single responsibility principle. We ensured that is happening in the current implementation. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-f7b8fbeb82e3d7d5481ba3ed065d55838a21a82ebd055ac076ea36f222f88556 commit] to view the changes.
##create_SignUpTeam
### This method in the previous implementation checked if topic has slots. If yes, it added to signed up team, else created a signup as waitlist. We modified this in order to use the new table and call the functions of waitlist_teams.rb to perform actions on waitlists. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/12/commits/7194a53ec01e78ea0d95920624436da6fe9933e2 commit] to view the changes.
#sign_up_topic.rb
##users_on_waiting_list - Moved this method to fetch all users on waitlist for a topic to waitlist_teams model file.
##assign_to_first_waiting_team - The same functionality is being called in multiple places. This is modified to comply with DRY and is moved to the waitlist_teams model
##reassign_topic - Modified this method to use waitlist_teams.rb model file for actions on waitlisted teams.
##update_waitlisted_users - Moved this method to waitlist_teams model file.
##find_slots_waitlisted - Moved this method to waitlist_teams model file.
##find_waitlisted_topics - Moved this method to waitlist_teams model file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-e0df714a791bc6d36e6b27b82af71be36e8eac2cd21af5ea28a8bc5303953f5b diff] to view the changes.
#suggestion_controller.rb
##notification - Clean waitlist functionality is moved to a method in waitlist_teams model. team id is passed as a parameter to delete the waitlist for that team. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/14/files PR] to view the changes.
#invitation.rb
##remove_waitlists_for_team - Removed this method as we dont need it in this file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-c899291de1875b0c2483c0f132ed4503e6c33be63148d6e5d1f4235bfeb1c331 diff] to view the changes.

===3. Added new waitlist_teams Table ===
We added 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 is used to check the first team waitlisted instead of using queues to implement the functionality.
 
Having separated tables for signups and waitlists helps us in managing entries and enforcing constraints and makes it easier to implement and extend functionality if required.
 
The waitlist_teams.rb model class performs the following operations
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment

=== 4. Migrated existing waitlists to use new table===
Since the signed_up_teams table will no longer be used to store the waitlists, we moved all the entries for waitlisted teams to the new table so that all the existing waitlists don't get affected.
 
We have written a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
 
This ensures minimal regression breakages and that all existing functionalities are retained.

=== 5. Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
'''1. Adding Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
#Ways to get added to the waitlist for a topic
##Team requests a topic that has no slot available.
##When capacity/max choosers for a topic is increased
##When a student gets added to a team that already has a signed up topic
#Ways to get off a waitlist
##team gets the topic they are waiting for ( all other waitlists are dropped for the team)
##team drops off the waitlist
##instructor drops team from the waitlist
##a drop-topic deadline passes
##team is deleted
##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
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

# Make sure all existing waitlist functionality still passes

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* ''will be added for final submission''

'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[http://152.7.98.216:8080/view Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T04:08:50Z

Schidar: /* Actions performed */

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

We simplified the way we are handling the second case. For each topic, we have a waitlist object associated with it. If a team has requested for a topic that is not available, the team is queued on to the waitlist for this topic. In the waitlist table, we maintain the team id and the topic id for which this team is waitlisted. In the previous implementation, the waitlisting functionality is scattered across multiple files. All this is consolidated and placed in one model file ( waitlists.rb )
=== Issues with previous functionality ===
The previous implementation had 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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we have rewritten the methods in multiple controllers and model files that manipulate waitlists of a topic. All these classes now just invoke methods of waitlist_teams.rb. The following files contains the waitlist functionality which we have modified to refer to the new model file.

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''

== Design ==

=== Achieved Design Goals ===
Since our goal is to fix existing functionalities we did not update 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. We have eliminated the waitlist.rb file and moved all the references to this class to the new waitlist_teams.rb model file. We tested the existing features and ensured that we are not breaking what was working before we deployed our fix.
We can say that we achieved our goal of making experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Actions performed ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.Changes done 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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a commit] to view the changes.
#sign_up_sheet_controller.rb
##set_values_for_new_topic
###Added code to get waitlisted entries from new table instead of having all the entries from signed_up_teams table. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/15/commits/44a0f06761dfc681d6ed8e6d9ecd3017a816848d commit] to view the changes.
#sign_up_sheet.rb
##cancel_all_wailists
###This method previously has done 2 things, it cancelled waitlist and also updated the signed_up_team topic which needs to be split to comply with single responsibility principle. We ensured that is happening in the current implementation. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-f7b8fbeb82e3d7d5481ba3ed065d55838a21a82ebd055ac076ea36f222f88556 commit] to view the changes.
##create_SignUpTeam
### This method in the previous implementation checked if topic has slots. If yes, it added to signed up team, else created a signup as waitlist. We modified this in order to use the new table and call the functions of waitlist_teams.rb to perform actions on waitlists. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/12/commits/7194a53ec01e78ea0d95920624436da6fe9933e2 commit] to view the changes.
#sign_up_topic.rb
##users_on_waiting_list - Moved this method to fetch all users on waitlist for a topic to waitlist_teams model file.
##assign_to_first_waiting_team - The same functionality is being called in multiple places. This is modified to comply with DRY and is moved to the waitlist_teams model
##reassign_topic - Modified this method to use waitlist_teams.rb model file for actions on waitlisted teams.
##update_waitlisted_users - Moved this method to waitlist_teams model file.
##find_slots_waitlisted - Moved this method to waitlist_teams model file.
##find_waitlisted_topics - Moved this method to waitlist_teams model file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-e0df714a791bc6d36e6b27b82af71be36e8eac2cd21af5ea28a8bc5303953f5b diff] to view the changes.
#suggestion_controller.rb
##notification - Clean waitlist functionality is moved to a method in waitlist_teams model. team id is passed as a parameter to delete the waitlist for that team. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/14/files PR] to view the changes.
#invitation.rb
##remove_waitlists_for_team - Removed this method as we dont need it in this file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-c899291de1875b0c2483c0f132ed4503e6c33be63148d6e5d1f4235bfeb1c331 diff] to view the changes.

===3. Added new waitlist_teams Table ===
We added 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 is used to check the first team waitlisted instead of using queues to implement the functionality.
 
Having separated tables for signups and waitlists helps us in managing entries and enforcing constraints and makes it easier to implement and extend functionality if required.
 
The waitlist_teams.rb model class performs the following operations
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment

=== 4. 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.
=== 5. Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
'''1. Adding Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
#Ways to get added to the waitlist for a topic
##Team requests a topic that has no slot available.
##When capacity/max choosers for a topic is increased
##When a student gets added to a team that already has a signed up topic
#Ways to get off a waitlist
##team gets the topic they are waiting for ( all other waitlists are dropped for the team)
##team drops off the waitlist
##instructor drops team from the waitlist
##a drop-topic deadline passes
##team is deleted
##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
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

# Make sure all existing waitlist functionality still passes

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* ''will be added for final submission''

'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[http://152.7.98.216:8080/view Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T04:06:14Z

Schidar: /* 2. Files and methods refactored */

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

We simplified the way we are handling the second case. For each topic, we have a waitlist object associated with it. If a team has requested for a topic that is not available, the team is queued on to the waitlist for this topic. In the waitlist table, we maintain the team id and the topic id for which this team is waitlisted. In the previous implementation, the waitlisting functionality is scattered across multiple files. All this is consolidated and placed in one model file ( waitlists.rb )
=== Issues with previous functionality ===
The previous implementation had 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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we have rewritten the methods in multiple controllers and model files that manipulate waitlists of a topic. All these classes now just invoke methods of waitlist_teams.rb. The following files contains the waitlist functionality which we have modified to refer to the new model file.

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''

== Design ==

=== Achieved Design Goals ===
Since our goal is to fix existing functionalities we did not update 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. We have eliminated the waitlist.rb file and moved all the references to this class to the new waitlist_teams.rb model file. We tested the existing features and ensured that we are not breaking what was working before we deployed our fix.
We can say that we achieved our goal of making experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Actions performed ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a commit] to view the changes.
#sign_up_sheet_controller.rb
##set_values_for_new_topic
###Added code to get waitlisted entries from new table instead of having all the entries from signed_up_teams table. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/15/commits/44a0f06761dfc681d6ed8e6d9ecd3017a816848d commit] to view the changes.
#sign_up_sheet.rb
##cancel_all_wailists
###This method previously has done 2 things, it cancelled waitlist and also updated the signed_up_team topic which needs to be split to comply with single responsibility principle. We ensured that is happening in the current implementation. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-f7b8fbeb82e3d7d5481ba3ed065d55838a21a82ebd055ac076ea36f222f88556 commit] to view the changes.
##create_SignUpTeam
### This method in the previous implementation checked if topic has slots. If yes, it added to signed up team, else created a signup as waitlist. We modified this in order to use the new table and call the functions of waitlist_teams.rb to perform actions on waitlists. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/12/commits/7194a53ec01e78ea0d95920624436da6fe9933e2 commit] to view the changes.
#sign_up_topic.rb
##users_on_waiting_list - Moved this method to fetch all users on waitlist for a topic to waitlist_teams model file.
##assign_to_first_waiting_team - The same functionality is being called in multiple places. This is modified to comply with DRY and is moved to the waitlist_teams model
##reassign_topic - Modified this method to use waitlist_teams.rb model file for actions on waitlisted teams.
##update_waitlisted_users - Moved this method to waitlist_teams model file.
##find_slots_waitlisted - Moved this method to waitlist_teams model file.
##find_waitlisted_topics - Moved this method to waitlist_teams model file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-e0df714a791bc6d36e6b27b82af71be36e8eac2cd21af5ea28a8bc5303953f5b diff] to view the changes.
#suggestion_controller.rb
##notification - Clean waitlist functionality is moved to a method in waitlist_teams model. team id is passed as a parameter to delete the waitlist for that team. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/14/files PR] to view the changes.
#invitation.rb
##remove_waitlists_for_team - Removed this method as we dont need it in this file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-c899291de1875b0c2483c0f132ed4503e6c33be63148d6e5d1f4235bfeb1c331 diff] to view the changes.

===3. 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
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment

=== 4. 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.
=== 5. Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
'''1. Adding Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
#Ways to get added to the waitlist for a topic
##Team requests a topic that has no slot available.
##When capacity/max choosers for a topic is increased
##When a student gets added to a team that already has a signed up topic
#Ways to get off a waitlist
##team gets the topic they are waiting for ( all other waitlists are dropped for the team)
##team drops off the waitlist
##instructor drops team from the waitlist
##a drop-topic deadline passes
##team is deleted
##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
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

# Make sure all existing waitlist functionality still passes

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* ''will be added for final submission''

'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[http://152.7.98.216:8080/view Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T04:05:21Z

Schidar: /* 2. Files and methods refactored */

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

We simplified the way we are handling the second case. For each topic, we have a waitlist object associated with it. If a team has requested for a topic that is not available, the team is queued on to the waitlist for this topic. In the waitlist table, we maintain the team id and the topic id for which this team is waitlisted. In the previous implementation, the waitlisting functionality is scattered across multiple files. All this is consolidated and placed in one model file ( waitlists.rb )
=== Issues with previous functionality ===
The previous implementation had 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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we have rewritten the methods in multiple controllers and model files that manipulate waitlists of a topic. All these classes now just invoke methods of waitlist_teams.rb. The following files contains the waitlist functionality which we have modified to refer to the new model file.

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''

== Design ==

=== Achieved Design Goals ===
Since our goal is to fix existing functionalities we did not update 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. We have eliminated the waitlist.rb file and moved all the references to this class to the new waitlist_teams.rb model file. We tested the existing features and ensured that we are not breaking what was working before we deployed our fix.
We can say that we achieved our goal of making experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Actions performed ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a/view commit] to view the changes.
#sign_up_sheet_controller.rb
##set_values_for_new_topic
###Added code to get waitlisted entries from new table instead of having all the entries from signed_up_teams table. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/15/commits/44a0f06761dfc681d6ed8e6d9ecd3017a816848d/view commit] to view the changes.
#sign_up_sheet.rb
##cancel_all_wailists
###This method previously has done 2 things, it cancelled waitlist and also updated the signed_up_team topic which needs to be split to comply with single responsibility principle. We ensured that is happening in the current implementation. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-f7b8fbeb82e3d7d5481ba3ed065d55838a21a82ebd055ac076ea36f222f88556/view commit] to view the changes.
##create_SignUpTeam
### This method in the previous implementation checked if topic has slots. If yes, it added to signed up team, else created a signup as waitlist. We modified this in order to use the new table and call the functions of waitlist_teams.rb to perform actions on waitlists. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/12/commits/7194a53ec01e78ea0d95920624436da6fe9933e2/view commit] to view the changes.
#sign_up_topic.rb
##users_on_waiting_list - Moved this method to fetch all users on waitlist for a topic to waitlist_teams model file.
##assign_to_first_waiting_team - The same functionality is being called in multiple places. This is modified to comply with DRY and is moved to the waitlist_teams model
##reassign_topic - Modified this method to use waitlist_teams.rb model file for actions on waitlisted teams.
##update_waitlisted_users - Moved this method to waitlist_teams model file.
##find_slots_waitlisted - Moved this method to waitlist_teams model file.
##find_waitlisted_topics - Moved this method to waitlist_teams model file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-e0df714a791bc6d36e6b27b82af71be36e8eac2cd21af5ea28a8bc5303953f5b diff] to view the changes.
#suggestion_controller.rb
##notification - Clean waitlist functionality is moved to a method in waitlist_teams model. team id is passed as a parameter to delete the waitlist for that team. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/14/files PR] to view the changes.
#invitation.rb
##remove_waitlists_for_team - Removed this method as we dont need it in this file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-c899291de1875b0c2483c0f132ed4503e6c33be63148d6e5d1f4235bfeb1c331 diff] to view the changes.

===3. 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
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment

=== 4. 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.
=== 5. Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
'''1. Adding Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
#Ways to get added to the waitlist for a topic
##Team requests a topic that has no slot available.
##When capacity/max choosers for a topic is increased
##When a student gets added to a team that already has a signed up topic
#Ways to get off a waitlist
##team gets the topic they are waiting for ( all other waitlists are dropped for the team)
##team drops off the waitlist
##instructor drops team from the waitlist
##a drop-topic deadline passes
##team is deleted
##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
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

# Make sure all existing waitlist functionality still passes

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* ''will be added for final submission''

'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[http://152.7.98.216:8080/view Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T04:04:22Z

Schidar: /* 2. Files and methods refactored */

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

We simplified the way we are handling the second case. For each topic, we have a waitlist object associated with it. If a team has requested for a topic that is not available, the team is queued on to the waitlist for this topic. In the waitlist table, we maintain the team id and the topic id for which this team is waitlisted. In the previous implementation, the waitlisting functionality is scattered across multiple files. All this is consolidated and placed in one model file ( waitlists.rb )
=== Issues with previous functionality ===
The previous implementation had 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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we have rewritten the methods in multiple controllers and model files that manipulate waitlists of a topic. All these classes now just invoke methods of waitlist_teams.rb. The following files contains the waitlist functionality which we have modified to refer to the new model file.

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''

== Design ==

=== Achieved Design Goals ===
Since our goal is to fix existing functionalities we did not update 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. We have eliminated the waitlist.rb file and moved all the references to this class to the new waitlist_teams.rb model file. We tested the existing features and ensured that we are not breaking what was working before we deployed our fix.
We can say that we achieved our goal of making experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Actions performed ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a/view commit] to view the changes.
#sign_up_sheet_controller.rb
##set_values_for_new_topic
###Added code to get waitlisted entries from new table instead of having all the entries from signed_up_teams table. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/15/commits/44a0f06761dfc681d6ed8e6d9ecd3017a816848d/view commit] to view the changes.
#sign_up_sheet.rb
##cancel_all_wailists
###This method previously has done 2 things, it cancelled waitlist and also updated the signed_up_team topic which needs to be split to comply with single responsibility principle. We ensured that is happening in the current implementation. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-f7b8fbeb82e3d7d5481ba3ed065d55838a21a82ebd055ac076ea36f222f88556/view commit] to view the changes.
##create_SignUpTeam
### This method in the previous implementation checked if topic has slots. If yes, it added to signed up team, else created a signup as waitlist. We modified this in order to use the new table and call the functions of waitlist_teams.rb to perform actions on waitlists. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/12/commits/7194a53ec01e78ea0d95920624436da6fe9933e2/view commit] to view the changes.
#sign_up_topic.rb
##users_on_waiting_list - Moved this method to fetch all users on waitlist for a topic to waitlist_teams model file.
##assign_to_first_waiting_team - The same functionality is being called in multiple places. This is modified to comply with DRY and is moved to the waitlist_teams model
##reassign_topic - Modified this method to use waitlist_teams.rb model file for actions on waitlisted teams.
##update_waitlisted_users - Moved this method to waitlist_teams model file.
##find_slots_waitlisted - Moved this method to waitlist_teams model file.
##find_waitlisted_topics - Moved this method to waitlist_teams model file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-e0df714a791bc6d36e6b27b82af71be36e8eac2cd21af5ea28a8bc5303953f5b/view PR] to view the changes.
#suggestion_controller.rb
##notification - Clean waitlist functionality is moved to a method in waitlist_teams model. team id is passed as a parameter to delete the waitlist for that team. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/14/files PR] to view the changes.
#invitation.rb
##remove_waitlists_for_team - Removed this method as we dont need it in this file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-c899291de1875b0c2483c0f132ed4503e6c33be63148d6e5d1f4235bfeb1c331 diff] to view the changes.

===3. 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
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment

=== 4. 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.
=== 5. Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
'''1. Adding Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
#Ways to get added to the waitlist for a topic
##Team requests a topic that has no slot available.
##When capacity/max choosers for a topic is increased
##When a student gets added to a team that already has a signed up topic
#Ways to get off a waitlist
##team gets the topic they are waiting for ( all other waitlists are dropped for the team)
##team drops off the waitlist
##instructor drops team from the waitlist
##a drop-topic deadline passes
##team is deleted
##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
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

# Make sure all existing waitlist functionality still passes

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* ''will be added for final submission''

'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[http://152.7.98.216:8080/view Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T03:59:27Z

Schidar: /* 2. Files and methods refactored */

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

We simplified the way we are handling the second case. For each topic, we have a waitlist object associated with it. If a team has requested for a topic that is not available, the team is queued on to the waitlist for this topic. In the waitlist table, we maintain the team id and the topic id for which this team is waitlisted. In the previous implementation, the waitlisting functionality is scattered across multiple files. All this is consolidated and placed in one model file ( waitlists.rb )
=== Issues with previous functionality ===
The previous implementation had 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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we have rewritten the methods in multiple controllers and model files that manipulate waitlists of a topic. All these classes now just invoke methods of waitlist_teams.rb. The following files contains the waitlist functionality which we have modified to refer to the new model file.

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''

== Design ==

=== Achieved Design Goals ===
Since our goal is to fix existing functionalities we did not update 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. We have eliminated the waitlist.rb file and moved all the references to this class to the new waitlist_teams.rb model file. We tested the existing features and ensured that we are not breaking what was working before we deployed our fix.
We can say that we achieved our goal of making experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Actions performed ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a/view commit] to view the changes.
#sign_up_sheet_controller.rb
##set_values_for_new_topic
###Added code to get waitlisted entries from new table instead of having all the entries from signed_up_teams table. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/15/commits/44a0f06761dfc681d6ed8e6d9ecd3017a816848d/view commit] to view the changes.
#sign_up_sheet.rb
##cancel_all_wailists
###This method previously has done 2 things, it cancelled waitlist and also updated the signed_up_team topic which needs to be split to comply with single responsibility principle. We ensured that is happening in the current implementation. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-f7b8fbeb82e3d7d5481ba3ed065d55838a21a82ebd055ac076ea36f222f88556/view commit] to view the changes.
##create_SignUpTeam
### This method in the previous implementation checked if topic has slots. If yes, it added to signed up team, else created a signup as waitlist. We modified this in order to use the new table and call the functions of waitlist_teams.rb to perform actions on waitlists. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/12/commits/7194a53ec01e78ea0d95920624436da6fe9933e2/view commit] to view the changes.
#sign_up_topic.rb
##users_on_waiting_list - Moved this method to fetch all users on waitlist for a topic to waitlist_teams model file.
##assign_to_first_waiting_team - The same functionality is being called in multiple places. This is modified to comply with DRY and is moved to the waitlist_teams model
##reassign_topic - Modified this method to use waitlist_teams.rb model file for actions on waitlisted teams.
##update_waitlisted_users - Moved this method to waitlist_teams model file.
##find_slots_waitlisted - Moved this method to waitlist_teams model file.
##find_waitlisted_topics - Moved this method to waitlist_teams model file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-e0df714a791bc6d36e6b27b82af71be36e8eac2cd21af5ea28a8bc5303953f5b/view PR] to view the changes.
#suggestion_controller.rb
##notification - Clean waitlist functionality is moved to a method in waitlist_teams model. team id is passed as a parameter to delete the waitlist for that team. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/14/files/view PR] to view the changes.
#invitation.rb
##remove_waitlists_for_team
###Removing from waitlist and adding to team to sign up should be as a single transaction
###There should be additional checks to make sure that there is enough space left before adding team to signed_up_sheet
###All functionality should be moved to waitlist_helper and implemented in a robust and dry manner. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/14/files/view PR] to view the changes.

===3. 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
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment

=== 4. 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.
=== 5. Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
'''1. Adding Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
#Ways to get added to the waitlist for a topic
##Team requests a topic that has no slot available.
##When capacity/max choosers for a topic is increased
##When a student gets added to a team that already has a signed up topic
#Ways to get off a waitlist
##team gets the topic they are waiting for ( all other waitlists are dropped for the team)
##team drops off the waitlist
##instructor drops team from the waitlist
##a drop-topic deadline passes
##team is deleted
##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
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

# Make sure all existing waitlist functionality still passes

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* ''will be added for final submission''

'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[http://152.7.98.216:8080/view Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T03:55:55Z

Schidar:

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

We simplified the way we are handling the second case. For each topic, we have a waitlist object associated with it. If a team has requested for a topic that is not available, the team is queued on to the waitlist for this topic. In the waitlist table, we maintain the team id and the topic id for which this team is waitlisted. In the previous implementation, the waitlisting functionality is scattered across multiple files. All this is consolidated and placed in one model file ( waitlists.rb )
=== Issues with previous functionality ===
The previous implementation had 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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we have rewritten the methods in multiple controllers and model files that manipulate waitlists of a topic. All these classes now just invoke methods of waitlist_teams.rb. The following files contains the waitlist functionality which we have modified to refer to the new model file.

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''

== Design ==

=== Achieved Design Goals ===
Since our goal is to fix existing functionalities we did not update 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. We have eliminated the waitlist.rb file and moved all the references to this class to the new waitlist_teams.rb model file. We tested the existing features and ensured that we are not breaking what was working before we deployed our fix.
We can say that we achieved our goal of making experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Actions performed ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a/view commit] to view the changes.
#sign_up_sheet_controller.rb
##set_values_for_new_topic
###Added code to get waitlisted entries from new table instead of having all the entries from signed_up_teams table. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/15/commits/44a0f06761dfc681d6ed8e6d9ecd3017a816848d/view commit] to view the changes.
#sign_up_sheet.rb
##cancel_all_wailists
###This method previously has done 2 things, it cancelled waitlist and also updated the signed_up_team topic which needs to be split to comply with single responsibility principle. We ensured that is happening in the current implementation. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-f7b8fbeb82e3d7d5481ba3ed065d55838a21a82ebd055ac076ea36f222f88556/view commit] to view the changes.
##create_SignUpTeam
### This method in the previous implementation checked if topic has slots. If yes, it added to signed up team, else created a signup as waitlist. We modified this in order to use the new table and call the functions of waitlist_teams.rb to perform actions on waitlists. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/12/commits/7194a53ec01e78ea0d95920624436da6fe9933e2/view commit] to view the changes.
#sign_up_topic.rb
##users_on_waiting_list - Moved this method to fetch all users on waitlist for a topic to waitlist_teams model file.
##assign_to_first_waiting_team - The same functionality is being called in multiple places. This is modified to comply with DRY and is moved to the waitlist_teams model
##reassign_topic - Modified this method to use waitlist_teams.rb model file for actions on waitlisted teams.
##update_waitlisted_users - Moved this method to waitlist_teams model file.
##find_slots_waitlisted - Moved this method to waitlist_teams model file.
##find_waitlisted_topics - Moved this method to waitlist_teams model file. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-e0df714a791bc6d36e6b27b82af71be36e8eac2cd21af5ea28a8bc5303953f5b/view PR] to view the changes.
#suggestion_controller.rb
##notification - Clean waitlist functionality is moved to a method in waitlist_teams model. team id is passed as a parameter to delete the waitlist for that team. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/14/commits/e2c6614a726c1dbfd157b42ba0a1bd51db03433c/view PR] to view the changes.
#invitation.rb
##remove_waitlists_for_team
###Removing from waitlist and adding to team to sign up should be as a single transaction
###There should be additional checks to make sure that there is enough space left before adding team to signed_up_sheet
###All functionality should be moved to waitlist_helper and implemented in a robust and dry manner

===3. 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
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment

=== 4. 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.
=== 5. Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
'''1. Adding Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
#Ways to get added to the waitlist for a topic
##Team requests a topic that has no slot available.
##When capacity/max choosers for a topic is increased
##When a student gets added to a team that already has a signed up topic
#Ways to get off a waitlist
##team gets the topic they are waiting for ( all other waitlists are dropped for the team)
##team drops off the waitlist
##instructor drops team from the waitlist
##a drop-topic deadline passes
##team is deleted
##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
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

# Make sure all existing waitlist functionality still passes

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* ''will be added for final submission''

'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[http://152.7.98.216:8080/view Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T03:31:37Z

Schidar:

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

We simplified the way we are handling the second case. For each topic, we have a waitlist object associated with it. If a team has requested for a topic that is not available, the team is queued on to the waitlist for this topic. In the waitlist table, we maintain the team id and the topic id for which this team is waitlisted. In the previous implementation, the waitlisting functionality is scattered across multiple files. All this is consolidated and placed in one model file ( waitlists.rb )
=== Issues with previous functionality ===
The previous implementation had 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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we have rewritten the methods in multiple controllers and model files that manipulate waitlists of a topic. All these classes now just invoke methods of waitlist_teams.rb. The following files contains the waitlist functionality which we have modified to refer to the new model file.

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''

== Design ==

=== Achieved Design Goals ===
Since our goal is to fix existing functionalities we did not update 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. We have eliminated the waitlist.rb file and moved all the references to this class to the new waitlist_teams.rb model file. We tested the existing features and ensured that we are not breaking what was working before we deployed our fix.
We can say that we achieved our goal of making experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Actions performed ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a/view commit] to view the changes.
#sign_up_sheet_controller.rb
##set_values_for_new_topic
###Added code to get waitlisted entries from new table instead of having all the entries from signed_up_teams table. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/15/commits/44a0f06761dfc681d6ed8e6d9ecd3017a816848d/view commit] to view the changes.
#sign_up_sheet.rb
##cancel_all_wailists
###This method previously has done 2 things, it cancelled waitlist and also updated the signed_up_team topic which needs to be split to comply with single responsibility principle. We ensured that is happening in the current implementation. Refer to this [https://github.com/expertiza/expertiza/pull/2384/files#diff-f7b8fbeb82e3d7d5481ba3ed065d55838a21a82ebd055ac076ea36f222f88556/view commit] to view the changes.
##create_SignUpTeam
### This method in the previous implementation checked if topic has slots. If yes, it added to signed up team, else created a signup as waitlist. We modified this in order to use the new table and call the functions of waitlist_teams.rb to perform actions on waitlists. [https://github.com/akhilkumarmengani/expertiza/pull/12/commits/7194a53ec01e78ea0d95920624436da6fe9933e2/view commit] to view the changes.
#sign_up_topic.rb
##users_on_waiting_list - Move method to fetch all users on waitlist for a topic to waitlist_teams method.
##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
##reassign_topic - Use methods that perform actions on waitlist that should be moved to waitlist_helper, also use transactions to make it atomic.
##update_waitlisted_users - Move method to waitlist_teams model and use the new table
##find_slots_waitlisted - Move method to waitlist_teams model
##find_waitlisted_topics - Move method to waitlist_teams model
#suggestion_controller.rb
##notification
##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.
#invitation.rb
##remove_waitlists_for_team
###Removing from waitlist and adding to team to sign up should be as a single transaction
###There should be additional checks to make sure that there is enough space left before adding team to signed_up_sheet
###All functionality should be moved to waitlist_helper and implemented in a robust and dry manner

===3. 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
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment

=== 4. 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.
=== 5. Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
'''1. Adding Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
#Ways to get added to the waitlist for a topic
##Team requests a topic that has no slot available.
##When capacity/max choosers for a topic is increased
##When a student gets added to a team that already has a signed up topic
#Ways to get off a waitlist
##team gets the topic they are waiting for ( all other waitlists are dropped for the team)
##team drops off the waitlist
##instructor drops team from the waitlist
##a drop-topic deadline passes
##team is deleted
##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
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

# Make sure all existing waitlist functionality still passes

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* ''will be added for final submission''

'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[http://152.7.98.216:8080/view Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T03:04:12Z

Schidar:

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

We simplified the way we are handling the second case. For each topic, we have a waitlist object associated with it. If a team has requested for a topic that is not available, the team is queued on to the waitlist for this topic. In the waitlist table, we maintain the team id and the topic id for which this team is waitlisted. In the previous implementation, the waitlisting functionality is scattered across multiple files. All this is consolidated and placed in one model file ( waitlists.rb )
=== Issues with previous functionality ===
The previous implementation had 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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we have rewritten the methods in multiple controllers and model files that manipulate waitlists of a topic. All these classes now just invoke methods of waitlist_teams.rb. The following files contains the waitlist functionality which we have modified to refer to the new model file.

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''

== Design ==

=== Achieved Design Goals ===
Since our goal is to fix existing functionalities we did not update 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. We have eliminated the waitlist.rb file and moved all the references to this class to the new waitlist_teams.rb model file. We tested the existing features and ensured that we are not breaking what was working before we deployed our fix.
We can say that we achieved our goal of making experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Actions performed ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a/view commit] to view the changes.
#sign_up_sheet_controller.rb
##set_values_for_new_topic
###Added code to get waitlisted entries from new table instead of having all the entries from signed_up_teams table. Refer to this https://github.com/akhilkumarmengani/expertiza/pull/15/commits/44a0f06761dfc681d6ed8e6d9ecd3017a816848d/view commit] to view the changes.
#sign_up_sheet.rb
##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
##create_SignUpTeam
###It checks if topic has slots if yes it adds to signed up team, else creates a signup as waitlist
###This method should use the new table and call the helper functions of waitlist to perform actions on waitlists
#sign_up_topic.rb
##users_on_waiting_list - Move method to fetch all users on waitlist for a topic to waitlist_teams method.
##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
##reassign_topic - Use methods that perform actions on waitlist that should be moved to waitlist_helper, also use transactions to make it atomic.
##update_waitlisted_users - Move method to waitlist_teams model and use the new table
##find_slots_waitlisted - Move method to waitlist_teams model
##find_waitlisted_topics - Move method to waitlist_teams model
#suggestion_controller.rb
##notification
##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.
#invitation.rb
##remove_waitlists_for_team
###Removing from waitlist and adding to team to sign up should be as a single transaction
###There should be additional checks to make sure that there is enough space left before adding team to signed_up_sheet
###All functionality should be moved to waitlist_helper and implemented in a robust and dry manner

===3. 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
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment

=== 4. 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.
=== 5. Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
'''1. Adding Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
#Ways to get added to the waitlist for a topic
##Team requests a topic that has no slot available.
##When capacity/max choosers for a topic is increased
##When a student gets added to a team that already has a signed up topic
#Ways to get off a waitlist
##team gets the topic they are waiting for ( all other waitlists are dropped for the team)
##team drops off the waitlist
##instructor drops team from the waitlist
##a drop-topic deadline passes
##team is deleted
##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
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

# Make sure all existing waitlist functionality still passes

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* ''will be added for final submission''

'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[http://152.7.98.216:8080/view Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T02:52:27Z

Schidar:

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

We simplified the way we are handling the second case. For each topic, we have a waitlist object associated with it. If a team has requested for a topic that is not available, the team is queued on to the waitlist for this topic. In the waitlist table, we maintain the team id and the topic id for which this team is waitlisted. In the previous implementation, the waitlisting functionality is scattered across multiple files. All this is consolidated and placed in one model file ( waitlists.rb )
=== Issues with previous functionality ===
The previous implementation had 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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we have rewritten the methods in multiple controllers and model files that manipulate waitlists of a topic. All these classes now just invoke methods of waitlist.rb. The following files contains the waitlist functionality which we have modified to refer to the new model file.

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''

== Design ==

=== Achieved Design Goals ===
Since our goal is to fix existing functionalities we did not update 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. We tested the existing features and ensured that we are not breaking what was working before we deployed our fix.
We can say that we achieved our goal of making experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Actions performed ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a/view commit] to view the changes.
#sign_up_sheet_controller.rb
##switch_original_topic_to_approved_suggested_topic
###Change usage of is_waitlisted attribute in the signed_up_teams table to use the new table
###Add additional checks and transactions to make sure perform operations in an atomic way in case of failures.
#sign_up_sheet.rb
##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
##create_SignUpTeam
###It checks if topic has slots if yes it adds to signed up team, else creates a signup as waitlist
###This method should use the new table and call the helper functions of waitlist to perform actions on waitlists
#sign_up_topic.rb
##users_on_waiting_list - Move method to fetch all users on waitlist for a topic to waitlist_teams method.
##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
##reassign_topic - Use methods that perform actions on waitlist that should be moved to waitlist_helper, also use transactions to make it atomic.
##update_waitlisted_users - Move method to waitlist_teams model and use the new table
##find_slots_waitlisted - Move method to waitlist_teams model
##find_waitlisted_topics - Move method to waitlist_teams model
#suggestion_controller.rb
##notification
##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.
#invitation.rb
##remove_waitlists_for_team
###Removing from waitlist and adding to team to sign up should be as a single transaction
###There should be additional checks to make sure that there is enough space left before adding team to signed_up_sheet
###All functionality should be moved to waitlist_helper and implemented in a robust and dry manner

===3. 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
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment

=== 4. 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.
=== 5. Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
'''1. Adding Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
#Ways to get added to the waitlist for a topic
##Team requests a topic that has no slot available.
##When capacity/max choosers for a topic is increased
##When a student gets added to a team that already has a signed up topic
#Ways to get off a waitlist
##team gets the topic they are waiting for ( all other waitlists are dropped for the team)
##team drops off the waitlist
##instructor drops team from the waitlist
##a drop-topic deadline passes
##team is deleted
##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
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

# Make sure all existing waitlist functionality still passes

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* ''will be added for final submission''

'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[http://152.7.98.216:8080/view Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T01:56:28Z

Schidar: /* Problem Statement */

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

We simplified the way we are handling the second case. For each topic, we have a waitlist object associated with it. If a team has requested for a topic that is not available, the team is queued on to the waitlist for this topic. In the waitlist table, we maintain the team id and the topic id for which this team is waitlisted. In the previous implementation, the waitlisting functionality is scattered across multiple files. All this is consolidated and placed in one model file ( waitlists.rb )
=== Issues with previous functionality ===
The previous 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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we will rewrite or move the functions/methods to multiple controllers and model files that manipulate waitlists of a topic. All these classes will now just invoke methods of waitlist.rb. The following files contains the waitlist functionality, so we plan to either refactor or add the functionality.

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 ==

=== 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 be testing the existing features so that we are not breaking what was working before we deployed our fix.
Our goal is to make the experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Plan of action ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a/view commit] to view the changes.
#sign_up_sheet_controller.rb
##switch_original_topic_to_approved_suggested_topic
###Change usage of is_waitlisted attribute in the signed_up_teams table to use the new table
###Add additional checks and transactions to make sure perform operations in an atomic way in case of failures.
#sign_up_sheet.rb
##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
##create_SignUpTeam
###It checks if topic has slots if yes it adds to signed up team, else creates a signup as waitlist
###This method should use the new table and call the helper functions of waitlist to perform actions on waitlists
#sign_up_topic.rb
##users_on_waiting_list - Move method to fetch all users on waitlist for a topic to waitlist_teams method.
##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
##reassign_topic - Use methods that perform actions on waitlist that should be moved to waitlist_helper, also use transactions to make it atomic.
##update_waitlisted_users - Move method to waitlist_teams model and use the new table
##find_slots_waitlisted - Move method to waitlist_teams model
##find_waitlisted_topics - Move method to waitlist_teams model
#suggestion_controller.rb
##notification
##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.
#invitation.rb
##remove_waitlists_for_team
###Removing from waitlist and adding to team to sign up should be as a single transaction
###There should be additional checks to make sure that there is enough space left before adding team to signed_up_sheet
###All functionality should be moved to waitlist_helper and implemented in a robust and dry manner

===3. 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
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment

=== 4. 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.
=== 5. Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
'''1. Adding Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
#Ways to get added to the waitlist for a topic
##Team requests a topic that has no slot available.
##When capacity/max choosers for a topic is increased
##When a student gets added to a team that already has a signed up topic
#Ways to get off a waitlist
##team gets the topic they are waiting for ( all other waitlists are dropped for the team)
##team drops off the waitlist
##instructor drops team from the waitlist
##a drop-topic deadline passes
##team is deleted
##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
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

# Make sure all existing waitlist functionality still passes

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* ''will be added for final submission''

'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[http://152.7.98.216:8080/view Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T01:48:59Z

Schidar: /* Plan of action */

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we will rewrite or move the functions/methods to multiple controllers and model files that manipulate waitlists of a topic. All these classes will now just invoke methods of waitlist.rb. The following files contains the waitlist functionality, so we plan to either refactor or add the functionality.

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 ==

=== 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 be testing the existing features so that we are not breaking what was working before we deployed our fix.
Our goal is to make the experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Plan of action ==

Following are the sections of changes that we have done in this project : 
1. Updated the SIGNED_UP_TEAMS table. 
2. Refactored files that contains waitlist functionality 
3. Added new WAITLIST_TEAMS table using scaffold. 
4. Migrated the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Added the business logic to ''waitlist_teams.rb'' file 

=== 1.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 have eliminated the use of is_waitlisted column of this table. Instead, we have used a separate table waitlist_teams for waitlisting entries. With this, the signed_up_teams table consists of only signed up teams and waitlist_teams consists of only waitlisted up teams.
 
All existing references to the is_waitlisted flag has been rewritten to make use of the new table.

=== 2. Files and methods refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag are removed and waitlists are determined by using the new waitlist_team table.
#waitlist.rb
##We have completely eliminated this class. We have used WaitlistTeam in place of this class and this contains all business logic for managing waitlisted teams for topics. Refer to this [https://github.com/akhilkumarmengani/expertiza/pull/1/commits/f1520041e759518e87109be1fa6adf539d7deb0a/view commit] to view the changes.
#sign_up_sheet_controller.rb
##switch_original_topic_to_approved_suggested_topic
###Change usage of is_waitlisted attribute in the signed_up_teams table to use the new table
###Add additional checks and transactions to make sure perform operations in an atomic way in case of failures.
#sign_up_sheet.rb
##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
##create_SignUpTeam
###It checks if topic has slots if yes it adds to signed up team, else creates a signup as waitlist
###This method should use the new table and call the helper functions of waitlist to perform actions on waitlists
#sign_up_topic.rb
##users_on_waiting_list - Move method to fetch all users on waitlist for a topic to waitlist_teams method.
##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
##reassign_topic - Use methods that perform actions on waitlist that should be moved to waitlist_helper, also use transactions to make it atomic.
##update_waitlisted_users - Move method to waitlist_teams model and use the new table
##find_slots_waitlisted - Move method to waitlist_teams model
##find_waitlisted_topics - Move method to waitlist_teams model
#suggestion_controller.rb
##notification
##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.
#invitation.rb
##remove_waitlists_for_team
###Removing from waitlist and adding to team to sign up should be as a single transaction
###There should be additional checks to make sure that there is enough space left before adding team to signed_up_sheet
###All functionality should be moved to waitlist_helper and implemented in a robust and dry manner

===3. 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
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment

=== 4. 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.
=== 5. Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
'''1. Adding Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
#Ways to get added to the waitlist for a topic
##Team requests a topic that has no slot available.
##When capacity/max choosers for a topic is increased
##When a student gets added to a team that already has a signed up topic
#Ways to get off a waitlist
##team gets the topic they are waiting for ( all other waitlists are dropped for the team)
##team drops off the waitlist
##instructor drops team from the waitlist
##a drop-topic deadline passes
##team is deleted
##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
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

# Make sure all existing waitlist functionality still passes

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* ''will be added for final submission''

'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[http://152.7.98.216:8080/view Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-05-03T01:25:47Z

Schidar: /* Useful Links */

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we will rewrite or move the functions/methods to multiple controllers and model files that manipulate waitlists of a topic. All these classes will now just invoke methods of waitlist.rb. The following files contains the waitlist functionality, so we plan to either refactor or add the functionality.

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 ==

=== 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 be testing the existing features so that we are not breaking what was working before we deployed our fix.
Our goal is to make the experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Plan of action ==

Following are the sections of changes that we will be doing in this project : 
1. Update the SIGNED_UP_TEAMS table. 
2. Refactoring files that contains waitlist functionality 
3. Add new WAITLIST_TEAMS table using scaffold. 
4. Migrate the data to WAITLIST_TEAMS table from SIGNED_UP_TEAMS table. 
5. Add/Move the business logic to ''waitlist_teams.rb'' file 

=== 1.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.

=== 2. Files and methods to be refactored ===

#signed_up_team.rb
##All references to the is_waitlisted boolean flag should be removed and waitlists must be determined by using the new waitlist_team table.
#waitlist.rb
##This class must be scrapped away and we will use a separate model class 'WaitlistTeam' which will contain the business logic for managing and modifying waitlisted teams. We also plan on using a helper class 'WaitlistTeamHelper' to add the logic of waitlisting which is called in multiple places across the code. The helper class will help avoid redundant code and make sure the code is implemented in a DRY manner.
#sign_up_sheet_controller.rb
##switch_original_topic_to_approved_suggested_topic
###Change usage of is_waitlisted attribute in the signed_up_teams table to use the new table
###Add additional checks and transactions to make sure perform operations in an atomic way in case of failures.
#sign_up_sheet.rb
##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
##create_SignUpTeam
###It checks if topic has slots if yes it adds to signed up team, else creates a signup as waitlist
###This method should use the new table and call the helper functions of waitlist to perform actions on waitlists
#sign_up_topic.rb
##users_on_waiting_list - Move method to fetch all users on waitlist for a topic to waitlist_teams method.
##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
##reassign_topic - Use methods that perform actions on waitlist that should be moved to waitlist_helper, also use transactions to make it atomic.
##update_waitlisted_users - Move method to waitlist_teams model and use the new table
##find_slots_waitlisted - Move method to waitlist_teams model
##find_waitlisted_topics - Move method to waitlist_teams model
#suggestion_controller.rb
##notification
##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.
#invitation.rb
##remove_waitlists_for_team
###Removing from waitlist and adding to team to sign up should be as a single transaction
###There should be additional checks to make sure that there is enough space left before adding team to signed_up_sheet
###All functionality should be moved to waitlist_helper and implemented in a robust and dry manner

===3. 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
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#Get the number of waitlisted teams for all topics in an assignment

=== 4. 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.
=== 5. Specific Tasks Completed ===
''will be added for the final submission''

== Implementation ==
'''1. Adding Waitlist Teams Table, Validations and Model file:''' 
https://github.com/akhilkumarmengani/expertiza/pull/1/files (Adding waitlist_teams table) 
https://github.com/akhilkumarmengani/expertiza/pull/2/files (Migration script changes to add unique constraint on waitlist_teams table and remove id column) 
https://github.com/akhilkumarmengani/expertiza/pull/4/files (Schema changes) 
https://github.com/akhilkumarmengani/expertiza/pull/3/files (Validations) 
 
'''2. Migration Scripts''' 
https://github.com/akhilkumarmengani/expertiza/pull/10/files (Migrate existing data in signed_up_teams to waitlist_teams) 
 
'''3. Business Logic Changes''' 
Adding new methods for add, delete, signup of waitlist teams in WaitlistTeam.rb. 
Changes to existing method calls in model files 
 
https://github.com/akhilkumarmengani/expertiza/pull/5/files (WaitlistTeam model methods like CRUD etc) 
https://github.com/akhilkumarmengani/expertiza/pull/11/files (Methods to handle deletion cases) 
https://github.com/akhilkumarmengani/expertiza/pull/12 (Check if team is waitlisted before a topic signup) 
https://github.com/akhilkumarmengani/expertiza/pull/13 (Release waitlist and signup when a user joins another team and there are no other users in the old team) 
https://github.com/akhilkumarmengani/expertiza/pull/14/files (Synchronize waitlist features in other files) 
 
'''4. RSpec''' 
https://github.com/akhilkumarmengani/expertiza/pull/13 (RSpec changes to test model methods) 

== Testing ==
=== Video Demonstration ===
''will be added for the final submission''
=== Testing Goals and Test Objects ===

''Drawing from the project objectives:''
#Ways to get added to the waitlist for a topic
##Team requests a topic that has no slot available.
##When capacity/max choosers for a topic is increased
##When a student gets added to a team that already has a signed up topic
#Ways to get off a waitlist
##team gets the topic they are waiting for ( all other waitlists are dropped for the team)
##team drops off the waitlist
##instructor drops team from the waitlist
##a drop-topic deadline passes
##team is deleted
##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
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

# Make sure all existing waitlist functionality still passes

== Conclusions and Future Work ==
=== Comprehensive Testing and Scope ===
* ''will be added for final submission''

'''Conclusion:''' 
Following is the summary of what we have done in this project so far: 
1. Adding new table waitlist_teams to store waitlist teams for a topic and migration script for transferring the waitlist data from signed_up_teams. 
2. Changed the existing functionality to store the new waitlists data in this new table 
3. Existing waitlist business logic implementation is not in waitlist model class so we created a new model file and rewritten the code for waitlist functionality. 
4. There are number of methods in other model classes which are referencing waitlist functionality. We have changed all those references to the new methods that we have implemented. 
 
'''Future Work:''' 
1. We created a new table that will store the team in waitlist for a topic. Earlier there was only table (signed_up_teams) to keep track of signed up teams and waitlist teams. This table has is_waitlist column to figure out if the entry is for a sign up or waitlist. With the Introduction of new table for waitlist_teams this column now seems unreasonable and it will not impact the functionality. Though we have script to migrate the existing waitlist data to new table, the column is_waitlist is not removed yet. Teams working on it further can work on it and remove all the references of is_waitlist column. 
2. Teams can work on writing more test cases for waitlist functionality because there are various flows in which this functionality is touched Examples: Accept Invitation, Leaving team etc. 

== Useful Links ==

[https://github.com/expertiza/expertiza/pull/2384/view Pull request] 

[http://152.7.98.216:8080/view Deployed application with changes] 

[https://github.com/akhilkumarmengani/expertiza/view 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'')

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

2022-04-12T02:19:42Z

Schidar: /* Class Diagram */

== Problem Statement==

Waitlist feature is utilized during subject assignment in an assignment. For example, during the topic allocation of the Final Project (and design doc), each team had the opportunity to sign up for a topic in which they were interested or to add to a waitlist of a topic in which they were not interested. When a team is added to the queue, many circumstances emerge. The waitlist feature currently does not adhere to the open-closed design paradigm. As a result, our task in this project is to resolve these issues by rewriting the waitlist functionality.

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.

== Solution ==

To simplify waitlist functionality, to reduce code redundancy and to fix the Single-responsibility principle that is being violated, we will rewrite or move the functions/methods to multiple controllers and model files that manipulate waitlists of a topic. All these classes will now just invoke methods of waitlist.rb. The following files contains the waitlist functionality, so we plan to either refactor or add the functionality.

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 ==

=== 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 be testing the existing features so that we are not breaking what was working before we deployed our fix.
Our goal is to make the experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are 
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 which is a reference to the teams table 
'''topic_id''' : foreign key in waitlists_team table which is a reference to the signed_up_teams table 
 
These relationships along with the attributes of the classes are depicted in the class diagram below.
 
 
[[File:Waitlists_class_diagram.png|600px|]]

== Plan of action ==

=== 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 ===

#signed_up_team.rb
##All references to is_waitlisted should be removed and waitlists must be determined by using the new waitlist_team table.
#waitlist.rb
##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.
#sign_up_sheet_controller.rb
##switch_original_topic_to_approved_suggested_topic
###Change usage of is_waitlisted attribute in the signed_up_teams table to use the new table
###Add additional checks and transactions to make sure perform operations in an atomic way in case of failures.
#sign_up_sheet.rb
##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
##create_SignUpTeam
###It checks if topic has slots if yes it adds to signed up team, else creates a signup as waitlist
###This method should use the new table and call the helper functions of waitlist to perform actions on waitlists
#sign_up_topic.rb
##users_on_waiting_list - Move method to fetch all users on waitlist for a topic to waitlist_teams method.
##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
##reassign_topic - Use methods that perform actions on waitlist that should be moved to waitlist_helper, also use transactions to make it atomic.
##update_waitlisted_users - Move method to waitlist_teams model and use the new table
##find_slots_waitlisted - Move method to waitlist_teams model
##find_waitlisted_topics - Move method to waitlist_teams model
#suggestion_controller.rb
##notification
##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.
#invitation.rb
##remove_waitlists_for_team
###Removing from waitlist and adding to team to sign up should be as a single transaction
###There should be additional checks to make sure that there is enough space left before adding team to signed_up_sheet
###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
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#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:''
#Ways to get added to the waitlist for a topic
##Team requests a topic that has no slot available.
##When capacity/max choosers for a topic is increased
##When a student gets added to a team that already has a signed up topic
#Ways to get off a waitlist
##team gets the topic they are waiting for ( all other waitlists are dropped for the team)
##team drops off the waitlist
##instructor drops team from the waitlist
##a drop-topic deadline passes
##team is deleted
##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
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

# 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'')

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

2022-04-12T01:55:52Z

Schidar: /* UML Diagram */

== 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 be testing the existing features so that we are not breaking what was working before we deployed our fix.
Our goal is to make the experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

In this Unified Modeling Language (UML), we summarize the details of the system's users and their interactions with the system. 
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

[[File:Waitlists_uml_diagram.png|600px|]]

=== 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 
 
 

[[File:Waitlists_class_diagram.png|600px|]]

=== 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 ===

#signed_up_team.rb
##All references to is_waitlisted should be removed and waitlists must be determined by using the new waitlist_team table.
#waitlist.rb
##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.
#sign_up_sheet_controller.rb
##switch_original_topic_to_approved_suggested_topic
###Change usage of is_waitlisted attribute in the signed_up_teams table to use the new table
###Add additional checks and transactions to make sure perform operations in an atomic way in case of failures.
#sign_up_sheet.rb
##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
##create_SignUpTeam
###It checks if topic has slots if yes it adds to signed up team, else creates a signup as waitlist
###This method should use the new table and call the helper functions of waitlist to perform actions on waitlists
#sign_up_topic.rb
##users_on_waiting_list - Move method to fetch all users on waitlist for a topic to waitlist_teams method.
##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
##reassign_topic - Use methods that perform actions on waitlist that should be moved to waitlist_helper, also use transactions to make it atomic.
##update_waitlisted_users - Move method to waitlist_teams model and use the new table
##find_slots_waitlisted - Move method to waitlist_teams model
##find_waitlisted_topics - Move method to waitlist_teams model
#suggestion_controller.rb
##notification
##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.
#invitation.rb
##remove_waitlists_for_team
###Removing from waitlist and adding to team to sign up should be as a single transaction
###There should be additional checks to make sure that there is enough space left before adding team to signed_up_sheet
###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
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#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:''
#Ways to get added to the waitlist for a topic
##Team requests a topic that has no slot available.
##When capacity/max choosers for a topic is increased
##When a student gets added to a team that already has a signed up topic
#Ways to get off a waitlist
##team gets the topic they are waiting for ( all other waitlists are dropped for the team)
##team drops off the waitlist
##instructor drops team from the waitlist
##a drop-topic deadline passes
##team is deleted
##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
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

'''Student's View'''

[[File:Student_waitlist_page.png|900px|]]

----

'''Instructor's View'''

[[File:Instructor_signup_page.png|900px|]]

----
'''Instructor's View With Waitlists'''

[[File:Waitlist.png|900px|]]

----

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

# 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'')

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

2022-04-07T01:45:55Z

Schidar: /* Problem Statement */

== 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 ===

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

[[File:Waitlists_class_diagram.png|600px|]]

=== 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 ===

#signed_up_team.rb
##All references to is_waitlisted should be removed and waitlists must be determined by using the new waitlist_team table.
#waitlist.rb
##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.
#sign_up_sheet_controller.rb
##switch_original_topic_to_approved_suggested_topic
###Change usage of is_waitlisted attribute in the signed_up_teams table to use the new table
###Add additional checks and transactions to make sure perform operations in an atomic way in case of failures.
#sign_up_sheet.rb
##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
##create_SignUpTeam
###It checks if topic has slots if yes it adds to signed up team, else creates a signup as waitlist
###This method should use the new table and call the helper functions of waitlist to perform actions on waitlists
#sign_up_topic.rb
##users_on_waiting_list - Move method to fetch all users on waitlist for a topic to waitlist_teams method.
##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
##reassign_topic - Use methods that perform actions on waitlist that should be moved to waitlist_helper, also use transactions to make it atomic.
##update_waitlisted_users - Move method to waitlist_teams model and use the new table
##find_slots_waitlisted - Move method to waitlist_teams model
##find_waitlisted_topics - Move method to waitlist_teams model
#suggestion_controller.rb
##notification
##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.
#invitation.rb
##remove_waitlists_for_team
###Removing from waitlist and adding to team to sign up should be as a single transaction
###There should be additional checks to make sure that there is enough space left before adding team to signed_up_sheet
###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
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#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:''
#Ways to get added to the waitlist for a topic
##Team requests a topic that has no slot available.
##When capacity/max choosers for a topic is increased
##When a student gets added to a team that already has a signed up topic
#Ways to get off a waitlist
##team gets the topic they are waiting for ( all other waitlists are dropped for the team)
##team drops off the waitlist
##instructor drops team from the waitlist
##a drop-topic deadline passes
##team is deleted
##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
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

=== 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.''

# 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'')

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

2022-04-07T01:37:39Z

Schidar: /* Overview of Major Changes */

== 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 ===

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

[[File:Waitlists_class_diagram.png|600px|]]

=== 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 ===

#signed_up_team.rb
##All references to is_waitlisted should be removed and waitlists must be determined by using the new waitlist_team table.
#waitlist.rb
##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.
#sign_up_sheet_controller.rb
##switch_original_topic_to_approved_suggested_topic
###Change usage of is_waitlisted attribute in the signed_up_teams table to use the new table
###Add additional checks and transactions to make sure perform operations in an atomic way in case of failures.
#sign_up_sheet.rb
##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
##create_SignUpTeam
###It checks if topic has slots if yes it adds to signed up team, else creates a signup as waitlist
###This method should use the new table and call the helper functions of waitlist to perform actions on waitlists
#sign_up_topic.rb
##users_on_waiting_list - Move method to fetch all users on waitlist for a topic to waitlist_teams method.
##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
##reassign_topic - Use methods that perform actions on waitlist that should be moved to waitlist_helper, also use transactions to make it atomic.
##update_waitlisted_users - Move method to waitlist_teams model and use the new table
##find_slots_waitlisted - Move method to waitlist_teams model
##find_waitlisted_topics - Move method to waitlist_teams model
#suggestion_controller.rb
##notification
##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.
#invitation.rb
##remove_waitlists_for_team
###Removing from waitlist and adding to team to sign up should be as a single transaction
###There should be additional checks to make sure that there is enough space left before adding team to signed_up_sheet
###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
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#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:''
#Ways to get added to the waitlist for a topic
##Team requests a topic that has no slot available.
##When capacity/max choosers for a topic is increased
##When a student gets added to a team that already has a signed up topic
#Ways to get off a waitlist
##team gets the topic they are waiting for ( all other waitlists are dropped for the team)
##team drops off the waitlist
##instructor drops team from the waitlist
##a drop-topic deadline passes
##team is deleted
##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
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

=== 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.''

# 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'')

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

2022-04-07T00:57:33Z

Schidar: /* Problem Statement */

== 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 ===

== 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 ===

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

[[File:Waitlists_class_diagram.png|600px|]]

=== 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 ===

#signed_up_team.rb
##All references to is_waitlisted should be removed and waitlists must be determined by using the new waitlist_team table.
#waitlist.rb
##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.
#sign_up_sheet_controller.rb
##switch_original_topic_to_approved_suggested_topic
###Change usage of is_waitlisted attribute in the signed_up_teams table to use the new table
###Add additional checks and transactions to make sure perform operations in an atomic way in case of failures.
#sign_up_sheet.rb
##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
##create_SignUpTeam
###It checks if topic has slots if yes it adds to signed up team, else creates a signup as waitlist
###This method should use the new table and call the helper functions of waitlist to perform actions on waitlists
#sign_up_topic.rb
##users_on_waiting_list - Move method to fetch all users on waitlist for a topic to waitlist_teams method.
##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
##reassign_topic - Use methods that perform actions on waitlist that should be moved to waitlist_helper, also use transactions to make it atomic.
##update_waitlisted_users - Move method to waitlist_teams model and use the new table
##find_slots_waitlisted - Move method to waitlist_teams model
##find_waitlisted_topics - Move method to waitlist_teams model
#suggestion_controller.rb
##notification
##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.
#invitation.rb
##remove_waitlists_for_team
###Removing from waitlist and adding to team to sign up should be as a single transaction
###There should be additional checks to make sure that there is enough space left before adding team to signed_up_sheet
###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
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#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:''
#Ways to get added to the waitlist for a topic
##Team requests a topic that has no slot available.
##When capacity/max choosers for a topic is increased
##When a student gets added to a team that already has a signed up topic
#Ways to get off a waitlist
##team gets the topic they are waiting for ( all other waitlists are dropped for the team)
##team drops off the waitlist
##instructor drops team from the waitlist
##a drop-topic deadline passes
##team is deleted
##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
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

=== 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.''

# 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'')

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

2022-04-07T00:31:27Z

Schidar: /* Problem Statement */

== 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 ).

=== Feature Overview ===

=== Issues with existing functionality ===

=== Overview of Major Changes ===

== 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 ===

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

[[File:Waitlists_class_diagram.png|600px|]]

=== 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 ===

#signed_up_team.rb
##All references to is_waitlisted should be removed and waitlists must be determined by using the new waitlist_team table.
#waitlist.rb
##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.
#sign_up_sheet_controller.rb
##switch_original_topic_to_approved_suggested_topic
###Change usage of is_waitlisted attribute in the signed_up_teams table to use the new table
###Add additional checks and transactions to make sure perform operations in an atomic way in case of failures.
#sign_up_sheet.rb
##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
##create_SignUpTeam
###It checks if topic has slots if yes it adds to signed up team, else creates a signup as waitlist
###This method should use the new table and call the helper functions of waitlist to perform actions on waitlists
#sign_up_topic.rb
##users_on_waiting_list - Move method to fetch all users on waitlist for a topic to waitlist_teams method.
##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
##reassign_topic - Use methods that perform actions on waitlist that should be moved to waitlist_helper, also use transactions to make it atomic.
##update_waitlisted_users - Move method to waitlist_teams model and use the new table
##find_slots_waitlisted - Move method to waitlist_teams model
##find_waitlisted_topics - Move method to waitlist_teams model
#suggestion_controller.rb
##notification
##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.
#invitation.rb
##remove_waitlists_for_team
###Removing from waitlist and adding to team to sign up should be as a single transaction
###There should be additional checks to make sure that there is enough space left before adding team to signed_up_sheet
###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
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#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:''
#Ways to get added to the waitlist for a topic
##Team requests a topic that has no slot available.
##When capacity/max choosers for a topic is increased
##When a student gets added to a team that already has a signed up topic
#Ways to get off a waitlist
##team gets the topic they are waiting for ( all other waitlists are dropped for the team)
##team drops off the waitlist
##instructor drops team from the waitlist
##a drop-topic deadline passes
##team is deleted
##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
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

=== 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.''

# 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'')

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

2022-04-06T23:41:51Z

Schidar: /* Problem Statement */

== 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. The current implementation has most of the code for manipulating waitlists in sign_up_topic.rb, with other portions in waitlist.rb, invitation.rb, lottery_controller.rb, suggestion_controller.rb and signed_up_team.rb. There are other files too which invoke waitlist functionality by calling methods of the above class.

=== Feature Overview ===

=== Issues with existing functionality ===

=== Overview of Major Changes ===

== 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 ===

[[File:Waitlists_uml_diagram.png|600px|]]

=== Class Diagram ===

[[File:Waitlists_class_diagram.png|600px|]]

=== 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 ===

#signed_up_team.rb
##All references to is_waitlisted should be removed and waitlists must be determined by using the new waitlist_team table.
#waitlist.rb
##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.
#sign_up_sheet_controller.rb
##switch_original_topic_to_approved_suggested_topic
###Change usage of is_waitlisted attribute in the signed_up_teams table to use the new table
###Add additional checks and transactions to make sure perform operations in an atomic way in case of failures.
#sign_up_sheet.rb
##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
##create_SignUpTeam
###It checks if topic has slots if yes it adds to signed up team, else creates a signup as waitlist
###This method should use the new table and call the helper functions of waitlist to perform actions on waitlists
#sign_up_topic.rb
##users_on_waiting_list - Move method to fetch all users on waitlist for a topic to waitlist_teams method.
##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
##reassign_topic - Use methods that perform actions on waitlist that should be moved to waitlist_helper, also use transactions to make it atomic.
##update_waitlisted_users - Move method to waitlist_teams model and use the new table
##find_slots_waitlisted - Move method to waitlist_teams model
##find_waitlisted_topics - Move method to waitlist_teams model
#suggestion_controller.rb
##notification
##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.
#invitation.rb
##remove_waitlists_for_team
###Removing from waitlist and adding to team to sign up should be as a single transaction
###There should be additional checks to make sure that there is enough space left before adding team to signed_up_sheet
###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
#Delete all waitlists for team
#Purge all waitlists for topic
#Add team to waitlist
#Delete specific team from waitlist
#Get all waitlisted topics for team
#Get all waitlisted teams for topic
#Get first team in waitlist for topic
#Check waitlist empty for topic
#Check if team has any waitlists
#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:''
#Ways to get added to the waitlist for a topic
##Team requests a topic that has no slot available.
##When capacity/max choosers for a topic is increased
##When a student gets added to a team that already has a signed up topic
#Ways to get off a waitlist
##team gets the topic they are waiting for ( all other waitlists are dropped for the team)
##team drops off the waitlist
##instructor drops team from the waitlist
##a drop-topic deadline passes
##team is deleted
##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
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>
<pre>
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.
</pre>

=== Manual Testing ===

=== 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.''

# 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'')

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

2022-04-06T20:38:47Z

Schidar: /* Problem Statement */

CSC/ECE 517 Spring 2022 - E2218: Refactor response controller

2022-03-27T21:35:21Z

Schidar:

This page details project documentation for the CSC/ECE 517 Spring 2022, '''E2218 refactor response_controller.rb''' project.

== Background ==

A response is the object that is created when someone fills out a review rubric, such as when one writes a review, gives feedback to a reviewer, or fills out a survey. Responses to the individual rubric items are kept in Answer objects; each Answer object has a response_id to say what Response it is part of. Since response_controller needs to work with many kinds of responses, its code is pretty general. It is not the worst controller in the system, but it would be much clearer if its method names were more descriptive of what they do.

=== Mentor ===

Ed Gehringer, efg@ncsu.edu

=== Team Members ===

* Sai Naga Vamshi Chidara (schidar@ncsu.edu)
* Akhil Kumar Mengani (amengan@ncsu.edu)
* Samson Reddy Mulkur (smulkur@ncsu.edu)

== Modified Files and Refactorization ==
A. '''response_controller.rb''' 

'''authorize_show_calibration_results'''
This method is used to authorize if the user(reviewer) is allowed to view the calibration results for the corresponding
''calibration_response_map_id'' and ''review_response_map_id''
passed as parameters in the URL.
Ex: https://expertiza.ncsu.edu/response/show_calibration_results_for_student?calibration_response_map_id=165688&review_response_map_id=165790
When someone tries to change the map_id's, the request should be authorized to check if the user can access the calibration result or not. 
[[File:Authorize_show_calibration_results.png|1180px|]]

'''set_response'''
@response and @map instance variables are initialized the same way across multiple methods.
In order to avoid duplication, we created a before_action action which will be called first before calling the corresponding methods.
[[File:Set_response_method.png|1170px|]]

B. '''response_helper.rb''' 

Following methods are moved from the ''response_controller.rb'' class to ''response_helper.rb'' class since these methods are called from the
controller action methods.
i) '''current_user_is_reviewer'''
ii) '''sort_questions'''
iii) '''store_total_cake_score'''
iv) '''set_content''' 

[[File:Response_helper_1.png|1170px|]]

[[File:Response_helper_2.png|1170px|]]

C. '''assignment_questionnaire.rb''' 
'''get_questions_by_assignment_id'''
Parameters : assignment_id
When a user clicks on 'calibration results' from UI, questions in the assignment that has been reviewed are displayed.
A new method is added in the ''AssignmentQuestionnaire'' model class that returns the appropriate questions by querying the
''AssignmentQuestionnaire'' using the ''assignment_id''.
This method is added to separate the business logic of retrieving the questions from the controller class.

[[File: Get_questions_by_assignment_id.png|1170px|]]

D. '''awarded_badge.rb''' 
'''award_badge'''
Parameters : participant_id, badge_name
This method adds the ''badge_name'' to a specific ''participant_id'' in the AwardedBadges table.
A separate method is created in the ''AwardedBadges'' model class to avoid the controller class from knowing the business logic of adding a badge
name to a participant.

[[File:RespControllerAwardBadge.png|1170px|]]

[[File:AwardBadgeMethod.png|1170px|]]

E. '''cake.rb''' 
'''store_total_cake_score'''
This method clearly exposes the logic of retrieving the score for a cake question in the ''response_controller.rb'' class which is an incorrect
design.
So, a model class method ''get_total_score_for_questions'' is added and the same logic of iterating over the Cake questions is moved there.
Return results for this method remains same here.
[[File:Cake.png|1170px|]]

F. '''response.rb''' 
'''calibration_results_info'''
This method in ''response.rb'' model is completely removed because this method only adds more complexity to the model class.
We refactored the method ''show_calibration_results_for_student'' in the ''response_controller.rb'' class.
Previously, ''calibration_results_info'' was just doing nothing but getting responses using ''calibration_response_map_id'' and
''review_response_map_id'', and querying ''AssignmentQuestionnaire''.
Both of these operations can be done by using ''find'' method of model class and adding model class ''get_questions_by_assignment_id'' method.

'''create_or_get_response'''
Method name ''populate_new_response'' is changed to ''create_or_get_response'' to convey the functionality of the method.

[[File:Create_or_get_response.png|1170px|]]

G. '''Code Climate issues''' 
'''Update'''
Made changes to split a line into multiple lines because it is too long.
[[File:Update_line_long.png|1170px|]]

'''Create'''
Made changes to split a line into multiple lines because it is too long.
[[File:Create_line_long.png|1170px|]]

== Testing ==
This is a refactoring project, so we have refactored response controller while ensuring that existing tests don't break.
=== Running Tests ===
<pre>
rspec spec/controllers/response_controller_spec.rb
</pre>

<pre>
rspec spec/controllers/questionnaires_controller_spec.rb
</pre>

=== UI Testing ===
1) Login using the following details. User Name: student432 Password: password

[[File:resp_p1.png|800px|]]

2) Click on the assignment Design Exercise pertaining to course CSC/ECE 517, Spring 2017

[[File:resp_p2.png|800px|]]

3) Click on other's work

[[File:resp_p3.png|800px|]]

4) Click on show calibration results, verify if the calibration results are displayed on the UI.

[[File:resp_p4.png|800px|]]

[[File:resp_p5.png|800px|]]

==GitHub links and Pull Request==
Link to Expertiza repository: [https://github.com/expertiza/expertiza here]

Link to the forked repository: [https://github.com/vamshi-chidara/expertiza here]

Link to Pull Request: [https://github.com/expertiza/expertiza/pull/2327 here]

CSC/ECE 517 Spring 2022 - E2218: Refactor response controller

2022-03-22T02:59:11Z

Schidar:

This page details project documentation for the CSC/ECE 517 Spring 2022, '''E2218 refactor response_controller.rb''' project.

== Background ==

A response is the object that is created when someone fills out a review rubric, such as when one writes a review, gives feedback to a reviewer, or fills out a survey. Responses to the individual rubric items are kept in Answer objects; each Answer object has a response_id to say what Response it is part of. Since response_controller needs to work with many kinds of responses, its code is pretty general. It is not the worst controller in the system, but it would be much clearer if its method names were more descriptive of what they do.

=== Mentor ===

Ed Gehringer, efg@ncsu.edu

=== Team Members ===

* Sai Naga Vamshi Chidara (schidar@ncsu.edu)
* Akhil Kumar Mengani (amengan@ncsu.edu)
* Samson Reddy Mulkur (smulkur@ncsu.edu)

== Modified Files and Refactorization ==
A. '''response_controller.rb''' 

'''authorize_show_calibration_results'''
This method is used to authorize if the user(reviewer) is allowed to view the calibration results for the corresponding
''calibration_response_map_id'' and ''review_response_map_id''
passed as parameters in the URL.
Ex: https://expertiza.ncsu.edu/response/show_calibration_results_for_student?calibration_response_map_id=165688&review_response_map_id=165790
When someone tries to change the map_id's, the request should be authorized to check if the user can access the calibration result or not. 
[[File:Authorize_show_calibration_results.png|1180px|]]

'''set_response'''
@response and @map instance variables are initialized the same way across multiple methods.
In order to avoid duplication, we created a before_action action which will be called first before calling the corresponding methods.
[[File:Set_response_method.png|1170px|]]

B. '''response_helper.rb''' 

Following methods are moved from the ''response_controller.rb'' class to ''response_helper.rb'' class since these methods are called from the
controller action methods.
i) '''current_user_is_reviewer'''
ii) '''sort_questions'''
iii) '''store_total_cake_score'''
iv) '''set_content''' 

[[File:Response_helper_1.png|1170px|]]

[[File:Response_helper_2.png|1170px|]]

C. '''assignment_questionnaire.rb''' 
'''get_questions_by_assignment_id'''
Parameters : assignment_id
When a user clicks on 'calibration results' from UI, questions in the assignment that has been reviewed are displayed.
A new method is added in the ''AssignmentQuestionnaire'' model class that returns the appropriate questions by querying the
''AssignmentQuestionnaire'' using the ''assignment_id''.
This method is added to separate the business logic of retrieving the questions from the controller class.

[[File: Get_questions_by_assignment_id.png|1170px|]]

D. '''awarded_badge.rb''' 
'''award_badge'''
Parameters : participant_id, badge_name
This method adds the ''badge_name'' to a specific ''participant_id'' in the AwardedBadges table.
A separate method is created in the ''AwardedBadges'' model class to avoid the controller class from knowing the business logic of adding a badge
name to a participant.

[[File:RespControllerAwardBadge.png|1170px|]]

[[File:AwardBadgeMethod.png|1170px|]]

E. '''cake.rb''' 
'''store_total_cake_score'''
This method clearly exposes the logic of retrieving the score for a cake question in the ''response_controller.rb'' class which is an incorrect
design.
So, a model class method ''get_total_score_for_questions'' is added and the same logic of iterating over the Cake questions is moved there.
Return results for this method remains same here.
[[File:Cake.png|1170px|]]

F. '''response.rb''' 
'''calibration_results_info'''
This method in ''response.rb'' model is completely removed because this method only adds more complexity to the model class.
We refactored the method ''show_calibration_results_for_student'' in the ''response_controller.rb'' class.
Previously, ''calibration_results_info'' was just doing nothing but getting responses using ''calibration_response_map_id'' and
''review_response_map_id'', and querying ''AssignmentQuestionnaire''.
Both of these operations can be done by using ''find'' method of model class and adding model class ''get_questions_by_assignment_id'' method.

'''create_or_get_response'''
Method name ''populate_new_response'' is changed to ''create_or_get_response'' to convey the functionality of the method.

[[File:Create_or_get_response.png|1170px|]]

G. '''Code Climate issues''' 
'''Update'''
Made changes to split a line into multiple lines because it is too long.
[[File:Update_line_long.png|1170px|]]

'''Create'''
Made changes to split a line into multiple lines because it is too long.
[[File:Create_line_long.png|1170px|]]

== Testing ==

=== Running Tests ===
<pre>
rspec spec/models/responses_spec.rb
</pre>
<pre>
rspec spec/controllers/questionnaires_controller_spec.rb
</pre>

==GitHub links and Pull Request==
Link to Expertiza repository: [https://github.com/expertiza/expertiza here]

Link to the forked repository: [https://github.com/vamshi-chidara/expertiza here]

Link to Pull Request: [https://github.com/expertiza/expertiza/pull/2327 here]

CSC/ECE 517 Spring 2022 - E2218: Refactor response controller

2022-03-21T16:14:14Z

Schidar:

This page details project documentation for the CSC/ECE 517 Spring 2022, "E2218 refactor response_controller.rb" project.

== Background ==

A response is the object that is created when someone fills out a review rubric, such as when one writes a review, gives feedback to a reviewer, or fills out a survey. Responses to the individual rubric items are kept in Answer objects; each Answer object has a response_id to say what Response it is part of. Since response_controller needs to work with many kinds of responses, its code is pretty general. It is not the worst controller in the system, but it would be much clearer if its method names were more descriptive of what they do.

=== Mentor ===

Ed Gehringer, efg@ncsu.edu

=== Team Members ===

* Sai Naga Vamshi Chidara (schidar@ncsu.edu)
* Akhil Kumar (amengan@ncsu.edu)
* Samson Mulkur (smulkur@ncsu.edu)

== Code Modifications and Refactorization ==
Described below are the code refactoring tasks and issues addressed by this team. We have also included any pertinent details, reasonings, comments, warnings, etc., corresponding to each task.

=== METHOD: def set_response ===
@response and @map instance variables are initialized the same way across multiple methods. In order to avoid duplication, we created a
before_action action which will be called first before calling the corresponding methods.

[[File:Set_response_method.png|1200px|]]

== Modified Files ==
<code>response_controller.rb</code>

<code>response_helper.rb</code>

<code>assignment_questionnaire.rb</code>

<code>awarded_badge.rb</code>

<code>cake.rb</code>

<code>response.rb</code>
== Testing ==

=== Running Tests ===
<pre>
rspec spec/controllers/questionnaires_controller_spec.rb
</pre>

==GitHub links and Pull Request==
Link to Expertiza repository: [https://github.com/expertiza/expertiza here]

Link to the forked repository: [https://github.com/vamshi-chidara/expertiza here]

Link to Pull Request: [https://github.com/expertiza/expertiza/pull/2327 here]

CSC/ECE 517 Spring 2022 - E2218: Refactor response controller

2022-03-21T16:11:54Z

Schidar: /* Code Modifications and Refactorization */

This page details project documentation for the CSC/ECE 517 Spring 2022, "E2218 refactor response_controller.rb" project.

== Background ==

A response is the object that is created when someone fills out a review rubric, such as when one writes a review, gives feedback to a reviewer, or fills out a survey. Responses to the individual rubric items are kept in Answer objects; each Answer object has a response_id to say what Response it is part of. Since response_controller needs to work with many kinds of responses, its code is pretty general. It is not the worst controller in the system, but it would be much clearer if its method names were more descriptive of what they do.

=== Mentor ===

Ed Gehringer, efg@ncsu.edu

=== Team Members ===

* Sai Naga Vamshi Chidara (schidar@ncsu.edu)
* Akhil Kumar (amengan@ncsu.edu)
* Samson Mulkur (smulkur@ncsu.edu)

== Code Modifications and Refactorization ==
Described below are the code refactoring tasks and issues addressed by this team. We have also included any pertinent details, reasonings, comments, warnings, etc., corresponding to each task.

=== METHOD: def set_response ===
@response and @map instance variables are initialized the same way across multiple methods. In order to avoid duplication, we created a
before_action action which will be called first before calling the corresponding methods.

[[File:Set_response_method.png|1200px|thumb|left]]

== Modified Files ==
<code>response_controller.rb</code>

<code>response_helper.rb</code>

<code>assignment_questionnaire.rb</code>

<code>awarded_badge.rb</code>

<code>cake.rb</code>

<code>response.rb</code>
== Testing ==

=== Running Tests ===
<pre>
rspec spec/controllers/questionnaires_controller_spec.rb
</pre>

==GitHub links and Pull Request==
Link to Expertiza repository: [https://github.com/expertiza/expertiza here]

Link to the forked repository: [https://github.com/vamshi-chidara/expertiza here]

Link to Pull Request: [https://github.com/expertiza/expertiza/pull/2327 here]

CSC/ECE 517 Spring 2022 - E2218: Refactor response controller

2022-03-21T16:10:52Z

Schidar: /* Code Modifications and Refactorization */

This page details project documentation for the CSC/ECE 517 Spring 2022, "E2218 refactor response_controller.rb" project.

== Background ==

A response is the object that is created when someone fills out a review rubric, such as when one writes a review, gives feedback to a reviewer, or fills out a survey. Responses to the individual rubric items are kept in Answer objects; each Answer object has a response_id to say what Response it is part of. Since response_controller needs to work with many kinds of responses, its code is pretty general. It is not the worst controller in the system, but it would be much clearer if its method names were more descriptive of what they do.

=== Mentor ===

Ed Gehringer, efg@ncsu.edu

=== Team Members ===

* Sai Naga Vamshi Chidara (schidar@ncsu.edu)
* Akhil Kumar (amengan@ncsu.edu)
* Samson Mulkur (smulkur@ncsu.edu)

== Code Modifications and Refactorization ==
Described below are the code refactoring tasks and issues addressed by this team. We have also included any pertinent details, reasonings, comments, warnings, etc., corresponding to each task.

* '''Initializing response and map variables'''
@response and @map instance variables are initialized the same way across multiple methods. In order to avoid duplication, we created a
before_action action which will be called first before calling the corresponding methods.

[[File:Set_response_method.png|1205px|thumb|left]]

== Modified Files ==
<code>response_controller.rb</code>

<code>response_helper.rb</code>

<code>assignment_questionnaire.rb</code>

<code>awarded_badge.rb</code>

<code>cake.rb</code>

<code>response.rb</code>
== Testing ==

=== Running Tests ===
<pre>
rspec spec/controllers/questionnaires_controller_spec.rb
</pre>

==GitHub links and Pull Request==
Link to Expertiza repository: [https://github.com/expertiza/expertiza here]

Link to the forked repository: [https://github.com/vamshi-chidara/expertiza here]

Link to Pull Request: [https://github.com/expertiza/expertiza/pull/2327 here]

File:Set response method.png

2022-03-21T16:07:54Z

Schidar: Before action method to initialize response and map instance variables

Before action method to initialize response and map instance variables

CSC/ECE 517 Spring 2022 - E2218: Refactor response controller

2022-03-21T16:02:24Z

Schidar:

This page details project documentation for the CSC/ECE 517 Spring 2022, "E2218 refactor response_controller.rb" project.

== Background ==

A response is the object that is created when someone fills out a review rubric, such as when one writes a review, gives feedback to a reviewer, or fills out a survey. Responses to the individual rubric items are kept in Answer objects; each Answer object has a response_id to say what Response it is part of. Since response_controller needs to work with many kinds of responses, its code is pretty general. It is not the worst controller in the system, but it would be much clearer if its method names were more descriptive of what they do.

=== Mentor ===

Ed Gehringer, efg@ncsu.edu

=== Team Members ===

* Sai Naga Vamshi Chidara (schidar@ncsu.edu)
* Akhil Kumar (amengan@ncsu.edu)
* Samson Mulkur (smulkur@ncsu.edu)

== Code Modifications and Refactorization ==
Described below are the code refactoring tasks and issues addressed by this team. We have also included any pertinent details, reasonings, comments, warnings, etc., corresponding to each task.

* '''Initializing response and map variables'''
@response and @map instance variables are initialized the same way across multiple methods. In order to avoid duplication, we created a
before_action action which will be called first before calling the corresponding methods.

def set_response
@response = Response.find(params[:id])
@map = @response.map
end

== Modified Files ==
<code>response_controller.rb</code>

<code>response_helper.rb</code>

<code>assignment_questionnaire.rb</code>

<code>awarded_badge.rb</code>

<code>cake.rb</code>

<code>response.rb</code>
== Testing ==

=== Running Tests ===
<pre>
rspec spec/controllers/questionnaires_controller_spec.rb
</pre>

==GitHub links and Pull Request==
Link to Expertiza repository: [https://github.com/expertiza/expertiza here]

Link to the forked repository: [https://github.com/vamshi-chidara/expertiza here]

Link to Pull Request: [https://github.com/expertiza/expertiza/pull/2327 here]

CSC/ECE 517 Spring 2022 - E2218: Refactor response controller

2022-03-21T16:02:09Z

Schidar:

This page details project documentation for the CSC/ECE 517 Spring 2022, "E2218 refactor response_controller.rb" project.

== Background ==

A response is the object that is created when someone fills out a review rubric, such as when one writes a review, gives feedback to a reviewer, or fills out a survey. Responses to the individual rubric items are kept in Answer objects; each Answer object has a response_id to say what Response it is part of. Since response_controller needs to work with many kinds of responses, its code is pretty general. It is not the worst controller in the system, but it would be much clearer if its method names were more descriptive of what they do.

=== Mentor ===

Ed Gehringer, efg@ncsu.edu

=== Team Members ===

* Sai Naga Vamshi Chidara (schidar@ncsu.edu)
* Akhil Kumar (amengan@ncsu.edu)
* Samson Mulkur (smulkur@ncsu.edu)

== Code Modifications and Refactorization ==
Described below are the code refactoring tasks and issues addressed by this team. We have also included any pertinent details, reasonings, comments, warnings, etc., corresponding to each task.

* '''Initializing response and map variables'''
@response and @map instance variables are initialized the same way across multiple methods. In order to avoid duplication, we created a
before_action action which will be called first before calling the corresponding methods.

def set_response
@response = Response.find(params[:id])
@map = @response.map
end

== Modified Files ==
<code>response_controller.rb</code>

<code>response_helper.rb</code>

<code>assignment_questionnaire.rb</code>

<code>awarded_badge.rb</code>

<code>cake.rb</code>

<code>response.rb</code>

== Testing ==

=== Running Tests ===
<pre>
rspec spec/controllers/questionnaires_controller_spec.rb
</pre>

==GitHub links and Pull Request==
Link to Expertiza repository: [https://github.com/expertiza/expertiza here]

Link to the forked repository: [https://github.com/vamshi-chidara/expertiza here]

Link to Pull Request: [https://github.com/expertiza/expertiza/pull/2327 here]

CSC/ECE 517 Spring 2022 - E2218: Refactor response controller

2022-03-21T16:00:06Z

Schidar: /* Code Modifications and Refactorization */

This page details project documentation for the CSC/ECE 517 Spring 2022, "E2218 refactor response_controller.rb" project.

== Background ==

A response is the object that is created when someone fills out a review rubric, such as when one writes a review, gives feedback to a reviewer, or fills out a survey. Responses to the individual rubric items are kept in Answer objects; each Answer object has a response_id to say what Response it is part of. Since response_controller needs to work with many kinds of responses, its code is pretty general. It is not the worst controller in the system, but it would be much clearer if its method names were more descriptive of what they do.

=== Mentor ===

Ed Gehringer, efg@ncsu.edu

=== Team Members ===

* Sai Naga Vamshi Chidara (schidar@ncsu.edu)
* Akhil Kumar (amengan@ncsu.edu)
* Samson Mulkur (smulkur@ncsu.edu)

== Code Modifications and Refactorization ==
Described below are the code refactoring tasks and issues addressed by this team. We have also included any pertinent details, reasonings, comments, warnings, etc., corresponding to each task.

* '''Initializing response and map variables'''
@response and @map instance variables are initialized the same way across multiple methods. In order to avoid duplication, we created a
before_action action which will be called first before calling the corresponding methods.

def set_response
@response = Response.find(params[:id])
@map = @response.map
end

== Modified Files ==
<code>response_controller.rb</code>

<code>response_helper.rb</code>

<code>assignment_questionnaire.rb</code>

<code>awarded_badge.rb</code>

<code>cake.rb</code>

<code>response.rb</code>

==GitHub links and Pull Request==
Link to Expertiza repository: [https://github.com/expertiza/expertiza here]

Link to the forked repository: [https://github.com/vamshi-chidara/expertiza here]

Link to Pull Request: [https://github.com/expertiza/expertiza/pull/2327 here]

CSC/ECE 517 Spring 2022 - E2218: Refactor response controller

2022-03-21T15:58:03Z

Schidar: /* Code Modifications and Refactorization */

This page details project documentation for the CSC/ECE 517 Spring 2022, "E2218 refactor response_controller.rb" project.

== Background ==

A response is the object that is created when someone fills out a review rubric, such as when one writes a review, gives feedback to a reviewer, or fills out a survey. Responses to the individual rubric items are kept in Answer objects; each Answer object has a response_id to say what Response it is part of. Since response_controller needs to work with many kinds of responses, its code is pretty general. It is not the worst controller in the system, but it would be much clearer if its method names were more descriptive of what they do.

=== Mentor ===

Ed Gehringer, efg@ncsu.edu

=== Team Members ===

* Sai Naga Vamshi Chidara (schidar@ncsu.edu)
* Akhil Kumar (amengan@ncsu.edu)
* Samson Mulkur (smulkur@ncsu.edu)

== Code Modifications and Refactorization ==
Described below are the code refactoring tasks and issues addressed by this team. We have also included any pertinent details, reasonings, comments, warnings, etc., corresponding to each task.

* '''Initializing response and map variables'''
@response and @map instance variables are initialized the same way across multiple methods. In order to avoid duplication, we created a
before_action action which will be called first before calling the corresponding methods.

== Modified Files ==
<code>response_controller.rb</code>

<code>response_helper.rb</code>

<code>assignment_questionnaire.rb</code>

<code>awarded_badge.rb</code>

<code>cake.rb</code>

<code>response.rb</code>

==GitHub links and Pull Request==
Link to Expertiza repository: [https://github.com/expertiza/expertiza here]

Link to the forked repository: [https://github.com/vamshi-chidara/expertiza here]

Link to Pull Request: [https://github.com/expertiza/expertiza/pull/2327 here]

CSC/ECE 517 Spring 2022 - E2218: Refactor response controller

2022-03-21T15:24:09Z

Schidar: /* Code Modifications and Refactorization */

This page details project documentation for the CSC/ECE 517 Spring 2022, "E2218 refactor response_controller.rb" project.

== Background ==

A response is the object that is created when someone fills out a review rubric, such as when one writes a review, gives feedback to a reviewer, or fills out a survey. Responses to the individual rubric items are kept in Answer objects; each Answer object has a response_id to say what Response it is part of. Since response_controller needs to work with many kinds of responses, its code is pretty general. It is not the worst controller in the system, but it would be much clearer if its method names were more descriptive of what they do.

=== Mentor ===

Ed Gehringer, efg@ncsu.edu

=== Team Members ===

* Sai Naga Vamshi Chidara (schidar@ncsu.edu)
* Akhil Kumar (amengan@ncsu.edu)
* Samson Mulkur (smulkur@ncsu.edu)

== Code Modifications and Refactorization ==
Described below are the code refactoring tasks and issues addressed by this team. We have also included any pertinent details, reasonings, comments, warnings, etc., corresponding to each task.

* '''Initializing response and map variables'''
@response and @map instance variables are initialized the same way across multiple methods. In order to avoid duplication, we created a before_action action which will be called first before calling the corresponding methods.

== Modified Files ==
<code>response_controller.rb</code>

<code>response_helper.rb</code>

<code>assignment_questionnaire.rb</code>

<code>awarded_badge.rb</code>

<code>cake.rb</code>

<code>response.rb</code>

==GitHub links and Pull Request==
Link to Expertiza repository: [https://github.com/expertiza/expertiza here]

Link to the forked repository: [https://github.com/vamshi-chidara/expertiza here]

Link to Pull Request: [https://github.com/expertiza/expertiza/pull/2327 here]

CSC/ECE 517 Spring 2022 - E2218: Refactor response controller

2022-03-21T03:08:30Z

Schidar:

This page details project documentation for the CSC/ECE 517 Spring 2022, "E2218 refactor response_controller.rb" project.

== Background ==

A response is the object that is created when someone fills out a review rubric, such as when one writes a review, gives feedback to a reviewer, or fills out a survey. Responses to the individual rubric items are kept in Answer objects; each Answer object has a response_id to say what Response it is part of. Since response_controller needs to work with many kinds of responses, its code is pretty general. It is not the worst controller in the system, but it would be much clearer if its method names were more descriptive of what they do.

=== Mentor ===

Ed Gehringer, efg@ncsu.edu

=== Team Members ===

* Sai Naga Vamshi Chidara (schidar@ncsu.edu)
* Akhil Kumar (amengan@ncsu.edu)
* Samson Mulkur (smulkur@ncsu.edu)

== Code Modifications and Refactorization ==
Described below are the code refactoring tasks and issues addressed by this team. We have also included any pertinent details, reasonings, comments, warnings, etc., corresponding to each task.

== Modified Files ==
<code>response_controller.rb</code>

<code>response_helper.rb</code>

<code>assignment_questionnaire.rb</code>

<code>awarded_badge.rb</code>

<code>cake.rb</code>

<code>response.rb</code>

==GitHub links and Pull Request==
Link to Expertiza repository: [https://github.com/expertiza/expertiza here]

Link to the forked repository: [https://github.com/vamshi-chidara/expertiza here]

Link to Pull Request: [https://github.com/expertiza/expertiza/pull/2327 here]

CSC/ECE 517 Spring 2022 - E2218: Refactor response controller

2022-03-21T03:08:16Z

Schidar: /* Refactorization and Code Modifications */

This page details project documentation for the CSC/ECE 517 Spring 2022, "E2218 refactor response_controller.rb" project.

== Background ==

A response is the object that is created when someone fills out a review rubric, such as when one writes a review, gives feedback to a reviewer, or fills out a survey. Responses to the individual rubric items are kept in Answer objects; each Answer object has a response_id to say what Response it is part of. Since response_controller needs to work with many kinds of responses, its code is pretty general. It is not the worst controller in the system, but it would be much clearer if its method names were more descriptive of what they do.

=== Mentor ===

Ed Gehringer, efg@ncsu.edu

=== Team Members ===

* Sai Naga Vamshi Chidara (schidar@ncsu.edu)
* Akhil Kumar (amengan@ncsu.edu)
* Samson Mulkur (smulkur@ncsu.edu)

== Issues ==

== Code Modifications and Refactorization ==
Described below are the code refactoring tasks and issues addressed by this team. We have also included any pertinent details, reasonings, comments, warnings, etc., corresponding to each task.

== Modified Files ==
<code>response_controller.rb</code>

<code>response_helper.rb</code>

<code>assignment_questionnaire.rb</code>

<code>awarded_badge.rb</code>

<code>cake.rb</code>

<code>response.rb</code>

==GitHub links and Pull Request==
Link to Expertiza repository: [https://github.com/expertiza/expertiza here]

Link to the forked repository: [https://github.com/vamshi-chidara/expertiza here]

Link to Pull Request: [https://github.com/expertiza/expertiza/pull/2327 here]

CSC/ECE 517 Spring 2022 - E2218: Refactor response controller

2022-03-21T01:33:03Z

Schidar:

This page details project documentation for the CSC/ECE 517 Spring 2022, "E2218 refactor response_controller.rb" project.

== Background ==

A response is the object that is created when someone fills out a review rubric, such as when one writes a review, gives feedback to a reviewer, or fills out a survey. Responses to the individual rubric items are kept in Answer objects; each Answer object has a response_id to say what Response it is part of. Since response_controller needs to work with many kinds of responses, its code is pretty general. It is not the worst controller in the system, but it would be much clearer if its method names were more descriptive of what they do.

=== Mentor ===

Ed Gehringer, efg@ncsu.edu

=== Team Members ===

* Sai Naga Vamshi Chidara (schidar@ncsu.edu)
* Akhil Kumar (amengan@ncsu.edu)
* Samson Mulkur (smulkur@ncsu.edu)

== Issues ==

== Refactorization and Code Modifications ==
Below is a list of code refactor tasks and issues addressed by this team in this project. We have also included any pertinent details, reasonings, comments, warnings, etc., corresponding to each task.

== Modified Files ==
<code>response_controller.rb</code>

<code>response_helper.rb</code>

<code>assignment_questionnaire.rb</code>

<code>awarded_badge.rb</code>

<code>cake.rb</code>

<code>response.rb</code>

==GitHub links and Pull Request==
Link to Expertiza repository: [https://github.com/expertiza/expertiza here]

Link to the forked repository: [https://github.com/vamshi-chidara/expertiza here]

Link to Pull Request: [https://github.com/expertiza/expertiza/pull/2327 here]

CSC/ECE 517 Spring 2022 - E2218: Refactor response controller

2022-03-21T01:09:34Z

Schidar:

CSC/ECE 517 Spring 2022 - E2218: Refactor response controller

2022-03-21T00:43:41Z

Schidar: Created page with "This page details project documentation for the CSC/ECE 517 Spring 2022, "E2218 refactor response_controller.rb" project. == Background == A response is the object that is..."