Expertiza_Wiki - User contributions [en]

Restart Instructions for Expertiza

2023-01-24T01:51:46Z

Ddoshi2:

The Expertiza application runs under the Phusion Passenger server for Apache. Passenger dynamically starts and kills instances of the rails application as demand on the application changes. After making changes to the application code, only the rails application need be restarted, not Apache. Apache only need be restarted when making changes to the Apache web server configuration in /etc/httpd/.

== Restarting the rails application ==

'''Deprecated'''

Restarting preferably is done via capistrano. See [[Deploying_Expertiza_to_Production]] for capistrano setup instructions.

From your development machine in the expertiza app directory, run

: cap deploy:restart

'''Current System instruction (2023)'''

If you have sudo access, you can SSH into the production server and run

: sudo -u rails touch /var/www/expertiza/current/tmp/restart.txt

If this dosen't work, restart the server using the command - shutdown -r
After doing shutdown -r, you might need to restart redis server as well using the command

/etc/init.d/redis_6379 start

== Restarting Apache web server ==

: sudo /etc/init.d/httpd restart

SSL Password: expertiza

== Troubleshooting ==

# Apache needs to be started if you get a Connection Refused error when connecting to the site.
#: Stop the /usr/etc/httpd process if it is running.
#:: ps –ef | grep httpd
#: If httpd is running, kill its pid
#:: kill <process id>
#: Start the apache server
#:: apachectl start
#:: Enter the SSL password: expertiza
# MediaWiki will be started as part of the initialization of the environment. There is no further requirement for this processes.
# It may be necessary to restart MySQL if you are receiving the error: <i>Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock'</i> or <i>Connection refused - /var/lib/mysql/mysql.sock</i>.
#: /sbin/service mysqld restart

(Note: If only the MySql server needs to be restarted, simply run: sudo /etc/init.d/mysqld restart )

Back to [[Expertiza_documentation]] Main page.

CSC/ECE 517 Fall 2021 - E2150. Integrate suggestion detection algorithm

2021-11-28T21:39:07Z

Ddoshi2:

== Problem Definition ==
Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, students learn from the reviews they receive to improve their own performance. In order to make this happen, it would be good to have everyone give quality reviews instead of generic ones. Currently, Expertiza has a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services. We need to make the UI more intuitive by allowing users to view the feedback of specific review comments and the code needs to be refactored to remove redundancy to follow the DRY principle.

== Previous Implementation ==

=== Overview ===
The previous implementation added the following features:
# Setup a config file 'review_metric.yml' where the instructor can select what review metric to display for the current assignments
# API calls (sentiment, problem, suggestion) are made and a table is rendered below, displaying the feedback of the review comments.
# The total time taken by the API calls was also displayed.

=== UI Screenshots ===
The following image shows how a reviewer interacts with the system to get feedback on the review comments.
[[File:Steps_metric.png|1200px|thumb|center]]

=== Control Flow ===

[[File:Review_metric.png]]

== Issues with Previous Work ==

With the previous implementation of this project, students can write comments and request feedback for the comments. There are certain issues with the previous implementation that needs to be addressed.

# The criteria are numbered in the view, and those numbers do not correspond to anything on the rubric form. So if the rubric is long, it would be quite difficult for the reviewer to figure out what automated feedback referred to which comment.
# Too much specific information on metrics is encoded into the text. While some of the info is in configuration files, the help text for the info buttons is in the code.
# Currently there are many repetitive blocks of code. For Ex.; in _response_analysis.html for the getReviewFeedback(), the API call for each type of tag (sentiment, suggestion, etc) is being repeated. Only the API link differs there.
# The previous implementation takes the text area field in the view to fetch the review comment, but it’s not updated dynamically when the user types a comment. The user needs to save the form then go back to edit view and then request feedback.

== Proposed Solution ==
[[File:PreviousImplementation.jpeg|1000px|thumb| center | previous Implementation]]
# We need to improve the UI so that if there are many rubric items, users can easily check the feedback for each comment given to each rubric item. We propose the following solution
## Each comment on hover shows the user's respective comment on the specific rubric review question so that the feedback is easily accessible.
### On click of the get review feedback button, we loop through the dynamically created review question form and store the mapping of questions and the reviewer's corresponding comments which on hovered are displayed as a popup.
[[File:Proposedsolution.jpeg|1000px|thumb| center | LOFI Design of Proposed Solution]]

# Another issue with the current implementation is that code is quite repetitive for making different API calls (Sentiment, Suggestion, etc). We propose to store the API link in the config file and refer to the variable in the getReviewFeedback()
# We also plan to remove a global variable response_general, which is being used to store the response of API calls. We will refactor the makeRequest function to directly return the response which can be used in various places. This will resolve implicit coupling issues in the code and make it more easily extendable.
# The previous implementation has hardcoded configuration information like the help text button. We propose to save this information in config files which can be easily modified and will remove unnecessary information from the code.

== Implementation ==

=== UI Changes ===
We refactored the UI of the generated table showing the problem, suggestion, and sentiment of the review comment, by adding a tooltip for prompting the Question and its corresponding review comment in the table itself.
==== UI screenshots ====
==== Javascript implementation ====
#Description - We have added a tooltip in front of every comment number, which on hovering shows the question for which the feedback is given as well as the review comment given for that question.
#File changed - app/views/response/_response_analysis.html.erb

=== Bug Fixes (Dynamic Feedback) ===
Previously, the implementation took into account the text area field because of which we need to save the form before getting the feedback. We changed the implementation so that users can type in a review comment and dynamically get feedback on it before saving.
==== Javascript implementation ====
#Description - The global variable response_general was used to store the response, which was not needed as the Promise will return the response and we threw an error in case of rejection, which is handled at the place we call makeRequest
#File changed - app/views/response/_response_analysis.html.erb

=== Refactoring (removing code duplication) ===
In the previous implementation, code was duplicated for handling different scenarios of fetching the review comment. The code was mostly the same with some conditions. We abstracted the functionality into a method that can be used at multiple places instead of duplicating the code
==== Javascript implementation ====
#Description - The internal function create_comment_object is used for generating comment object according to question and class_name of DOM. This comment JSON is then used to pass to the API for fetching the predictions.
#File changed - app/views/response/_response_analysis.html.erb

=== Error handling improvements ===
We introduced error handling by changing the “Loading…” text to “Request failed. Please try again.” if the API for generating feedback fails. Previously, this case was not handled
==== Javascript implementation ====
#Description - We have added try-catch blocks while making API call, and if the promise is rejected we catch the error and change the “Loading…” text at the bottom to “Request failed. Please try again.”
#Files changed - app/views/response/_response_analysis.html.erb

=== Possible files to be edited ===
# review_metrics.yml
# response.html.erb
# _response_analysis.html.erb
# response_controller.rb
# response_controller_spec.rb

== Sample API Input/Output ==
* Input Text is passed in the following JSON format
{
"text": "This is an excellent project. Keep up the great work"
}

* Output is returned in the following JSON format:
{
"sentiment_score": 0.9,
"sentiment_tone": "Positive",
"suggestions": "absent",
"suggestions_chances": 10.17,
"text": "This is an excellent project. Keep up the great work",
"total_volume": 10,
"volume_without_stopwords": 6
}

== Testing Plan ==
This project mainly addresses the UI issues and some code refactoring in views. Therefore, we will be focussing on view tests as all the automated tests have been previously implemented and new code won't affect those.

===View Tests(Manual)===

#The functionality was written on the client side in javascript solely in _response_analysis.html.erb
#To test this view, any type of review must be accessible as a student.
#There is a button at the bottom of the review called 'Get Review Feedback'.
#When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is shown in above screenshot).
#As API calls will take time, 'Loading..' text will appear until the API calls are complete
#All the review feedback for the comments will be displayed in a colorful table.
#In the feedback table, upon hovering on the comment number, we will be able to see the rubric item and review comments associated with that particular rubric item

== Important Links ==
# https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.fxfungdw1d5r
# https://github.com/expertiza/expertiza/pull/1952 (Previous implementation pull request)
# https://www.youtube.com/watch?v=OYZvNVa3GZ8&feature=youtu.be (Youtube video for previous implementation)

== Team ==

* Prashan Sengo (psengo)

* Griffin Brookshire (glbrook2)

* Divyang Doshi (ddoshi2)

* Srujan Ponnur (sponnur)

CSC/ECE 517 Fall 2021 - E2150. Integrate suggestion detection algorithm

2021-11-28T21:38:44Z

Ddoshi2:

== Problem Definition ==
Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, students learn from the reviews they receive to improve their own performance. In order to make this happen, it would be good to have everyone give quality reviews instead of generic ones. Currently, Expertiza has a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services. We need to make the UI more intuitive by allowing users to view the feedback of specific review comments and the code needs to be refactored to remove redundancy to follow the DRY principle.

== Previous Implementation ==

=== Overview ===
The previous implementation added the following features:
# Setup a config file 'review_metric.yml' where the instructor can select what review metric to display for the current assignments
# API calls (sentiment, problem, suggestion) are made and a table is rendered below, displaying the feedback of the review comments.
# The total time taken by the API calls was also displayed.

=== UI Screenshots ===
The following image shows how a reviewer interacts with the system to get feedback on the review comments.
[[File:Steps_metric.png|1200px|thumb|center]]

=== Control Flow ===

[[File:Review_metric.png]]

== Issues with Previous Work ==

With the previous implementation of this project, students can write comments and request feedback for the comments. There are certain issues with the previous implementation that needs to be addressed.

# The criteria are numbered in the view, and those numbers do not correspond to anything on the rubric form. So if the rubric is long, it would be quite difficult for the reviewer to figure out what automated feedback referred to which comment.
# Too much specific information on metrics is encoded into the text. While some of the info is in configuration files, the help text for the info buttons is in the code.
# Currently there are many repetitive blocks of code. For Ex.; in _response_analysis.html for the getReviewFeedback(), the API call for each type of tag (sentiment, suggestion, etc) is being repeated. Only the API link differs there.
# The previous implementation takes the text area field in the view to fetch the review comment, but it’s not updated dynamically when the user types a comment. The user needs to save the form then go back to edit view and then request feedback.

=== Proposed Solution ===
[[File:PreviousImplementation.jpeg|1000px|thumb| center | previous Implementation]]
# We need to improve the UI so that if there are many rubric items, users can easily check the feedback for each comment given to each rubric item. We propose the following solution
## Each comment on hover shows the user's respective comment on the specific rubric review question so that the feedback is easily accessible.
### On click of the get review feedback button, we loop through the dynamically created review question form and store the mapping of questions and the reviewer's corresponding comments which on hovered are displayed as a popup.
[[File:Proposedsolution.jpeg|1000px|thumb| center | LOFI Design of Proposed Solution]]

# Another issue with the current implementation is that code is quite repetitive for making different API calls (Sentiment, Suggestion, etc). We propose to store the API link in the config file and refer to the variable in the getReviewFeedback()
# We also plan to remove a global variable response_general, which is being used to store the response of API calls. We will refactor the makeRequest function to directly return the response which can be used in various places. This will resolve implicit coupling issues in the code and make it more easily extendable.
# The previous implementation has hardcoded configuration information like the help text button. We propose to save this information in config files which can be easily modified and will remove unnecessary information from the code.

== Implementation ==

=== UI Changes ===
We refactored the UI of the generated table showing the problem, suggestion, and sentiment of the review comment, by adding a tooltip for prompting the Question and its corresponding review comment in the table itself.
==== UI screenshots ====
==== Javascript implementation ====
#Description - We have added a tooltip in front of every comment number, which on hovering shows the question for which the feedback is given as well as the review comment given for that question.
#File changed - app/views/response/_response_analysis.html.erb

=== Bug Fixes (Dynamic Feedback) ===
Previously, the implementation took into account the text area field because of which we need to save the form before getting the feedback. We changed the implementation so that users can type in a review comment and dynamically get feedback on it before saving.
==== Javascript implementation ====
#Description - The global variable response_general was used to store the response, which was not needed as the Promise will return the response and we threw an error in case of rejection, which is handled at the place we call makeRequest
#File changed - app/views/response/_response_analysis.html.erb

=== Refactoring (removing code duplication) ===
In the previous implementation, code was duplicated for handling different scenarios of fetching the review comment. The code was mostly the same with some conditions. We abstracted the functionality into a method that can be used at multiple places instead of duplicating the code
==== Javascript implementation ====
#Description - The internal function create_comment_object is used for generating comment object according to question and class_name of DOM. This comment JSON is then used to pass to the API for fetching the predictions.
#File changed - app/views/response/_response_analysis.html.erb

=== Error handling improvements ===
We introduced error handling by changing the “Loading…” text to “Request failed. Please try again.” if the API for generating feedback fails. Previously, this case was not handled
==== Javascript implementation ====
#Description - We have added try-catch blocks while making API call, and if the promise is rejected we catch the error and change the “Loading…” text at the bottom to “Request failed. Please try again.”
#Files changed - app/views/response/_response_analysis.html.erb

=== Possible files to be edited ===
# review_metrics.yml
# response.html.erb
# _response_analysis.html.erb
# response_controller.rb
# response_controller_spec.rb

== Sample API Input/Output ==
* Input Text is passed in the following JSON format
{
"text": "This is an excellent project. Keep up the great work"
}

* Output is returned in the following JSON format:
{
"sentiment_score": 0.9,
"sentiment_tone": "Positive",
"suggestions": "absent",
"suggestions_chances": 10.17,
"text": "This is an excellent project. Keep up the great work",
"total_volume": 10,
"volume_without_stopwords": 6
}

== Testing Plan ==
This project mainly addresses the UI issues and some code refactoring in views. Therefore, we will be focussing on view tests as all the automated tests have been previously implemented and new code won't affect those.

===View Tests(Manual)===

#The functionality was written on the client side in javascript solely in _response_analysis.html.erb
#To test this view, any type of review must be accessible as a student.
#There is a button at the bottom of the review called 'Get Review Feedback'.
#When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is shown in above screenshot).
#As API calls will take time, 'Loading..' text will appear until the API calls are complete
#All the review feedback for the comments will be displayed in a colorful table.
#In the feedback table, upon hovering on the comment number, we will be able to see the rubric item and review comments associated with that particular rubric item

== Important Links ==
# https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.fxfungdw1d5r
# https://github.com/expertiza/expertiza/pull/1952 (Previous implementation pull request)
# https://www.youtube.com/watch?v=OYZvNVa3GZ8&feature=youtu.be (Youtube video for previous implementation)

== Team ==

* Prashan Sengo (psengo)

* Griffin Brookshire (glbrook2)

* Divyang Doshi (ddoshi2)

* Srujan Ponnur (sponnur)

CSC/ECE 517 Fall 2021 - E2150. Integrate suggestion detection algorithm

2021-11-28T21:31:31Z

Ddoshi2:

== Problem Definition ==
Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, students learn from the reviews they receive to improve their own performance. In order to make this happen, it would be good to have everyone give quality reviews instead of generic ones. Currently, Expertiza has a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services. We need to make the UI more intuitive by allowing users to view the feedback of specific review comments and the code needs to be refactored to remove redundancy to follow the DRY principle.

== Previous Implementation ==

=== Overview ===
The previous implementation added the following features:
# Setup a config file 'review_metric.yml' where the instructor can select what review metric to display for the current assignments
# API calls (sentiment, problem, suggestion) are made and a table is rendered below, displaying the feedback of the review comments.
# The total time taken by the API calls was also displayed.

=== UI Screenshots ===
The following image shows how a reviewer interacts with the system to get feedback on the review comments.
[[File:Steps_metric.png|1200px|thumb|center]]

=== Control Flow ===

[[File:Review_metric.png]]

== Issues with Previous Work ==

With the previous implementation of this project, students can write comments and request feedback for the comments. There are certain issues with the previous implementation that needs to be addressed.

# The criteria are numbered in the view, and those numbers do not correspond to anything on the rubric form. So if the rubric is long, it would be quite difficult for the reviewer to figure out what automated feedback referred to which comment.
# Too much specific information on metrics is encoded into the text. While some of the info is in configuration files, the help text for the info buttons is in the code.
# Currently there are many repetitive blocks of code. For Ex.; in _response_analysis.html for the getReviewFeedback(), the API call for each type of tag (sentiment, suggestion, etc) is being repeated. Only the API link differs there.
# The previous implementation takes the text area field in the view to fetch the review comment, but it’s not updated dynamically when the user types a comment. The user needs to save the form then go back to edit view and then request feedback.

== Implementation ==

=== UI Changes ===
We refactored the UI of the generated table showing the problem, suggestion, and sentiment of the review comment, by adding a tooltip for prompting the Question and its corresponding review comment in the table itself.
==== UI screenshots ====
==== Javascript implementation ====
#Description - We have added a tooltip in front of every comment number, which on hovering shows the question for which the feedback is given as well as the review comment given for that question.
#File changed - app/views/response/_response_analysis.html.erb

=== Bug Fixes (Dynamic Feedback) ===
Previously, the implementation took into account the text area field because of which we need to save the form before getting the feedback. We changed the implementation so that users can type in a review comment and dynamically get feedback on it before saving.
==== Javascript implementation ====
#Description - The global variable response_general was used to store the response, which was not needed as the Promise will return the response and we threw an error in case of rejection, which is handled at the place we call makeRequest
#File changed - app/views/response/_response_analysis.html.erb

=== Refactoring (removing code duplication) ===
In the previous implementation, code was duplicated for handling different scenarios of fetching the review comment. The code was mostly the same with some conditions. We abstracted the functionality into a method that can be used at multiple places instead of duplicating the code
==== Javascript implementation ====
#Description - The internal function create_comment_object is used for generating comment object according to question and class_name of DOM. This comment JSON is then used to pass to the API for fetching the predictions.
#File changed - app/views/response/_response_analysis.html.erb

=== Error handling improvements ===
We introduced error handling by changing the “Loading…” text to “Request failed. Please try again.” if the API for generating feedback fails. Previously, this case was not handled
==== Javascript implementation ====
#Description - We have added try-catch blocks while making API call, and if the promise is rejected we catch the error and change the “Loading…” text at the bottom to “Request failed. Please try again.”
#Files changed - app/views/response/_response_analysis.html.erb

=== Refactoring ===
[[File:PreviousImplementation.jpeg|1000px|thumb| center | previous Implementation]]
# We need to improve the UI so that if there are many rubric items, users can easily check the feedback for each comment given to each rubric item. We propose the following solution
## Each comment on hover shows the user's respective comment on the specific rubric review question so that the feedback is easily accessible.
### On click of the get review feedback button, we loop through the dynamically created review question form and store the mapping of questions and the reviewer's corresponding comments which on hovered are displayed as a popup.
[[File:Proposedsolution.jpeg|1000px|thumb| center | LOFI Design of Proposed Solution]]

# Another issue with the current implementation is that code is quite repetitive for making different API calls (Sentiment, Suggestion, etc). We propose to store the API link in the config file and refer to the variable in the getReviewFeedback()
# We also plan to remove a global variable response_general, which is being used to store the response of API calls. We will refactor the makeRequest function to directly return the response which can be used in various places. This will resolve implicit coupling issues in the code and make it more easily extendable.
# The previous implementation has hardcoded configuration information like the help text button. We propose to save this information in config files which can be easily modified and will remove unnecessary information from the code.

=== Possible files to be edited ===
# review_metrics.yml
# response.html.erb
# _response_analysis.html.erb
# response_controller.rb
# response_controller_spec.rb

== Sample API Input/Output ==
* Input Text is passed in the following JSON format
{
"text": "This is an excellent project. Keep up the great work"
}

* Output is returned in the following JSON format:
{
"sentiment_score": 0.9,
"sentiment_tone": "Positive",
"suggestions": "absent",
"suggestions_chances": 10.17,
"text": "This is an excellent project. Keep up the great work",
"total_volume": 10,
"volume_without_stopwords": 6
}

== Implementation ==

== Testing Plan ==
This project mainly addresses the UI issues and some code refactoring in views. Therefore, we will be focussing on view tests as all the automated tests have been previously implemented and new code won't affect those.

===View Tests(Manual)===

#The functionality was written on the client side in javascript solely in _response_analysis.html.erb
#To test this view, any type of review must be accessible as a student.
#There is a button at the bottom of the review called 'Get Review Feedback'.
#When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is shown in above screenshot).
#As API calls will take time, 'Loading..' text will appear until the API calls are complete
#All the review feedback for the comments will be displayed in a colorful table.
#In the feedback table, upon hovering on the comment number, we will be able to see the rubric item and review comments associated with that particular rubric item

== Important Links ==
# https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.fxfungdw1d5r
# https://github.com/expertiza/expertiza/pull/1952 (Previous implementation pull request)
# https://www.youtube.com/watch?v=OYZvNVa3GZ8&feature=youtu.be (Youtube video for previous implementation)

== Team ==

* Prashan Sengo (psengo)

* Griffin Brookshire (glbrook2)

* Divyang Doshi (ddoshi2)

* Srujan Ponnur (sponnur)

CSC/ECE 517 Fall 2021 - E2150. Integrate suggestion detection algorithm

2021-11-28T21:21:57Z

Ddoshi2:

== Problem Definition ==
Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, students learn from the reviews they receive to improve their own performance. In order to make this happen, it would be good to have everyone give quality reviews instead of generic ones. Currently, Expertiza has a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services. We need to make the UI more intuitive by allowing users to view the feedback of specific review comments and the code needs to be refactored to remove redundancy to follow the DRY principle.

== Previous Implementation ==

=== Overview ===
The previous implementation added the following features:
# Setup a config file 'review_metric.yml' where the instructor can select what review metric to display for the current assignments
# API calls (sentiment, problem, suggestion) are made and a table is rendered below, displaying the feedback of the review comments.
# The total time taken by the API calls was also displayed.

=== UI Screenshots ===
The following image shows how a reviewer interacts with the system to get feedback on the review comments.
[[File:Steps_metric.png|1200px|thumb|center]]

=== Control Flow ===

[[File:Review_metric.png]]

== Issues with Previous Work ==

With the previous implementation of this project, students can write comments and request feedback for the comments. There are certain issues with the previous implementation that needs to be addressed.

# The criteria are numbered in the view, and those numbers do not correspond to anything on the rubric form. So if the rubric is long, it would be quite difficult for the reviewer to figure out what automated feedback referred to which comment.
# Too much specific information on metrics is encoded into the text. While some of the info is in configuration files, the help text for the info buttons is in the code.
# Currently there are many repetitive blocks of code. For Ex.; in _response_analysis.html for the getReviewFeedback(), the API call for each type of tag (sentiment, suggestion, etc) is being repeated. Only the API link differs there.
# The previous implementation takes the text area field in the view to fetch the review comment, but it’s not updated dynamically when the user types a comment. The user needs to save the form then go back to edit view and then request feedback.

== Implementation ==
=== UI Changes ===
We refactored the UI of the generated table showing the problem, suggestion, and sentiment of the review comment, by adding a tooltip for prompting the Question and its corresponding review comment in the table itself.
==== UI screenshots ====
==== Javascript implementation ====

=== Bug Fixes (Dynamic Feedback) ===
Previously, the implementation took into account the text area field because of which we need to save the form before getting the feedback. We changed the implementation so that users can type in a review comment and dynamically get feedback on it before saving.
==== Javascript implementation ====
[[File:Dynamic_1.png]]
[[File:Dynamic_2.png]]
#Description - The global variable response_general was used to store the response, which was not needed as the Promise will return the response and we threw an error in case of rejection, which is handled at the place we call makeRequest
#File changed - app/views/response/_response_analysis.html.erb

=== Refactoring (removing code duplication) ===
In the previous implementation, code was duplicated for handling different scenarios of fetching the review comment. The code was mostly the same with some conditions. We abstracted the functionality into a method that can be used at multiple places instead of duplicating the code
==== Javascript implementation ====
[[File:Code_duplication_1.png]]
#Description - The internal function create_comment_object is used for generating comment object according to question and class_name of DOM. This comment JSON is then used to pass to the API for fetching the predictions.
#File changed - app/views/response/_response_analysis.html.erb

=== Error handling improvements ===
We introduced error handling by changing the “Loading…” text to “Request failed. Please try again.” if the API for generating feedback fails. Previously, this case was not handled
==== Javascript implementation ====
[[File:Error_handling_1.png]]
#Description - We have added try-catch blocks while making API call, and if the promise is rejected we catch the error and change the “Loading…” text at the bottom to “Request failed. Please try again.”
#Files changed - app/views/response/_response_analysis.html.erb

=== Refactoring ===
[[File:PreviousImplementation.jpeg|1000px|thumb| center | previous Implementation]]
# We need to improve the UI so that if there are many rubric items, users can easily check the feedback for each comment given to each rubric item. We propose the following solution
## Each comment on hover shows the user's respective comment on the specific rubric review question so that the feedback is easily accessible.
### On click of the get review feedback button, we loop through the dynamically created review question form and store the mapping of questions and the reviewer's corresponding comments which on hovered are displayed as a popup.
[[File:Proposedsolution.jpeg|1000px|thumb| center | LOFI Design of Proposed Solution]]

# Another issue with the current implementation is that code is quite repetitive for making different API calls (Sentiment, Suggestion, etc). We propose to store the API link in the config file and refer to the variable in the getReviewFeedback()
# We also plan to remove a global variable response_general, which is being used to store the response of API calls. We will refactor the makeRequest function to directly return the response which can be used in various places. This will resolve implicit coupling issues in the code and make it more easily extendable.
# The previous implementation has hardcoded configuration information like the help text button. We propose to save this information in config files which can be easily modified and will remove unnecessary information from the code.

=== Possible files to be edited ===
# review_metrics.yml
# response.html.erb
# _response_analysis.html.erb
# response_controller.rb
# response_controller_spec.rb

== Sample API Input/Output ==
* Input Text is passed in the following JSON format
{
"text": "This is an excellent project. Keep up the great work"
}

* Output is returned in the following JSON format:
{
"sentiment_score": 0.9,
"sentiment_tone": "Positive",
"suggestions": "absent",
"suggestions_chances": 10.17,
"text": "This is an excellent project. Keep up the great work",
"total_volume": 10,
"volume_without_stopwords": 6
}

== Implementation ==

== Testing Plan ==
This project mainly addresses the UI issues and some code refactoring in views. Therefore, we will be focussing on view tests as all the automated tests have been previously implemented and new code won't affect those.

===View Tests(Manual)===

#The functionality was written on the client side in javascript solely in _response_analysis.html.erb
#To test this view, any type of review must be accessible as a student.
#There is a button at the bottom of the review called 'Get Review Feedback'.
#When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is shown in above screenshot).
#As API calls will take time, 'Loading..' text will appear until the API calls are complete
#All the review feedback for the comments will be displayed in a colorful table.
#In the feedback table, upon hovering on the comment number, we will be able to see the rubric item and review comments associated with that particular rubric item

== Important Links ==
# https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.fxfungdw1d5r
# https://github.com/expertiza/expertiza/pull/1952 (Previous implementation pull request)
# https://www.youtube.com/watch?v=OYZvNVa3GZ8&feature=youtu.be (Youtube video for previous implementation)

== Team ==

* Prashan Sengo (psengo)

* Griffin Brookshire (glbrook2)

* Divyang Doshi (ddoshi2)

* Srujan Ponnur (sponnur)

CSC/ECE 517 Fall 2021 - E2150. Integrate suggestion detection algorithm

2021-11-28T21:13:49Z

Ddoshi2:

== Problem Definition ==
Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, students learn from the reviews they receive to improve their own performance. In order to make this happen, it would be good to have everyone give quality reviews instead of generic ones. Currently, Expertiza has a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services. We need to make the UI more intuitive by allowing users to view the feedback of specific review comments and the code needs to be refactored to remove redundancy to follow the DRY principle.

== Previous Implementation ==

=== Overview ===
The previous implementation added the following features:
# Setup a config file 'review_metric.yml' where the instructor can select what review metric to display for the current assignments
# API calls (sentiment, problem, suggestion) are made and a table is rendered below, displaying the feedback of the review comments.
# The total time taken by the API calls was also displayed.

=== UI Screenshots ===
The following image shows how a reviewer interacts with the system to get feedback on the review comments.
[[File:Steps_metric.png|1200px|thumb|center]]

=== Control Flow ===

[[File:Review_metric.png]]

== Issues with Previous Work ==

With the previous implementation of this project, students can write comments and request feedback for the comments. There are certain issues with the previous implementation that needs to be addressed.

# The criteria are numbered in the view, and those numbers do not correspond to anything on the rubric form. So if the rubric is long, it would be quite difficult for the reviewer to figure out what automated feedback referred to which comment.
# Too much specific information on metrics is encoded into the text. While some of the info is in configuration files, the help text for the info buttons is in the code.
# Currently there are many repetitive blocks of code. For Ex.; in _response_analysis.html for the getReviewFeedback(), the API call for each type of tag (sentiment, suggestion, etc) is being repeated. Only the API link differs there.
# The previous implementation takes the text area field in the view to fetch the review comment, but it’s not updated dynamically when the user types a comment. The user needs to save the form then go back to edit view and then request feedback.

== Implementation ==
=== UI Changes ===
We refactored the UI of the generated table showing the problem, suggestion, and sentiment of the review comment, by adding a tooltip for prompting the Question and its corresponding review comment in the table itself.
==== UI screenshots ====
==== Javascript implementation ====

=== Bug Fixes (Dynamic Feedback) ===
Previously, the implementation took into account the text area field because of which we need to save the form before getting the feedback. We changed the implementation so that users can type in a review comment and dynamically get feedback on it before saving.
==== Javascript implementation ====
#Description - The global variable response_general was used to store the response, which was not needed as the Promise will return the response and we threw an error in case of rejection, which is handled at the place we call makeRequest
#File changed - app/views/response/_response_analysis.html.erb

=== Refactoring (removing code duplication) ===
In the previous implementation, code was duplicated for handling different scenarios of fetching the review comment. The code was mostly the same with some conditions. We abstracted the functionality into a method that can be used at multiple places instead of duplicating the code
==== Javascript implementation ====
#Description - The internal function create_comment_object is used for generating comment object according to question and class_name of DOM. This comment JSON is then used to pass to the API for fetching the predictions.
#File changed - app/views/response/_response_analysis.html.erb

=== Error handling improvements ===
We introduced error handling by changing the “Loading…” text to “retry” if the API for generating feedback fails. Previously, this case was not handled
==== Javascript implementation ====
#Description - We have added try-catch blocks while making API call, and if the promise is rejected we catch the error and change the “Loading…” text at the bottom to “Request failed. Please try again.”
#Files changed - app/views/response/_response_analysis.html.erb

=== Refactoring ===
[[File:PreviousImplementation.jpeg|1000px|thumb| center | previous Implementation]]
# We need to improve the UI so that if there are many rubric items, users can easily check the feedback for each comment given to each rubric item. We propose the following solution
## Each comment on hover shows the user's respective comment on the specific rubric review question so that the feedback is easily accessible.
### On click of the get review feedback button, we loop through the dynamically created review question form and store the mapping of questions and the reviewer's corresponding comments which on hovered are displayed as a popup.
[[File:Proposedsolution.jpeg|1000px|thumb| center | LOFI Design of Proposed Solution]]

# Another issue with the current implementation is that code is quite repetitive for making different API calls (Sentiment, Suggestion, etc). We propose to store the API link in the config file and refer to the variable in the getReviewFeedback()
# We also plan to remove a global variable response_general, which is being used to store the response of API calls. We will refactor the makeRequest function to directly return the response which can be used in various places. This will resolve implicit coupling issues in the code and make it more easily extendable.
# The previous implementation has hardcoded configuration information like the help text button. We propose to save this information in config files which can be easily modified and will remove unnecessary information from the code.

=== Possible files to be edited ===
# review_metrics.yml
# response.html.erb
# _response_analysis.html.erb
# response_controller.rb
# response_controller_spec.rb

== Sample API Input/Output ==
* Input Text is passed in the following JSON format
{
"text": "This is an excellent project. Keep up the great work"
}

* Output is returned in the following JSON format:
{
"sentiment_score": 0.9,
"sentiment_tone": "Positive",
"suggestions": "absent",
"suggestions_chances": 10.17,
"text": "This is an excellent project. Keep up the great work",
"total_volume": 10,
"volume_without_stopwords": 6
}

== Implementation ==

== Testing Plan ==
This project mainly addresses the UI issues and some code refactoring in views. Therefore, we will be focussing on view tests as all the automated tests have been previously implemented and new code won't affect those.

===View Tests(Manual)===

#The functionality was written on the client side in javascript solely in _response_analysis.html.erb
#To test this view, any type of review must be accessible as a student.
#There is a button at the bottom of the review called 'Get Review Feedback'.
#When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is shown in above screenshot).
#As API calls will take time, 'Loading..' text will appear until the API calls are complete
#All the review feedback for the comments will be displayed in a colorful table.
#In the feedback table, upon hovering on the comment number, we will be able to see the rubric item and review comments associated with that particular rubric item

== Important Links ==
# https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.fxfungdw1d5r
# https://github.com/expertiza/expertiza/pull/1952 (Previous implementation pull request)
# https://www.youtube.com/watch?v=OYZvNVa3GZ8&feature=youtu.be (Youtube video for previous implementation)

== Team ==

* Prashan Sengo (psengo)

* Griffin Brookshire (glbrook2)

* Divyang Doshi (ddoshi2)

* Srujan Ponnur (sponnur)

File:Error handling 1.png

2021-11-28T21:05:15Z

Ddoshi2:

File:Code duplication 1.png

2021-11-28T21:04:54Z

Ddoshi2:

File:Global var 2.png

2021-11-28T21:04:36Z

Ddoshi2:

File:Global var 1.png

2021-11-28T21:04:19Z

Ddoshi2:

File:Dynamic 2.png

2021-11-28T21:01:47Z

Ddoshi2:

File:Dynamic 1.png

2021-11-28T21:01:04Z

Ddoshi2:

CSC/ECE 517 Fall 2021 - E2150. Integrate suggestion detection algorithm

2021-11-28T20:53:42Z

Ddoshi2:

== Problem Definition ==
Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, students learn from the reviews they receive to improve their own performance. In order to make this happen, it would be good to have everyone give quality reviews instead of generic ones. Currently, Expertiza has a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services. We need to make the UI more intuitive by allowing users to view the feedback of specific review comments and the code needs to be refactored to remove redundancy to follow the DRY principle.

== Previous Implementation ==

=== Overview ===
The previous implementation added the following features:
# Setup a config file 'review_metric.yml' where the instructor can select what review metric to display for the current assignments
# API calls (sentiment, problem, suggestion) are made and a table is rendered below, displaying the feedback of the review comments.
# The total time taken by the API calls was also displayed.

=== UI Screenshots ===
The following image shows how a reviewer interacts with the system to get feedback on the review comments.
[[File:Steps_metric.png|1200px|thumb|center]]

=== Control Flow ===

[[File:Review_metric.png]]

== Issues with Previous Work ==

With the previous implementation of this project, students can write comments and request feedback for the comments. There are certain issues with the previous implementation that needs to be addressed.

# The criteria are numbered in the view, and those numbers do not correspond to anything on the rubric form. So if the rubric is long, it would be quite difficult for the reviewer to figure out what automated feedback referred to which comment.
# Too much specific information on metrics is encoded into the text. While some of the info is in configuration files, the help text for the info buttons is in the code.
# Currently there are many repetitive blocks of code. For Ex.; in _response_analysis.html for the getReviewFeedback(), the API call for each type of tag (sentiment, suggestion, etc) is being repeated. Only the API link differs there.
# The previous implementation takes the text area field in the view to fetch the review comment, but it’s not updated dynamically when the user types a comment. The user needs to save the form then go back to edit view and then request feedback.

== Implementation ==
=== UI Changes ===
We refactored the UI of the generated table showing the problem, suggestion, and sentiment of the review comment, by adding a tooltip for prompting the Question and its corresponding review comment in the table itself.
==== UI screenshots ====
==== Javascript implementation ====

=== Bug Fixes (Dynamic Feedback) ===
Previously, the implementation took into account the text area field because of which we need to save the form before getting the feedback. We changed the implementation so that users can type in a review comment and dynamically get feedback on it before saving.
==== Javascript implementation ====

=== Refactoring ===
[[File:PreviousImplementation.jpeg|1000px|thumb| center | previous Implementation]]
# We need to improve the UI so that if there are many rubric items, users can easily check the feedback for each comment given to each rubric item. We propose the following solution
## Each comment on hover shows the user's respective comment on the specific rubric review question so that the feedback is easily accessible.
### On click of the get review feedback button, we loop through the dynamically created review question form and store the mapping of questions and the reviewer's corresponding comments which on hovered are displayed as a popup.
[[File:Proposedsolution.jpeg|1000px|thumb| center | LOFI Design of Proposed Solution]]

# Another issue with the current implementation is that code is quite repetitive for making different API calls (Sentiment, Suggestion, etc). We propose to store the API link in the config file and refer to the variable in the getReviewFeedback()
# We also plan to remove a global variable response_general, which is being used to store the response of API calls. We will refactor the makeRequest function to directly return the response which can be used in various places. This will resolve implicit coupling issues in the code and make it more easily extendable.
# The previous implementation has hardcoded configuration information like the help text button. We propose to save this information in config files which can be easily modified and will remove unnecessary information from the code.

=== Possible files to be edited ===
# review_metrics.yml
# response.html.erb
# _response_analysis.html.erb
# response_controller.rb
# response_controller_spec.rb

== Sample API Input/Output ==
* Input Text is passed in the following JSON format
{
"text": "This is an excellent project. Keep up the great work"
}

* Output is returned in the following JSON format:
{
"sentiment_score": 0.9,
"sentiment_tone": "Positive",
"suggestions": "absent",
"suggestions_chances": 10.17,
"text": "This is an excellent project. Keep up the great work",
"total_volume": 10,
"volume_without_stopwords": 6
}

== Implementation ==

== Testing Plan ==
This project mainly addresses the UI issues and some code refactoring in views. Therefore, we will be focussing on view tests as all the automated tests have been previously implemented and new code won't affect those.

===View Tests(Manual)===

#The functionality was written on the client side in javascript solely in _response_analysis.html.erb
#To test this view, any type of review must be accessible as a student.
#There is a button at the bottom of the review called 'Get Review Feedback'.
#When pressing button, API calls are issued and the metrics will show up within the table (a sample of which is shown in above screenshot).
#As API calls will take time, 'Loading..' text will appear until the API calls are complete
#All the review feedback for the comments will be displayed in a colorful table.
#In the feedback table, upon hovering on the comment number, we will be able to see the rubric item and review comments associated with that particular rubric item

== Important Links ==
# https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.fxfungdw1d5r
# https://github.com/expertiza/expertiza/pull/1952 (Previous implementation pull request)
# https://www.youtube.com/watch?v=OYZvNVa3GZ8&feature=youtu.be (Youtube video for previous implementation)

== Team ==

* Prashan Sengo (psengo)

* Griffin Brookshire (glbrook2)

* Divyang Doshi (ddoshi2)

* Srujan Ponnur (sponnur)

CSC/ECE 517 Fall 2021 - E2150. Integrate suggestion detection algorithm

2021-11-03T05:47:41Z

Ddoshi2:

CSC/ECE 517 Fall 2021 - E2150. Integrate suggestion detection algorithm

2021-11-03T05:45:15Z

Ddoshi2: /* Testing Plan */

CSC/ECE 517 Fall 2021 - E2150. Integrate suggestion detection algorithm

2021-11-03T00:42:37Z

Ddoshi2:

CSC/ECE 517 Fall 2021 - E2150. Integrate suggestion detection algorithm

2021-11-03T00:23:19Z

Ddoshi2:

CSC/ECE 517 Fall 2021 - E2150. Integrate suggestion detection algorithm

2021-11-02T23:33:45Z

Ddoshi2:

== Problem Defination ==
Peer-review systems like Expertiza utilize a lot of students’ input to determine each other’s performance. At the same time, students learn from the reviews they receive to improve their own performance. In order to make this happen,it would be good to have everyone give quality reviews instead of generic ones. Currently, Expertiza has a few classifiers that can detect useful features of review comments, such as whether they contain suggestions. The suggestion-detection algorithm has been coded as a web service, and other detection algorithms, such as problem detection and sentiment analysis, also exist as newer web services.
With the previous implementation of this project, student can write comments and request the fee

== Tasks ==
There are Several tasks that we are looking to address by the end of the project which are seen below:

# When a student submits a review (in the response_controller), we would like to call this web service with the student’s review as the input. We would then want to tell the student whether their reviews contain suggestions or not, so they can make improvements based on the results of the webservice.
#* The response_controller should pass a text string (the comments field of each Answer object) to the web service.
#* In fact, the response_controller could pass this string to a whole set of metrics (volume, sentiment, problem detection, suggestion counter).
# We would also like to evaluate how much time this API is taking and if possible work a way out to improve it. We don’t want the system to be terribly slow.
# We also have a web service for problem detection. That should be integrated too.

== Issues to be Addressed ==
# Update how current implementation gets data from the web service.
#* Yulin's code calls another module that grabs the data from web services in bulk, and divvies it out one item at a time.
#* How would you call it to get suggestion confidence and problem-detection confidence level, etc.?
# Reading a data structure that tells which metrics we are interested in now, and therefore which need to be shown in the view.
#* For example, the data structure may say, For this assignment, we are interested in
#** problem detection
#** suggestions, and
#** sentiment analysis.
#* For another assignment, it might be
#** localization and
#** helpfulness
#Displaying the information in an appropriate view.

== Comments on Prior Teams Implementation ==
* The criteria are numbered in the view, and those numbers do not correspond to anything on the rubric form.
** So if the rubric is long, it would be quite difficult for the reviewer to figure out what automated feedback referred to which comment
* There is too much specific information on metrics that is encoded into the text.
** While some of the info is in configuration files, the help text for the info buttons is in the code. Also, calls for each metric are programmed into the code, though, depending on how diverse they are, this is perhaps unavoidable
* The code can be more modularized.
** Currently there are many repetitive blocks of code. For ex; in _response_analysis.html for the getReviewFeedback(), the API call for each type of tag (sentiment, suggestion, etc) is being repeated. Only the API link differs there. So it might be more beneficial to store the API link in the config file and use the variable in the function

== API Endpoints==
* https://peer-reviews-nlp.herokuapp.com/all for all metrics at once
* https://peer-reviews-nlp.herokuapp.com/volume for volume metrics only
* https://peer-reviews-nlp.herokuapp.com/sentiment for sentiment metrics only
* https://peer-reviews-nlp.herokuapp.com/suggestions for suggestions metrics only

== JSON Formatting ==
* Input Text is passed in the following JSON format
{
"text" : "This is an excellent project. Keep up the great work"
}

* Output is returned in the following JSON format:
{
"sentiment_score": 0.9,
"sentiment_tone": "Positive",
"suggestions": "absent",
"suggestions_chances": 10.17,
"text": "This is an excellent project. Keep up the great work",
"total_volume": 10,
"volume_without_stopwords": 6
}

== Team ==

* Prashan Sengo (psengo)

* Griffin Brookshire ()

* Divyang Doshi ()

* Srujan ()

== Relevant Links ==
* https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2021_-_E2112._Integrate_Suggestion_Detection_Algorithm
* https://github.com/expertiza/expertiza/pull/1952
* https://github.com/harshkachhadia/expertiza/tree/beta
* https://youtu.be/OYZvNVa3GZ8

CSC/ECE 517 Fall 2021 - E2139. Remove multiple topics at a time

2021-10-20T01:01:20Z

Ddoshi2:

==About Expertiza==
Expertiza is a Ruby on Rails based open source project that allows users to submit a variety of document types, including URLs and wiki pages.
It allows the instructor to create and customize new or existing assignments as well as a list of topics for which students can sign up.
Expertiza allows students to form groups to work on various projects and assignments. It also allows students to peer review the work of other students.

==Project Description==
Expertiza has Assignment objects, which represent an assignment that is done by several users. For some assignments, students need to select a topic before submitting work. For deleting a topic, there is a checkbox beside each topic that can be selected and then the instructor or TA can delete the selected topics from the assignment. The feature needs to be tested thoroughly for various scenarios where different kinds of flags for the assignment are checked like the staggered deadline, private assignment, micro task assignment. Also, we need to test the feature when all topics are deleted, some topics are deleted and only one topic is deleted.

===Team Members===
<li> Divyang Doshi </li>
<li> Hardik Udeshi </li>
<li> Shlok Sayani </li>

===Files Involved===
spec/controllers/sign_up_sheet_controller_spec.rb

===Running test cases===
<pre>
run the command :- rspec spec/controllers/sign_up_sheet_controller_spec.rb
</pre>

==Testing scenarios==
<ol>

<li> When the assignment is a microtask and all other flags are False. </li>
<ol>
<li> Deleting all topics of microtask assignments. We first create some topics that are to be deleted afterward. Then, assign these topics to a microtask assignment. Then, we pass these topics all at a time to the delete_all_topics_for_assignment method. As of now, these topics need to be deleted by the method, we fire a query to check the topics with the same topic_ids exist in the database or not. If it is successfully deleted, the count should be returned with 0 by the query. We also assert that redirect to edit assignment page is successful after deletion of topics. </li>
<pre>
it 'deletes all topics for the microtask assignment and redirects to edit assignment page' do
create(:topic, id: 6000, assignment_id: 6000)
create(:topic, id: 7000, assignment_id: 6000)
params = {assignment_id: 6000}
post :delete_all_topics_for_assignment, params.merge(format: :html)
topics_exist = SignUpTopic.where(assignment_id: 6000).count
expect(topics_exist).to be_eql 0
expect(flash[:success]).to eq('All topics have been deleted successfully.')
expect(response).to redirect_to('/assignments/6000/edit')
end
</pre>

<li>Deleting multiple topics of microtask assignments. We first create some topics that are to be deleted afterward. Then, assign these topics to a microtask assignment. Then, we pass these topics multiple at a time to the delete_all_selected_topics method. As of now, these topics need to be deleted by the method, we fire a query to check the topics with the same topic_ids exist in the database or not. If it is successfully deleted, the count should be returned with the topic remaining by the query. We also assert that redirect to edit assignment page is successful after deletion of topics. </li>
<pre>
it 'delete_all_selected_topics for not microtask assignment and redirects to edit assignment page with multiple topic selected' do
create(:topic, id: 6000, assignment_id: 7000, topic_identifier: 'topic6000')
create(:topic, id: 7000, assignment_id: 7000, topic_identifier: 'topic7000')
create(:topic, id: 8000, assignment_id: 7000, topic_identifier: 'topic8000')
params = {assignment_id: 7000, topic_ids: ['topic6000', 'topic7000']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 7000).count
expect(topics_exist).to be_eql 1
expect(response).to redirect_to('/assignments/7000/edit#tabs-2')

params = {assignment_id: 7000, topic_ids: ['topic8000']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 7000).count
expect(topics_exist).to be_eql 0
expect(response).to redirect_to('/assignments/7000/edit#tabs-2')
end
</pre>
<li>
Deleting single topic of microtask assignments. We first create a topic that is to be deleted afterward. Then, assign this topic to a microtask assignment. Then, we pass this topic to delete_all_selected_topics. As of now, this topic needs to be deleted by the method, we fire a query to check the topic with the same topic_id exists in the database or not. If it is successfully deleted, the count should be returned 0 by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'delete_all_selected_topics for a microtask assignment and redirects to edit assignment page with single topic selected' do
create(:topic, id: 6000, assignment_id: 6000, topic_identifier: 'topic6000')
params = {assignment_id: 6000, topic_ids: ['topic6000']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 6000).count
expect(topics_exist).to be_eql 0
expect(response).to redirect_to('/assignments/6000/edit#tabs-2')
end
</pre>
</ol>

<li>When the assignment is not microtask assignment and staggered and private flags are True. </li>
<ol>

<li> Deleting single topic of non-microtask assignments. We first create a topic that is to be deleted afterward. Then, assign this topic to a non-microtask assignment. Then, we pass this topic to delete_all_selected_topics. As of now, this topic needs to be deleted by the method, we fire a query to check the topic with the same topic_id exists in the database or not. If it is successfully deleted, the count should be returned 0 by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'delete_all_selected_topics for not microtask assignment and redirects to edit assignment page with single topic selected' do
create(:topic, id: 6000, assignment_id: 7000, topic_identifier: 'topic6000')
params = {assignment_id: 7000, topic_ids: ['topic6000']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 7000).count
expect(topics_exist).to be_eql 0
expect(response).to redirect_to('/assignments/7000/edit#tabs-2')
end
</pre>

<li> Deleting multiple topics of non-microtask assignments. We first create some topics that are to be deleted afterward. Then, assign these topics to a non-microtask assignment. Then, we pass these topics multiple at a time to the delete_all_selected_topics method. As of now, these topics need to be deleted by the method, we fire a query to check the topics with the same topic_ids exist in the database or not. If it is successfully deleted, the count should be returned with the topic remaining by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'delete_all_selected_topics for not microtask assignment and redirects to edit assignment page with multiple topic selected' do
create(:topic, id: 6000, assignment_id: 7000, topic_identifier: 'topic6000')
create(:topic, id: 7000, assignment_id: 7000, topic_identifier: 'topic7000')
create(:topic, id: 8000, assignment_id: 7000, topic_identifier: 'topic8000')
params = {assignment_id: 7000, topic_ids: ['topic6000', 'topic7000']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 7000).count
expect(topics_exist).to be_eql 1
expect(response).to redirect_to('/assignments/7000/edit#tabs-2')

params = {assignment_id: 7000, topic_ids: ['topic8000']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 7000).count
expect(topics_exist).to be_eql 0
expect(response).to redirect_to('/assignments/7000/edit#tabs-2')
end
</pre>

<li> Deleting all topics of non-microtask assignments. We first create some topics that are to be deleted afterward. Then, assign these topics to a non-microtask assignment. Then, we pass these topics all at a time to the delete_all_topics_for_assignment method. As of now, these topics need to be deleted by the method, we fire a query to check the topics with the same topic_ids exist in the database or not. If it is successfully deleted, the count should be returned with 0 by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'deletes all topics for not microtask assignment and redirects to edit assignment page' do
create(:topic, id: 6000, assignment_id: 7000)
create(:topic, id: 7000, assignment_id: 7000)
params = {assignment_id: 7000}
post :delete_all_topics_for_assignment, params.merge(format: :html)
topics_exist = SignUpTopic.where(assignment_id: 7000).count
expect(topics_exist).to be_eql 0
expect(flash[:success]).to eq('All topics have been deleted successfully.')
expect(response).to redirect_to('/assignments/7000/edit')
end
</pre>

</ol>

<li> When the assignment is a staggered deadline and microtask and private flags are False. </li>
<ol>
<li> Deleting single topic of staggered deadline assignments. We first create a topic that is to be deleted afterward. Then, assign this topic to a staggered deadline assignment. Then, we pass this topic to delete_all_selected_topics. As of now, this topic needs to be deleted by the method, we fire a query to check the topic with the same topic_id exists in the database or not. If it is successfully deleted, the count should be returned 0 by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'create topic and delete_all_selected_topics for a staggered deadline assignment and redirects to edit assignment page with single topic selected' do
create(:topic, id: 40, assignment_id: 40, topic_identifier: 'E1733')
params = {assignment_id: 40, topic_ids: ['E1733']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 40).count
expect(topics_exist).to be_eql 0
expect(response).to redirect_to('/assignments/40/edit#tabs-2')
end
</pre>

<li> Deleting multiple topics of staggered deadline assignments. We first create some topics that are to be deleted afterward. Then, assign these topics to a staggered deadline assignment. Then, we pass these topics multiple at a time to the delete_all_selected_topics method. As of now, these topics need to be deleted by the method, we fire a query to check the topics with the same topic_ids exist in the database or not. If it is successfully deleted, the count should be returned with the topic remaining by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'create topic and delete_all_selected_topics for a staggered deadline assignment and redirects to edit assignment page with multiple topic selected' do
create(:topic, id: 30, assignment_id: 40, topic_identifier: 'E1735')
create(:topic, id: 40, assignment_id: 40, topic_identifier: 'E1736')
create(:topic, id: 50, assignment_id: 40, topic_identifier: 'E1737')
create(:topic, id: 60, assignment_id: 40, topic_identifier: 'E1738')
create(:topic, id: 70, assignment_id: 40, topic_identifier: 'E1739')
params = {assignment_id: 40, topic_ids: ['E1735', 'E1736']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 40).count
expect(topics_exist).to be_eql 3
expect(response).to redirect_to('/assignments/40/edit#tabs-2')

params = {assignment_id: 40, topic_ids: ['E1737', 'E1738']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 40).count
expect(topics_exist).to be_eql 1
expect(response).to redirect_to('/assignments/40/edit#tabs-2')

params = {assignment_id: 40, topic_ids: ['E1739']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 40).count
expect(topics_exist).to be_eql 0
expect(response).to redirect_to('/assignments/40/edit#tabs-2')
end
</pre>
<li> Deleting all topics of staggered deadline assignments. We first create some topics that are to be deleted afterward. Then, assign these topics to a staggered deadline assignment. Then, we pass these topics all at a time to the delete_all_topics_for_assignment method. As of now, these topics need to be deleted by the method, we fire a query to check the topics with the same topic_ids exist in the database or not. If it is successfully deleted, the count should be returned with 0 by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'deletes all topics for the staggered deadline assignment and redirects to edit assignment page' do
create(:topic, id: 30, assignment_id: 40, topic_identifier: 'E1740')
create(:topic, id: 40, assignment_id: 40, topic_identifier: 'E1741')
create(:topic, id: 50, assignment_id: 40, topic_identifier: 'E1742')
params = {assignment_id: 40}
post :delete_all_topics_for_assignment, params
topics_exist = SignUpTopic.where(assignment_id: 40).count
expect(topics_exist).to be_eql 0
expect(flash[:success]).to eq('All topics have been deleted successfully.')
expect(response).to redirect_to('/assignments/40/edit')
end
</pre>
</ol>
<li> When the assignment is a non-staggered deadline and microtask and private flags are True. </li>
<ol>
<li> Deleting single topic of non-staggered deadline assignments. We first create a topic that is to be deleted afterward. Then, assign this topic to a non-staggered deadline assignment. Then, we pass this topic to delete_all_selected_topics. As of now, this topic needs to be deleted by the method, we fire a query to check the topic with the same topic_id exists in the database or not. If it is successfully deleted, the count should be returned 0 by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'create topic and delete_all_selected_topics for not a staggered deadline assignment and redirects to edit assignment page with single topic selected' do
create(:topic, id: 30, assignment_id: 30, topic_identifier: 'E1734')
params = {assignment_id: 30, topic_ids: ['E1734']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 30).count
expect(topics_exist).to be_eql 0
expect(response).to redirect_to('/assignments/30/edit#tabs-2')
end
</pre>

<li> Deleting multiple topics of non-staggered deadline assignments. We first create some topics that are to be deleted afterward. Then, assign these topics to a non-staggered deadline assignment. Then, we pass these topics multiple at a time to the delete_all_selected_topics method. As of now, these topics need to be deleted by the method, we fire a query to check the topics with the same topic_ids exist in the database or not. If it is successfully deleted, the count should be returned with the topic remaining by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'create topic and delete_all_selected_topics for not a staggered deadline assignment and redirects to edit assignment page with multiple topic selected' do
create(:topic, id: 30, assignment_id: 30, topic_identifier: 'E1735')
create(:topic, id: 40, assignment_id: 30, topic_identifier: 'E1736')
create(:topic, id: 50, assignment_id: 30, topic_identifier: 'E1737')
create(:topic, id: 60, assignment_id: 30, topic_identifier: 'E1738')
create(:topic, id: 70, assignment_id: 30, topic_identifier: 'E1739')
params = {assignment_id: 30, topic_ids: ['E1735', 'E1736']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 30).count
expect(topics_exist).to be_eql 3
expect(response).to redirect_to('/assignments/30/edit#tabs-2')

params = {assignment_id: 30, topic_ids: ['E1737', 'E1738']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 30).count
expect(topics_exist).to be_eql 1
expect(response).to redirect_to('/assignments/30/edit#tabs-2')

params = {assignment_id: 30, topic_ids: ['E1739']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 30).count
expect(topics_exist).to be_eql 0
expect(response).to redirect_to('/assignments/30/edit#tabs-2')
end
</pre>

<li> Deleting all topics of non-staggered deadline assignments. We first create some topics that are to be deleted afterward. Then, assign these topics to a non-staggered deadline assignment. Then, we pass these topics all at a time to the delete_all_topics_for_assignment method. As of now, these topics need to be deleted by the method, we fire a query to check the topics with the same topic_ids exist in the database or not. If it is successfully deleted, the count should be returned with 0 by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'deletes all topics for the non-staggered deadline assignment and redirects to edit assignment page' do
create(:topic, id: 30, assignment_id: 30, topic_identifier: 'E1740')
create(:topic, id: 40, assignment_id: 30, topic_identifier: 'E1741')
create(:topic, id: 50, assignment_id: 30, topic_identifier: 'E1742')
params = {assignment_id: 30}
post :delete_all_topics_for_assignment, params
topics_exist = SignUpTopic.where(assignment_id: 30).count
expect(topics_exist).to be_eql 0
expect(flash[:success]).to eq('All topics have been deleted successfully.')
expect(response).to redirect_to('/assignments/30/edit')
end
</pre>

</ol>

<li> When the assignment is private and other flags are False. </li>
<ol>
<li> Test deleting a single topic in private assignments. We first create a topic that is to be deleted afterwards. Then, assign this topic to a private assignment. Then, we pass this topic to delete_all_selected_topics. As of now, this topic needs to be deleted by the method, we fire a query to check the topic with the same topic_id exists in the database or not. If it is successfully deleted, the count should be returned 0 by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'delete_all_selected_topics for a private assignment and redirects to edit assignment page with single topic selected' do
create(:topic, id: 2, assignment_id: 2, topic_identifier: 'topic2')
params = {assignment_id: 2, topic_ids: ['topic2']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 2).count
expect(topics_exist).to be_eql 0
expect(response).to redirect_to('/assignments/2/edit#tabs-2')
end
</pre>

<li> Deleting multiple topics of private assignments. We first create some topics that are to be deleted afterward. Then, assign these topics to a private assignment. Then, we pass these topics multiple at a time to the delete_all_selected_topics method. As of now, these topics need to be deleted by the method, we fire a query to check the topics with the same topic_ids exist in the database or not. If it is successfully deleted, the count should be returned with the topic remaining by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'delete_all_selected_topics for a private assignment and redirects to edit assignment page with multiple topic selected' do
create(:topic, id: 2, assignment_id: 2, topic_identifier: 'topic2')
create(:topic, id: 3, assignment_id: 2, topic_identifier: 'topic3')
create(:topic, id: 4, assignment_id: 2, topic_identifier: 'topic4')
params = {assignment_id: 2, topic_ids: ['topic2', 'topic3']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 2).count
expect(topics_exist).to be_eql 1
expect(response).to redirect_to('/assignments/2/edit#tabs-2')

params = {assignment_id: 2, topic_ids: ['topic4']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 2).count
expect(topics_exist).to be_eql 0
expect(response).to redirect_to('/assignments/2/edit#tabs-2')
end
</pre>
<li> Deleting all topics of private assignments. We first create some topics that are to be deleted afterward. Then, assign these topics to a private assignment. Then, we pass these topics all at a time to the delete_all_topics_for_assignment method. As of now, these topics need to be deleted by the method, we fire a query to check the topics with the same topic_ids exist in the database or not. If it is successfully deleted, the count should be returned with 0 by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'deletes all topics for the private assignment and redirects to edit assignment page' do
create(:topic, id: 2, assignment_id: 2)
create(:topic, id: 3, assignment_id: 2)
params = {assignment_id: 2}
post :delete_all_topics_for_assignment, params.merge(format: :html)
topics_exist = SignUpTopic.where(assignment_id: 2).count
expect(topics_exist).to be_eql 0
expect(flash[:success]).to eq('All topics have been deleted successfully.')
expect(response).to redirect_to('/assignments/2/edit')
end
</pre>
</ol>
<li> When the assignment is non-private and other flags are True. </li>
<ol>
<li> Deleting single topic of non-private assignments. We first create a topic that is to be deleted afterward. Then, assign this topic to a non-private assignment. Then, we pass this topic to delete_all_selected_topics. As of now, this topic needs to be deleted by the method, we fire a query to check the topic with the same topic_id exists in the database or not. If it is successfully deleted, the count should be returned 0 by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'delete_all_selected_topics for a non private assignment and redirects to edit assignment page with single topic selected' do
create(:topic, id: 2, assignment_id: 3, topic_identifier: 'topic2')
params = {assignment_id: 3, topic_ids: ['topic2']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 3).count
expect(topics_exist).to be_eql 0
expect(response).to redirect_to('/assignments/3/edit#tabs-2')
end
</pre>

<li> Deleting multiple topics of non-private assignments. We first create some topics that are to be deleted afterward. Then, assign these topics to a non-private assignment. Then, we pass these topics multiple at a time to the delete_all_selected_topics method. As of now, these topics need to be deleted by the method, we fire a query to check the topics with the same topic_ids exist in the database or not. If it is successfully deleted, the count should be returned with the topic remaining by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'delete_all_selected_topics for a non private assignment and redirects to edit assignment page with multiple topic selected' do
create(:topic, id: 2, assignment_id: 3, topic_identifier: 'topic2')
create(:topic, id: 3, assignment_id: 3, topic_identifier: 'topic3')
create(:topic, id: 8, assignment_id: 3, topic_identifier: 'topic4')
params = {assignment_id: 3, topic_ids: ['topic2', 'topic3']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 3).count
expect(topics_exist).to be_eql 1
expect(response).to redirect_to('/assignments/3/edit#tabs-2')

params = {assignment_id: 3, topic_ids: ['topic4']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 3).count
expect(topics_exist).to be_eql 0
expect(response).to redirect_to('/assignments/3/edit#tabs-2')
end
</pre>

<li> Deleting all topics of non-private assignments. We first create some topics that are to be deleted afterward. Then, assign these topics to a non-private assignment. Then, we pass these topics all at a time to the delete_all_topics_for_assignment method. As of now, these topics need to be deleted by the method, we fire a query to check the topics with the same topic_ids exist in the database or not. If it is successfully deleted, the count should be returned with 0 by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'deletes all topics for non private assignment and redirects to edit assignment page' do
create(:topic, id: 2, assignment_id: 3)
create(:topic, id: 3, assignment_id: 3)
params = {assignment_id: 3}
post :delete_all_topics_for_assignment, params.merge(format: :html)
topics_exist = SignUpTopic.where(assignment_id: 3).count
expect(topics_exist).to be_eql 0
expect(flash[:success]).to eq('All topics have been deleted successfully.')
expect(response).to redirect_to('/assignments/3/edit')
end
</pre>

</ol>

</ol>

==Test Results==

==Repository Link==

https://github.com/hvudeshi/expertiza/tree/beta

CSC/ECE 517 Fall 2021 - E2139. Remove multiple topics at a time

2021-10-20T00:53:09Z

Ddoshi2:

==About Expertiza==
Expertiza is a Ruby on Rails based open source project that allows users to submit a variety of document types, including URLs and wiki pages.
It allows the instructor to create and customize new or existing assignments as well as a list of topics for which students can sign up.
Expertiza allows students to form groups to work on various projects and assignments. It also allows students to peer review the work of other students.

==Project Description==
Expertiza has Assignment objects, which represent an assignment that is done by a number of users. For some assignments, students need to select a topic before submitting work. For deleting a topic, there is a checkbox beside each topic that can be selected and then the instructor or TA can delete the selected topics from the assignment. The feature needs to be tested thoroughly for various scenarios where different kinds of flags for the assignment are checked like staggered deadline, private assignment, micro task assignment. Also, we need to test the feature when all topics are deleted, some topics are deleted and only one topic is deleted.

===Team Members===
<li> Divyang Doshi </li>
<li> Hardik Udeshi </li>
<li> Shlok Sayani </li>

===Files Involved===
spec/controllers/sign_up_sheet_controller_spec.rb

===Running test cases===
<pre>
run the command :- rspec spec/controllers/sign_up_sheet_controller_spec.rb
</pre>

==Testing scenarios==
<ol>

<li> When the assignment is a microtask and all other flags are False. </li>
<ol>
<li> Deleting all topics of microtask assignments. We first create some topics that are to be deleted afterward. Then, assign these topics to a microtask assignment. Then, we pass these topics all at a time to the delete_all_topics_for_assignment method. As of now, these topics need to be deleted by the method, we fire a query to check the topics with the same topic_ids exist in the database or not. If it is successfully deleted, the count should be returned with 0 by the query. We also assert that redirect to edit assignment page is successful after deletion of topics. </li>
<pre>
it 'deletes all topics for the microtask assignment and redirects to edit assignment page' do
create(:topic, id: 6000, assignment_id: 6000)
create(:topic, id: 7000, assignment_id: 6000)
params = {assignment_id: 6000}
post :delete_all_topics_for_assignment, params.merge(format: :html)
topics_exist = SignUpTopic.where(assignment_id: 6000).count
expect(topics_exist).to be_eql 0
expect(flash[:success]).to eq('All topics have been deleted successfully.')
expect(response).to redirect_to('/assignments/6000/edit')
end
</pre>

<li>Deleting multiple topics of microtask assignments. We first create some topics that are to be deleted afterward. Then, assign these topics to a microtask assignment. Then, we pass these topics multiple at a time to the delete_all_selected_topics method. As of now, these topics need to be deleted by the method, we fire a query to check the topics with the same topic_ids exist in the database or not. If it is successfully deleted, the count should be returned with the topic remaining by the query. We also assert that redirect to edit assignment page is successful after deletion of topics. </li>
<pre>
it 'delete_all_selected_topics for not microtask assignment and redirects to edit assignment page with multiple topic selected' do
create(:topic, id: 6000, assignment_id: 7000, topic_identifier: 'topic6000')
create(:topic, id: 7000, assignment_id: 7000, topic_identifier: 'topic7000')
create(:topic, id: 8000, assignment_id: 7000, topic_identifier: 'topic8000')
params = {assignment_id: 7000, topic_ids: ['topic6000', 'topic7000']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 7000).count
expect(topics_exist).to be_eql 1
expect(response).to redirect_to('/assignments/7000/edit#tabs-2')

params = {assignment_id: 7000, topic_ids: ['topic8000']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 7000).count
expect(topics_exist).to be_eql 0
expect(response).to redirect_to('/assignments/7000/edit#tabs-2')
end
</pre>
<li>
Deleting single topic of microtask assignments. We first create a topic that is to be deleted afterward. Then, assign this topic to a microtask assignment. Then, we pass this topic to delete_all_selected_topics. As of now, this topic needs to be deleted by the method, we fire a query to check the topic with the same topic_id exists in the database or not. If it is successfully deleted, the count should be returned 0 by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'delete_all_selected_topics for a microtask assignment and redirects to edit assignment page with single topic selected' do
create(:topic, id: 6000, assignment_id: 6000, topic_identifier: 'topic6000')
params = {assignment_id: 6000, topic_ids: ['topic6000']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 6000).count
expect(topics_exist).to be_eql 0
expect(response).to redirect_to('/assignments/6000/edit#tabs-2')
end
</pre>
</ol>

<li>When the assignment is not microtask assignment and staggered and private flags are True. </li>
<ol>

<li> Deleting single topic of non-microtask assignments. We first create a topic that is to be deleted afterward. Then, assign this topic to a non-microtask assignment. Then, we pass this topic to delete_all_selected_topics. As of now, this topic needs to be deleted by the method, we fire a query to check the topic with the same topic_id exists in the database or not. If it is successfully deleted, the count should be returned 0 by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'delete_all_selected_topics for not microtask assignment and redirects to edit assignment page with single topic selected' do
create(:topic, id: 6000, assignment_id: 7000, topic_identifier: 'topic6000')
params = {assignment_id: 7000, topic_ids: ['topic6000']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 7000).count
expect(topics_exist).to be_eql 0
expect(response).to redirect_to('/assignments/7000/edit#tabs-2')
end
</pre>

<li> Deleting multiple topics of non-microtask assignments. We first create some topics that are to be deleted afterward. Then, assign these topics to a non-microtask assignment. Then, we pass these topics multiple at a time to the delete_all_selected_topics method. As of now, these topics need to be deleted by the method, we fire a query to check the topics with the same topic_ids exist in the database or not. If it is successfully deleted, the count should be returned with the topic remaining by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'delete_all_selected_topics for not microtask assignment and redirects to edit assignment page with multiple topic selected' do
create(:topic, id: 6000, assignment_id: 7000, topic_identifier: 'topic6000')
create(:topic, id: 7000, assignment_id: 7000, topic_identifier: 'topic7000')
create(:topic, id: 8000, assignment_id: 7000, topic_identifier: 'topic8000')
params = {assignment_id: 7000, topic_ids: ['topic6000', 'topic7000']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 7000).count
expect(topics_exist).to be_eql 1
expect(response).to redirect_to('/assignments/7000/edit#tabs-2')

params = {assignment_id: 7000, topic_ids: ['topic8000']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 7000).count
expect(topics_exist).to be_eql 0
expect(response).to redirect_to('/assignments/7000/edit#tabs-2')
end
</pre>

<li> Deleting all topics of non-microtask assignments. We first create some topics that are to be deleted afterward. Then, assign these topics to a non-microtask assignment. Then, we pass these topics all at a time to the delete_all_topics_for_assignment method. As of now, these topics need to be deleted by the method, we fire a query to check the topics with the same topic_ids exist in the database or not. If it is successfully deleted, the count should be returned with 0 by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'deletes all topics for not microtask assignment and redirects to edit assignment page' do
create(:topic, id: 6000, assignment_id: 7000)
create(:topic, id: 7000, assignment_id: 7000)
params = {assignment_id: 7000}
post :delete_all_topics_for_assignment, params.merge(format: :html)
topics_exist = SignUpTopic.where(assignment_id: 7000).count
expect(topics_exist).to be_eql 0
expect(flash[:success]).to eq('All topics have been deleted successfully.')
expect(response).to redirect_to('/assignments/7000/edit')
end
</pre>

</ol>

<li> When the assignment is a staggered deadline and microtask and private flags are False. </li>
<ol>
<li> Deleting single topic of staggered deadline assignments. We first create a topic that is to be deleted afterward. Then, assign this topic to a staggered deadline assignment. Then, we pass this topic to delete_all_selected_topics. As of now, this topic needs to be deleted by the method, we fire a query to check the topic with the same topic_id exists in the database or not. If it is successfully deleted, the count should be returned 0 by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'create topic and delete_all_selected_topics for a staggered deadline assignment and redirects to edit assignment page with single topic selected' do
create(:topic, id: 40, assignment_id: 40, topic_identifier: 'E1733')
params = {assignment_id: 40, topic_ids: ['E1733']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 40).count
expect(topics_exist).to be_eql 0
expect(response).to redirect_to('/assignments/40/edit#tabs-2')
end
</pre>

<li> Deleting multiple topics of staggered deadline assignments. We first create some topics that are to be deleted afterward. Then, assign these topics to a staggered deadline assignment. Then, we pass these topics multiple at a time to the delete_all_selected_topics method. As of now, these topics need to be deleted by the method, we fire a query to check the topics with the same topic_ids exist in the database or not. If it is successfully deleted, the count should be returned with the topic remaining by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'create topic and delete_all_selected_topics for a staggered deadline assignment and redirects to edit assignment page with multiple topic selected' do
create(:topic, id: 30, assignment_id: 40, topic_identifier: 'E1735')
create(:topic, id: 40, assignment_id: 40, topic_identifier: 'E1736')
create(:topic, id: 50, assignment_id: 40, topic_identifier: 'E1737')
create(:topic, id: 60, assignment_id: 40, topic_identifier: 'E1738')
create(:topic, id: 70, assignment_id: 40, topic_identifier: 'E1739')
params = {assignment_id: 40, topic_ids: ['E1735', 'E1736']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 40).count
expect(topics_exist).to be_eql 3
expect(response).to redirect_to('/assignments/40/edit#tabs-2')

params = {assignment_id: 40, topic_ids: ['E1737', 'E1738']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 40).count
expect(topics_exist).to be_eql 1
expect(response).to redirect_to('/assignments/40/edit#tabs-2')

params = {assignment_id: 40, topic_ids: ['E1739']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 40).count
expect(topics_exist).to be_eql 0
expect(response).to redirect_to('/assignments/40/edit#tabs-2')
end
</pre>
<li> Deleting all topics of staggered deadline assignments. We first create some topics that are to be deleted afterward. Then, assign these topics to a staggered deadline assignment. Then, we pass these topics all at a time to the delete_all_topics_for_assignment method. As of now, these topics need to be deleted by the method, we fire a query to check the topics with the same topic_ids exist in the database or not. If it is successfully deleted, the count should be returned with 0 by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'deletes all topics for the staggered deadline assignment and redirects to edit assignment page' do
create(:topic, id: 30, assignment_id: 40, topic_identifier: 'E1740')
create(:topic, id: 40, assignment_id: 40, topic_identifier: 'E1741')
create(:topic, id: 50, assignment_id: 40, topic_identifier: 'E1742')
params = {assignment_id: 40}
post :delete_all_topics_for_assignment, params
topics_exist = SignUpTopic.where(assignment_id: 40).count
expect(topics_exist).to be_eql 0
expect(flash[:success]).to eq('All topics have been deleted successfully.')
expect(response).to redirect_to('/assignments/40/edit')
end
</pre>
</ol>
<li> When the assignment is a non-staggered deadline and microtask and private flags are True. </li>
<ol>
<li> Deleting single topic of non-staggered deadline assignments. We first create a topic that is to be deleted afterward. Then, assign this topic to a non-staggered deadline assignment. Then, we pass this topic to delete_all_selected_topics. As of now, this topic needs to be deleted by the method, we fire a query to check the topic with the same topic_id exists in the database or not. If it is successfully deleted, the count should be returned 0 by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'create topic and delete_all_selected_topics for not a staggered deadline assignment and redirects to edit assignment page with single topic selected' do
create(:topic, id: 30, assignment_id: 30, topic_identifier: 'E1734')
params = {assignment_id: 30, topic_ids: ['E1734']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 30).count
expect(topics_exist).to be_eql 0
expect(response).to redirect_to('/assignments/30/edit#tabs-2')
end
</pre>

<li> Deleting multiple topics of non-staggered deadline assignments. We first create some topics that are to be deleted afterward. Then, assign these topics to a non-staggered deadline assignment. Then, we pass these topics multiple at a time to the delete_all_selected_topics method. As of now, these topics need to be deleted by the method, we fire a query to check the topics with the same topic_ids exist in the database or not. If it is successfully deleted, the count should be returned with the topic remaining by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'create topic and delete_all_selected_topics for not a staggered deadline assignment and redirects to edit assignment page with multiple topic selected' do
create(:topic, id: 30, assignment_id: 30, topic_identifier: 'E1735')
create(:topic, id: 40, assignment_id: 30, topic_identifier: 'E1736')
create(:topic, id: 50, assignment_id: 30, topic_identifier: 'E1737')
create(:topic, id: 60, assignment_id: 30, topic_identifier: 'E1738')
create(:topic, id: 70, assignment_id: 30, topic_identifier: 'E1739')
params = {assignment_id: 30, topic_ids: ['E1735', 'E1736']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 30).count
expect(topics_exist).to be_eql 3
expect(response).to redirect_to('/assignments/30/edit#tabs-2')

params = {assignment_id: 30, topic_ids: ['E1737', 'E1738']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 30).count
expect(topics_exist).to be_eql 1
expect(response).to redirect_to('/assignments/30/edit#tabs-2')

params = {assignment_id: 30, topic_ids: ['E1739']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 30).count
expect(topics_exist).to be_eql 0
expect(response).to redirect_to('/assignments/30/edit#tabs-2')
end
</pre>

<li> Deleting all topics of non-staggered deadline assignments. We first create some topics that are to be deleted afterward. Then, assign these topics to a non-staggered deadline assignment. Then, we pass these topics all at a time to the delete_all_topics_for_assignment method. As of now, these topics need to be deleted by the method, we fire a query to check the topics with the same topic_ids exist in the database or not. If it is successfully deleted, the count should be returned with 0 by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'deletes all topics for the non-staggered deadline assignment and redirects to edit assignment page' do
create(:topic, id: 30, assignment_id: 30, topic_identifier: 'E1740')
create(:topic, id: 40, assignment_id: 30, topic_identifier: 'E1741')
create(:topic, id: 50, assignment_id: 30, topic_identifier: 'E1742')
params = {assignment_id: 30}
post :delete_all_topics_for_assignment, params
topics_exist = SignUpTopic.where(assignment_id: 30).count
expect(topics_exist).to be_eql 0
expect(flash[:success]).to eq('All topics have been deleted successfully.')
expect(response).to redirect_to('/assignments/30/edit')
end
</pre>

</ol>

<li> When the assignment is private and other flags are False. </li>
<ol>
<li> Test deleting a single topic in private assignments. We first create a topic that is to be deleted afterwards. Then, assign this topic to a private assignment. Then, we pass this topic to delete_all_selected_topics. As of now, this topic needs to be deleted by the method, we fire a query to check the topic with the same topic_id exists in the database or not. If it is successfully deleted, the count should be returned 0 by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'delete_all_selected_topics for a private assignment and redirects to edit assignment page with single topic selected' do
create(:topic, id: 2, assignment_id: 2, topic_identifier: 'topic2')
params = {assignment_id: 2, topic_ids: ['topic2']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 2).count
expect(topics_exist).to be_eql 0
expect(response).to redirect_to('/assignments/2/edit#tabs-2')
end
</pre>

<li> Deleting multiple topics of private assignments. We first create some topics that are to be deleted afterward. Then, assign these topics to a private assignment. Then, we pass these topics multiple at a time to the delete_all_selected_topics method. As of now, these topics need to be deleted by the method, we fire a query to check the topics with the same topic_ids exist in the database or not. If it is successfully deleted, the count should be returned with the topic remaining by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'delete_all_selected_topics for a private assignment and redirects to edit assignment page with multiple topic selected' do
create(:topic, id: 2, assignment_id: 2, topic_identifier: 'topic2')
create(:topic, id: 3, assignment_id: 2, topic_identifier: 'topic3')
create(:topic, id: 4, assignment_id: 2, topic_identifier: 'topic4')
params = {assignment_id: 2, topic_ids: ['topic2', 'topic3']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 2).count
expect(topics_exist).to be_eql 1
expect(response).to redirect_to('/assignments/2/edit#tabs-2')

params = {assignment_id: 2, topic_ids: ['topic4']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 2).count
expect(topics_exist).to be_eql 0
expect(response).to redirect_to('/assignments/2/edit#tabs-2')
end
</pre>
<li> Deleting all topics of private assignments. We first create some topics that are to be deleted afterward. Then, assign these topics to a private assignment. Then, we pass these topics all at a time to the delete_all_topics_for_assignment method. As of now, these topics need to be deleted by the method, we fire a query to check the topics with the same topic_ids exist in the database or not. If it is successfully deleted, the count should be returned with 0 by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'deletes all topics for the private assignment and redirects to edit assignment page' do
create(:topic, id: 2, assignment_id: 2)
create(:topic, id: 3, assignment_id: 2)
params = {assignment_id: 2}
post :delete_all_topics_for_assignment, params.merge(format: :html)
topics_exist = SignUpTopic.where(assignment_id: 2).count
expect(topics_exist).to be_eql 0
expect(flash[:success]).to eq('All topics have been deleted successfully.')
expect(response).to redirect_to('/assignments/2/edit')
end
</pre>
</ol>
<li> When the assignment is non-private and other flags are True. </li>
<ol>
<li> Deleting single topic of non-private assignments. We first create a topic that is to be deleted afterward. Then, assign this topic to a non-private assignment. Then, we pass this topic to delete_all_selected_topics. As of now, this topic needs to be deleted by the method, we fire a query to check the topic with the same topic_id exists in the database or not. If it is successfully deleted, the count should be returned 0 by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'delete_all_selected_topics for a non private assignment and redirects to edit assignment page with single topic selected' do
create(:topic, id: 2, assignment_id: 3, topic_identifier: 'topic2')
params = {assignment_id: 3, topic_ids: ['topic2']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 3).count
expect(topics_exist).to be_eql 0
expect(response).to redirect_to('/assignments/3/edit#tabs-2')
end
</pre>

<li> Deleting multiple topics of non-private assignments. We first create some topics that are to be deleted afterward. Then, assign these topics to a non-private assignment. Then, we pass these topics multiple at a time to the delete_all_selected_topics method. As of now, these topics need to be deleted by the method, we fire a query to check the topics with the same topic_ids exist in the database or not. If it is successfully deleted, the count should be returned with the topic remaining by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'delete_all_selected_topics for a non private assignment and redirects to edit assignment page with multiple topic selected' do
create(:topic, id: 2, assignment_id: 3, topic_identifier: 'topic2')
create(:topic, id: 3, assignment_id: 3, topic_identifier: 'topic3')
create(:topic, id: 8, assignment_id: 3, topic_identifier: 'topic4')
params = {assignment_id: 3, topic_ids: ['topic2', 'topic3']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 3).count
expect(topics_exist).to be_eql 1
expect(response).to redirect_to('/assignments/3/edit#tabs-2')

params = {assignment_id: 3, topic_ids: ['topic4']}
post :delete_all_selected_topics, params
expect(flash[:success]).to eq('All selected topics have been deleted successfully.')
topics_exist = SignUpTopic.where(assignment_id: 3).count
expect(topics_exist).to be_eql 0
expect(response).to redirect_to('/assignments/3/edit#tabs-2')
end
</pre>

<li> Deleting all topics of non-private assignments. We first create some topics that are to be deleted afterward. Then, assign these topics to a non-private assignment. Then, we pass these topics all at a time to the delete_all_topics_for_assignment method. As of now, these topics need to be deleted by the method, we fire a query to check the topics with the same topic_ids exist in the database or not. If it is successfully deleted, the count should be returned with 0 by the query. We also assert that redirect to edit assignment page is successful after deletion of topics.
</li>
<pre>
it 'deletes all topics for non private assignment and redirects to edit assignment page' do
create(:topic, id: 2, assignment_id: 3)
create(:topic, id: 3, assignment_id: 3)
params = {assignment_id: 3}
post :delete_all_topics_for_assignment, params.merge(format: :html)
topics_exist = SignUpTopic.where(assignment_id: 3).count
expect(topics_exist).to be_eql 0
expect(flash[:success]).to eq('All topics have been deleted successfully.')
expect(response).to redirect_to('/assignments/3/edit')
end
</pre>

</ol>

</ol>

==Test Results==

==Repository Link==

https://github.com/hvudeshi/expertiza/tree/beta

CSC/ECE 517 Fall 2021 - E2139. Remove multiple topics at a time

2021-10-19T07:57:47Z

Ddoshi2:

CSC/ECE 517 Fall 2021 - E2139. Remove multiple topics at a time

2021-10-19T04:02:35Z

Ddoshi2: Created page with "==About Expertiza== Expertiza is a Ruby on Rails based open source project that allows users to submit a variety of document types, including URLs and wiki pages. It allows th..."

CSC/ECE 517 Fall 2021

2021-10-19T03:46:51Z

Ddoshi2:

== OSS Projects ==
* [[CSC/ECE 517 Fall 2021 - {$num}. {$desc.title}]]
* [[CSC/ECE 517 Fall 2021 - E2128. Refactor student_quizzes_controller.rb & late_policies_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2132. Add tests cases for review mapping helper.rb]]
* [[CSC/ECE 517 Fall 2021 - E2134. Write unit tests for admin_controller.rb and institution_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2138. Auto-generate submission directory names based on assignment]]
* [[CSC/ECE 517 Fall 2021 - E2142. Improve e-mail notifications]]
* [[CSC/ECE 517 Fall 2021 - E2133. Write tests for popup_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2120. Refactor reputation_web_service_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2139. Remove multiple topics at a time]]