Expertiza_Wiki - User contributions [en]

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

2022-04-25T23:44:41Z

Amengan: /* 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.

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 ==
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-25T21:46:04Z

Amengan: /* 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.

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 ===
''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-12T02:25:34Z

Amengan: /* 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 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 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

===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 ==
''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-12T02:23:01Z

Amengan: /* 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 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

=== 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-12T02:17:46Z

Amengan: /* Issues with existing functionality */

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

== 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-12T02:17:22Z

Amengan: /* Solution */

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

''Italic text''== 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: 
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|]]

== 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-12T02:10:08Z

Amengan: /* Solution */

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

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

== 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-12T02:09:56Z

Amengan: /* Overview of Major Changes */

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

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

== 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-12T02:08:26Z

Amengan: /* Proposed design and 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.

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

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

== 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-12T02:07:06Z

Amengan: /* 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.

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

File:Instructor signup page 2.png

2022-04-07T03:49:17Z

Amengan:

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

2022-04-07T03:10:54Z

Amengan: /* Manual Testing */

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

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

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

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

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

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

1) signed_up_team.rb

2) waitlist.rb

3) sign_up_sheet_controller.rb

4) sign_up_sheet.rb

5) sign_up_topic.rb

6) suggestion_controller.rb

7) invitation.rb

== Proposed design and Plan of action ==

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

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

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

=== UML Diagram ===

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

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

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

[[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|]]

----

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

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-07T03:01:33Z

Amengan: /* Manual Testing */

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

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

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

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

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

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

1) signed_up_team.rb

2) waitlist.rb

3) sign_up_sheet_controller.rb

4) sign_up_sheet.rb

5) sign_up_topic.rb

6) suggestion_controller.rb

7) invitation.rb

== Proposed design and Plan of action ==

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

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

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

=== UML Diagram ===

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

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

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

[[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 sees the following page during the topic signup. 

[[File:Student_waitlist_page.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. 

Instructor sees the following page during the topic signup 

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

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

=== 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-07T03:00:56Z

Amengan: /* Manual Testing */

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

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

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

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

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

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

1) signed_up_team.rb

2) waitlist.rb

3) sign_up_sheet_controller.rb

4) sign_up_sheet.rb

5) sign_up_topic.rb

6) suggestion_controller.rb

7) invitation.rb

== Proposed design and Plan of action ==

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

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

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

=== UML Diagram ===

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

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

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

[[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 sees the following page during the topic signup. 

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

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

Instructor sees the following page during the topic signup 

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

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

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

File:Instructor signup page.png

2022-04-07T02:57:08Z

Amengan:

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

2022-04-07T02:56:52Z

Amengan: /* Manual Testing */

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

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

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

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

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

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

1) signed_up_team.rb

2) waitlist.rb

3) sign_up_sheet_controller.rb

4) sign_up_sheet.rb

5) sign_up_topic.rb

6) suggestion_controller.rb

7) invitation.rb

== Proposed design and Plan of action ==

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

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

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

=== UML Diagram ===

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

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

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

[[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 sees the following page during the topic signup. 

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

'''Test 1:''' 
Student should be able to add their team to the waitlist by clicking on '''Check''' icon 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 if they are no longer interested in it.

'''Test 3:''' 

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

File:Student waitlist page.png

2022-04-07T02:45:48Z

Amengan:

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

2022-04-07T02:42:17Z

Amengan: /* 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 continue to test the system after each issue has been fixed. This will allow us to ensure two things:

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

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

=== UML Diagram ===

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

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

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

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

=== 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-07T02:33:12Z

Amengan: /* Class 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 continue to test the system after each issue has been fixed. This will allow us to ensure two things:

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

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

=== UML Diagram ===

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

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

=== 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-07T02:27:29Z

Amengan: /* 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 continue to test the system after each issue has been fixed. This will allow us to ensure two things:

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

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

=== UML Diagram ===

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

[[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-06T21:58:35Z

Amengan:

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

'''The topic is unavailable''':

In this case, the team is waitlisted for the topic. When any other team drops this topic, then a waitlisted team will be assigned for this topic.
=== Feature Overview ===

=== Issues with existing functionality ===

=== Overview of Major Changes ===

== Proposed design and Plan of action ==

=== General Design Goals ===

=== UML Diagram ===

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

=== Class Diagram ===

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

=== Changes to the signed_up_teams Table ===
=== Files and methods to be refactored ===

#signed_up_team.rb

#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
#sign_up_topic.rb

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

===Refactoring and Design Patterns===
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.

=== 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 waitlist for a topic
##Team requests a topic that has no slot available.
##When capacity/max choosers for a topic is increased
##When student gets added to a team which has 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 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.

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

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

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

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

=== Manual UI Tests ===
*Student ID in header
<pre>
Scenario: Student ID in grading history view
Logged in as an Instructor/Admin
On Assignment page, click on Grading History
Resulting Grading History Table is shown
Student ID appears in the header, not in any table columns
</pre>

=== 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 Mulkur (''smulkur'')
*Akhil Mengani (''amengan'')
*Sai Naga Vamshi Chidara (''schidar'')
=== Mentor ===
*Naman Shrimali (''nshrima'')

File:Waitlists uml diagram.png

2022-04-06T21:53:55Z

Amengan:

File:Waitlists class diagram.png

2022-04-06T21:53:12Z

Amengan:

CSC/ECE 517 Spring 2022 - E2218: Refactor response controller

2022-03-22T02:23:34Z

Amengan:

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''' 
1. '''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|1200px|]]

B. '''response_helper.rb''' 
1 . 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|1200px|]]

[[File:Response_helper_2.png|1200px|]]

C. '''assignment_questionnaire.rb''' 
1. ''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|1200px|]]

D. '''awarded_badge.rb''' 
1. ''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|1200px|]]

[[File:AwardBadgeMethod.png|1200px|]]

E. '''cake.rb''' 
1. ''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|1200px|]]

F. '''response.rb''' 
1. ''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.

2. ''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|1200px|]]

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

G. '''Code Climate issues''' 
1. ''Update'' 
 Made changes to split a line into multiple lines because it is too long. 

[[File:Update_line_long.png|1200px|]]
2. ''Create'' 
 Made changes to split a line into multiple lines because it is too long. 

[[File:Create_line_long.png|1200px|]]

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

File:Show calibration rsults info.png

2022-03-22T02:18:17Z

Amengan:

File:Response helper 2.png

2022-03-22T02:18:07Z

Amengan:

File:Response helper 1.png

2022-03-22T02:17:56Z

Amengan:

File:Get questions by assignment id.png

2022-03-22T02:17:46Z

Amengan:

File:Create or get response.png

2022-03-22T02:17:32Z

Amengan:

File:Cake.png

2022-03-22T02:17:21Z

Amengan:

CSC/ECE 517 Spring 2022 - E2218: Refactor response controller

2022-03-22T02:17:10Z

Amengan:

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

B. '''response_helper.rb''' 
1 . 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'''

C. '''assignment_questionnaire.rb''' 
1. ''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.

D. '''awarded_badge.rb''' 
1. ''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|1200px|]]

[[File:AwardBadgeMethod.png|1200px|]]

E. '''cake.rb''' 
1. ''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.

F. '''response.rb''' 
1. ''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.

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

3. ''create_or_get_response''
Method name ''populate_new_response'' is changed to ''create_or_get_response'' to convey the functionality of the method. 

G. '''Code Climate issues''' 
1. ''Update'' 
 Made changes to split a line into multiple lines because it is too long. 

[[File:Update_line_long.png|1200px|]]
2. ''Create'' 
 Made changes to split a line into multiple lines because it is too long. 

[[File:Create_line_long.png|1200px|]]

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

File:Awrded badge method.png

2022-03-22T02:15:41Z

Amengan:

File:Authorize show calibration results.png

2022-03-22T02:15:16Z

Amengan:

CSC/ECE 517 Spring 2022 - E2218: Refactor response controller

2022-03-22T02:13:19Z

Amengan:

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

B. '''response_helper.rb''' 
1 . 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'''

C. '''assignment_questionnaire.rb''' 
1. ''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.

D. '''awarded_badge.rb''' 
1. ''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|1200px|]]

[[File:AwardBadgeMethod.png|1200px|]]

E. '''cake.rb''' 
1. ''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.

F. '''response.rb''' 
1. ''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.

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

3. ''create_or_get_response''
Method name ''populate_new_response'' is changed to ''create_or_get_response'' to convey the functionality of the method. 

G. '''Code Climate issues''' 
1. ''Update'' 
 Made changes to split a line into multiple lines because it is too long. 

[[File:Update_line_long.png|1200px|]]
2. ''Create'' 
 Made changes to split a line into multiple lines because it is too long. 

[[File:Create_line_long.png|1200px|]]

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