Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2021 - E2163. Refactor waitlist functionality

2021-12-08T21:41:00Z

Akuchib:

== About Expertiza ==
The [http://expertiza.ncsu.edu/ Expertiza] platform employs a divide-and-conquer strategy for creating reusable learning objects via active-learning exercises built entirely on [http://rubyonrails.org/ Ruby on Rails] framework. Students get to choose from a list of tasks to complete either individually or in teams. It also allows the instructor to create a list of topics the students can sign up for. They then prepare their work and submit it to a peer-review mechanism. On submission, other students can assess their peers work and provide feedback. Expertiza encourages students to collaborate in order to improve the learning experiences from one another. It aids their learning by making them translate what is taught in the lectures and apply those concepts to a real-world issue.

== Problem Statement ==
When a team requests a topic which is not available, the team is waitlisted for the topic, given that bidding is not in use for the assignment. When another team drops a topic, then a waitlisted team will be assigned the topic, if there are any teams waitlisted for it. Implement a waitlist object associated with each topic, and a team that requested it when it was not available would just be queued on the waitlist. The waitlist would just enqueue ordered pairs〈team_id, topic_id〉
Currently, the functionality relevant to waitlisting is scattered across the multiple files. These functions need to be consolidated and placed in a single class.

== Control Flow ==
In the current implementation, multiple models and controllers perform actions that indirectly affect the teams in the waitlist and require to be added or removed from the waitlist. Due to this the same redundant operations of modifying the waitlist is being performed by multiple models and controllers. In order to improve the functionality all the redundant operations being performed on the waitlist need to be moved to the 'waitlist.rb' file and all the other controllers and models will be utilising these methods to manipulate the waitlists.

'''Planned implementation:''' The Context object in our case the waitlist object delegates an algorithm to different Strategy objects to execute waitlist functions as shown below. The Context calls algorithm() on a Strategy1 object, which performs the algorithm and returns the result to Context.

'''Existing Control Flow'''
<br>
[[File:Block diagram waitlist current.png|850px]]

'''Modified Control Flow'''
<br>
[[File:Block diagram waitlist modified.png|850px]]

== Solution Approach ==

===Refactoring===
Goal of the project is to simplify waitlist functionality by moving all the functions manipulating waitlists to waitlist.rb, along with a WaitingTeam class that would consist of a 〈team_id, topic_id〉pair to store information regarding teams on waitlist for a particular topic. Classes should just invoke methods of waitlist.rb for the following functionality:
# Add themselves to waitlists
# Add another team to a waitlist
# Take a team off a waitlist
# Purge all waitlists of a specific team
# Clear a specific waitlist of all waiting teams

Introduce a waitlist object associated with each topic so that any team that requested it when it was not available would just be queued on the waitlist. The waitlist would just enqueue ordered pairs〈team_id, topic_id〉

===Design Pattern===
As we are decoupling the functionality manipulating waitlists that is scattered across various files and putting it all under a single class the design pattern opted for is Strategy Design Pattern. It is a behavioural design pattern that lets you define a family of algorithms, put each of them into a separate class, and make their objects interchangeable. The plan is to isolate the code, internal data, and dependencies of various algorithms related to waitlist from the rest of the code. Various clients now get a simple class to execute the algorithms and switch them at runtime.

'''Tentative list of files to be modified'''
# sign_up_topic.rb
# invitation.rb
# waitlist.rb
# lottery_controller.rb
# suggestion_controller.rb
# signed_up_team.rb
# student_teams_controller.rb

== UI Test Steps ==
* Step 1: Signup as an instructor and click on Manage Assignments

[[File:Manage assignments.png|550px]]
[[File:Add assignment.png|550px]]

* Step 2: Create an assignment with the required configurations and click on create.

[[File:Create assignment.png|550px]]

* Step 3: Post assignment creation, go to manage assignments, and edit the newly created assignment

[[File:Edit new assignment.png|550px]]

* Step 4: Selected the 'has topics' options and create new topics for the students to sign up using the topics tab.

[[File:Has_topics_assignment_option.png|550px]]
[[File:Create topics.png|550px]]

* Step 5: Add participants to the assignment using the participant tab and then assign the participants to teams using the teams tab and save the changes.

[[File:Add participants and teams.png|550px]]
[[File:Add teams.png|550px]]
[[File:Add participants.png|550px]]

* Step 6: Impersonate one student that you had added to one team in the previous step.

[[File:Impersonate user.png|550px]]

* Step 7: In the assignment tabs, choose the assignment that you had created in the previous step and click on sign-up sheet to sign up for a topic.

[[File:Signup_sheet.png|550px]]

* Step 8: Sign up for any topic of your choice. If it is available then you will be assigned the slot and the number of available slots will be updated.

[[File:Student7488 signup.png|550px]]
[[File:Student7488 signedup.png|550px]]

* Step 9: Impersonate as another student from another team that you had created for the same assignment in the previous steps and follow the same steps as mentioned above to sign up for a topic. Sign up for the same topic as the previously impersonated student.

[[File:Student431 signup.png|550px]]

* Step 10: You will now notice that since there was only one available slot and the previous team already signed up for it, the current team will be added to the waitlist for that topic.

[[File:Student 431 waitlisted.png|550px]]

* Step 11: You can also check the student currently assigned to a topic and the waitlisted students in the manage assignments tab on logging in as an instructor(As done in the previous steps)

[[File:Teams signedup waitlisted.png|550px]]

* Step 12: Following the above mentioned steps various scenarios can be tested via the UI like:
# Adding more topics
# Multiple teams signing up for the same topic
# Teams dropping topics etc.

'''In the current implemention the following issue exists which will be fixed:'''

'''Scenario 1:''' Assigned teams dropping topics

'''Expected Behaviour :'''
After one team signs up for a topic and the second team that signs up for the same topic is added to the waitlist, if the first team drops the topic, ideally the available slots should be updated and the second team should be assigned the topic since it is the first on the waitlist.

'''Current Issue :'''
The available slot after one team drops the topic does not update due to which the first team in the waitlist is not automatically assigned the topic.
[[File:Topic dropped.png|550px]]

'''Proposed Solution :'''
Implement a new waitlist object to maintain the list of topics and the teams in the waitlist as ordered pairs: 〈team_id, topic_id〉as soon as the first team drops the topic the team_id field will be updated to the second team since it is the first on the waitlist.

'''Scenario 2:''' Instructor intervention when assigned teams drops topics

'''Expected Behaviour :'''
After one team signs up for a topic and the second team that signs up for the same topic is added to the waitlist, if the first team drops the topic, ideally the available slots should be updated and the second team should be assigned the topic since it is the first on the waitlist also we know that the manage topics tab while the instructor edits the assignment also contains the team that is currently assigned the topic and the list of waitlisted teams it should be updated when a change occurs.

'''Current Issue :'''
The instructor does not see in the manage assignments topics tab that the topic is not assigned to the first team once it chooses to drop it.
[[File:Teams signedup waitlisted.png|550px]]

'''Proposed Solution :'''
Since the same functionality of maintaining the waitlist is being done at multiple places, the code does not update for the manage assignments topic tab for the instructor. In order to fix this, implementation of a new waitlist object is done to maintain the list of topics and the teams in the waitlist as ordered pairs: 〈team_id, topic_id〉as soon as the first team drops the topic the team_id field will be updated to the second team since it is the first on the waitlist and the same object will be consumed everywhere. Hence, the manage assignments topic will be updated automatically.

== Test Plan ==
This project entails code refactoring such that all functionality relevant to waitlist is easily available under one class. Focus is on ensuring existing tests work as expected as the newly added code will not impact functionality per se. However, new unit tests will be written for testing waitlist.rb independently. Furthermore, test cases for suggestion_controller.rb & signed_up_team.rb are missing in the current implementation. Hence, we will be adding spec files for the aforementioned files as well. Certain edge cases will also be tested which have not been covered by the current tests.

'''Test Files'''
# sign_up_topic_spec.rb
# invitation_spec.rb
# waitlist_spec.rb
# lottery_controller_spec.rb
# suggestion_controller_spec.rb
# signed_up_team_spec.rb
# student_teams_controller_spec.rb

'''Cases To Be Tested'''
# Add team to waitlist if topic isn't available: When a team signs up for a topic already assigned to another team they automatically get added to the waitlist of that topic.
# Push the first waitlisted member (if exists) in case a confirmed slot is deleted: When a team drops the topic assigned to them or the instructor deletes the assignment of a topic to a particular team then the first team on the waitlist get assigned the topic for that assignment.
# Remove waitlists for team if a topic is confirmed: Once a team on the waitlists of multiple topics gets assigned a topic, the team is removed from the other waitlists.
# Clean waitlists & assign topic if the user has a team but not a topic: If a team hasn't signed up for a topic it should get auto-assigned one topic.

'''Automated Tests'''

Automated testing can be done using Capybara. Since a major part of the scenario can be tested using the UI, an automated test to create teams and sign up for topics can be created using Capybara with Cucumber. These tests can be written using the TDD approach prior to defining the code.

'''Code Coverage:''' Code coverage for the test cases can be obtained using the Code Coverage plugin and SimpleCov gem. The lines in the functions for which test cases are written in the corresponding spec file are highlighted in green and the rest of the lines are highlighted in red.

== References ==
# [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.r80b3xxz9peq Problem Statement]
# [https://github.com/nehajaideep/expertiza Forked Repository]

== Team ==
* Ankit Singh (asingh072318)

* Asrita Kuchibhotla (kAsrita)

* Neha Kotcherlakota (nehajaideep)

* Vinit Desai (VinitDesai1998)

CSC/ECE 517 Fall 2021 - E2163. Refactor waitlist functionality

2021-12-08T21:31:40Z

Akuchib: /* Test Plan */

== About Expertiza ==
The [http://expertiza.ncsu.edu/ Expertiza] platform employs a divide-and-conquer strategy for creating reusable learning objects via active-learning exercises built entirely on [http://rubyonrails.org/ Ruby on Rails] framework. Students get to choose from a list of tasks to complete either individually or in teams. It also allows the instructor to create a list of topics the students can sign up for. They then prepare their work and submit it to a peer-review mechanism. On submission, other students can assess their peers work and provide feedback. Expertiza encourages students to collaborate in order to improve the learning experiences from one another. It aids their learning by making them translate what is taught in the lectures and apply those concepts to a real-world issue.

== Problem Statement ==
When a team requests a topic which is not available, the team is waitlisted for the topic, given that bidding is not in use for the assignment. When another team drops a topic, then a waitlisted team will be assigned the topic, if there are any teams waitlisted for it. Implement a waitlist object associated with each topic, and a team that requested it when it was not available would just be queued on the waitlist. The waitlist would just enqueue ordered pairs〈team_id, topic_id〉
Currently, the functionality relevant to waitlisting is scattered across the multiple files. These functions need to be consolidated and placed in a single class.

== Control Flow ==
In the current implementation, multiple models and controllers perform actions that indirectly affect the teams in the waitlist and require to be added or removed from the waitlist. Due to this the same redundant operations of modifying the waitlist is being performed by multiple models and controllers. In order to improve the functionality all the redundant operations being performed on the waitlist need to be moved to the 'waitlist.rb' file and all the other controllers and models will be utilising these methods to manipulate the waitlists.

'''Planned implementation:''' The Context object in our case the waitlist object delegates an algorithm to different Strategy objects to execute waitlist functions as shown below. The Context calls algorithm() on a Strategy1 object, which performs the algorithm and returns the result to Context.

'''Existing Control Flow'''
<br>
[[File:Block diagram waitlist current.png|850px]]

'''Modified Control Flow'''
<br>
[[File:Block diagram waitlist modified.png|850px]]

== Solution Approach ==

===Refactoring===
Goal of the project is to simplify waitlist functionality by moving all the functions manipulating waitlists to waitlist.rb, along with a WaitingTeam class that would consist of a 〈team_id, topic_id〉pair to store information regarding teams on waitlist for a particular topic. Classes should just invoke methods of waitlist.rb for the following functionality:
# Add themselves to waitlists
# Add another team to a waitlist
# Take a team off a waitlist
# Purge all waitlists of a specific team
# Clear a specific waitlist of all waiting teams

Introduce a waitlist object associated with each topic so that any team that requested it when it was not available would just be queued on the waitlist. The waitlist would just enqueue ordered pairs〈team_id, topic_id〉

===Design Pattern===
As we are decoupling the functionality manipulating waitlists that is scattered across various files and putting it all under a single class the design pattern opted for is Strategy Design Pattern. It is a behavioural design pattern that lets you define a family of algorithms, put each of them into a separate class, and make their objects interchangeable. The plan is to isolate the code, internal data, and dependencies of various algorithms related to waitlist from the rest of the code. Various clients now get a simple class to execute the algorithms and switch them at runtime.

'''Tentative list of files to be modified'''
# sign_up_topic.rb
# invitation.rb
# waitlist.rb
# lottery_controller.rb
# suggestion_controller.rb
# signed_up_team.rb
# student_teams_controller.rb

== UI Test Steps ==
* Step 1: Signup as an instructor and click on Manage Assignments

[[File:Manage assignments.png|550px]]
[[File:Add assignment.png|550px]]

* Step 2: Create an assignment with the required configurations and click on create.

[[File:Create assignment.png|550px]]

* Step 3: Post assignment creation, go to manage assignments, and edit the newly created assignment

[[File:Edit new assignment.png|550px]]

* Step 4: Selected the 'has topics' options and create new topics for the students to sign up using the topics tab.

[[File:Has_topics_assignment_option.png|550px]]
[[File:Create topics.png|550px]]

* Step 5: Add participants to the assignment using the participant tab and then assign the participants to teams using the teams tab and save the changes.

[[File:Add participants and teams.png|550px]]
[[File:Add teams.png|550px]]
[[File:Add participants.png|550px]]

* Step 6: Impersonate one student that you had added to one team in the previous step.

[[File:Impersonate user.png|550px]]

* Step 7: In the assignment tabs, choose the assignment that you had created in the previous step and click on sign-up sheet to sign up for a topic.

[[File:Signup_sheet.png|550px]]

* Step 8: Sign up for any topic of your choice. If it is available then you will be assigned the slot and the number of available slots will be updated.

[[File:Student7488 signup.png|550px]]
[[File:Student7488 signedup.png|550px]]

* Step 9: Impersonate as another student from another team that you had created for the same assignment in the previous steps and follow the same steps as mentioned above to sign up for a topic. Sign up for the same topic as the previously impersonated student.

[[File:Student431 signup.png|550px]]

* Step 10: You will now notice that since there was only one available slot and the previous team already signed up for it, the current team will be added to the waitlist for that topic.

[[File:Student 431 waitlisted.png|550px]]

* Step 11: You can also check the student currently assigned to a topic and the waitlisted students in the manage assignments tab on logging in as an instructor(As done in the previous steps)

[[File:Teams signedup waitlisted.png|550px]]

* Step 12: Following the above mentioned steps various scenarios can be tested via the UI like:
# Adding more topics
# Multiple teams signing up for the same topic
# Teams dropping topics etc.

'''In the current implemention the following issue exists which will be fixed:'''

'''Scenario 1:''' Assigned teams dropping topics

'''Expected Behaviour :'''
After one team signs up for a topic and the second team that signs up for the same topic is added to the waitlist, if the first team drops the topic, ideally the available slots should be updated and the second team should be assigned the topic since it is the first on the waitlist.

'''Current Issue :'''
The available slot after one team drops the topic does not update due to which the first team in the waitlist is not automatically assigned the topic.
[[File:Topic dropped.png|550px]]

'''Proposed Solution :'''
Implement a new waitlist object to maintain the list of topics and the teams in the waitlist as ordered pairs: 〈team_id, topic_id〉as soon as the first team drops the topic the team_id field will be updated to the second team since it is the first on the waitlist.

'''Scenario 2:''' Instructor intervention when assigned teams drops topics

'''Expected Behaviour :'''
After one team signs up for a topic and the second team that signs up for the same topic is added to the waitlist, if the first team drops the topic, ideally the available slots should be updated and the second team should be assigned the topic since it is the first on the waitlist also we know that the manage topics tab while the instructor edits the assignment also contains the team that is currently assigned the topic and the list of waitlisted teams it should be updated when a change occurs.

'''Current Issue :'''
The instructor does not see in the manage assignments topics tab that the topic is not assigned to the first team once it chooses to drop it.
[[File:Teams signedup waitlisted.png|550px]]

'''Proposed Solution :'''
Since the same functionality of maintaining the waitlist is being done at multiple places, the code does not update for the manage assignments topic tab for the instructor. In order to fix this, implementation of a new waitlist object is done to maintain the list of topics and the teams in the waitlist as ordered pairs: 〈team_id, topic_id〉as soon as the first team drops the topic the team_id field will be updated to the second team since it is the first on the waitlist and the same object will be consumed everywhere. Hence, the manage assignments topic will be updated automatically.

== Test Plan ==
This project entails code refactoring such that all functionality relevant to waitlist is easily available under one class. Focus is on ensuring existing tests work as expected as the newly added code will not impact functionality per se. However, new unit tests will be written for testing waitlist.rb independently. Furthermore, test cases for suggestion_controller.rb & signed_up_team.rb are missing in the current implementation. Hence, we will be adding spec files for the aforementioned files as well. Certain edge cases will also be tested which have not been covered by the current tests.

'''Test Files'''
# sign_up_topic_spec.rb
# invitation_spec.rb
# waitlist_spec.rb
# lottery_controller_spec.rb
# suggestion_controller_spec.rb
# signed_up_team_spec.rb
# student_teams_controller_spec.rb

'''Cases To Be Tested'''
# Add team to waitlist if topic isn't available: When a team signs up for a topic already assigned to another team they automatically get added to the waitlist of that topic.
# Push the first waitlisted member (if exists) in case a confirmed slot is deleted: When a team drops the topic assigned to them or the instructor deletes the assignment of a topic to a particular team then the first team on the waitlist get assigned the topic for that assignment.
# Remove waitlists for team if a topic is confirmed: Once a team on the waitlists of multiple topics gets assigned a topic, the team is removed from the other waitlists.
# Clean waitlists & assign topic if the user has a team but not a topic.
# Remove old team from waitlists.

'''Automated Tests'''

Automated testing can be done using Capybara. Since a major part of the scenario can be tested using the UI, an automated test to create teams and sign up for topics can be created using Capybara with Cucumber. These tests can be written using the TDD approach prior to defining the code.

'''Code Coverage:''' Code coverage for the test cases can be obtained using the Code Coverage plugin and SimpleCov gem. The lines in the functions for which test cases are written in the corresponding spec file are highlighted in green and the rest of the lines are highlighted in red.

== References ==
# [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.r80b3xxz9peq Problem Statement]
# [https://github.com/nehajaideep/expertiza Forked Repository]

== Team ==
* Ankit Singh (asingh072318)

* Asrita Kuchibhotla (kAsrita)

* Neha Kotcherlakota (nehajaideep)

* Vinit Desai (VinitDesai1998)

CSC/ECE 517 Fall 2021 - E2163. Refactor waitlist functionality

2021-11-09T21:23:11Z

Akuchib: /* Control Flow */

CSC/ECE 517 Fall 2021 - E2163. Refactor waitlist functionality

2021-11-09T21:05:17Z

Akuchib: /* Design Pattern */

CSC/ECE 517 Fall 2021 - E2163. Refactor waitlist functionality

2021-11-03T22:37:56Z

Akuchib:

CSC/ECE 517 Fall 2021 - E2163. Refactor waitlist functionality

2021-11-03T22:30:05Z

Akuchib:

CSC/ECE 517 Fall 2021 - E2163. Refactor waitlist functionality

2021-11-03T22:26:14Z

Akuchib:

== Expertiza Background ==

== Problem Statement ==
When a team requests a topic which is not available, the team is waitlisted for the topic, given that bidding is not in use for the assignment. When another team drops a topic, then a waitlisted team will be assigned the topic, if there are any teams waitlisted for it. Implement a waitlist object associated with each topic, and a team that requested it when it was not available would just be queued on the waitlist. The waitlist would just enqueue ordered pairs〈team_id, topic_id〉

=== Control Flow ===

== Solution Approach ==

=== Refactoring ===
Goal of the project is to simplify waitlist functionality by moving all the functions manipulating waitlists to waitlist.rb, along with a WaitingTeam class that would consist of a 〈team_id, topic_id〉pair to store information regarding teams on waitlist for a particular topic. Classes should just invoke methods of waitlist.rb for the following functionality:
# Add themselves to waitlists
# Add another team to a waitlist
# Take a team off a waitlist
# Purge all waitlists of a specific team
# Clear a specific waitlist of all waiting teams

Introduce a waitlist object associated with each topic so that any team that requested it when it was not available would just be queued on the waitlist. The waitlist would just enqueue ordered pairs〈team_id, topic_id〉

=== Design Pattern ===
As we are decoupling the functionality manipulating waitlists that is scattered across various files and putting it all under a single class the design pattern opted for Strategy Design Pattern. is a behavioral design pattern that lets you define a family of algorithms, put each of them into a separate class, and make their objects interchangeable.
=== Tentative list of files to be modified ===
# sign_up_topic.rb
# invitation.rb
# waitlist.rb
# suggestion_controller.rb
# signed_up_team.rb
# student_teams_controller.rb

== Test Plan ==
This project entails code refactoring such that all functionality relevant to wailtist is easily available under one class. Focus is on ensuring existing tests work as expected as the newly added code will not impact functionality per se.

=== Test Files ===

#

== References ==
# [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.r80b3xxz9peq Problem Statement]
# [https://github.com/nehajaideep/expertiza Forked Repository]

== Team ==

* Ankit Singh (asingh072318)

* Asrita Kuchibhotla (kAsrita)

* Neha Kotcherlakota (nehajaideep)

* Vinit Desai (VinitDesai1998)

CSC/ECE 517 Fall 2021 - E2163. Refactor waitlist functionality

2021-11-03T22:13:03Z

Akuchib:

== Problem Statement ==
When a team requests a topic which is not available, the team is waitlisted for the topic, given that bidding is not in use for the assignment. When another team drops a topic, then a waitlisted team will be assigned the topic, if there are any teams waitlisted for it. Implement a waitlist object associated with each topic, and a team that requested it when it was not available would just be queued on the waitlist. The waitlist would just enqueue ordered pairs〈team_id, topic_id〉

=== Control Flow ===

== Solution Approach ==

=== Refactoring ===
Goal of the project is to simplify waitlist functionality by moving all the functions manipulating waitlists to waitlist.rb, along with a WaitingTeam class that would consist of a 〈team_id, topic_id〉pair to store information regarding teams on waitlist for a particular topic. Classes should just invoke methods of waitlist.rb for the following functionality:
# Add themselves to waitlists
# Add another team to a waitlist
# Take a team off a waitlist
# Purge all waitlists of a specific team
# Clear a specific waitlist of all waiting teams

Introduce a waitlist object associated with each topic so that any team that requested it when it was not available would just be queued on the waitlist. The waitlist would just enqueue ordered pairs〈team_id, topic_id〉

=== Design Pattern ===
Strategy is a behavioral design pattern that lets you define a family of algorithms, put each of them into a separate class, and make their objects interchangeable.
=== Tentative list of files to be modified ===
# sign_up_topic.rb
# invitation.rb
# waitlist.rb
# suggestion_controller.rb
# signed_up_team.rb
# student_teams_controller.rb

== Test Plan ==
This project entails code refactoring such that all functionality relevant to wailtist is easily available under one class. Focus is on ensuring existing tests work as expected as the newly added code will not impact functionality per se.

=== Test Files ===

#

== References ==
# [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.r80b3xxz9peq Problem Statement]
# [https://github.com/nehajaideep/expertiza Forked Repository]

== Team ==

* Ankit Singh (asingh072318)

* Asrita Kuchibhotla (kAsrita)

* Neha Kotcherlakota (nehajaideep)

* Vinit Desai (VinitDesai1998)

CSC/ECE 517 Fall 2021 - E2163. Refactor waitlist functionality

2021-11-03T21:54:18Z

Akuchib:

== Problem Statement ==
When a team requests a topic which is not available, the team is waitlisted for the topic, given that bidding is not in use for the assignment. When another team drops a topic, then a waitlisted team will be assigned the topic, if there are any teams waitlisted for it. Implement a waitlist object associated with each topic, and a team that requested it when it was not available would just be queued on the waitlist. The waitlist would just enqueue ordered pairs〈team_id, topic_id〉

=== Control Flow ===

== Solution Approach ==

=== Refactoring ===
Have a waitlist object associated with each topic, and a team that requested it when it was not available would just be queued on the waitlist. The waitlist would just enqueue ordered pairs〈team_id, topic_id〉

=== Design Pattern ===
Strategy is a behavioral design pattern that lets you define a family of algorithms, put each of them into a separate class, and make their objects interchangeable.
=== Tentative list of files to be modified ===
# sign_up_topic.rb
# invitation.rb
# waitlist.rb
# suggestion_controller.rb
# signed_up_team.rb
# student_teams_controller.rb

== Test Plan ==
This project entails code refactoring such that all functionality relevant to wailtist is easily available under one class. Focus is on ensuring existing tests work as expected as the newly added code will not impact functionality per se.

=== Test Files ===

#

== References ==
# [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.r80b3xxz9peq Problem Statement]
# [https://github.com/nehajaideep/expertiza Forked Repository]

== Team ==

* Ankit Singh (asingh072318)

* Asrita Kuchibhotla (kAsrita)

* Neha Kotcherlakota (nehajaideep)

* Vinit Desai (VinitDesai1998)

CSC/ECE 517 Fall 2021 - E2163. Refactor waitlist functionality

2021-11-03T21:53:24Z

Akuchib: Created page with "== Problem Statement == When a team requests a topic which is not available, the team is waitlisted for the topic, given that bidding is not in use for the assignment. When an..."

== Problem Statement ==
When a team requests a topic which is not available, the team is waitlisted for the topic, given that bidding is not in use for the assignment. When another team drops a topic, then a waitlisted team will be assigned the topic, if there are any teams waitlisted for it. Implement a waitlist object associated with each topic, and a team that requested it when it was not available would just be queued on the waitlist. The waitlist would just enqueue ordered pairs〈team_id, topic_id〉

=== Control Flow ===

== Solution Approach ==

=== Refactoring ===
Have a waitlist object associated with each topic, and a team that requested it when it was not available would just be queued on the waitlist. The waitlist would just enqueue ordered pairs〈team_id, topic_id〉

=== Design Pattern ===
Strategy is a behavioral design pattern that lets you define a family of algorithms, put each of them into a separate class, and make their objects interchangeable.
=== Tentative list of files to be modified ===
# sign_up_topic.rb
# invitation.rb
# waitlist.rb
# suggestion_controller.rb
# signed_up_team.rb
# student_teams_controller.rb

== Test Plan ==
This project entails code refactoring such that all functionality relevant to wailtist is easily available under one class. Focus is on ensuring existing tests work as expected as the newly added code will not impact functionality per se.

=== Test Files ===

#

== References ==
# https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.r80b3xxz9peq [Problem Statement]
# https://github.com/nehajaideep/expertiza (Forked Repository)

== Team ==

* Ankit Singh (asingh072318)

* Asrita Kuchibhotla (kAsrita)

* Neha Kotcherlakota (nehajaideep)

* Vinit Desai (VinitDesai1998)

CSC/ECE 517 Fall 2021

2021-11-03T21:09:59Z

Akuchib: /* Final Projects */

== OSS Projects ==

* [[CSC/ECE 517 Fall 2021 - E2117. Refactor questionaires_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2128. Refactor student_quizzes_controller.rb & late_policies_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2129. Refactor auth_controller.rb & password_retrieval_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]]
* [[CSC/ECE 517 Fall 2021 - E2131. Improve assessment360_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2121. Refactor suggestion_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2122. Refactor impersonate_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2123. Refactor sign_up_sheet_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2126. Refactor account_request_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2124. Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2125. Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Fall 2021 - E2127. Refactor teams_controller]]
* [[CSC/ECE 517 Fall 2021 - E2130. Refactor submitted_content_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2140. Create new late policy successfully and fix Bank link]]
* [[CSC/ECE 517 Fall 2021 - E2141. OSS project Finklestein: Instructors & Institutions]]
* [[CSC/ECE 517 Fall 2021 - E2144. Refactor delayed mailer and scheduled task]]
* [[CSC/ECE 517 Fall 2021 - E2147. Role-based reviewing]]
* [[CSC/ECE 517 Fall 2021 - E2145. OSS Project Beige]]
* [[CSC/ECE 517 Fall 2021 - E2146. Introduce a Student View for instructors]]
* [[CSC/ECE 517 Fall 2021 - Refactor Evaluation of SQL Queries]]
* [[CSC/ECE 517 Fall 2021 - E2135. Email notification to reviewers and instructors]]
* [[CSC/ECE 517 Fall 2021 - E2168. Testing - Reputations]]
* [[CSC/ECE 517 Fall 2021 - E2149. Finish Github metrics integration - Reputations]]

== Final Projects ==
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2166._Testing_-_Scoring_%26_Grades#Description_about_project CSC/ECE 517 Fall 2021 - E2166. Testing - Scoring_and_Grades]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2150._Integrate_suggestion_detection_algorithm#Description_about_project CSC/ECE 517 Fall 2021 - E2150. Integrate suggestion detection algorithm]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review CSC/ECE 517 Fall 2021 - E2151. Allow reviewers to bid on what to review]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2152._Revision_planning_tool#Description_about_project CSC/ECE 517 Fall 2021 - E2152. Revision_planning_tool]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2170._Testing_-_Response_Maps#Description_about_project CSC/ECE 517 Fall 2021 - E2170. Testing - Response Maps]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2153._Improving_search_facility_in_Expertiza#Description_about_project CSC/ECE 517 Fall 2021 - E2153. Improving search facility in Expertiza]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2162._Further_refactoring_and_improvement_of_review_mapping_helper CSC/ECE 517 Fall 2021 - E2162. Further refactoring and improvement of review mapping helper]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2163._Refactor_waitlist_functionality CSC/ECE 517 Fall 2021 - E2163. Refactor waitlist functionality]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2165._Fix_teammate-review_view CSC/ECE 517 Fall 2021 - E2165. Fix teammate review view ]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2155._Calibration_submissions_should_be_copied_along_with_calibration_assignments CSC/ECE 517 Fall 2021 - E2155. Calibration submissions should be copied along with calibration assignments]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2148._Completion/Progress_View CSC/ECE 517 Fall 2021 - E2148. Completion/Progress view]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail CSC/ECE 517 Fall 2021 - E2158. Grading audit trail ]
*[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2159._Expertiza_internationalization CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2160._Implementing_and_testing_import_export_controllers#Description_about_project CSC/ECE 517 Fall 2021 - E2160. Implementing and testing import and export controllers]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2164._Heatgrid_fixes_and_improvements#Description_about_project CSC/ECE 517 Fall 2021 - E2164. Heatgrid fixes and improvements]

CSC/ECE 517 Fall 2021

2021-11-03T21:05:46Z

Akuchib: /* Final Projects */

== OSS Projects ==

* [[CSC/ECE 517 Fall 2021 - E2117. Refactor questionaires_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2128. Refactor student_quizzes_controller.rb & late_policies_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2129. Refactor auth_controller.rb & password_retrieval_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]]
* [[CSC/ECE 517 Fall 2021 - E2131. Improve assessment360_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2121. Refactor suggestion_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2122. Refactor impersonate_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2123. Refactor sign_up_sheet_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2126. Refactor account_request_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2124. Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2125. Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Fall 2021 - E2127. Refactor teams_controller]]
* [[CSC/ECE 517 Fall 2021 - E2130. Refactor submitted_content_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2140. Create new late policy successfully and fix Bank link]]
* [[CSC/ECE 517 Fall 2021 - E2141. OSS project Finklestein: Instructors & Institutions]]
* [[CSC/ECE 517 Fall 2021 - E2144. Refactor delayed mailer and scheduled task]]
* [[CSC/ECE 517 Fall 2021 - E2147. Role-based reviewing]]
* [[CSC/ECE 517 Fall 2021 - E2145. OSS Project Beige]]
* [[CSC/ECE 517 Fall 2021 - E2146. Introduce a Student View for instructors]]
* [[CSC/ECE 517 Fall 2021 - Refactor Evaluation of SQL Queries]]
* [[CSC/ECE 517 Fall 2021 - E2135. Email notification to reviewers and instructors]]
* [[CSC/ECE 517 Fall 2021 - E2168. Testing - Reputations]]
* [[CSC/ECE 517 Fall 2021 - E2149. Finish Github metrics integration - Reputations]]

== Final Projects ==
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2166._Testing_-_Scoring_%26_Grades#Description_about_project CSC/ECE 517 Fall 2021 - E2166. Testing - Scoring_and_Grades]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2150._Integrate_suggestion_detection_algorithm#Description_about_project CSC/ECE 517 Fall 2021 - E2150. Integrate suggestion detection algorithm]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2151._Allow_reviewers_to_bid_on_what_to_review CSC/ECE 517 Fall 2021 - E2151. Allow reviewers to bid on what to review]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2152._Revision_planning_tool#Description_about_project CSC/ECE 517 Fall 2021 - E2152. Revision_planning_tool]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2170._Testing_-_Response_Maps#Description_about_project CSC/ECE 517 Fall 2021 - E2170. Testing - Response Maps]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2153._Improving_search_facility_in_Expertiza#Description_about_project CSC/ECE 517 Fall 2021 - E2153. Improving search facility in Expertiza]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2162._Further_refactoring_and_improvement_of_review_mapping_helper CSC/ECE 517 Fall 2021 - E2162. Further refactoring and improvement of review mapping helper]
* [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.r80b3xxz9peq CSC/ECE 517 Fall 2021 - E2163. Refactor waitlist functionality]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2165._Fix_teammate-review_view CSC/ECE 517 Fall 2021 - E2165. Fix teammate review view ]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2155._Calibration_submissions_should_be_copied_along_with_calibration_assignments CSC/ECE 517 Fall 2021 - E2155. Calibration submissions should be copied along with calibration assignments]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2148._Completion/Progress_View CSC/ECE 517 Fall 2021 - E2148. Completion/Progress view]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2158._Grading_audit_trail CSC/ECE 517 Fall 2021 - E2158. Grading audit trail ]
*[https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2159._Expertiza_internationalization CSC/ECE 517 Fall 2021 - E2159. Expertiza internationalization]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2160._Implementing_and_testing_import_export_controllers#Description_about_project CSC/ECE 517 Fall 2021 - E2160. Implementing and testing import and export controllers]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2164._Heatgrid_fixes_and_improvements#Description_about_project CSC/ECE 517 Fall 2021 - E2164. Heatgrid fixes and improvements]

CSC/ECE 517 Fall 2021 - E2130. Refactor submitted content controller.rb

2021-10-27T03:23:38Z

Akuchib:

'''E2130: Refactor 'submitted_content_controller' '''

This page provides detailed explanation of the Submitted Content Controller which is a part of the '''Expertiza''' project. The aim of the project is to refactor the 'submitted_content_controller', which contains the methods to submit assignment related information such as submit & remove hyperlinks, files and other relevant information that could be part of the assignment. It also handles views based on the user roles and permissions they have.
The project involved refactoring some parts of the controller to incorporate the OODD principles so that the readability of code could be improved.

==About Expertiza==
The [http://expertiza.ncsu.edu/ Expertiza] platform employs a divide-and-conquer strategy for creating reusable learning objects via active-learning exercises built entirely on [http://rubyonrails.org/ Ruby on Rails] framework. Students get to choose from a list of tasks to complete either individually or in teams. They then prepare their work and submit it to a peer-review mechanism. On submission, other students can assess their peers work and provide feedback. Expertiza encourages students to collaborate in order to improve the learning experiences from one another. It aids their learning by making them translate what is taught in the lectures and apply those concepts to a real-world issue.

==Problem Statement==
'''submitted_content_controller''' had some problems that violate essential rails design principles which needed to be rectified. Issues included some methods being too long which needed to be broken down, a few methods needed better naming and a few that were no longer needed.

Broadly, the following issues were addressed as a part of refactoring this controller:
* Renaming methods to more appropriate and functionality specific names.
* The existing code was reused to perform either the same function or re-purposed to do a similar function adhering to standards and improving overall quality of the code.
* Introduction of modular code in order to make each module easier to understand, test and refactor independently of others.

==Problems and Solutions ==
* '''Problem 1''': action_allowed method should be changed to use new_access_control methods.
:The original code does not make use of the new access control methods which are a part of the authorization_helper.rb
<pre>
def action_allowed?
['Instructor',
'Teaching Assistant',
'Administrator',
'Super-Administrator',
'Student'].include? current_role_name and
((%w[edit].include? action_name) ? are_needed_authorizations_present?(params[:id], "reader", "reviewer") : true) and
one_team_can_submit_work?
end
</pre>
* '''Solution''': On using the new access control methods:
<pre>
def action_allowed?
if %w[edit update list_submissions].include? params[:action]
current_user_has_admin_privileges? || current_user_teaching_staff_of_assignment?(params[:id])
else
current_user_has_ta_privileges?
end

case params[:action]
when 'edit'
current_user_has_student_privileges? &&
are_needed_authorizations_present?(params[:id], "reader", "reviewer")
when 'submit_file', 'submit_hyperlink'
current_user_has_student_privileges? &&
one_team_can_submit_work?
else
current_user_has_student_privileges?
end
end
</pre>

2. '''Problem 2''': Remove the comment “# hence use team count for the check”.
::The current code no longer checks for the team count to see if a participant belongs to a team. Comment on line #19 removed.

3. '''Problem 3''': Change the method name view to something more informative of the method.
:The original code uses the generic 'view' method name to display a view corresponding to a case when submissions cannot be accepted, for instance in the case when a deadline is passed.
<pre>
def view
@participant = AssignmentParticipant.find(params[:id])
return unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
# @can_submit is the flag indicating if the user can submit or not in current stage
@can_submit = false
@stage = @assignment.get_current_stage(SignedUpTeam.topic_id(@participant.parent_id, @participant.user_id))
redirect_to action: 'edit', id: params[:id], view: true
end
</pre>
* '''Solution''': We found changing the name to disable_submission to be more apt in this case
<pre>
def disable_submission
@participant = AssignmentParticipant.find(params[:id])
return unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
# @can_submit is the flag indicating if the user can submit or not in current stage
@can_submit = false
@stage = @assignment.get_current_stage(SignedUpTeam.topic_id(@participant.parent_id, @participant.user_id))
redirect_to action: 'edit', id: params[:id], view: true
end
</pre>

4. '''Problem 4''': submit_hyperlink is filled with a lot of logging code.
:Logging is essential to understand the behavior of the application and to debug unexpected issues or for simply tracking events as in the production environment, we can’t debug issues without proper log files.
* '''Solution''': We added a function for the sole purpose of logging so that it can be reused wherever required.
<pre>
def log_info(controller_name, participant_name, message, request)
ExpertizaLogger.info LoggerMessage.new(controller_name, participant_name, message, request)
end
</pre>

5. '''Problem 5''': Check the validity of the comment ”# Note: This is not used yet in the view until we all decide to do so”.
:
* '''Solution''': The function to remove_hyperlink performs as expected, hence the comment is no longer valid.

6. '''Problem 6''': submit_file method is long.
:
* '''Solution''': Implemented modular code by separating the function into simpler functions.
<pre>
def tested
@current_folder = DisplayOption.new
@current_folder.name = "/"
@current_folder.name = FileHelper.sanitize_folder(params[:current_folder][:name]) if params[:current_folder]
curr_directory = if params[:origin] == 'review'
participant.review_file_path(params[:response_map_id]).to_s + @current_folder.name
else
participant.team.path.to_s + @current_folder.name
end
return curr_directory
end
</pre>

7. '''Problem 7''': Move mail_assigned_reviewers to a mailer class.
:
* '''Solution''': Moved the mail_assigned_reviewers to mailer_helper.rb
<pre>
def self.mail_assigned_reviewers(team)
maps = ResponseMap.where(reviewed_object_id: @participant.assignment.id, reviewee_id: team.id, type: 'ReviewResponseMap')
unless maps.nil?
maps.each do |map|
# Mailing function
Mailer.general_email(
to: User.find(Participant.find(map.reviewer_id).user_id).email,
subject: "Link to update the review for Assignment '#{@participant.assignment.name}'",
cc: User.find_by(@participant.assignment.instructor_id).email,
link: "Link: https://expertiza.ncsu.edu/response/new?id=#{map.id}",
assignment: @participant.assignment.name
).deliver_now
end
end
end
</pre>

8. '''Problem 8''': Change the method name of folder_action.
:
* '''Solution''': Renamed folder_action to perform_folder_action.
<pre>
def perform_folder_action
@participant = AssignmentParticipant.find(params[:id])
return unless current_user_id?(@participant.user_id)
@current_folder = DisplayOption.new
@current_folder.name = "/"
@current_folder.name = FileHelper.sanitize_folder(params[:current_folder][:name]) if params[:current_folder]
if params[:faction][:delete]
SubmittedFiles.delete_selected_files
elsif params[:faction][:rename]
SubmittedFiles.rename_selected_file
elsif params[:faction][:move]
SubmittedFiles.move_selected_file
elsif params[:faction][:copy]
SubmittedFiles.copy_selected_file
elsif params[:faction][:create]
create_new_folder
end
redirect_to action: 'edit', id: @participant.id
end
</pre>

9. '''Problem 9''': Some of the actions in the code (from line 187 to 247) could perhaps be moved to another class
:
* '''Solution''': Separated functions related to submission of files into a new helper class called submitted_files_helper.rb.
<pre>
module SubmittedFiles

def move_selected_file
old_filename = params[:directories][params[:chk_files]] + "/" + params[:filenames][params[:chk_files]]
newloc = @participant.dir_path
newloc += "/"
newloc += params[:faction][:move]
begin
FileHelper.move_file(old_filename, newloc)
flash[:note] = "The file was successfully moved from \"/#{params[:filenames][params[:chk_files]]}\" to \"/#{params[:faction][:move]}\""
rescue StandardError => e
flash[:error] = "There was a problem moving the file: " + e.message
end
end

def rename_selected_file
old_filename = params[:directories][params[:chk_files]] + "/" + params[:filenames][params[:chk_files]]
new_filename = params[:directories][params[:chk_files]] + "/" + FileHelper.sanitize_filename(params[:faction][:rename])
begin
raise "A file already exists in this directory with the name \"#{params[:faction][:rename]}\"" if File.exist?(new_filename)
File.send("rename", old_filename, new_filename)
rescue StandardError => e
flash[:error] = "There was a problem renaming the file: " + e.message
end
end

def delete_selected_files

filename = params[:directories][params[:chk_files]] + "/" + params[:filenames][params[:chk_files]]
FileUtils.rm_r(filename)
participant = Participant.find_by(id: params[:id])
assignment = participant.try(:assignment)
team = participant.try(:team)
SubmissionRecord.create(team_id: team.try(:id),
content: filename,
user: participant.try(:name),
assignment_id: assignment.try(:id),
operation: "Remove File")
ExpertizaLogger.info LoggerMessage.new(controller_name, @participant.name, 'The selected file has been deleted.', request)
end

def copy_selected_file
old_filename = params[:directories][params[:chk_files]] + "/" + params[:filenames][params[:chk_files]]
new_filename = params[:directories][params[:chk_files]] + "/" + FileHelper.sanitize_filename(params[:faction][:copy])
begin
raise "A file with this name already exists. Please delete the existing file before copying." if File.exist?(new_filename)
raise "The referenced file does not exist." unless File.exist?(old_filename)
FileUtils.cp_r(old_filename, new_filename)
rescue StandardError => e
flash[:error] = "There was a problem copying the file: " + e.message
end
end

end

</pre>

== Testing Requirements ==

1. git clone https://github.com/Neelkanth7/expertiza

2. Change directory to expertiza. Run "bundle install" and rails db:migrate.

3. Start the rails server.

4. Run the following command in a new terminal of the expertiza directory:
i. rspec spec/controllers/submitted_content_controller_spec.rb (Test file mentioned missing)

==References==

* [https://github.com/Neelkanth7/expertiza Github] link to the project.
* [https://docs.google.com/document/d/19FHqVoYUw0HzqGfZ68H-Z-SYmeP_LoHS2rkXjnxeaSE/edit#heading=h.jpaayj9sgw5h Link] to the project description.

CSC/ECE 517 Fall 2021 - E2130. Refactor submitted content controller.rb

2021-10-21T02:10:49Z

Akuchib:

'''E2130: Refactor 'submitted_content_controller' '''

This page provides detailed explanation of the Submitted Content Controller which is a part of the '''Expertiza''' project. The aim of the project is to refactor the 'submitted_content_controller', which contains the methods to submit assignment related information such as submit & remove hyperlinks, files and other relevant information that could be part of the assignment. It also handles views based on the user roles and permissions they have.
The project involved refactoring some parts of the controller to incorporate the OODD principles so that the readability of code could be improved.

==About Expertiza==
The [http://expertiza.ncsu.edu/ Expertiza] platform employs a divide-and-conquer strategy for creating reusable learning objects via active-learning exercises built entirely on [http://rubyonrails.org/ Ruby on Rails] framework. Students get to choose from a list of tasks to complete either individually or in teams. They then prepare their work and submit it to a peer-review mechanism. On submission, other students can assess their peers work and provide feedback. Expertiza encourages students to collaborate in order to improve the learning experiences from one another. It aids their learning by making them translate what is taught in the lectures and apply those concepts to a real-world issue.

==Problem Statement==
'''submitted_content_controller''' had some problems that violate essential rails design principles which needed to be rectified. Issues included some methods being too long which needed to be broken down, a few methods needed better naming and a few that were no longer needed.

Broadly, the following issues were addressed as a part of refactoring this controller:
* Renaming methods to more appropriate and functionality specific names.
* The existing code was reused to perform either the same function or re-purposed to do a similar function adhering to standards and improving overall quality of the code.
* Introduction of modular code in order to make each module easier to understand, test and refactor independently of others.

==Problems and Solutions ==
* '''Problem 1''': action_allowed method should be changed to use new_access_control methods.
:The original code does not make use of the new access control methods which are a part of the authorization_helper.rb
<pre>
def action_allowed?
['Instructor',
'Teaching Assistant',
'Administrator',
'Super-Administrator',
'Student'].include? current_role_name and
((%w[edit].include? action_name) ? are_needed_authorizations_present?(params[:id], "reader", "reviewer") : true) and
one_team_can_submit_work?
end
</pre>
* '''Solution''': On using the new access control methods:
<pre>
def action_allowed?
if %w[edit update list_submissions].include? params[:action]
current_user_has_admin_privileges? || current_user_teaching_staff_of_assignment?(params[:id])
else
current_user_has_ta_privileges?
end

case params[:action]
when 'edit'
current_user_has_student_privileges? &&
are_needed_authorizations_present?(params[:id], "reader", "reviewer")
when 'submit_file', 'submit_hyperlink'
current_user_has_student_privileges? &&
one_team_can_submit_work?
else
current_user_has_student_privileges?
end
end
</pre>

2. '''Problem 2''': Remove the comment “# hence use team count for the check”.
::The current code no longer checks for the team count to see if a participant belongs to a team. Comment on line #19 removed.

3. '''Problem 3''': Change the method name view to something more informative of the method.
:The original code uses the generic 'view' method name to display a view corresponding to a case when submissions cannot be accepted, for instance in the case when a deadline is passed.
<pre>
def view
@participant = AssignmentParticipant.find(params[:id])
return unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
# @can_submit is the flag indicating if the user can submit or not in current stage
@can_submit = false
@stage = @assignment.get_current_stage(SignedUpTeam.topic_id(@participant.parent_id, @participant.user_id))
redirect_to action: 'edit', id: params[:id], view: true
end
</pre>
* '''Solution''': We found changing the name to disable_submission to be more apt in this case
<pre>
def disable_submission
@participant = AssignmentParticipant.find(params[:id])
return unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
# @can_submit is the flag indicating if the user can submit or not in current stage
@can_submit = false
@stage = @assignment.get_current_stage(SignedUpTeam.topic_id(@participant.parent_id, @participant.user_id))
redirect_to action: 'edit', id: params[:id], view: true
end
</pre>

4. '''Problem 4''': submit_hyperlink is filled with a lot of logging code.
:Logging is essential to understand the behavior of the application and to debug unexpected issues or for simply tracking events as in the production environment, we can’t debug issues without proper log files.
* '''Solution''': We added a function for the sole purpose of logging so that it can be reused wherever required.
<pre>
def log_info(controller_name, participant_name, message, request)
ExpertizaLogger.info LoggerMessage.new(controller_name, participant_name, message, request)
end
</pre>

5. '''Problem 5''': Check the validity of the comment ”# Note: This is not used yet in the view until we all decide to do so”.
:
* '''Solution''': The function to remove_hyperlink performs as expected, hence the comment is no longer valid.

6. '''Problem 6''': submit_file method is long.
:
* '''Solution''': Implemented modular code by separating the function into simpler functions.
<pre>
def tested
@current_folder = DisplayOption.new
@current_folder.name = "/"
@current_folder.name = FileHelper.sanitize_folder(params[:current_folder][:name]) if params[:current_folder]
curr_directory = if params[:origin] == 'review'
participant.review_file_path(params[:response_map_id]).to_s + @current_folder.name
else
participant.team.path.to_s + @current_folder.name
end
return curr_directory
end
</pre>

7. '''Problem 7''': Move mail_assigned_reviewers to a mailer class.
:
* '''Solution''': Moved the mail_assigned_reviewers to mailer_helper.rb
<pre>
def self.mail_assigned_reviewers(team)
maps = ResponseMap.where(reviewed_object_id: @participant.assignment.id, reviewee_id: team.id, type: 'ReviewResponseMap')
unless maps.nil?
maps.each do |map|
# Mailing function
Mailer.general_email(
to: User.find(Participant.find(map.reviewer_id).user_id).email,
subject: "Link to update the review for Assignment '#{@participant.assignment.name}'",
cc: User.find_by(@participant.assignment.instructor_id).email,
link: "Link: https://expertiza.ncsu.edu/response/new?id=#{map.id}",
assignment: @participant.assignment.name
).deliver_now
end
end
end
</pre>

8. '''Problem 8''': Change the method name of folder_action.
:
* '''Solution''': Renamed folder_action to perform_folder_action.
<pre>
def perform_folder_action
@participant = AssignmentParticipant.find(params[:id])
return unless current_user_id?(@participant.user_id)
@current_folder = DisplayOption.new
@current_folder.name = "/"
@current_folder.name = FileHelper.sanitize_folder(params[:current_folder][:name]) if params[:current_folder]
if params[:faction][:delete]
SubmittedFiles.delete_selected_files
elsif params[:faction][:rename]
SubmittedFiles.rename_selected_file
elsif params[:faction][:move]
SubmittedFiles.move_selected_file
elsif params[:faction][:copy]
SubmittedFiles.copy_selected_file
elsif params[:faction][:create]
create_new_folder
end
redirect_to action: 'edit', id: @participant.id
end
</pre>

9. '''Problem 9''': Some of the actions in the code (from line 187 to 247) could perhaps be moved to another class
:
* '''Solution''': Separated functions related to submission of files into a new helper class called submitted_files_helper.rb.
<pre>
module SubmittedFiles

def move_selected_file
old_filename = params[:directories][params[:chk_files]] + "/" + params[:filenames][params[:chk_files]]
newloc = @participant.dir_path
newloc += "/"
newloc += params[:faction][:move]
begin
FileHelper.move_file(old_filename, newloc)
flash[:note] = "The file was successfully moved from \"/#{params[:filenames][params[:chk_files]]}\" to \"/#{params[:faction][:move]}\""
rescue StandardError => e
flash[:error] = "There was a problem moving the file: " + e.message
end
end

def rename_selected_file
old_filename = params[:directories][params[:chk_files]] + "/" + params[:filenames][params[:chk_files]]
new_filename = params[:directories][params[:chk_files]] + "/" + FileHelper.sanitize_filename(params[:faction][:rename])
begin
raise "A file already exists in this directory with the name \"#{params[:faction][:rename]}\"" if File.exist?(new_filename)
File.send("rename", old_filename, new_filename)
rescue StandardError => e
flash[:error] = "There was a problem renaming the file: " + e.message
end
end

def delete_selected_files

filename = params[:directories][params[:chk_files]] + "/" + params[:filenames][params[:chk_files]]
FileUtils.rm_r(filename)
participant = Participant.find_by(id: params[:id])
assignment = participant.try(:assignment)
team = participant.try(:team)
SubmissionRecord.create(team_id: team.try(:id),
content: filename,
user: participant.try(:name),
assignment_id: assignment.try(:id),
operation: "Remove File")
ExpertizaLogger.info LoggerMessage.new(controller_name, @participant.name, 'The selected file has been deleted.', request)
end

def copy_selected_file
old_filename = params[:directories][params[:chk_files]] + "/" + params[:filenames][params[:chk_files]]
new_filename = params[:directories][params[:chk_files]] + "/" + FileHelper.sanitize_filename(params[:faction][:copy])
begin
raise "A file with this name already exists. Please delete the existing file before copying." if File.exist?(new_filename)
raise "The referenced file does not exist." unless File.exist?(old_filename)
FileUtils.cp_r(old_filename, new_filename)
rescue StandardError => e
flash[:error] = "There was a problem copying the file: " + e.message
end
end

end

</pre>

== Testing Requirements ==

1. git clone https://github.com/Neelkanth7/expertiza

2. Change directory to expertiza. Run "bundle install" and rails db:migrate.

3. Start the rails server.

4. Run the following command in a new terminal of the expertiza directory:
i. rspec spec/controllers/submitted_content_controller_spec.rb

==References==

* [https://github.com/Neelkanth7/expertiza Github] link to the project.
* [https://docs.google.com/document/d/19FHqVoYUw0HzqGfZ68H-Z-SYmeP_LoHS2rkXjnxeaSE/edit#heading=h.jpaayj9sgw5h Link] to the project description.

CSC/ECE 517 Fall 2021 - E2130. Refactor submitted content controller.rb

2021-10-21T01:59:10Z

Akuchib:

'''E2130: Refactor 'submitted_content_controller' '''

This page provides detailed explanation of the Submitted Content Controller which is a part of the '''Expertiza''' project. The aim of the project is to refactor the 'submitted_content_controller', which contains the methods to submit assignment related information such as submit & remove hyperlinks, files and other relevant information that could be part of the assignment. It also handles views based on the user roles and permissions they have.
The project involved refactoring some parts of the controller to incorporate the OODD principles so that the readability of code could be improved.

==About Expertiza==
The [http://expertiza.ncsu.edu/ Expertiza] platform employs a divide-and-conquer strategy for creating reusable learning objects via active-learning exercises built entirely on [http://rubyonrails.org/ Ruby on Rails] framework. Students get to choose from a list of tasks to complete either individually or in teams. They then prepare their work and submit it to a peer-review mechanism. On submission, other students can assess their peers work and provide feedback. Expertiza encourages students to collaborate in order to improve the learning experiences from one another. It aids their learning by making them translate what is taught in the lectures and apply those concepts to a real-world issue.

==Problem Statement==
'''submitted_content_controller''' had some problems that violate essential rails design principles which needed to be rectified. Issues included some methods being too long which needed to be broken down, a few methods needed better naming and a few that were no longer needed.

Broadly, the following issues were addressed as a part of refactoring this controller:
* Renaming methods to more appropriate and functionality specific names.
* The existing code was reused to perform either the same function or re-purposed to do a similar function adhering to standards and improving overall quality of the code.
* Introduction of modular code in order to make each module easier to understand, test and refactor independently of others.

==Problems and Solutions ==
* '''Problem 1''': action_allowed method should be changed to use new_access_control methods.
:The original code does not make use of the new access control methods which are a part of the authorization_helper.rb
<pre>
def action_allowed?
['Instructor',
'Teaching Assistant',
'Administrator',
'Super-Administrator',
'Student'].include? current_role_name and
((%w[edit].include? action_name) ? are_needed_authorizations_present?(params[:id], "reader", "reviewer") : true) and
one_team_can_submit_work?
end
</pre>
* '''Solution''': On using the new access control methods:
<pre>
def action_allowed?
if %w[edit update list_submissions].include? params[:action]
current_user_has_admin_privileges? || current_user_teaching_staff_of_assignment?(params[:id])
else
current_user_has_ta_privileges?
end

case params[:action]
when 'edit'
current_user_has_student_privileges? &&
are_needed_authorizations_present?(params[:id], "reader", "reviewer")
when 'submit_file', 'submit_hyperlink'
current_user_has_student_privileges? &&
one_team_can_submit_work?
else
current_user_has_student_privileges?
end
end
</pre>

2. '''Problem 2''': Remove the comment “# hence use team count for the check”.
::The current code no longer checks for the team count to see if a participant belongs to a team. Comment on line #19 removed.

3. '''Problem 3''': Change the method name view to something more informative of the method.
:The original code uses the generic 'view' method name to display a view corresponding to a case when submissions cannot be accepted, for instance in the case when a deadline is passed.
<pre>
def view
@participant = AssignmentParticipant.find(params[:id])
return unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
# @can_submit is the flag indicating if the user can submit or not in current stage
@can_submit = false
@stage = @assignment.get_current_stage(SignedUpTeam.topic_id(@participant.parent_id, @participant.user_id))
redirect_to action: 'edit', id: params[:id], view: true
end
</pre>
* '''Solution''': We found changing the name to disable_submission to be more apt in this case
<pre>
def disable_submission
@participant = AssignmentParticipant.find(params[:id])
return unless current_user_id?(@participant.user_id)
@assignment = @participant.assignment
# @can_submit is the flag indicating if the user can submit or not in current stage
@can_submit = false
@stage = @assignment.get_current_stage(SignedUpTeam.topic_id(@participant.parent_id, @participant.user_id))
redirect_to action: 'edit', id: params[:id], view: true
end
</pre>

4. '''Problem 4''': submit_hyperlink is filled with a lot of logging code.
:Logging is essential to understand the behavior of the application and to debug unexpected issues or for simply tracking events as in the production environment, we can’t debug issues without proper log files.
* '''Solution''': We added a function for the sole purpose of logging so that it can be reused wherever required.
<pre>
def log_info(controller_name, participant_name, message, request)
ExpertizaLogger.info LoggerMessage.new(controller_name, participant_name, message, request)
end
</pre>

5. '''Problem 5''': Check the validity of the comment ”# Note: This is not used yet in the view until we all decide to do so”.
:
* '''Solution''':
<pre>

</pre>

6. '''Problem 6''': submit_file method is long.
:
* '''Solution''': Implemented modular code by separating the function into simpler functions.
<pre>
def tested
@current_folder = DisplayOption.new
@current_folder.name = "/"
@current_folder.name = FileHelper.sanitize_folder(params[:current_folder][:name]) if params[:current_folder]
curr_directory = if params[:origin] == 'review'
participant.review_file_path(params[:response_map_id]).to_s + @current_folder.name
else
participant.team.path.to_s + @current_folder.name
end
return curr_directory
end
</pre>

7. '''Problem 7''': Move mail_assigned_reviewers to a mailer class.
:
* '''Solution''': Moved the mail_assigned_reviewers to mailer_helper.rb
<pre>
def self.mail_assigned_reviewers(team)
maps = ResponseMap.where(reviewed_object_id: @participant.assignment.id, reviewee_id: team.id, type: 'ReviewResponseMap')
unless maps.nil?
maps.each do |map|
# Mailing function
Mailer.general_email(
to: User.find(Participant.find(map.reviewer_id).user_id).email,
subject: "Link to update the review for Assignment '#{@participant.assignment.name}'",
cc: User.find_by(@participant.assignment.instructor_id).email,
link: "Link: https://expertiza.ncsu.edu/response/new?id=#{map.id}",
assignment: @participant.assignment.name
).deliver_now
end
end
end
</pre>

8. '''Problem 8''': Change the method name of folder_action.
:
* '''Solution''': Renamed folder_action to perform_folder_action.
<pre>
def perform_folder_action
@participant = AssignmentParticipant.find(params[:id])
return unless current_user_id?(@participant.user_id)
@current_folder = DisplayOption.new
@current_folder.name = "/"
@current_folder.name = FileHelper.sanitize_folder(params[:current_folder][:name]) if params[:current_folder]
if params[:faction][:delete]
SubmittedFiles.delete_selected_files
elsif params[:faction][:rename]
SubmittedFiles.rename_selected_file
elsif params[:faction][:move]
SubmittedFiles.move_selected_file
elsif params[:faction][:copy]
SubmittedFiles.copy_selected_file
elsif params[:faction][:create]
create_new_folder
end
redirect_to action: 'edit', id: @participant.id
end
</pre>

9. '''Problem 9''': Some of the actions in the code (from line 187 to 247) could perhaps be moved to another class
:
* '''Solution''':
<pre>

</pre>

== Testing Requirements ==

1. git clone https://github.com/Neelkanth7/expertiza

2. Change directory to expertiza. Run "bundle install" and rails db:migrate.

3. Start the rails server.

4. Run the following command in a new terminal of the expertiza directory:
i. rspec spec/controllers/submitted_content_controller_spec.rb

==References==

* [https://github.com/Neelkanth7/expertiza Github] link to the project.
* [https://docs.google.com/document/d/19FHqVoYUw0HzqGfZ68H-Z-SYmeP_LoHS2rkXjnxeaSE/edit#heading=h.jpaayj9sgw5h Link] to the project description.

CSC/ECE 517 Fall 2021 - E2130. Refactor submitted content controller.rb

2021-10-20T23:58:55Z

Akuchib:

CSC/ECE 517 Fall 2021 - E2130. Refactor submitted content controller.rb

2021-10-20T23:55:12Z

Akuchib:

CSC/ECE 517 Fall 2021 - E2130. Refactor submitted content controller.rb

2021-10-20T23:50:56Z

Akuchib:

CSC/ECE 517 Fall 2021 - E2130. Refactor submitted content controller.rb

2021-10-20T23:36:49Z

Akuchib:

CSC/ECE 517 Fall 2021 - E2130. Refactor submitted content controller.rb

2021-10-20T23:20:54Z

Akuchib:

CSC/ECE 517 Fall 2021 - E2130. Refactor submitted content controller.rb

2021-10-20T23:20:18Z

Akuchib:

CSC/ECE 517 Fall 2021 - E2130. Refactor submitted content controller.rb

2021-10-20T23:15:13Z

Akuchib:

CSC/ECE 517 Fall 2021 - E2130. Refactor submitted content controller.rb

2021-10-20T23:14:38Z

Akuchib:

CSC/ECE 517 Fall 2021 - E2130. Refactor submitted content controller.rb

2021-10-20T21:58:50Z

Akuchib:

CSC/ECE 517 Fall 2021 - E2130. Refactor submitted content controller.rb

2021-10-20T21:58:00Z

Akuchib:

CSC/ECE 517 Fall 2021 - E2130. Refactor submitted content controller.rb

2021-10-20T21:57:20Z

Akuchib:

CSC/ECE 517 Fall 2021 - E2130. Refactor submitted content controller.rb

2021-10-20T21:56:39Z

Akuchib:

CSC/ECE 517 Fall 2021 - E2130. Refactor submitted content controller.rb

2021-10-20T21:52:12Z

Akuchib:

CSC/ECE 517 Fall 2021 - E2130. Refactor submitted content controller.rb

2021-10-20T21:42:26Z

Akuchib:

CSC/ECE 517 Fall 2021 - E2130. Refactor submitted content controller.rb

2021-10-20T21:41:52Z

Akuchib:

CSC/ECE 517 Fall 2021 - E2130. Refactor submitted content controller.rb

2021-10-20T21:40:22Z

Akuchib:

CSC/ECE 517 Fall 2021 - E2130. Refactor submitted content controller.rb

2021-10-20T21:22:06Z

Akuchib:

'''E2130: Refactor 'submitted_content_controller' Controller'''

This page provides detailed explanation of the Submitted Content Controller which is a part of the '''Expertiza''' project. The aim of the project is to refactor the 'submitted_content_controller', which contains the methods to submit assignment related information such as submit & remove hyperlinks, files and other relevant information that could be part of the assignment. It also handles views based on the user roles and permissions they have.
The project involved refactoring some parts of the controller to incorporate the OODD principles so that the readability of code could be improved.

==Introduction to Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] is a peer review based system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types for assignments, including the URLs and wiki pages.

== Project Description ==
'''submitted_content_Controller''' had some problems that violate some essential Rails design principles which needed to be rectified. There are few methods in this controller that are far too long and need to be broken down into multiple methods. A few methods need to be commented as well. Few Methods need to be renamed.

===Create Method===
The method '''Create''' is called when an instructor tries to create a team manually. This works for both, creating ''assignment teams'' and ''course teams''. Assignment teams are teams made to do a particular assignment together and ''Course Teams'' are teams which are made for the whole course.

===Delete Method===
The method '''Delete''' is called when an instructor tries to delete a team manually. This works for both, deleting ''assignment teams'' and ''course teams''.

===List Method===
The method '''List''' lists all the team nodes and the instructor is able to expand each team node to see the user nodes as well.

===Inherit Method===
The method '''Inherit''' inherits teams from course to assignments, but the “Inherit Teams From Course” option should not display when either 1) we are editing a course object or 2) the current assignment object does not have a course associated with it.

===Running Tests===
rspec spec/controllers/submitted_content_controller_spec.rb

===Files Modified===
1. teams_controller.rb
2. team.rb
3. signed_up_team.rb
4. routes.rb
5. app/views/teams/new.html.erb

== Refactoring ==
[https://en.wikipedia.org/wiki/Code_refactoring '''Refactoring'''] is restructuring of code without the need of changing any external behavior. It reduces complexity and improves readability. It also becomes easy to extend the application with respect to different modules and their functionalities.
Some common techniques to refactor are:

* Moving methods to appropriate modules
* Breaking methods into more meaningful functionality
* Creating more generalized code.
* Renaming methods and variable.
* Inheritance

== Tasks ==

===Refactoring delete method===
Description: The delete method manipulates a waitlist. This code is moved to signed_up_team.rb model class.

Initially, the code was:

def delete
# delete records in team, teams_users, signed_up_teams table
@team = Team.find_by(id: params[:id])
unless @team.nil?
course = Object.const_get(session[:team_type]).find(@team.parent_id)
@signed_up_team = SignedUpTeam.where(team_id: @team.id)
@teams_users = TeamsUser.where(team_id: @team.id)
if @signed_up_team == 1 && !@signUps.first.is_waitlisted # this team hold a topic
# if there is another team in waitlist, make this team hold this topic
topic_id = @signed_up_team.first.topic_id
next_wait_listed_team = SignedUpTeam.where(topic_id: topic_id, is_waitlisted: true).first
# if slot exist, then confirm the topic for this team and delete all waitlists for this team
SignUpTopic.assign_to_first_waiting_team(next_wait_listed_team) if next_wait_listed_team
end
@sign_up_team.destroy_all if @sign_up_team
@teams_users.destroy_all if @teams_users
@team.destroy if @team
undo_link("The team \"#{@team.name}\" has been successfully deleted.")
end
redirect_to :back
end

Which was changed to:

def delete
# delete records in team, teams_users, signed_up_teams table
@team = Team.find_by(id: params[:id])
unless @team.nil?
course = Object.const_get(session[:team_type]).find(@team.parent_id)
@signed_up_team = SignedUpTeam.where(team_id: @team.id)
@teams_users = TeamsUser.where(team_id: @team.id)
# On team deletion topic team was holding will be assigned to first team in waitlist.
SignedUpTeam.assign_topic_to_first_in_waitlist_post_team_deletion(@signed_up_team, @signups)
@sign_up_team.destroy_all if @sign_up_team
@teams_users.destroy_all if @teams_users
@team.destroy if @team
undo_link("The team \"#{@team.name}\" has been successfully deleted.")
end
redirect_to :back
end

and a new method was introduced in signed_up_team.rb model:
# this method checks when a team is deleted if there is a team in waitlist for the topic
# deleted team was holding, then assign topic to first team in waitlist
def self.assign_topic_to_first_in_waitlist_post_team_deletion (signed_up_team, signups)
if signed_up_team == 1 && !signups.first.is_waitlisted # this team hold a topic
# if there is another team in waitlist, make this team hold this topic
topic_id = signed_up_team.first.topic_id
next_wait_listed_team = SignedUpTeam.where(topic_id: topic_id, is_waitlisted: true).first
# if slot exist, then confirm the topic for this team and delete all waitlists for this team
SignUpTopic.assign_to_first_waiting_team(next_wait_listed_team) if next_wait_listed_team
end
end

===Refactoring inherit method===

Description: The code that copies a list is moved to team.rb model class.

Initially, the code was:
def inherit
assignment = Assignment.find(params[:id])
if assignment.course_id >= 0
course = Course.find(assignment.course_id)
teams = course.get_teams
unless teams.empty?
teams.each do |team|
team.copy(assignment.id)
end
else
flash[:note] = "No teams were found when trying to inherit."
end
else
flash[:error] = "No course was found for this assignment."
end
redirect_to controller: 'teams', action: 'list', id: assignment.id
end

Which was changed to:
def inherit
assignment = Assignment.find(params[:id])
if assignment.course_id >= 0
course = Course.find(assignment.course_id)
teams = course.get_teams
unless teams.empty?
# copy_assignment method copies teams to assignment
Team.copy_assignment(teams,assignment)
else
flash[:note] = "No teams were found when trying to inherit."
end
else
flash[:error] = "No course was found for this assignment."
end
redirect_to controller: 'teams', action: 'list', id: assignment.id
end

and a new method was introduced in team.rb model:
def self.copy_assignment(teams,assignment)
teams.each do |team|
team.copy(assignment.id)
end
end

===Refactoring create method===

Description: It creates new teams against a parent id

Initially the create method was:

def create
parent = Object.const_get(session[:team_type]).find(params[:id])
begin
Team.check_for_existing(parent, params[:team][:name], session[:team_type])
@team = Object.const_get(session[:team_type] + 'Team').create(name: params[:team][:name], parent_id: parent.id)
TeamNode.create(parent_id: parent.id, node_object_id: @team.id)
undo_link("The team \"#{@team.name}\" has been successfully created.")
redirect_to action: 'list', id: parent.id
rescue TeamExistsError
flash[:error] = $ERROR_INFO
redirect_to action: 'new', id: parent.id
end
end

Which changed to:

def create
begin
parent = get_parent_and_check_if_exists(params[:id])
@team = Object.const_get(session[:team_type] + 'Team').create(name: params[:team][:name], parent_id: parent.id)
TeamNode.create(parent_id: parent.id, node_object_id: @team.id)
undo_link("The team \"#{@team.name}\" has been successfully created.")
redirect_to action: 'list', id: parent.id
rescue TeamExistsError
flash_and_redirect_on_update_or_create_error('new', parent_id)
end
end

# called to fetch parent and check if team with same name and type already exists.
def get_parent_and_check_if_exists(parent_id)
parent = Object.const_get(session[:team_type]).find(parent_id)
Team.check_for_existing(parent, params[:team][:name], session[:team_type])
return parent
end

# to flash and redirect the user when there is any update or create error
def flash_and_redirect_on_update_or_create_error(action, id)
flash[:error] = $ERROR_INFO
redirect_to action: action, id: id
end

===Refactoring update method===

Description: It updates an existing team name

Initially the update method was:

def update
@team = Team.find(params[:id])
parent = Object.const_get(session[:team_type]).find(@team.parent_id)
begin
Team.check_for_existing(parent, params[:team][:name], session[:team_type])
@team.name = params[:team][:name]
@team.save
flash[:success] = "The team \"#{@team.name}\" has been successfully updated."
undo_link("")
redirect_to action: 'list', id: parent.id
rescue TeamExistsError
flash[:error] = $ERROR_INFO
redirect_to action: 'edit', id: @team.id
end
end

Which changed to:

# It updates an existing team name
def update
@team = Team.find(params[:id])
begin
parent = get_parent_and_check_if_exists(@team.parent_id)
@team.name = params[:team][:name]
@team.save
flash[:success] = "The team \"#{@team.name}\" has been successfully updated."
undo_link("")
redirect_to action: 'list', id: parent.id
rescue TeamExistsError
flash_and_redirect_on_update_or_create_error('edit', @team.id)
end
end

# called to fetch parent and check if team with same name and type already exists.
def get_parent_and_check_if_exists(parent_id)
parent = Object.const_get(session[:team_type]).find(parent_id)
Team.check_for_existing(parent, params[:team][:name], session[:team_type])
return parent
end

# to flash and redirect the user when there is any update or create error
def flash_and_redirect_on_update_or_create_error(action, id)
flash[:error] = $ERROR_INFO
redirect_to action: action, id: id
end

===Create Teams===

The new method self.create_teams() is created in Team.rb model and placed the common of create_teams method.
# This function is used to create teams with random names.
# Instructors can call by clicking "Create temas" icon anc then click "Create teams" at the bottom.
def self.create_teams(session,params)
parent = Object.const_get(session[:team_type]).find(params[:id])
Team.randomize_all_by_parent(parent, session[:team_type], params[:team_size].to_i)
end

Exiting code of create_teams() method in teams_controller.rb

# This function is used to create teams with random names.
# Instructors can call by clicking "Create temas" icon anc then click "Create teams" at the bottom.
def create_teams
parent = Object.const_get(session[:team_type]).find(params[:id])
Team.randomize_all_by_parent(parent, session[:team_type], params[:team_size].to_i)
undo_link("Random teams have been successfully created.")
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'Random teams have been successfully created', request)
redirect_to action: 'list', id: parent.id
end

Modified the teams_controller.rb file and it is now using the Team.create_teams(session,params) present in Team.rb model to create teams.

# This function is used to create teams with random names.
# Instructors can call by clicking "Create temas" icon anc then click "Create teams" at the bottom.
def create_teams
Team.create_teams(session,params)
undo_link("Random teams have been successfully created.")
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'Random teams have been successfully created', request)
redirect_to action: 'list', id: parent.id
end

===signUps should be signups===
Existing code for the signUps nouns are modified to signups.

Existing code teams_controller.rb

def delete
# delete records in team, teams_users, signed_up_teams table
@team = Team.find_by(id: params[:id])
unless @team.nil?
course = Object.const_get(session[:team_type]).find(@team.parent_id)
@signed_up_team = SignedUpTeam.where(team_id: @team.id)
@teams_users = TeamsUser.where(team_id: @team.id)

SignedUpTeam.assign_topic_to_first_in_waitlist_post_team_deletion(@signed_up_team, @signUps)

@sign_up_team.destroy_all if @sign_up_team
@teams_users.destroy_all if @teams_users
@team.destroy if @team
undo_link("The team \"#{@team.name}\" has been successfully deleted.")
end
redirect_to :back
end

Modified code in teams_controller.rb

def delete
# delete records in team, teams_users, signed_up_teams table
@team = Team.find_by(id: params[:id])
unless @team.nil?
course = Object.const_get(session[:team_type]).find(@team.parent_id)
@signed_up_team = SignedUpTeam.where(team_id: @team.id)
@teams_users = TeamsUser.where(team_id: @team.id)

SignedUpTeam.assign_topic_to_first_in_waitlist_post_team_deletion(@signed_up_team, @signups)

@sign_up_team.destroy_all if @sign_up_team
@teams_users.destroy_all if @teams_users
@team.destroy if @team
undo_link("The team \"#{@team.name}\" has been successfully deleted.")
end
redirect_to :back
end

Existing code signed_up_team.rb

def self.assign_topic_to_first_in_waitlist_post_team_deletion (signed_up_team, signUps)
if signed_up_team == 1 && !signups.first.is_waitlisted # this team hold a topic
# if there is another team in waitlist, make this team hold this topic
topic_id = signed_up_team.first.topic_id
next_wait_listed_team = SignedUpTeam.where(topic_id: topic_id, is_waitlisted: true).first
# if slot exist, then confirm the topic for this team and delete all waitlists for this team
SignUpTopic.assign_to_first_waiting_team(next_wait_listed_team) if next_wait_listed_team
end
end

Modified code in signed_up_team.rb

def self.assign_topic_to_first_in_waitlist_post_team_deletion (signed_up_team, signups)
if signed_up_team == 1 && !signups.first.is_waitlisted # this team hold a topic
# if there is another team in waitlist, make this team hold this topic
topic_id = signed_up_team.first.topic_id
next_wait_listed_team = SignedUpTeam.where(topic_id: topic_id, is_waitlisted: true).first
# if slot exist, then confirm the topic for this team and delete all waitlists for this team
SignUpTopic.assign_to_first_waiting_team(next_wait_listed_team) if next_wait_listed_team
end
end

== Testing the submitted_content_controller ==

=== Instructions for testing Rspecs ===

1. git clone https://github.com/Neelkanth7/expertiza.git

2. Change to the expertiza directory and then perform "bundle install" and rake db:migrate.

3. Start the rails server

4. In a new terminal and in the expertiza directory, perform the following commands:
i. rspec spec/controllers/submitted_content_controller_spec.rb

===Testing Inherit Method===

===Testing Create Method===

===Testing Delete Method===

===Testing List Method===

==References==

* [https://github.com/Neelkanth7/expertiza Github] link to the project.
* [https://docs.google.com/document/d/19FHqVoYUw0HzqGfZ68H-Z-SYmeP_LoHS2rkXjnxeaSE/edit#heading=h.jpaayj9sgw5h Link] to the project description.

CSC/ECE 517 Fall 2021 - E2130. Refactor submitted content controller.rb

2021-10-20T21:21:36Z

Akuchib:

'''E2127: Refactor 'submitted_content_controller' Controller'''

This page provides detailed explanation of the Submitted Content Controller which is a part of the '''Expertiza''' project. The aim of the project is to refactor the 'submitted_content_controller', which contains the methods to submit assignment related information such as submit & remove hyperlinks, files and other relevant information that could be part of the assignment. It also handles views based on the user roles and permissions they have.
The project involved refactoring some parts of the controller to incorporate the OODD principles so that the readability of code could be improved.

==Introduction to Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] is a peer review based system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types for assignments, including the URLs and wiki pages.

== Project Description ==
'''submitted_content_Controller''' had some problems that violate some essential Rails design principles which needed to be rectified. There are few methods in this controller that are far too long and need to be broken down into multiple methods. A few methods need to be commented as well. Few Methods need to be renamed.

===Create Method===
The method '''Create''' is called when an instructor tries to create a team manually. This works for both, creating ''assignment teams'' and ''course teams''. Assignment teams are teams made to do a particular assignment together and ''Course Teams'' are teams which are made for the whole course.

===Delete Method===
The method '''Delete''' is called when an instructor tries to delete a team manually. This works for both, deleting ''assignment teams'' and ''course teams''.

===List Method===
The method '''List''' lists all the team nodes and the instructor is able to expand each team node to see the user nodes as well.

===Inherit Method===
The method '''Inherit''' inherits teams from course to assignments, but the “Inherit Teams From Course” option should not display when either 1) we are editing a course object or 2) the current assignment object does not have a course associated with it.

===Running Tests===
rspec spec/controllers/submitted_content_controller_spec.rb

===Files Modified===
1. teams_controller.rb
2. team.rb
3. signed_up_team.rb
4. routes.rb
5. app/views/teams/new.html.erb

== Refactoring ==
[https://en.wikipedia.org/wiki/Code_refactoring '''Refactoring'''] is restructuring of code without the need of changing any external behavior. It reduces complexity and improves readability. It also becomes easy to extend the application with respect to different modules and their functionalities.
Some common techniques to refactor are:

* Moving methods to appropriate modules
* Breaking methods into more meaningful functionality
* Creating more generalized code.
* Renaming methods and variable.
* Inheritance

== Tasks ==

===Refactoring delete method===
Description: The delete method manipulates a waitlist. This code is moved to signed_up_team.rb model class.

Initially, the code was:

def delete
# delete records in team, teams_users, signed_up_teams table
@team = Team.find_by(id: params[:id])
unless @team.nil?
course = Object.const_get(session[:team_type]).find(@team.parent_id)
@signed_up_team = SignedUpTeam.where(team_id: @team.id)
@teams_users = TeamsUser.where(team_id: @team.id)
if @signed_up_team == 1 && !@signUps.first.is_waitlisted # this team hold a topic
# if there is another team in waitlist, make this team hold this topic
topic_id = @signed_up_team.first.topic_id
next_wait_listed_team = SignedUpTeam.where(topic_id: topic_id, is_waitlisted: true).first
# if slot exist, then confirm the topic for this team and delete all waitlists for this team
SignUpTopic.assign_to_first_waiting_team(next_wait_listed_team) if next_wait_listed_team
end
@sign_up_team.destroy_all if @sign_up_team
@teams_users.destroy_all if @teams_users
@team.destroy if @team
undo_link("The team \"#{@team.name}\" has been successfully deleted.")
end
redirect_to :back
end

Which was changed to:

def delete
# delete records in team, teams_users, signed_up_teams table
@team = Team.find_by(id: params[:id])
unless @team.nil?
course = Object.const_get(session[:team_type]).find(@team.parent_id)
@signed_up_team = SignedUpTeam.where(team_id: @team.id)
@teams_users = TeamsUser.where(team_id: @team.id)
# On team deletion topic team was holding will be assigned to first team in waitlist.
SignedUpTeam.assign_topic_to_first_in_waitlist_post_team_deletion(@signed_up_team, @signups)
@sign_up_team.destroy_all if @sign_up_team
@teams_users.destroy_all if @teams_users
@team.destroy if @team
undo_link("The team \"#{@team.name}\" has been successfully deleted.")
end
redirect_to :back
end

and a new method was introduced in signed_up_team.rb model:
# this method checks when a team is deleted if there is a team in waitlist for the topic
# deleted team was holding, then assign topic to first team in waitlist
def self.assign_topic_to_first_in_waitlist_post_team_deletion (signed_up_team, signups)
if signed_up_team == 1 && !signups.first.is_waitlisted # this team hold a topic
# if there is another team in waitlist, make this team hold this topic
topic_id = signed_up_team.first.topic_id
next_wait_listed_team = SignedUpTeam.where(topic_id: topic_id, is_waitlisted: true).first
# if slot exist, then confirm the topic for this team and delete all waitlists for this team
SignUpTopic.assign_to_first_waiting_team(next_wait_listed_team) if next_wait_listed_team
end
end

===Refactoring inherit method===

Description: The code that copies a list is moved to team.rb model class.

Initially, the code was:
def inherit
assignment = Assignment.find(params[:id])
if assignment.course_id >= 0
course = Course.find(assignment.course_id)
teams = course.get_teams
unless teams.empty?
teams.each do |team|
team.copy(assignment.id)
end
else
flash[:note] = "No teams were found when trying to inherit."
end
else
flash[:error] = "No course was found for this assignment."
end
redirect_to controller: 'teams', action: 'list', id: assignment.id
end

Which was changed to:
def inherit
assignment = Assignment.find(params[:id])
if assignment.course_id >= 0
course = Course.find(assignment.course_id)
teams = course.get_teams
unless teams.empty?
# copy_assignment method copies teams to assignment
Team.copy_assignment(teams,assignment)
else
flash[:note] = "No teams were found when trying to inherit."
end
else
flash[:error] = "No course was found for this assignment."
end
redirect_to controller: 'teams', action: 'list', id: assignment.id
end

and a new method was introduced in team.rb model:
def self.copy_assignment(teams,assignment)
teams.each do |team|
team.copy(assignment.id)
end
end

===Refactoring create method===

Description: It creates new teams against a parent id

Initially the create method was:

def create
parent = Object.const_get(session[:team_type]).find(params[:id])
begin
Team.check_for_existing(parent, params[:team][:name], session[:team_type])
@team = Object.const_get(session[:team_type] + 'Team').create(name: params[:team][:name], parent_id: parent.id)
TeamNode.create(parent_id: parent.id, node_object_id: @team.id)
undo_link("The team \"#{@team.name}\" has been successfully created.")
redirect_to action: 'list', id: parent.id
rescue TeamExistsError
flash[:error] = $ERROR_INFO
redirect_to action: 'new', id: parent.id
end
end

Which changed to:

def create
begin
parent = get_parent_and_check_if_exists(params[:id])
@team = Object.const_get(session[:team_type] + 'Team').create(name: params[:team][:name], parent_id: parent.id)
TeamNode.create(parent_id: parent.id, node_object_id: @team.id)
undo_link("The team \"#{@team.name}\" has been successfully created.")
redirect_to action: 'list', id: parent.id
rescue TeamExistsError
flash_and_redirect_on_update_or_create_error('new', parent_id)
end
end

# called to fetch parent and check if team with same name and type already exists.
def get_parent_and_check_if_exists(parent_id)
parent = Object.const_get(session[:team_type]).find(parent_id)
Team.check_for_existing(parent, params[:team][:name], session[:team_type])
return parent
end

# to flash and redirect the user when there is any update or create error
def flash_and_redirect_on_update_or_create_error(action, id)
flash[:error] = $ERROR_INFO
redirect_to action: action, id: id
end

===Refactoring update method===

Description: It updates an existing team name

Initially the update method was:

def update
@team = Team.find(params[:id])
parent = Object.const_get(session[:team_type]).find(@team.parent_id)
begin
Team.check_for_existing(parent, params[:team][:name], session[:team_type])
@team.name = params[:team][:name]
@team.save
flash[:success] = "The team \"#{@team.name}\" has been successfully updated."
undo_link("")
redirect_to action: 'list', id: parent.id
rescue TeamExistsError
flash[:error] = $ERROR_INFO
redirect_to action: 'edit', id: @team.id
end
end

Which changed to:

# It updates an existing team name
def update
@team = Team.find(params[:id])
begin
parent = get_parent_and_check_if_exists(@team.parent_id)
@team.name = params[:team][:name]
@team.save
flash[:success] = "The team \"#{@team.name}\" has been successfully updated."
undo_link("")
redirect_to action: 'list', id: parent.id
rescue TeamExistsError
flash_and_redirect_on_update_or_create_error('edit', @team.id)
end
end

# called to fetch parent and check if team with same name and type already exists.
def get_parent_and_check_if_exists(parent_id)
parent = Object.const_get(session[:team_type]).find(parent_id)
Team.check_for_existing(parent, params[:team][:name], session[:team_type])
return parent
end

# to flash and redirect the user when there is any update or create error
def flash_and_redirect_on_update_or_create_error(action, id)
flash[:error] = $ERROR_INFO
redirect_to action: action, id: id
end

===Create Teams===

The new method self.create_teams() is created in Team.rb model and placed the common of create_teams method.
# This function is used to create teams with random names.
# Instructors can call by clicking "Create temas" icon anc then click "Create teams" at the bottom.
def self.create_teams(session,params)
parent = Object.const_get(session[:team_type]).find(params[:id])
Team.randomize_all_by_parent(parent, session[:team_type], params[:team_size].to_i)
end

Exiting code of create_teams() method in teams_controller.rb

# This function is used to create teams with random names.
# Instructors can call by clicking "Create temas" icon anc then click "Create teams" at the bottom.
def create_teams
parent = Object.const_get(session[:team_type]).find(params[:id])
Team.randomize_all_by_parent(parent, session[:team_type], params[:team_size].to_i)
undo_link("Random teams have been successfully created.")
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'Random teams have been successfully created', request)
redirect_to action: 'list', id: parent.id
end

Modified the teams_controller.rb file and it is now using the Team.create_teams(session,params) present in Team.rb model to create teams.

# This function is used to create teams with random names.
# Instructors can call by clicking "Create temas" icon anc then click "Create teams" at the bottom.
def create_teams
Team.create_teams(session,params)
undo_link("Random teams have been successfully created.")
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'Random teams have been successfully created', request)
redirect_to action: 'list', id: parent.id
end

===signUps should be signups===
Existing code for the signUps nouns are modified to signups.

Existing code teams_controller.rb

def delete
# delete records in team, teams_users, signed_up_teams table
@team = Team.find_by(id: params[:id])
unless @team.nil?
course = Object.const_get(session[:team_type]).find(@team.parent_id)
@signed_up_team = SignedUpTeam.where(team_id: @team.id)
@teams_users = TeamsUser.where(team_id: @team.id)

SignedUpTeam.assign_topic_to_first_in_waitlist_post_team_deletion(@signed_up_team, @signUps)

@sign_up_team.destroy_all if @sign_up_team
@teams_users.destroy_all if @teams_users
@team.destroy if @team
undo_link("The team \"#{@team.name}\" has been successfully deleted.")
end
redirect_to :back
end

Modified code in teams_controller.rb

def delete
# delete records in team, teams_users, signed_up_teams table
@team = Team.find_by(id: params[:id])
unless @team.nil?
course = Object.const_get(session[:team_type]).find(@team.parent_id)
@signed_up_team = SignedUpTeam.where(team_id: @team.id)
@teams_users = TeamsUser.where(team_id: @team.id)

SignedUpTeam.assign_topic_to_first_in_waitlist_post_team_deletion(@signed_up_team, @signups)

@sign_up_team.destroy_all if @sign_up_team
@teams_users.destroy_all if @teams_users
@team.destroy if @team
undo_link("The team \"#{@team.name}\" has been successfully deleted.")
end
redirect_to :back
end

Existing code signed_up_team.rb

def self.assign_topic_to_first_in_waitlist_post_team_deletion (signed_up_team, signUps)
if signed_up_team == 1 && !signups.first.is_waitlisted # this team hold a topic
# if there is another team in waitlist, make this team hold this topic
topic_id = signed_up_team.first.topic_id
next_wait_listed_team = SignedUpTeam.where(topic_id: topic_id, is_waitlisted: true).first
# if slot exist, then confirm the topic for this team and delete all waitlists for this team
SignUpTopic.assign_to_first_waiting_team(next_wait_listed_team) if next_wait_listed_team
end
end

Modified code in signed_up_team.rb

def self.assign_topic_to_first_in_waitlist_post_team_deletion (signed_up_team, signups)
if signed_up_team == 1 && !signups.first.is_waitlisted # this team hold a topic
# if there is another team in waitlist, make this team hold this topic
topic_id = signed_up_team.first.topic_id
next_wait_listed_team = SignedUpTeam.where(topic_id: topic_id, is_waitlisted: true).first
# if slot exist, then confirm the topic for this team and delete all waitlists for this team
SignUpTopic.assign_to_first_waiting_team(next_wait_listed_team) if next_wait_listed_team
end
end

== Testing the submitted_content_controller ==

=== Instructions for testing Rspecs ===

1. git clone https://github.com/Neelkanth7/expertiza.git

2. Change to the expertiza directory and then perform "bundle install" and rake db:migrate.

3. Start the rails server

4. In a new terminal and in the expertiza directory, perform the following commands:
i. rspec spec/controllers/submitted_content_controller_spec.rb

===Testing Inherit Method===

===Testing Create Method===

===Testing Delete Method===

===Testing List Method===

==References==

* [https://github.com/Neelkanth7/expertiza Github] link to the project.
* [https://docs.google.com/document/d/19FHqVoYUw0HzqGfZ68H-Z-SYmeP_LoHS2rkXjnxeaSE/edit#heading=h.jpaayj9sgw5h Link] to the project description.

CSC/ECE 517 Fall 2021 - E2130. Refactor submitted content controller.rb

2021-10-20T20:29:55Z

Akuchib: Created page with "'''E2127: Refactor 'submitted_content_controller' Controller''' This page provides a brief description of the '''Expertiza''' project. The project is aimed at refactoring the..."

'''E2127: Refactor 'submitted_content_controller' Controller'''

This page provides a brief description of the '''Expertiza''' project. The project is aimed at refactoring the 'Teams_Controller' Controller, which contains the methods to create new teams, list the existing teams, create new teams by inheriting existing teams, deleting existing teams and creating multiple teams at once by assigning them random topics. The project entailed, refactoring some part of the controller to improve the readability of code and then creating test cases in [https://en.wikipedia.org/wiki/RSpec RSpec] to verify the methods it possesses.

==Introduction to Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] is a peer review based system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types for assignments, including the URLs and wiki pages.

== Project Description ==
'''Teams_Controller''' primarily handles the team creation, deletion and other behaviours. Most of those are called from the instructor’s view. When manual testing is done, most of the methods can be called by clicking the “Create teams” icon from both assignments and courses.
The following tasks have been performed as per the requirements.

===Create Method===
The method '''Create''' is called when an instructor tries to create a team manually. This works for both, creating ''assignment teams'' and ''course teams''. Assignment teams are teams made to do a particular assignment together and ''Course Teams'' are teams which are made for the whole course.

===Delete Method===
The method '''Delete''' is called when an instructor tries to delete a team manually. This works for both, deleting ''assignment teams'' and ''course teams''.

===List Method===
The method '''List''' lists all the team nodes and the instructor is able to expand each team node to see the user nodes as well.

===Inherit Method===
The method '''Inherit''' inherits teams from course to assignments, but the “Inherit Teams From Course” option should not display when either 1) we are editing a course object or 2) the current assignment object does not have a course associated with it.

===Running Tests===
rspec spec/controllers/teams_controller_spec.rb

===Files Modified===
1. teams_controller.rb
2. team.rb
3. signed_up_team.rb
4. routes.rb
5. app/views/teams/new.html.erb

== Refactoring ==
[https://en.wikipedia.org/wiki/Code_refactoring '''Refactoring'''] is restructuring of code without the need of changing any external behavior. It reduces complexity and improves readability. It also becomes easy to extend the application with respect to different modules and their functionalities.
Some common techniques to refactor are:

* Moving methods to appropriate modules
* Breaking methods into more meaningful functionality
* Creating more generalized code.
* Renaming methods and variable.
* Inheritance

== Tasks ==

===Refactoring delete method===
Description: The delete method manipulates a waitlist. This code is moved to signed_up_team.rb model class.

Initially, the code was:

def delete
# delete records in team, teams_users, signed_up_teams table
@team = Team.find_by(id: params[:id])
unless @team.nil?
course = Object.const_get(session[:team_type]).find(@team.parent_id)
@signed_up_team = SignedUpTeam.where(team_id: @team.id)
@teams_users = TeamsUser.where(team_id: @team.id)
if @signed_up_team == 1 && !@signUps.first.is_waitlisted # this team hold a topic
# if there is another team in waitlist, make this team hold this topic
topic_id = @signed_up_team.first.topic_id
next_wait_listed_team = SignedUpTeam.where(topic_id: topic_id, is_waitlisted: true).first
# if slot exist, then confirm the topic for this team and delete all waitlists for this team
SignUpTopic.assign_to_first_waiting_team(next_wait_listed_team) if next_wait_listed_team
end
@sign_up_team.destroy_all if @sign_up_team
@teams_users.destroy_all if @teams_users
@team.destroy if @team
undo_link("The team \"#{@team.name}\" has been successfully deleted.")
end
redirect_to :back
end

Which was changed to:

def delete
# delete records in team, teams_users, signed_up_teams table
@team = Team.find_by(id: params[:id])
unless @team.nil?
course = Object.const_get(session[:team_type]).find(@team.parent_id)
@signed_up_team = SignedUpTeam.where(team_id: @team.id)
@teams_users = TeamsUser.where(team_id: @team.id)
# On team deletion topic team was holding will be assigned to first team in waitlist.
SignedUpTeam.assign_topic_to_first_in_waitlist_post_team_deletion(@signed_up_team, @signups)
@sign_up_team.destroy_all if @sign_up_team
@teams_users.destroy_all if @teams_users
@team.destroy if @team
undo_link("The team \"#{@team.name}\" has been successfully deleted.")
end
redirect_to :back
end

and a new method was introduced in signed_up_team.rb model:
# this method checks when a team is deleted if there is a team in waitlist for the topic
# deleted team was holding, then assign topic to first team in waitlist
def self.assign_topic_to_first_in_waitlist_post_team_deletion (signed_up_team, signups)
if signed_up_team == 1 && !signups.first.is_waitlisted # this team hold a topic
# if there is another team in waitlist, make this team hold this topic
topic_id = signed_up_team.first.topic_id
next_wait_listed_team = SignedUpTeam.where(topic_id: topic_id, is_waitlisted: true).first
# if slot exist, then confirm the topic for this team and delete all waitlists for this team
SignUpTopic.assign_to_first_waiting_team(next_wait_listed_team) if next_wait_listed_team
end
end

===Refactoring inherit method===

Description: The code that copies a list is moved to team.rb model class.

Initially, the code was:
def inherit
assignment = Assignment.find(params[:id])
if assignment.course_id >= 0
course = Course.find(assignment.course_id)
teams = course.get_teams
unless teams.empty?
teams.each do |team|
team.copy(assignment.id)
end
else
flash[:note] = "No teams were found when trying to inherit."
end
else
flash[:error] = "No course was found for this assignment."
end
redirect_to controller: 'teams', action: 'list', id: assignment.id
end

Which was changed to:
def inherit
assignment = Assignment.find(params[:id])
if assignment.course_id >= 0
course = Course.find(assignment.course_id)
teams = course.get_teams
unless teams.empty?
# copy_assignment method copies teams to assignment
Team.copy_assignment(teams,assignment)
else
flash[:note] = "No teams were found when trying to inherit."
end
else
flash[:error] = "No course was found for this assignment."
end
redirect_to controller: 'teams', action: 'list', id: assignment.id
end

and a new method was introduced in team.rb model:
def self.copy_assignment(teams,assignment)
teams.each do |team|
team.copy(assignment.id)
end
end

===Refactoring create method===

Description: It creates new teams against a parent id

Initially the create method was:

def create
parent = Object.const_get(session[:team_type]).find(params[:id])
begin
Team.check_for_existing(parent, params[:team][:name], session[:team_type])
@team = Object.const_get(session[:team_type] + 'Team').create(name: params[:team][:name], parent_id: parent.id)
TeamNode.create(parent_id: parent.id, node_object_id: @team.id)
undo_link("The team \"#{@team.name}\" has been successfully created.")
redirect_to action: 'list', id: parent.id
rescue TeamExistsError
flash[:error] = $ERROR_INFO
redirect_to action: 'new', id: parent.id
end
end

Which changed to:

def create
begin
parent = get_parent_and_check_if_exists(params[:id])
@team = Object.const_get(session[:team_type] + 'Team').create(name: params[:team][:name], parent_id: parent.id)
TeamNode.create(parent_id: parent.id, node_object_id: @team.id)
undo_link("The team \"#{@team.name}\" has been successfully created.")
redirect_to action: 'list', id: parent.id
rescue TeamExistsError
flash_and_redirect_on_update_or_create_error('new', parent_id)
end
end

# called to fetch parent and check if team with same name and type already exists.
def get_parent_and_check_if_exists(parent_id)
parent = Object.const_get(session[:team_type]).find(parent_id)
Team.check_for_existing(parent, params[:team][:name], session[:team_type])
return parent
end

# to flash and redirect the user when there is any update or create error
def flash_and_redirect_on_update_or_create_error(action, id)
flash[:error] = $ERROR_INFO
redirect_to action: action, id: id
end

===Refactoring update method===

Description: It updates an existing team name

Initially the update method was:

def update
@team = Team.find(params[:id])
parent = Object.const_get(session[:team_type]).find(@team.parent_id)
begin
Team.check_for_existing(parent, params[:team][:name], session[:team_type])
@team.name = params[:team][:name]
@team.save
flash[:success] = "The team \"#{@team.name}\" has been successfully updated."
undo_link("")
redirect_to action: 'list', id: parent.id
rescue TeamExistsError
flash[:error] = $ERROR_INFO
redirect_to action: 'edit', id: @team.id
end
end

Which changed to:

# It updates an existing team name
def update
@team = Team.find(params[:id])
begin
parent = get_parent_and_check_if_exists(@team.parent_id)
@team.name = params[:team][:name]
@team.save
flash[:success] = "The team \"#{@team.name}\" has been successfully updated."
undo_link("")
redirect_to action: 'list', id: parent.id
rescue TeamExistsError
flash_and_redirect_on_update_or_create_error('edit', @team.id)
end
end

# called to fetch parent and check if team with same name and type already exists.
def get_parent_and_check_if_exists(parent_id)
parent = Object.const_get(session[:team_type]).find(parent_id)
Team.check_for_existing(parent, params[:team][:name], session[:team_type])
return parent
end

# to flash and redirect the user when there is any update or create error
def flash_and_redirect_on_update_or_create_error(action, id)
flash[:error] = $ERROR_INFO
redirect_to action: action, id: id
end

===Create Teams===

The new method self.create_teams() is created in Team.rb model and placed the common of create_teams method.
# This function is used to create teams with random names.
# Instructors can call by clicking "Create temas" icon anc then click "Create teams" at the bottom.
def self.create_teams(session,params)
parent = Object.const_get(session[:team_type]).find(params[:id])
Team.randomize_all_by_parent(parent, session[:team_type], params[:team_size].to_i)
end

Exiting code of create_teams() method in teams_controller.rb

# This function is used to create teams with random names.
# Instructors can call by clicking "Create temas" icon anc then click "Create teams" at the bottom.
def create_teams
parent = Object.const_get(session[:team_type]).find(params[:id])
Team.randomize_all_by_parent(parent, session[:team_type], params[:team_size].to_i)
undo_link("Random teams have been successfully created.")
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'Random teams have been successfully created', request)
redirect_to action: 'list', id: parent.id
end

Modified the teams_controller.rb file and it is now using the Team.create_teams(session,params) present in Team.rb model to create teams.

# This function is used to create teams with random names.
# Instructors can call by clicking "Create temas" icon anc then click "Create teams" at the bottom.
def create_teams
Team.create_teams(session,params)
undo_link("Random teams have been successfully created.")
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'Random teams have been successfully created', request)
redirect_to action: 'list', id: parent.id
end

===signUps should be signups===
Existing code for the signUps nouns are modified to signups.

Existing code teams_controller.rb

def delete
# delete records in team, teams_users, signed_up_teams table
@team = Team.find_by(id: params[:id])
unless @team.nil?
course = Object.const_get(session[:team_type]).find(@team.parent_id)
@signed_up_team = SignedUpTeam.where(team_id: @team.id)
@teams_users = TeamsUser.where(team_id: @team.id)

SignedUpTeam.assign_topic_to_first_in_waitlist_post_team_deletion(@signed_up_team, @signUps)

@sign_up_team.destroy_all if @sign_up_team
@teams_users.destroy_all if @teams_users
@team.destroy if @team
undo_link("The team \"#{@team.name}\" has been successfully deleted.")
end
redirect_to :back
end

Modified code in teams_controller.rb

def delete
# delete records in team, teams_users, signed_up_teams table
@team = Team.find_by(id: params[:id])
unless @team.nil?
course = Object.const_get(session[:team_type]).find(@team.parent_id)
@signed_up_team = SignedUpTeam.where(team_id: @team.id)
@teams_users = TeamsUser.where(team_id: @team.id)

SignedUpTeam.assign_topic_to_first_in_waitlist_post_team_deletion(@signed_up_team, @signups)

@sign_up_team.destroy_all if @sign_up_team
@teams_users.destroy_all if @teams_users
@team.destroy if @team
undo_link("The team \"#{@team.name}\" has been successfully deleted.")
end
redirect_to :back
end

Existing code signed_up_team.rb

def self.assign_topic_to_first_in_waitlist_post_team_deletion (signed_up_team, signUps)
if signed_up_team == 1 && !signups.first.is_waitlisted # this team hold a topic
# if there is another team in waitlist, make this team hold this topic
topic_id = signed_up_team.first.topic_id
next_wait_listed_team = SignedUpTeam.where(topic_id: topic_id, is_waitlisted: true).first
# if slot exist, then confirm the topic for this team and delete all waitlists for this team
SignUpTopic.assign_to_first_waiting_team(next_wait_listed_team) if next_wait_listed_team
end
end

Modified code in signed_up_team.rb

def self.assign_topic_to_first_in_waitlist_post_team_deletion (signed_up_team, signups)
if signed_up_team == 1 && !signups.first.is_waitlisted # this team hold a topic
# if there is another team in waitlist, make this team hold this topic
topic_id = signed_up_team.first.topic_id
next_wait_listed_team = SignedUpTeam.where(topic_id: topic_id, is_waitlisted: true).first
# if slot exist, then confirm the topic for this team and delete all waitlists for this team
SignUpTopic.assign_to_first_waiting_team(next_wait_listed_team) if next_wait_listed_team
end
end

== Testing the Teams_Controller ==

=== Instructions for testing Rspecs ===

1. git clone https://github.com/bhaskarsinha1311/expertiza.git

2. Change to the expertiza directory and then perform "bundle install" and rake db:migrate.

3. Start the rails server

4. In a new terminal and in the expertiza directory, perform the following commands:
i. rspec spec/controllers/teams_controller_spec.rb
ii. rspec spec/features/inherit_teams_display_spec.rb
iii. rspec spec/features/list_teams_spec.rb

The results to the above commands can be found [https://www.youtube.com/watch?v=CcSruLHQoeU/ here].

===Testing Inherit Method===

To test that while creating an assignment team, the inherit teams section should be displayed, we log in as instructor got to list page and click on Create Team Link. On this page, we test that it should contain the string 'Inherit Teams From Course'.
To do this test manually, user need lo log in as an Instructor and navigate to assignments page for any course. There the user can click on 'Create Teams' icon and will be redirected to the Create teams page for an assignment, there the user can check for the 'inherit teams' button in the view, ideally, it should be there.

it 'should display inherit teams while creating an assignment team' do
create(:assignment)
create(:assignment_node)
create(:assignment_team)
login_as("instructor6")
visit '/teams/list?id=1&type=Assignment'
click_link 'Create Team'
expect(page).to have_content('Inherit Teams From Course')
end

To test that while creating a course team, the inherit teams section should not be displayed, we do same steps in the previous case but finally, we test that the page does NOT contain 'Inherit Teams from Course'.
To do this test manually, user need lo log in as an Instructor and navigate to courses page. There the user can click on 'Create Teams' icon and will be redirected to 'create team' page, ideally, the 'Inherit Teams' button should not be displayed.

it 'should not display inherit teams while creating a course team' do
create(:course)
create(:course_node)
create(:course_team)
login_as("instructor6")
visit '/teams/list?id=1&type=Course'
click_link 'Create Team'
expect(page).to have_no_content('Inherit Teams From Course')
end

Similarly, for creating a team for an assignment without a course, we test that the page does not contain 'Inherit Teams From Course'. For this particular test case, we added a new factory object defined as an assignment with the course set to nil.
This can not be tested manually because assignment cannot be created without a course parent.

it 'should not display inherit teams while creating team for an assignment without a course' do
create(:assignment_without_course)
create(:assignment_without_course_node)
create(:assignment_without_course_team)
login_as("instructor6")
visit '/teams/list?id=1&type=Assignment'
click_link 'Create Team'
expect(page).to have_no_content('Inherit Teams From Course')
end

===Testing Create Method===

This test checks that after creating an assignment team the count in the teams table increase by 1.
This test cannot be performed manually as it is testing the count of a database table.
But, the user can check this functionality online by logging in as an instructor, going to the assignment page of any course and clicking on 'create teams' icon. Following up with entering the required details and clicking on 'create team'.

describe "POST #create" do
context "with an assignment team" do
it "increases count by 1" do
expect{create :assignment_team, assignment: @assignment}.to change(Team,:count).by(1)
end
it "redirects to the list page" do
end
end
end

The same test an be applied to create a course team as well.

context "with a course team" do
it "increases the count by 1" do
expect{create :course_team, course: @course}.to change(Team,:count).by(1)
end
end

===Testing Delete Method===

The delete method should work for deleting both assignment and course teams. We check this functionality by deleting the respective team and then check if the count of Teams goes down by 1.
The user can check this test manually by logging in as an instructor navigating to the page of any team for an assignment and clicking on 'Delete Team' icon.

context "with an assignment team " do
it "deletes an assignment team" do
@assignment = create(:assignment)
@a_team = create(:assignment_team)
expect{ @a_team.delete }.to change(Team, :count).by(-1)
end
end

Same Delete test has been applied to the course team
The manual check can also be performed in a similar way by logging in as an instructor navigating to the page of any team for an assignment and clicking on 'Delete Team' icon.

context "with a course team " do
it "deletes a course team" do
@course = create(:course)
@c_team = create(:course_team)
expect{ @c_team.delete }.to change(Team, :count).by(-1)
end
end

===Testing List Method===

The list method lists all the team nodes. This test that we have written, checks whether the instructor is able to view the team nodes in the list view.
To do this test manually user can log into the system as an instructor and click on any course, the course teams will be displayed. Also, the user can click on any team node to view information about that team.

describe 'List Team' do

it 'should list all team nodes' do
create(:assignment)
create(:assignment_node)
assignment_team = create(:assignment_team)
team_user = create(:team_user)
login_as("instructor6")
visit '/teams/list?id=1&type=Assignment'
page.all('#theTable tr').each do |tr|
expect(tr).to have_content?(assignment_team.name)
end
end
end

==References==

* [https://github.com/bhaskarsinha1311/expertiza/ Github] link to the project.
* [https://docs.google.com/document/d/1TFC0G3zW-xkJYuloh_BmvWnj3dGZB23GOIYuikNRf_I/edit Link] to the project description.
* [https://www.youtube.com/watch?v=CcSruLHQoeU/ Youtube video of tests]

CSC/ECE 517 Fall 2021

2021-10-20T20:28:41Z

Akuchib:

== 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]]
* [[CSC/ECE 517 Fall 2021 - E2131. Improve assessment360_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2121. Refactor suggestion_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2122. Refactor impersonate_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2126. Refactor account_request_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2124. Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2125. Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Fall 2021 - E2127. Refactor teams_controller]]
* [[CSC/ECE 517 Fall 2021 - E2130. Refactor submitted_content_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2141. OSS project Finklestein: Instructors & Institutions]]
* [[CSC/ECE 517 Fall 2021 - E2147. Role-based reviewing]]

CSC/ECE 517 Fall 2021

2021-10-20T20:25:07Z

Akuchib: /* OSS Projects */

== 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]]
* [[CSC/ECE 517 Fall 2021 - E2131. Improve assessment360_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2121. Refactor suggestion_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2122. Refactor impersonate_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2126. Refactor account_request_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2124. Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2125. Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Fall 2021 - E2127. Refactor teams_controller]]
* [[CSC/ECE 517 Fall 2021 - E2127. Refactor submitted_content_controller.rb]]
* [[CSC/ECE 517 Fall 2021 - E2141. OSS project Finklestein: Instructors & Institutions]]
* [[CSC/ECE 517 Fall 2021 - E2147. Role-based reviewing]]