Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2023

2023-03-21T20:31:45Z

Kvankad: Create new page for spring 2023

== OSS Projects ==

[[CSC/ECE 517 Spring_2023 - E2320. Reimplement the Question hierarchy]]

CSC/ECE 517 Spring 2023- E2320. Reimplement the Question hierarchy

2023-03-21T20:31:17Z

Kvankad: Kvankad moved page CSC/ECE 517 Spring 2023- E2320. Reimplement the Question hierarchy to CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question hierarchy: Changing title to conform to format

#REDIRECT [[CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question hierarchy]]

CSC/ECE 517 Spring 2023 - E2320. Reimplement the Question hierarchy

2023-03-21T20:31:17Z

==Expertiza==

[http://expertiza.ncsu.edu/ Expertiza] is a [http://rubyonrails.org/ Ruby on Rails] based open source project. Instructors have the ability to add new projects, assignments, etc., as well as edit existing ones. Later on, they can view student submissions and grade them. Students can also use Expertiza to organize into teams to work on different projects and assignments and submit their work. They can also review other students' submissions.

==Question Hierarchy==

The Question class and its subclasses are used to implement all rubric items, quiz questions, and survey questions in Expertiza. Here is the hierarchy.

Choice question
Scored question
Scale [√]
Criterion [√]
Unscored question
Dropdown [√]
MultipleChoice
CheckBox [√] [should this be a Scored question?}

TextResponse
TextArea [√]
TextField [√]

UploadFile [√]

==Problem Statement==
Dropdown, MultipleChoice, and Scale questions have a lot in common: you display the alternatives and let the user choose one of them. They also differ, in that only Scale is required to have a numeric sequence of choices; Dropdown and MultipleChoice may, but also may have selections that don’t correspond to anything numeric. We would like to write a single piece of code to display all three types of questions

==Files Modified==

Below are the files we changed as part of the reimplementation

question.rb
scale.rb
criterion.rb
text_area.rb
text_field.rb
text_response.rb
questionnaires_controller.rb
answer.rb
checkbox.rb
choice_question.rb
dropdown.rb
multiple_choice_checkbox.rb
multiple_choice_radio.rb
question.rb
question_advice.rb
questionnaire.rb
quiz_question.rb
quiz_question_choice.rb
scored_question.rb
unscored_question.rb

==Reimplementation==
As a part of the reimplementation project, Migrations are created, added relevant old code files and partials are included in the old code files to avoid HTML concatenation.

== Testing Plan ==

==Team==
=====Mentor=====
* Prof. Edward F. Gehringer
* Priyam Garg

=====Members=====
* Colleen Britt
* Kimberly Jones
* Priyanka Arghode

==References==

#[https://expertiza.ncsu.edu/ Expertiza]
#[https://stackoverflow.com/questions/3425971/organizing-partials-for-a-polymorphic-resource Organizing Partials]
#[https://www.amberbit.com/blog/2011/12/27/render-views-and-partials-outside-controllers-in-rails-3 Render Views and Partials Outside Controllers]
#[https://github.com/pparghod/reimplementation-back-end Github Repo]

MainPage

2023-03-21T20:25:37Z

Kvankad: Added link for Spring 2023

==Expertiza==
* [[Expertiza documentation]]

* [[CSC/ECE 517 Summer 2008]]
* [[CSC/ECE 517 Fall 2010]]
* [[CSC/ECE 517 Fall 2011]]
* [[CSC/ECE 517 Fall 2012]]
* [[CSC/ECE 517 Fall 2013]]
* [[CSC/ECE 517 Fall 2014]]
* [[CSC/ECE 517 Fall 2015]]
* [[CSC/ECE 517 Fall 2016]]
* [[CSC/ECE 517 Spring 2014]]
* [[CSC/ECE 517 Spring 2015]]
* [[CSC/ECE 517 Spring 2016]]
* [[CSC/ECE 517 Spring 2017]]
* [[CSC/ECE 517 Fall 2017]]
* [[CSC/Independent Study Spring 2018]]
* [[CSC/ECE 517 Spring 2018]]
* [[CSC/ECE 517 Fall 2018]]
* [[CSC/ECE 517 Spring 2019]]
* [[CSC/ECE 517 Fall 2019]]
* [[CSC/ECE 517 Spring 2020]]
* [[CSC/ECE 517 Summer 2020]]
* [[CSC/ECE 517 Fall 2020]]
* [[CSC/ECE 517 Spring 2021]]
* [[CSC/ECE 517 Fall 2021]]
* [[CSC/ECE 517 Spring 2022]]
* [[CSC/ECE 517 Fall 2022]]
* [[CSC/ECE 517 Spring 2023]]
* [[CSC 456 Spring 2011|CSC 456 Spring 2012]]
* [[ECE 633]]
* [[KCU]]
* [[Progress reports]]
* [[ReactJs Frontend]]
* [[Front-End/Back-End]]

==Application Behavior==
* [[Grading]]

==Metaprogramming==
* [[CSC/ECE_517_Spring_2013/ch1b_1k_hf|Lecture on Metaprogramming]]

==Development==

''Expertiza now has a Java dependency, so the machine you are using to develop Expertiza on should have the JVM installed.''

* [[Setting Up a Development Machine]]
* [[Creating a Linux Development Environment for Expertiza - Installation Guide]]
* [[Using git and github for projects]]
* [[Using heroku to deploy your projects]]
* [[How to Begin a Project from the Current Expertiza Repository]]
* [[Git]]
* [[How to Change a User's Password on a Development Machine]]
* [[Debugging Rails]]
* [http://rajanalwan.com/ui_guidelines/ Design Template]

==Production==
* [[Deploying to Production]]
* [[Downloading Production Data]]
* [[Accessing the Production Server]]

==Testing==
* [[Using Cucumber with Expertiza]]
* [[Rails Testing Overview]]
* [[Expertiza Continuous Integration]]

==References==
* [[Object-Oriented Design and Programming]]

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

2022-04-12T05:05:02Z

Kvankad: waitlist classes

== 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. <br>
We have two users to the system '''Student''' and '''Instructor'''. The interactions these users have with the system are stated below.

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

'''Instructor Interactions''' <br>
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.<br>
2. Instructor should be able to add any team to the waitlist.<br>
3. Instructor should be able to drop any team from the waitlist.<br>
4. Instructor should be able to fetch the details of the teams in a waitlist for a particular topic.<br>
5. Instructor should be able to fetch the details of the topics in which a team is waitlisted. <br>

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

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table are<br>
1. teams<br>
2. signed_up_teams<br>

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

== Plan of action ==

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

=== 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.
<br/>
We plan on retiring/removing the waitlist flag from the signed_up_teams table and separating this functionality.
<br/>
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''
<br/>
The attributes for the table are team_id(refers to the ''teams'' table), topic_id (refers to the ''sign_up_topics'' table)
<br/>
This table only stores the waitlisted teams for each topic.
<br/>
The default timestamp in the table will be used to check the first team waitlisted instead of using queues to implement the functionality.
<br/>
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.
<br/><br/>
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.
<br/>
We plan on writing a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
<br/>
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:''' <br>
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.<br>

'''Test 2:'''<br>
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.<br>

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

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

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

''' Test 6:''' <br>
Instructor should be able to view all the topics available

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

''' Test 8:''' <br>
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-07T03:44:54Z

Kvankad:

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

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

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

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

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

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

1) signed_up_team.rb

2) waitlist.rb

3) sign_up_sheet_controller.rb

4) sign_up_sheet.rb

5) sign_up_topic.rb

6) suggestion_controller.rb

7) invitation.rb

== Proposed design and Plan of action ==

=== General Design Goals ===
Since our goal is to fix existing functionalities we will not be updating the existing design patterns being employed in the code. Yet, we would like to discuss what makes these refactoring important. Refactoring is a systematic process of improving code without creating new functionality. Thus, a key to the success of our project is ensuring everything that was working before our changes work even after our changes have been added. To ensure this. We will be testing the existing features so that we are not breaking what was working before we deployed our fix.
Our goal is to make the experiza system more reliable and have code that is consistent with the standards of object-oriented design.

=== UML Diagram ===

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

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

'''Instructor Interactions''' <br>
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.<br>
2. Instructor should be able to add any team to the waitlist.<br>
3. Instructor should be able to drop any team from the waitlist.<br>
4. Instructor should be able to fetch the details of the teams in a waitlist for a particular topic.<br>
5. Instructor should be able to fetch the details of the topics in which a team is waitlisted. <br>

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

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table:<br>
1. teams<br>
2. signed_up_teams<br>

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 <br>
'''topic_id''' : foreign key in waitlists_team table reference by signed_up_teams table <br>
<br>
<br>

[[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.
<br/>
We plan on retiring/removing the waitlist flag from the signed_up_teams table and separating this functionality.
<br/>
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''
<br/>
The attributes for the table are team_id(refers to the ''teams'' table), topic_id (refers to the ''sign_up_topics'' table)
<br/>
This table only stores the waitlisted teams for each topic.
<br/>
The default timestamp in the table will be used to check the first team waitlisted instead of using queues to implement the functionality.
<br/>
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.
<br/><br/>
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.
<br/>
We plan on writing a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
<br/>
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:''' <br>
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.<br>

'''Test 2:'''<br>
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.<br>

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

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

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

''' Test 6:''' <br>
Instructor should be able to view all the topics available

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

''' Test 8:''' <br>
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-07T03:41:17Z

Kvankad: add waitlist

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

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

'''Instructor Interactions''' <br>
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.<br>
2. Instructor should be able to add any team to the waitlist.<br>
3. Instructor should be able to drop any team from the waitlist.<br>
4. Instructor should be able to fetch the details of the teams in a waitlist for a particular topic.<br>
5. Instructor should be able to fetch the details of the topics in which a team is waitlisted. <br>

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

=== Class Diagram ===

Tables associated with '''waitlist_teams''' table:<br>
1. teams<br>
2. signed_up_teams<br>

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 <br>
'''topic_id''' : foreign key in waitlists_team table reference by signed_up_teams table <br>
<br>
<br>

[[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.
<br/>
We plan on retiring/removing the waitlist flag from the signed_up_teams table and separating this functionality.
<br/>
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''
<br/>
The attributes for the table are team_id(refers to the ''teams'' table), topic_id (refers to the ''sign_up_topics'' table)
<br/>
This table only stores the waitlisted teams for each topic.
<br/>
The default timestamp in the table will be used to check the first team waitlisted instead of using queues to implement the functionality.
<br/>
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.
<br/><br/>
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.
<br/>
We plan on writing a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
<br/>
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:''' <br>
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.<br>

'''Test 2:'''<br>
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.<br>

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

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

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

''' Test 6:''' <br>
Instructor should be able to view all the topics available

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

''' Test 8:''' <br>
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:Waitlist.png

2022-04-07T03:38:00Z

Kvankad:

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

2022-04-06T23:07:39Z

Kvankad:

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

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

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

=== UML Diagram ===

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

=== Class Diagram ===

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

=== Changes to the signed_up_teams Table ===
signed_up_teams table consists of a mapping of team_id, topic_id, is_waitlisted. This table was being used for multiple purposes, one to store the signed up teams and also the waitlisted teams for a topic.
<br/>
We plan on retiring/removing the waitlist flag from the signed_up_teams table and separating this functionality.
<br/>
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''
<br/>
The attributes for the table are team_id(refers to the ''teams'' table), topic_id (refers to the ''sign_up_topics'' table)
<br/>
This table only stores the waitlisted teams for each topic.
<br/>
The default timestamp in the table will be used to check the first team waitlisted instead of using queues to implement the functionality.
<br/>
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.
<br/><br/>
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.
<br/>
We plan on writing a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
<br/>
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-06T22:49:31Z

Kvankad:

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

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

=== Class Diagram ===

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

=== Changes to the signed_up_teams Table ===
signed_up_teams table consists of a mapping of team_id, topic_id, is_waitlisted. This table was being used for multiple purposes, one to store the signed up teams and also the waitlisted teams for a topic.
<br/>
We plan on retiring/removing the waitlist flag from the signed_up_teams table and separating this functionality.
<br/>
All existing references to the is_waitlisted flag will be rewritten to make use of the new table.
<br/>
Managing entries and enforcing constraints will be easier to implement and extend if required.

=== 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 ===
#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
##Get the number of waitlisted teams for all topics in an assignment

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

===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.
<br/>
We plan on writing a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
<br/>
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-06T22:48:07Z

Kvankad:

== 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 ===
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.
<br/>
We plan on retiring/removing the waitlist flag from the signed_up_teams table and separating this functionality.
<br/>
All existing references to the is_waitlisted flag will be rewritten to make use of the new table.
<br/>
Managing entries and enforcing constraints will be easier to implement and extend if required.

=== 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 ===
#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
##Get the number of waitlisted teams for all topics in an assignment

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

===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.
<br/>
We plan on writing a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
<br/>
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-06T22:43:35Z

Kvankad:

== 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 ===
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.
<br/>
We plan on retiring/removing the waitlist flag from the signed_up_teams table and separating this functionality.
<br/>
All existing references to the is_waitlisted flag will be rewritten to make use of the new table.
<br/>
Managing entries and enforcing constraints will be easier to implement and extend if required.

=== 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 ===
#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
##Get the number of waitlisted teams for all topics in an assignment

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

===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.
<br/>
We plan on writing a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
<br/>
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>

=== 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-06T22:41:56Z

Kvankad:

== 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 ===
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.
<br/>
We plan on retiring/removing the waitlist flag from the signed_up_teams table and separating this functionality.
<br/>
All existing references to the is_waitlisted flag will be rewritten to make use of the new table.
<br/>
Managing entries and enforcing constraints will be easier to implement and extend if required.

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

===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.
<br/>
We plan on writing a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
<br/>
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
##Get the number of waitlisted teams for all topics in an assignment

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

=== 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-06T22:37:12Z

Kvankad: signed_up_teams table

== 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 ===
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.
<br/>
We plan on retiring/removing the waitlist flag from the signed_up_teams table and separating this functionality.
<br/>
All existing references to the is_waitlisted flag will be rewritten to make use of the new table.
<br/>
Managing entries and enforcing constraints will be easier to implement and extend if required.

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

===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.
<br/>
We plan on writing a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
<br/>
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
##Get the number of waitlisted teams for all topics in an assignment

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

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

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

2022-04-06T22:27:18Z

Kvankad: add operation

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

===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.
<br/>
We plan on writing a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
<br/>
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
##Get the number of waitlisted teams for all topics in an assignment

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

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

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

2022-04-06T22:24:37Z

Kvankad: add migration details

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

===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.
<br/>
We plan on writing a migration script to move the waitlists from signed_up_teams table to waitlist_teams table.
<br/>
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 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'')

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

2022-04-06T22:16:46Z

Kvankad: add other files to the refactor

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

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

2022-04-06T22:10:17Z

Kvankad: sign_up_topic changes

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

'''The topic is available''':

In this case, the team will be assigned this topic ( Assuming that there is no bidding for the assignment ).

'''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
##cancel_all_wailists (typo in code)
###Does 2 things - 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 ===
#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'')

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

2022-04-06T21:36:23Z

Kvankad: invitation changes

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

'''The topic is available''':

In this case, the team will be assigned this topic ( Assuming that there is no bidding for the assignment ).

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

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

2022-04-06T20:25:51Z

Kvankad: files changed

== Problem Statement==

=== Feature Overview ===

=== Issues with existing functionality ===

=== Overview of Major Changes ===

== Proposed design and Plan of action ==

=== General Design Goals ===
=== 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
#invitation.rb

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

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

2022-04-06T19:43:19Z

Kvankad: Reordered segments

== Problem Statement==

=== Feature Overview ===

=== Issues with existing functionality ===

=== Overview of Major Changes ===

== Proposed design and Plan of action ==

=== General Design Goals ===
=== Changes to the signed_up_teams Table ===
=== Files Involved ===

===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: Topic for a 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 waitlist for the topic.

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

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

2022-04-06T18:06:51Z

Kvankad: added new cases

== Project Overview ==
=== Feature Overview ===

=== Overview of Major Changes ===

=== Files Involved ===

=== Testing ===

==== Issues with Existing Tests ====

== Statement of Problem ==

== Plan and List of Work Done ==

=== General Design Goals ===
====Changes to the signed_up_teams Table====

====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: Topic for a 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 waitlist for the topic.

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

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

2022-04-06T15:31:16Z

Kvankad: Initial Commit with skeleton

== Project Overview ==
=== Feature Overview ===

=== Overview of Major Changes ===

=== Files Involved ===

=== Testing ===

==== Issues with Existing Tests ====

== Statement of Problem ==

== Plan and List of Work Done ==

=== General Design Goals ===
====Changes to the signed_up_teams Table====

====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.
#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: Topic for a 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 waitlist for the topic.

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

CSC/ECE 517 Spring 2022

2022-04-06T14:34:05Z

Kvankad: Added E2242 fix teammate -review page

== OSS Projects ==

* [[CSC/ECE 517 Spring 2022 - E2200: Testing advice_controller]]
* [[CSC/ECE 517 Spring 2022 - E2203: Adding tests for courses_controller, eula_controller]]
* [[CSC/ECE 517 Spring 2022 - E2204: Adding tests for markup_styles_controller, lock_controller]]
* [[CSC/ECE 517 Spring 2022 - E2208: Testing for submission_records_controller, profile_controller]]
* [[CSC/ECE 517 Spring 2022 - E2218: Refactor response_controller]]
* [[CSC/ECE 517 Spring 2022 - E2217: Refactor questionnaires_controller]]
* [[CSC/ECE 517 Spring 2022 - E2216: Refactor late_policies_controller]]
* [[CSC/ECE 517 Spring 2022 - E2215: Refactor student_quizzes_controller]]
* [[CSC/ECE 517 Spring 2022 - E2214: Refactor teams_controller]]
* [[CSC/ECE 517 Spring 2022 - E2219: Improve assessment360_controller.rb]]
* [[CSC/ECE 517 Spring 2022 - E2211: Testing for summary_helper]]
* [[CSC/ECE 517 Spring 2022 - E2225: Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2022 - E2221: Refactor submitted content controller.rb]]
* [[CSC/ECE 517 Spring 2022 - E2206: Testing for users_controller]]
* [[CSC/ECE 517 Spring 2022 - E2207: Testing for submitted_content_controller.rb]]
* [[CSC/ECE 517 Spring 2022 - E2205: Testing for participants_controller, versions_controller]]
* [[CSC/ECE 517 Spring 2022 - E2212: Testing for hamer.rb]]
* [[CSC/ECE 517 Spring 2022 - S2200: Refactoring evaluation of SQL queries (Java/JUnit)]]
* [[CSC/ECE 517 Spring 2022 - S2222: Refactor impersonate_controller]]
* [[CSC/ECE 517 Spring 2022 - E2202- Testing for badges_controller, publishing_controller]]
*[[CSC/ECE 517 Spring 2022 - E2220: Refactor reputation_web_service_controller]]
* [[CSC/ECE 517 Spring 2022 - E2224: Refactor review_mapping_controller]]
* [[CSC/ECE 517 Spring 2022 - E2209: Testing for analytic helper.rb, join team requests helper.rb]]
* [[CSC/ECE 517 Spring 2022 - E2227: SQL Injection Fix]]
* [[CSC/ECE 517 Spring 2022 - E2223. Refactor sign up sheet controller.rb]]
* [[CSC/ECE 517 Spring 2022 - E2201: Testing for assignment_questionnaire_controller.rb]]
* [[CSC/ECE 517 Spring 2022 - E2243. Refactor student_teams functionality]]

== Final Projects ==
* [[CSC/ECE 517 Spring 2022 - E2245: View for results of bidding]]
* [[CSC/ECE 517 Spring 2022 - E2241: Heatgrid fixes and improvements]]
* [[CSC/ECE 517 Spring 2022 - E2237: Grading audit trail]]
* [[CSC/ECE 517 Spring 2022 - S2201: Improving User Experience for SQLFE]]
* [[CSC/ECE 517 Spring 2022 - E2236: Fix issues related to deadlines and late policies]]
* [[CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review]]
* [[CSC/ECE 517 Spring 2022 - E2233. Improving search facility in Expertiza]]
* [[CSC/ECE 517 Spring 2022 - E2234. Calibration submissions should be copied along with calibration assignments]]
* [[CSC/ECE 517 Spring 2022 - E2244. Support for saying your team pair-programmed]]
* [[CSC/ECE 517 Spring 2022 - E2246: Email your authors/reviewers, with complete tests]]
* [[CSC/ECE 517 Spring 2022 - E2229: Track the time students look at other submissions]]
* [[CSC/ECE 517 Spring 2022 - E2239: Further refactoring and improvement of review mapping helper.rb ]]
* [[CSC/ECE 517 Spring 2022 - E2240. Re-write waitlist functionality ]]
* [[CSC/ECE 517 Spring 2022 - E2242. Fix teammate-review view ]]

CSC/ECE 517 Spring 2022 - E2220: Refactor reputation web service controller

2022-03-28T03:57:21Z

Kvankad: added test plan heading

This page provides information about the refactoring work done on the reputation web service controller as part of the OSS project.

__TOC__

<h2> Team </h2>
<h3> Mentor </h3>
* Naman Shrimali (nshrima)
<h3> Team Members (MissingSemicolon) </h3>
* Eshwar Chandra Vidhyasagar Theda (ethedla)
* Gokul Krishna Koganti (gkogant)
* Krishna Saurabh Vankadaru (kvankad)

<h2> Expertiza </h2>

Expertiza is an assignment management portal. This portal can be used by instructors to create assignments. It can be used by students to submit their academic works and peer review others' works. Expertiza allows students to
create, join and work in teams.

<h2> Background of reputation web service controller </h2>

Expertiza provides a way for students to peer review others' works. The motive of this provision is to encourage students to learn more while reviewing others' works and utilize the reviews to reflect on the grades. However, to depend on the peer reviews, the reviews' credibility has to be established. This credibility can be evaluated through reputation scores computed by reputation systems. These systems are deployed as web services and facilitate the calculation of past and present assignment scores for peer review research.

In the project's scope, we focus on the aspect of refactoring the file reputation_web_service_controller.rb. This is a controller file used for the calculation of reputation scores. This is measured based on how close the current review scores are to the other.

<h2> Issues identified </h2>
<ol>
<li> Some methods are violating the single responsibility principle, i.e, some methods are doing more than one tasks. These methods must be broken down such that each method performs only one task. </li>
<li> In send_post_request, references to specific assignments, such as 724, 735, and 756 are no longer relevant and must be removed. </li>
<li> Some method names followed bad naming convention. These method names are general and are in noun forms. Specific relevant names must be used as method names.</li>
<li> Detailed method descriptions are needed to be inserted into the code as comments.</li>
<li> There is a lot of unused/commented code, which should be removed.</li>
<li> Some spelling mistakes are identified in the code.</li>
</ol>

<h2> Enhancements </h2>
<h3> Functionality Fixes</h3>
<p> The controller we received to perform refactoring work on, was not in a working condition. We found many issues pertaining to the below mentioned fixes and had to debug the file extensively. Later refactoring work is done on the debugged and working code.</p>
<ol>
<li> The case of when a post request to reputation web service fails is not handled properly, resulting in a long error message on the view. This error has been handled to display formatted error on the page. <br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/15/commits/84c9f30f9ee29759b5a41c9d11cda53c298fe49b </li><br/>

<li> Commented out the part of encryption and decryption as the public key files are not available.<br/>
<b> Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/15/commits/db83d497dd284cf0700d219f1b225f2d6c508ac8 </li><br/>

<li> In send_post_request (old version, currently prepare_request_body), init_header has been removed and requested & response JSON has been displayed in the beautify JSON for the implemented algorithms. This is done by using constant objects instead of URL strings. <br/>
<b> Commit link: </b>https://github.com/krishnasaurabh/expertiza/pull/17/commits/f343438383d56d577648ef4dd91de4fc3501449a</li><br/>

<li> When the control is redirected to the client, in the older versions, the data was being passed through the use of instance variables. Now, the parameters are being passed using flash.<br/>
<b> Commit link: </b>https://github.com/krishnasaurabh/expertiza/pull/15/commits/bf2ab75eb7b25e6d0b79791610beb371383b6042</li>

</ol>
<h3> Refactoring </h3>
<h4> Introduced single responsibility principle to the functions</h4>
<p> All the functions are modified in a way to concur with the single responsibility principle i.e, each function performs only one considerable task.</p>
<p>The following functions violated SRP:</p>
<ol>
<li> The <b>db_query</b> method not only queries, but calculates sums.</li>
<li> The <b>json_generator</b> method not only generates json, but also queries the database based on the ‘type’ it receives.</li>
<li> The <b>send_post_request</b> not only sends a post request, but generates a body based on parameters received, encrypts the data, hits the post request, decrypts the response data, and updates participants.</li>
</ol>
<p>SRP is introduced in the following ways:</p><ol>
<li> The <b>db_query</b> method is split into calculate_peer_review_grade and get_peer_reviews methods. <br/>
get_peer_reviews uses get_peer_reviews_for_responses method, which further calls get_valid_answers_for_response, get_max_question_score , calculate_peer_review_grade methods.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/5/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>

<li> The <b>json_generator</b> method is split into generate_json_body, generate_json_for_peer_reviews, generate_json_for_quiz_scores.These functions further use helper methods to abide by the SRP principle.<br/>
generate_json_for_peer_reviews calls get_peer_reviews and generate_json_body methods.<br/>
get_peer_reviews calls get_peer_reviews_for_responses method.<br/>
generate_json_for_quiz_scores calls get_quiz_score and generate_json_body methods.<br/>
get_quiz_score calls get_ids_list and get_scores methods.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>

<li> The <b>send_post_request</b> is split into prepare_request_body and process_response_body methods.<br/>
prepare_request_method uses add_expert_grades, add_quiz_scores, add_hamer_reputation_values, add_lauw_reputation_values, encrypt_request_body, format_into_JSON to prepare the request body.<br/> process_response_body makes use of decrypt_response and update_participants to process the response received.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>
</ol>

<h4> Removed unnecessary references in the send_post_request body</h4>
<p>In send_post_request, there are references to specific assignments, such as 724, 735, and 756. They were put in to gather data for a paper published in 2015. They are no longer relevant and are removed. Relevant tests are also removed.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/commit/d5d0a6de203b9643bcb1750328261ea6e9abdde5
<h4> Changed method names to make them more meaningful</h4>
<p> Method names should be verbs, and should say what the method does. Method names should not be so general that they could apply to many different methods. Bad method names are observed in the methods, db_query and json_generator. These method names are too general and needed changing.</p>
<ul>
<li> db_query is changed to get_peer_reviews method.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li>
<li> json_generator is split into various methods with specific method names: generate_json_body, generate_json_for_peer_reviews, generate_json_for_quiz_scores. .<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/b305e98448538dd342640e62a1cd4c2fae6b3b5d </li>
</ul>

<h4> Function descriptions</h4>
<p> In the older version, controller's functions did not have function descriptions. In the current version, a detailed functional description has been added to each method. Additionally, descriptions include what parameters are accepted and what is returned. Proper convention is followed in accordance with the industry standards for the method descriptions, parameters and return specifications.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/20/commits/d8c86b0c0a073c894e0700e6f4f971a1ec845cee

<h4> Removed unnecessary code</h4>
<p>Commented code blocks that are unused are found and deleted from the controller's body. RSA Encryption and Decryption are not being used for now. Such code is commented out for potential future use. </p>
<b>Commit link: </b> https://github.com/expertiza/expertiza/pull/2291/commits/673fe2099991c21237c59c71d7ee51f063e55b70

<h4> Corrected spelling mistakes </h4>
<p> Only one instance of spelling error has been identified i.e, dimention. It has been corrected.</p>
<b>Commit link: </b> https://github.com/expertiza/expertiza/pull/2226/commits/efc4b4dcbd5d3b1f783d660f70ac18abfb451ab7

<h4> Used map functionality instead of for loop to make the code compact</h4>
<p> In some functions table's records are replaced with the record's ID. This is done by looping the table and changing each record. We improved this by using the map functionality to map the records with their respective IDs.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/commit/36bc4fa30d7c6548cb64e59ebca2a3afe4c9c4a9

<h2> Test Plan </h2>

<h3> Manual Testing </h3>

To test the changes manually use the following link to access the reputation web service endpoint.
<br/>http://152.7.177.155:8080/reputation_web_service/client<br/>
<b> Username :</b> instructor6 <br/>
<b>Password :</b> password <br/>

<br/>
<p> Enter assignment id which is a mandatory field, the secondary assignment id is optional. Enter the round number for which we want to calculate the reputation for (1-3) </p>
<p> Select the type of algorithm to calculate the reputation for the peer reviews.</p>
<p> Based on the type of algorithm selected, some of the additional information is automatically passed. Other additional information is optional.
<p> Click send request (This might take a few minutes, please be patient)</p>
<p> On clicking the send request, the JSON for the post request to the reputation web service is formed, and then sent. <br/>On receiving the response, we parse it and update the reputation of participants of the assignment provided. <br/>The request and response JSONs can be seen in both minified and beautified versions.
<br/> There is also a summary of the choices selected above the beautified JSONs.
<br/>
<br/>
[[File:Manual_Testing.png|800px]]

<h3> Testing via rspec </h3>
<br/>
Only a few methods and flows have automated test cases. Adding test cases is not in the scope of this project, and will be taken up later, to make the entire controller robust.<br/> However, we have made sure that all the existing test cases are not broken and working as they are supposed to be.</p>
<p> To run the automated rspec cases run the below command to verify if all the test cases are working.</p>
<pre> rspec spec/controllers/reputation_web_service_controller_spec.rb </pre>

<h2> Future Work </h2>
<ol>
<li> Client view has checkboxes for choosing between the action to be performed. But only the first checked action is being considered. This has to be fixed by the use of radio buttons.
<li> Hamer and Lauw actions are not resulting in any functional implementations. These algorithms have to be implemented.</li>
<li> Need to fix the usage of assignment_id and another_assignment_id for the Hamer and Lauw algorithms</li>
<li> Client is a bad method name and needs to be changed.</li>
<li> Formatting string into JSON can be improved. Instead of prepending characters like '{', dictionaries can be used and then converted into JSON.</li>
</ol>

<h2> GitHub Repository and Pull Request links </h2>

Link to the Expertiza repository: https://github.com/expertiza/expertiza <br/>
Link to the forked repository: https://github.com/krishnasaurabh/expertiza/tree/beta <br/>
Link to the pull request: https://github.com/expertiza/expertiza/pull/2291 <br/>

CSC/ECE 517 Spring 2022 - E2220: Refactor reputation web service controller

2022-03-22T04:57:27Z

Kvankad: added description for testing

This page provides information about the refactoring work done on the reputation web service controller as part of the OSS project.

__TOC__

<h2> Team </h2>
<h3> Mentor </h3>
* Naman Shrimali (nshrima)
<h3> Team Members (MissingSemicolon) </h3>
* Eshwar Chandra Vidhyasagar Theda (ethedla)
* Gokul Krishna Koganti (gkogant)
* Krishna Saurabh Vankadaru (kvankad)

<h2> Expertiza </h2>

Expertiza is an assignment management portal. This portal can be used by instructors to create assignments. It can be used by students to submit their academic works and peer review others' works. Expertiza allows students to
create, join and work in teams.

<h2> Background of reputation web service controller </h2>

Expertiza provides a way for students to peer review others' works. The motive of this provision is to encourage students to learn more while reviewing others' works and utilize the reviews to reflect on the grades. However, to depend on the peer reviews, the reviews' credibility has to be established. This credibility can be evaluated through reputation scores computed by reputation systems. These systems are deployed as web services and facilitate the calculation of past and present assignment scores for peer review research.

In the project's scope, we focus on the aspect of refactoring the file reputation_web_service_controller.rb. This is a controller file used for the calculation of reputation scores. This is measured based on how close the current review scores are to the other.

<h2> Issues identified </h2>
<ol>
<li> Some methods are violating the single responsibility principle, i.e, some methods are doing more than one tasks. These methods must be broken down such that each method performs only one task. </li>
<li> In send_post_request, references to specific assignments, such as 724, 735, and 756 are no longer relevant and must be removed. </li>
<li> Some method names followed bad naming convention. These method names are general and are in noun forms. Specific relevant names must be used as method names.</li>
<li> Detailed method descriptions are needed to be inserted into the code as comments.</li>
<li> There is a lot of unused/commented code, which should be removed.</li>
<li> Some spelling mistakes are identified in the code.</li>
</ol>

<h2> Enhancements </h2>
<h3> Functionality Fixes</h3>
<p> The controller we received to perform refactoring work on, was not in a working condition. We found many issues pertaining to the below mentioned fixes and had to debug the file extensively. Later refactoring work is done on the debugged and working code.</p>
<ol>
<li> The case of when a post request to reputation web service fails is not handled properly, resulting in a long error message on the view. This error has been handled to display formatted error on the page. <br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/15/commits/84c9f30f9ee29759b5a41c9d11cda53c298fe49b </li><br/>

<li> Commented out the part of encryption and decryption as the public key files are not available.<br/>
<b> Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/15/commits/db83d497dd284cf0700d219f1b225f2d6c508ac8 </li><br/>

<li> In send_post_request (old version, currently prepare_request_body), init_header has been removed and requested & response JSON has been displayed in the beautify JSON for the implemented algorithms. This is done by using constant objects instead of URL strings. <br/>
<b> Commit link: </b>https://github.com/krishnasaurabh/expertiza/pull/17/commits/f343438383d56d577648ef4dd91de4fc3501449a</li><br/>

<li> When the control is redirected to the client, in the older versions, the data was being passed through the use of instance variables. Now, the parameters are being passed using flash.<br/>
<b> Commit link: </b>https://github.com/krishnasaurabh/expertiza/pull/15/commits/bf2ab75eb7b25e6d0b79791610beb371383b6042</li>

</ol>
<h3> Refactoring </h3>
<h4> Introduced single responsibility principle to the functions</h4>
<p> All the functions are modified in a way to concur with the single responsibility principle i.e, each function performs only one considerable task.</p>
<p>The following functions violated SRP:</p>
<ol>
<li> The <b>db_query</b> method not only queries, but calculates sums.</li>
<li> The <b>json_generator</b> method not only generates json, but also queries the database based on the ‘type’ it receives.</li>
<li> The <b>send_post_request</b> not only sends a post request, but generates a body based on parameters received, encrypts the data, hits the post request, decrypts the response data, and updates participants.</li>
</ol>
<p>SRP is introduced in the following ways:</p><ol>
<li> The <b>db_query</b> method is split into calculate_peer_review_grade and get_peer_reviews methods. <br/>
get_peer_reviews uses get_peer_reviews_for_responses method, which further calls get_valid_answers_for_response, get_max_question_score , calculate_peer_review_grade methods.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/5/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>

<li> The <b>json_generator</b> method is split into generate_json_body, generate_json_for_peer_reviews, generate_json_for_quiz_scores.These functions further use helper methods to abide by the SRP principle.<br/>
generate_json_for_peer_reviews calls get_peer_reviews and generate_json_body methods.<br/>
get_peer_reviews calls get_peer_reviews_for_responses method.<br/>
generate_json_for_quiz_scores calls get_quiz_score and generate_json_body methods.<br/>
get_quiz_score calls get_ids_list and get_scores methods.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>

<li> The <b>send_post_request</b> is split into prepare_request_body and process_response_body methods.<br/>
prepare_request_method uses add_expert_grades, add_quiz_scores, add_hamer_reputation_values, add_lauw_reputation_values, encrypt_request_body, format_into_JSON to prepare the request body.<br/> process_response_body makes use of decrypt_response and update_participants to process the response received.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li><br/>
</ol>

<h4> Removed unnecessary references in the send_post_request body</h4>
<p>In send_post_request, there are references to specific assignments, such as 724, 735, and 756. They were put in to gather data for a paper published in 2015. They are no longer relevant and are removed. Relevant tests are also removed.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/commit/d5d0a6de203b9643bcb1750328261ea6e9abdde5
<h4> Changed method names to make them more meaningful</h4>
<p> Method names should be verbs, and should say what the method does. Method names should not be so general that they could apply to many different methods. Bad method names are observed in the methods, db_query and json_generator. These method names are too general and needed changing.</p>
<ul>
<li> db_query is changed to get_peer_reviews method.<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/3c5b2b5e33675aaf121a954180eee11f31a8cb36 </li>
<li> json_generator is split into various methods with specific method names: generate_json_body, generate_json_for_peer_reviews, generate_json_for_quiz_scores. .<br/>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/3/commits/b305e98448538dd342640e62a1cd4c2fae6b3b5d </li>
</ul>

<h4> Function descriptions</h4>
<p> In the older version, controller's functions did not have function descriptions. In the current version, a detailed functional description has been added to each method. Additionally, descriptions include what parameters are accepted and what is returned. Proper convention is followed in accordance with the industry standards for the method descriptions, parameters and return specifications.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/pull/20/commits/d8c86b0c0a073c894e0700e6f4f971a1ec845cee

<h4> Removed unnecessary code</h4>
<p>Commented code blocks that are unused are found and deleted from the controller's body. RSA Encryption and Decryption are not being used for now. Such code is commented out for potential future use. </p>
<b>Commit link: </b> https://github.com/expertiza/expertiza/pull/2291/commits/673fe2099991c21237c59c71d7ee51f063e55b70

<h4> Corrected spelling mistakes </h4>
<p> Only one instance of spelling error has been identified i.e, dimention. It has been corrected.</p>
<b>Commit link: </b> https://github.com/expertiza/expertiza/pull/2226/commits/efc4b4dcbd5d3b1f783d660f70ac18abfb451ab7

<h4> Used map functionality instead of for loop to make the code compact</h4>
<p> In some functions table's records are replaced with the record's ID. This is done by looping the table and changing each record. We improved this by using the map functionality to map the records with their respective IDs.</p>
<b>Commit link: </b> https://github.com/krishnasaurabh/expertiza/commit/36bc4fa30d7c6548cb64e59ebca2a3afe4c9c4a9

<h2> Manual Testing </h2>

To test the changes manually use the following link to access the reputation web service endpoint.
<br/>http://152.7.177.155:8080/reputation_web_service/client
<br/>
<p> Enter assignment id which is a mandatory field, the secondary assignment id is optional. Enter the round number for which we want to calculate the reputation for (1-3) </p>
<p> Select the type of algorithm to calculate the reputation for the peer reviews.</p>
<p> Based on the type of algorithm selected, some of the additional information is automatically passed. Other additional information is optional.
<p> Click send request (This might take a few minutes, please be patient)</p>
<p> On clicking the send request, the JSON for the post request to the reputation web service is formed, and then sent. <br/>On receiving the response, we parse it and update the reputation of participants of the assignment provided. <br/>The request and response JSONs can be seen in both minified and beautified versions.
<br/> There is also a summary of the choices selected above the beautified JSONs.
<br/>
[[File:Manual_Testing.png|800px]]

<h2> Testing via rspec </h2>
Only a few methods and flows have automated test cases. Adding test cases is not in the scope of this project, and will be taken up later, to make the entire controller robust.<br/> However, we have made sure that all the existing test cases are not broken and working as they are supposed to be.</p>
<p> To run the automated rspec cases run the below command to verify if all the test cases are working.</p>
<pre> rspec spec/controllers/reputation_web_service_controller_spec.rb </pre>

<h2> Future Work </h2>
<ol>
<li> Client view has checkboxes for choosing between the action to be performed. But only the first checked action is being considered. This has to be fixed by the use of radio buttons.
<li> Hamer and Lauw actions are not resulting in any functional implementations. These algorithms have to be implemented.</li>
<li> Need to fix the usage of assignment_id and another_assignment_id for the Hamer and Lauw algorithms</li>
<li> Client is a bad method name and needs to be changed.</li>
<li> Formatting string into JSON can be improved. Instead of prepending characters like '{', dictionaries can be used and then converted into JSON.</li>
</ol>

<h2> GitHub Repository and Pull Request links </h2>

Link to the Expertiza repository: https://github.com/expertiza/expertiza <br/>
Link to the forked repository: https://github.com/krishnasaurabh/expertiza/tree/beta <br/>
Link to the pull request: https://github.com/expertiza/expertiza/pull/2291 <br/>