Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-06T03:26:27Z

Jkini: /* Testing */

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Divyang Doshi (ddoshi2)

=== Team Members ===
* Vijaya Durga Kona (vkona)
* Anand Morlaw (asmorlaw)
* Varun Garg (vgarg4)
* Jagdish Kini (jkini)

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

=== What needs to be done ===
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Design =
== Problems and planned changes (need to change the content) ==

=== Problem 1: Review_bids_others_work is a DRY violation ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 2: Run_bidding algorithm should be assign_reviewers ===
In this issue, <code>Run_bidding_algorithm</code> algorithm should be assigned a new name which is <code>assign_reviewers</code>.

*''' Proposed Solution ''': <code>Run_bidding_algorithm</code> will be refactored to a new name which is <code>assign_reviewers</code>. Accordingly, we will have to refractor this on the calling side too.

=== Problem 3: Currently it doesn't work if some student does not bid. In this case, the algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': We will work on refactoring the <code>get_data_for_review_report</code> to use partial inputs.

=== Problem 4: Figure out why running the bidding algorithm only works on assignments with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===
So this is an open-ended issue. Currently, the bidding algorithm only works on assignments with the team. Currently, if the assignment does not have a team then no project gets assigned to the user until a team is formed. Yes, we can tweak the code so that an individual user gets assigned a project, but it won't make much sense as this is supposed to be a group project and there will be limited topics for the same. If the algorithm will go on assigning projects to individual users also then the pool will get exhausted.

=== Problem 5: Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===
For this issue we need to include a count which contains the count of the number of students/teams who have made their bids.

*''' Proposed Solution ''': For this we would include a count in the method <code>assign_bidding</code> of controller <code>review_bids_controller.rb</code>. This attribute will help us to keep track of the number of students bidding for reviews. We will increment this count whenever a team or a student bids for a particular review and decrement it if all the bids are removed by any team. This count will be stored in DB and shown to the users in the view page.

=== Problem 6: Ability to allow the algorithm to run again after running once. ===
Bidding algorithm is allowed to run only once in the TOPICS webpage in the process of managing Assignments. The button <code>Run Review Algorithm</code> is enabled only when the parameter of the assignment <code>can_choose_topic_to_review</code> is true.

*''' Proposed Solution ''': Dependency on <code>can_choose_topic_to_review</code> attribute will be removed for the visibility of the button <code>Run Review Algorithm</code>

=== Problem 7: Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===
The methods in rebiew_bid.rb are to get bidding data, to assign review topics, assign topic to reviewer and for getting individual reviewer_ids bidding data. These all are class methods. If we convert these to the instance methods, then we will have to create an object and then call these methods. So we will have to go through the flow to check whether it fits perfectly. If we are not able to convert these to instance methods, then a better approach would be to move these functions to a helper function.

=== Problem 8: In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 9: Test whether the topic changes color depending on the number of outstanding bids ===
<code>get_topic_bg_color_review_bids</code> in <code>review_bids_helper.rb</code> and <code>review_bids_show.html.erb</code> are responsible for the color changes based on the number of participants and bid size.
*''' Proposed Solution ''': A new test case will be added in <code>review_bids_helper_spec.rb</code> for this case that test the changes in background color based on the number of participants and outstanding size.

= Diagram =
'''Author's View''' : The flow for authors to email reviewers regarding the work they have been reviewed for:

[[File:E2231-1.png|500px]] 

= Testing =
; RSpec
The main task here of testing is to make sure no functionality is breaking because of the refractoring.

* If we decide to move the code of review_bid.rb to a helper as discussed as a possible approach for problem 7, then we will have to add some additional test cases to make sure the functionality is still working as necessary.

; Physical Testing

We will have to run the project and check for all possible functionality that might get affected because of the refactoring done.
:
=== Edge Cases and Pre-Conditions ===

:

= Reference =
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/expertiza/expertiza Expertiza on GitHub]

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-06T03:26:17Z

Jkini: /* Testing */

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-06T03:25:58Z

Jkini: /* Testing (need to change the content) */

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Divyang Doshi (ddoshi2)

=== Team Members ===
* Vijaya Durga Kona (vkona)
* Anand Morlaw (asmorlaw)
* Varun Garg (vgarg4)
* Jagdish Kini (jkini)

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

=== What needs to be done ===
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Design =
== Problems and planned changes (need to change the content) ==

=== Problem 1: Review_bids_others_work is a DRY violation ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 2: Run_bidding algorithm should be assign_reviewers ===
In this issue, <code>Run_bidding_algorithm</code> algorithm should be assigned a new name which is <code>assign_reviewers</code>.

*''' Proposed Solution ''': <code>Run_bidding_algorithm</code> will be refactored to a new name which is <code>assign_reviewers</code>. Accordingly, we will have to refractor this on the calling side too.

=== Problem 3: Currently it doesn't work if some student does not bid. In this case, the algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': We will work on refactoring the <code>get_data_for_review_report</code> to use partial inputs.

=== Problem 4: Figure out why running the bidding algorithm only works on assignments with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===
So this is an open-ended issue. Currently, the bidding algorithm only works on assignments with the team. Currently, if the assignment does not have a team then no project gets assigned to the user until a team is formed. Yes, we can tweak the code so that an individual user gets assigned a project, but it won't make much sense as this is supposed to be a group project and there will be limited topics for the same. If the algorithm will go on assigning projects to individual users also then the pool will get exhausted.

=== Problem 5: Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===
For this issue we need to include a count which contains the count of the number of students/teams who have made their bids.

*''' Proposed Solution ''': For this we would include a count in the method <code>assign_bidding</code> of controller <code>review_bids_controller.rb</code>. This attribute will help us to keep track of the number of students bidding for reviews. We will increment this count whenever a team or a student bids for a particular review and decrement it if all the bids are removed by any team. This count will be stored in DB and shown to the users in the view page.

=== Problem 6: Ability to allow the algorithm to run again after running once. ===
Bidding algorithm is allowed to run only once in the TOPICS webpage in the process of managing Assignments. The button <code>Run Review Algorithm</code> is enabled only when the parameter of the assignment <code>can_choose_topic_to_review</code> is true.

*''' Proposed Solution ''': Dependency on <code>can_choose_topic_to_review</code> attribute will be removed for the visibility of the button <code>Run Review Algorithm</code>

=== Problem 7: Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===
The methods in rebiew_bid.rb are to get bidding data, to assign review topics, assign topic to reviewer and for getting individual reviewer_ids bidding data. These all are class methods. If we convert these to the instance methods, then we will have to create an object and then call these methods. So we will have to go through the flow to check whether it fits perfectly. If we are not able to convert these to instance methods, then a better approach would be to move these functions to a helper function.

=== Problem 8: In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 9: Test whether the topic changes color depending on the number of outstanding bids ===
<code>get_topic_bg_color_review_bids</code> in <code>review_bids_helper.rb</code> and <code>review_bids_show.html.erb</code> are responsible for the color changes based on the number of participants and bid size.
*''' Proposed Solution ''': A new test case will be added in <code>review_bids_helper_spec.rb</code> for this case that test the changes in background color based on the number of participants and outstanding size.

= Diagram =
'''Author's View''' : The flow for authors to email reviewers regarding the work they have been reviewed for:

[[File:E2231-1.png|500px]] 

= Testing =
; RSpec
The main task here of testing is to make sure no functionality is breaking because of the refractoring.
If we decide to move the code of review_bid.rb to a helper as discussed as a possible approach for problem 7, then we will have to add some additional test cases to make sure the functionality is still working as necessary.

; Physical Testing

We will have to run the project and check for all possible functionality that might get affected because of the refactoring done.
:
=== Edge Cases and Pre-Conditions ===

:

= Reference =
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/expertiza/expertiza Expertiza on GitHub]

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-06T03:21:55Z

Jkini: /* Problem 7: Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? */

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Divyang Doshi (ddoshi2)

=== Team Members ===
* Vijaya Durga Kona (vkona)
* Anand Morlaw (asmorlaw)
* Varun Garg (vgarg4)
* Jagdish Kini (jkini)

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

=== What needs to be done ===
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Design =
== Problems and planned changes (need to change the content) ==

=== Problem 1: Review_bids_others_work is a DRY violation ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 2: Run_bidding algorithm should be assign_reviewers ===
In this issue, <code>Run_bidding_algorithm</code> algorithm should be assigned a new name which is <code>assign_reviewers</code>.

*''' Proposed Solution ''': <code>Run_bidding_algorithm</code> will be refactored to a new name which is <code>assign_reviewers</code>. Accordingly, we will have to refractor this on the calling side too.

=== Problem 3: Currently it doesn't work if some student does not bid. In this case, the algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': We will work on refactoring the <code>get_data_for_review_report</code> to use partial inputs.

=== Problem 4: Figure out why running the bidding algorithm only works on assignments with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===
So this is an open-ended issue. Currently, the bidding algorithm only works on assignments with the team. Currently, if the assignment does not have a team then no project gets assigned to the user until a team is formed. Yes, we can tweak the code so that an individual user gets assigned a project, but it won't make much sense as this is supposed to be a group project and there will be limited topics for the same. If the algorithm will go on assigning projects to individual users also then the pool will get exhausted.

=== Problem 5: Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===
For this issue we need to include a count which contains the count of the number of students/teams who have made their bids.

*''' Proposed Solution ''': For this we would include a count in the method <code>assign_bidding</code> of controller <code>review_bids_controller.rb</code>. This attribute will help us to keep track of the number of students bidding for reviews. We will increment this count whenever a team or a student bids for a particular review and decrement it if all the bids are removed by any team. This count will be stored in DB and shown to the users in the view page.

=== Problem 6: Ability to allow the algorithm to run again after running once. ===
Bidding algorithm is allowed to run only once in the TOPICS webpage in the process of managing Assignments. The button <code>Run Review Algorithm</code> is enabled only when the parameter of the assignment <code>can_choose_topic_to_review</code> is true.

*''' Proposed Solution ''': Dependency on <code>can_choose_topic_to_review</code> attribute will be removed for the visibility of the button <code>Run Review Algorithm</code>

=== Problem 7: Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===
The methods in rebiew_bid.rb are to get bidding data, to assign review topics, assign topic to reviewer and for getting individual reviewer_ids bidding data. These all are class methods. If we convert these to the instance methods, then we will have to create an object and then call these methods. So we will have to go through the flow to check whether it fits perfectly. If we are not able to convert these to instance methods, then a better approach would be to move these functions to a helper function.

=== Problem 8: In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 9: Test whether the topic changes color depending on the number of outstanding bids ===
<code>get_topic_bg_color_review_bids</code> in <code>review_bids_helper.rb</code> and <code>review_bids_show.html.erb</code> are responsible for the color changes based on the number of participants and bid size.
*''' Proposed Solution ''': A new test case will be added in <code>review_bids_helper_spec.rb</code> for this case that test the changes in background color based on the number of participants and outstanding size.

= Diagram =
'''Author's View''' : The flow for authors to email reviewers regarding the work they have been reviewed for:

[[File:E2231-1.png|500px]] 

= Testing (need to change the content) =
; RSpec
: As such no functionality changed in any function, only refactoring done. All the refactoring was carefully verified by running rspec tests. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb

; Physical Testing

We found that add_signup_topics_staggered was simply calling add_signup_topics function. So we eliminated the add_signup_topics_staggered function and manually checked and found that it is working perfectly fine.

Delete signup and delete signup as instructor method successfully broken down to remove the dry code by creating a new helper function. This functionality has not been broken due to any changes and has been checked by running rspec and testing manually.
:
=== Edge Cases and Pre-Conditions ===
# When dropping topic if submission already done.
# When deadline from dropping topic has passed.
# Deleting topic when topic cannot be found.
# Signup in case when user cannot be found.
:
= Reference =
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/expertiza/expertiza Expertiza on GitHub]

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-06T03:00:26Z

Jkini: /* Problem 4: Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? */

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Divyang Doshi (ddoshi2)

=== Team Members ===
* Vijaya Durga Kona (vkona)
* Anand Morlaw (asmorlaw)
* Varun Garg (vgarg4)
* Jagdish Kini (jkini)

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

=== What needs to be done ===
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Design =
== Problems and planned changes (need to change the content) ==

=== Problem 1: Review_bids_others_work is a DRY violation ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 2: Run_bidding algorithm should be assign_reviewers ===
In this issue, <code>Run_bidding_algorithm</code> algorithm should be assigned a new name which is <code>assign_reviewers</code>.

*''' Proposed Solution ''': <code>Run_bidding_algorithm</code> will be refactored to a new name which is <code>assign_reviewers</code>. Accordingly, we will have to refractor this on the calling side too.

=== Problem 3: Currently it doesn't work if some student does not bid. In this case, the algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 4: Figure out why running the bidding algorithm only works on assignments with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===
So this is an open-ended issue. Currently, the bidding algorithm only works on assignments with the team. Currently, if the assignment does not have a team then no project gets assigned to the user until a team is formed. Yes, we can tweak the code so that an individual user gets assigned a project, but it won't make much sense as this is supposed to be a group project and there will be limited topics for the same. If the algorithm will go on assigning projects to individual users also then the pool will get exhausted.

=== Problem 5: Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 6: Ability to allow the algorithm to run again after running once. ===
Bidding algorithm is allowed to run only once in the TOPICS webpage in the process of managing Assignments. The button <code>Run Review Algorithm</code> is enabled only when the parameter of the assignment <code>can_choose_topic_to_review</code> is true.

*''' Proposed Solution ''': Dependency on <code>can_choose_topic_to_review</code> attribute will be removed for the visibility of the button <code>Run Review Algorithm</code>

=== Problem 7: Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 8: In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 9: Test whether the topic changes color depending on the number of outstanding bids ===
<code>get_topic_bg_color_review_bids</code> in <code>review_bids_helper.rb</code> and <code>review_bids_show.html.erb</code> are responsible for the color changes based on the number of participants and bid size.
*''' Proposed Solution ''': A new test case will be added in <code>review_bids_helper_spec.rb</code> for this case that test the changes in background color based on the number of participants and outstanding size.

= Diagram =
'''Author's View''' : The flow for authors to email reviewers regarding the work they have been reviewed for:

[[File:E2231-1.png|500px]] 

= Testing (need to change the content) =
; RSpec
: As such no functionality changed in any function, only refactoring done. All the refactoring was carefully verified by running rspec tests. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb

; Physical Testing

We found that add_signup_topics_staggered was simply calling add_signup_topics function. So we eliminated the add_signup_topics_staggered function and manually checked and found that it is working perfectly fine.

Delete signup and delete signup as instructor method successfully broken down to remove the dry code by creating a new helper function. This functionality has not been broken due to any changes and has been checked by running rspec and testing manually.
:
=== Edge Cases and Pre-Conditions ===
# When dropping topic if submission already done.
# When deadline from dropping topic has passed.
# Deleting topic when topic cannot be found.
# Signup in case when user cannot be found.
:
= Reference =
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/expertiza/expertiza Expertiza on GitHub]

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-06T02:43:56Z

Jkini: /* Problem 2: Run_bidding algorithm should be assign_reviewers */

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Divyang Doshi (ddoshi2)

=== Team Members ===
* Vijaya Durga Kona (vkona)
* Anand Morlaw (asmorlaw)
* Varun Garg (vgarg4)
* Jagdish Kini (jkini)

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

=== What needs to be done ===
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Design =
== Problems and planned changes (need to change the content) ==

=== Problem 1: Review_bids_others_work is a DRY violation ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 2: Run_bidding algorithm should be assign_reviewers ===
In this issue, <code>Run_bidding_algorithm</code> algorithm should be assigned a new name which is <code>assign_reviewers</code>.

*''' Proposed Solution ''': <code>Run_bidding_algorithm</code> will be refactored to a new name which is <code>assign_reviewers</code>. Accordingly, we will have to refractor this on the calling side too.

=== Problem 3: Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 4: Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 5: Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 6: Ability to allow the algorithm to run again after running once. ===
Bidding algorithm is allowed to run only once in the TOPICS webpage in the process of managing Assignments. The button <code>Run Review Algorithm</code> is enabled only when the parameter of the assignment <code>can_choose_topic_to_review</code> is true.

*''' Proposed Solution ''': Dependency on <code>can_choose_topic_to_review</code> attribute will be removed for the visibility of the button <code>Run Review Algorithm</code>

=== Problem 7: Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 8: In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 9: Test whether the topic changes color depending on the number of outstanding bids ===
<code>get_topic_bg_color_review_bids</code> in <code>review_bids_helper.rb</code> and <code>review_bids_show.html.erb</code> are responsible for the color changes based on the number of participants and bid size.
*''' Proposed Solution ''': A new test case will be added in <code>review_bids_helper_spec.rb</code> for this case that test the changes in background color based on the number of participants and outstanding size.

= Diagram =
'''Author's View''' : The flow for authors to email reviewers regarding the work they have been reviewed for:

[[File:E2231-1.png|500px]] 

= Testing (need to change the content) =
; RSpec
: As such no functionality changed in any function, only refactoring done. All the refactoring was carefully verified by running rspec tests. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb

; Physical Testing

We found that add_signup_topics_staggered was simply calling add_signup_topics function. So we eliminated the add_signup_topics_staggered function and manually checked and found that it is working perfectly fine.

Delete signup and delete signup as instructor method successfully broken down to remove the dry code by creating a new helper function. This functionality has not been broken due to any changes and has been checked by running rspec and testing manually.
:
=== Edge Cases and Pre-Conditions ===
# When dropping topic if submission already done.
# When deadline from dropping topic has passed.
# Deleting topic when topic cannot be found.
# Signup in case when user cannot be found.
:
= Reference =
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/expertiza/expertiza Expertiza on GitHub]

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-06T02:30:45Z

Jkini: /* Problem 2: Run_bidding algorithm should be assign_reviewers */

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Divyang Doshi (ddoshi2)

=== Team Members ===
* Vijaya Durga Kona (vkona)
* Anand Morlaw (asmorlaw)
* Varun Garg (vgarg4)
* Jagdish Kini (jkini)

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

=== What needs to be done ===
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Design =
== Problems and planned changes (need to change the content) ==

=== Problem 1: Review_bids_others_work is a DRY violation ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 2: Run_bidding algorithm should be assign_reviewers ===
In this issue, <code>Run_bidding_algorithm</code> algorithm should be assigned a new name which is assign_reviewers.

*''' Proposed Solution ''': <code>Run_bidding_algorithm</code> will be refactored to a new name which is assign_reviewers. Accordingly, we will have to refractor this on the calling side too.

=== Problem 3: Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 4: Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 5: Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 6: Ability to allow the algorithm to run again after running once. ===
Bidding algorithm is allowed to run only once in the TOPICS webpage in the process of managing Assignments. The button <code>Run Review Algorithm</code> is enabled only when the parameter of the assignment <code>can_choose_topic_to_review</code> is true.

*''' Proposed Solution ''': Removes the dependency on <code>can_choose_topic_to_review</code> attribute for the visibility of the button <code>Run Review Algorithm</code>

=== Problem 7: Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 8: In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 9: Test whether the topic changes color depending on the number of outstanding bids ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

= Diagram =
'''Author's View''' : The flow for authors to email reviewers regarding the work they have been reviewed for:

[[File:E2231-1.png|500px]] 

= Testing (need to change the content) =
; RSpec
: As such no functionality changed in any function, only refactoring done. All the refactoring was carefully verified by running rspec tests. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb

; Physical Testing

We found that add_signup_topics_staggered was simply calling add_signup_topics function. So we eliminated the add_signup_topics_staggered function and manually checked and found that it is working perfectly fine.

Delete signup and delete signup as instructor method successfully broken down to remove the dry code by creating a new helper function. This functionality has not been broken due to any changes and has been checked by running rspec and testing manually.
:
=== Edge Cases and Pre-Conditions ===
# When dropping topic if submission already done.
# When deadline from dropping topic has passed.
# Deleting topic when topic cannot be found.
# Signup in case when user cannot be found.
:
= Reference =
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/expertiza/expertiza Expertiza on GitHub]

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-06T01:53:46Z

Jkini: /* Problem 2: Run_bidding algorithm should be assign_reviewers */

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Divyang Doshi (ddoshi2)

=== Team Members ===
* Vijaya Durga Kona (vkona)
* Anand Morlaw (asmorlaw)
* Varun Garg (vgarg4)
* Jagdish Kini (jkini)

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

=== What needs to be done ===
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Design =
== Problems and planned changes (need to change the content) ==

=== Problem 1: Review_bids_others_work is a DRY violation ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 2: Run_bidding algorithm should be assign_reviewers ===
In this issue, <code>Run_bidding</code> algorithm should be assigned a new name which is assign_reviewers.

*''' Proposed Solution ''': <code>Run_bidding</code> will be refactored to a new name which is assign_reviewers. Accordingly, we will have to refractor this on the calling side too.

=== Problem 3: Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 4: Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 5: Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 6: Ability to allow the algorithm to run again after running once. ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 7: Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 8: In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 9: Test whether the topic changes color depending on the number of outstanding bids ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

= Diagram =
'''Author's View''' : The flow for authors to email reviewers regarding the work they have been reviewed for:

[[File:E2231-1.png|500px]] 

= Testing (need to change the content) =
; RSpec
: As such no functionality changed in any function, only refactoring done. All the refactoring was carefully verified by running rspec tests. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb

; Physical Testing

We found that add_signup_topics_staggered was simply calling add_signup_topics function. So we eliminated the add_signup_topics_staggered function and manually checked and found that it is working perfectly fine.

Delete signup and delete signup as instructor method successfully broken down to remove the dry code by creating a new helper function. This functionality has not been broken due to any changes and has been checked by running rspec and testing manually.
:
=== Edge Cases and Pre-Conditions ===
# When dropping topic if submission already done.
# When deadline from dropping topic has passed.
# Deleting topic when topic cannot be found.
# Signup in case when user cannot be found.
:
= Reference =
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/expertiza/expertiza Expertiza on GitHub]

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-06T01:21:20Z

Jkini: /* Diagram */

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Divyang Doshi (ddoshi2)

=== Team Members ===
* Vijaya Durga Kona (vkona)
* Anand Morlaw (asmorlaw)
* Varun Garg (vgarg4)
* Jagdish Kini (jkini)

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

=== What needs to be done ===
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Design =
== Problems and planned changes (need to change the content) ==

=== Problem 1: Review_bids_others_work is a DRY violation ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 2: Run_bidding algorithm should be assign_reviewers ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 3: Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 4: Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 5: Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 6: Ability to allow the algorithm to run again after running once. ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 7: Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 8: In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 9: Test whether the topic changes color depending on the number of outstanding bids ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

= Diagram =
'''Author's View''' : The flow for authors to email reviewers regarding the work they have been reviewed for:

[[File:E2231-1.png|500px]] 

= Testing (need to change the content) =
; RSpec
: As such no functionality changed in any function, only refactoring done. All the refactoring was carefully verified by running rspec tests. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb

; Physical Testing

We found that add_signup_topics_staggered was simply calling add_signup_topics function. So we eliminated the add_signup_topics_staggered function and manually checked and found that it is working perfectly fine.

Delete signup and delete signup as instructor method successfully broken down to remove the dry code by creating a new helper function. This functionality has not been broken due to any changes and has been checked by running rspec and testing manually.
:
=== Edge Cases and Pre-Conditions ===
# When dropping topic if submission already done.
# When deadline from dropping topic has passed.
# Deleting topic when topic cannot be found.
# Signup in case when user cannot be found.
:
= Reference =
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/expertiza/expertiza Expertiza on GitHub]

File:E2231-1.png

2022-04-06T01:21:05Z

Jkini:

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-06T01:17:56Z

Jkini: /* Diagram */

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Divyang Doshi (ddoshi2)

=== Team Members ===
* Vijaya Durga Kona (vkona)
* Anand Morlaw (asmorlaw)
* Varun Garg (vgarg4)
* Jagdish Kini (jkini)

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

=== What needs to be done ===
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Design =
== Problems and planned changes (need to change the content) ==

=== Problem 1: Review_bids_others_work is a DRY violation ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 2: Run_bidding algorithm should be assign_reviewers ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 3: Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 4: Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 5: Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 6: Ability to allow the algorithm to run again after running once. ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 7: Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 8: In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 9: Test whether the topic changes color depending on the number of outstanding bids ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

= Diagram =
'''Author's View''' : The flow for authors to email reviewers regarding the work they have been reviewed for:

[[File:E2231.jpg|500px]] 

= Testing (need to change the content) =
; RSpec
: As such no functionality changed in any function, only refactoring done. All the refactoring was carefully verified by running rspec tests. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb

; Physical Testing

We found that add_signup_topics_staggered was simply calling add_signup_topics function. So we eliminated the add_signup_topics_staggered function and manually checked and found that it is working perfectly fine.

Delete signup and delete signup as instructor method successfully broken down to remove the dry code by creating a new helper function. This functionality has not been broken due to any changes and has been checked by running rspec and testing manually.
:
=== Edge Cases and Pre-Conditions ===
# When dropping topic if submission already done.
# When deadline from dropping topic has passed.
# Deleting topic when topic cannot be found.
# Signup in case when user cannot be found.
:
= Reference =
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/expertiza/expertiza Expertiza on GitHub]

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-06T01:17:44Z

Jkini: /* Diagram */

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Divyang Doshi (ddoshi2)

=== Team Members ===
* Vijaya Durga Kona (vkona)
* Anand Morlaw (asmorlaw)
* Varun Garg (vgarg4)
* Jagdish Kini (jkini)

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

=== What needs to be done ===
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Design =
== Problems and planned changes (need to change the content) ==

=== Problem 1: Review_bids_others_work is a DRY violation ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 2: Run_bidding algorithm should be assign_reviewers ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 3: Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 4: Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 5: Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 6: Ability to allow the algorithm to run again after running once. ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 7: Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 8: In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 9: Test whether the topic changes color depending on the number of outstanding bids ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

= Diagram =
'''Author's View''' : The flow for authors to email reviewers regarding the work they have been reviewed for:

[[File:E2231.jpg|800px]] 

= Testing (need to change the content) =
; RSpec
: As such no functionality changed in any function, only refactoring done. All the refactoring was carefully verified by running rspec tests. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb

; Physical Testing

We found that add_signup_topics_staggered was simply calling add_signup_topics function. So we eliminated the add_signup_topics_staggered function and manually checked and found that it is working perfectly fine.

Delete signup and delete signup as instructor method successfully broken down to remove the dry code by creating a new helper function. This functionality has not been broken due to any changes and has been checked by running rspec and testing manually.
:
=== Edge Cases and Pre-Conditions ===
# When dropping topic if submission already done.
# When deadline from dropping topic has passed.
# Deleting topic when topic cannot be found.
# Signup in case when user cannot be found.
:
= Reference =
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/expertiza/expertiza Expertiza on GitHub]

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-06T01:17:31Z

Jkini: /* Diagram */

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Divyang Doshi (ddoshi2)

=== Team Members ===
* Vijaya Durga Kona (vkona)
* Anand Morlaw (asmorlaw)
* Varun Garg (vgarg4)
* Jagdish Kini (jkini)

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

=== What needs to be done ===
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Design =
== Problems and planned changes (need to change the content) ==

=== Problem 1: Review_bids_others_work is a DRY violation ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 2: Run_bidding algorithm should be assign_reviewers ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 3: Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 4: Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 5: Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 6: Ability to allow the algorithm to run again after running once. ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 7: Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 8: In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 9: Test whether the topic changes color depending on the number of outstanding bids ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

= Diagram =
'''Author's View''' : The flow for authors to email reviewers regarding the work they have been reviewed for:

[[File:E2231.jpg|800px] 

= Testing (need to change the content) =
; RSpec
: As such no functionality changed in any function, only refactoring done. All the refactoring was carefully verified by running rspec tests. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb

; Physical Testing

We found that add_signup_topics_staggered was simply calling add_signup_topics function. So we eliminated the add_signup_topics_staggered function and manually checked and found that it is working perfectly fine.

Delete signup and delete signup as instructor method successfully broken down to remove the dry code by creating a new helper function. This functionality has not been broken due to any changes and has been checked by running rspec and testing manually.
:
=== Edge Cases and Pre-Conditions ===
# When dropping topic if submission already done.
# When deadline from dropping topic has passed.
# Deleting topic when topic cannot be found.
# Signup in case when user cannot be found.
:
= Reference =
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/expertiza/expertiza Expertiza on GitHub]

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-06T01:16:32Z

Jkini: /* Diagram */

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Divyang Doshi (ddoshi2)

=== Team Members ===
* Vijaya Durga Kona (vkona)
* Anand Morlaw (asmorlaw)
* Varun Garg (vgarg4)
* Jagdish Kini (jkini)

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

=== What needs to be done ===
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Design =
== Problems and planned changes (need to change the content) ==

=== Problem 1: Review_bids_others_work is a DRY violation ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 2: Run_bidding algorithm should be assign_reviewers ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 3: Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 4: Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 5: Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 6: Ability to allow the algorithm to run again after running once. ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 7: Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 8: In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 9: Test whether the topic changes color depending on the number of outstanding bids ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

= Diagram =
'''Author's View''' : The flow for authors to email reviewers regarding the work they have been reviewed for:

[[File:E2231.jpg] 

= Testing (need to change the content) =
; RSpec
: As such no functionality changed in any function, only refactoring done. All the refactoring was carefully verified by running rspec tests. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb

; Physical Testing

We found that add_signup_topics_staggered was simply calling add_signup_topics function. So we eliminated the add_signup_topics_staggered function and manually checked and found that it is working perfectly fine.

Delete signup and delete signup as instructor method successfully broken down to remove the dry code by creating a new helper function. This functionality has not been broken due to any changes and has been checked by running rspec and testing manually.
:
=== Edge Cases and Pre-Conditions ===
# When dropping topic if submission already done.
# When deadline from dropping topic has passed.
# Deleting topic when topic cannot be found.
# Signup in case when user cannot be found.
:
= Reference =
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/expertiza/expertiza Expertiza on GitHub]

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-06T01:16:17Z

Jkini: /* Diagram */

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
= Team =
=== Mentor ===
* Divyang Doshi (ddoshi2)

=== Team Members ===
* Vijaya Durga Kona (vkona)
* Anand Morlaw (asmorlaw)
* Varun Garg (vgarg4)
* Jagdish Kini (jkini)

= Introduction =
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Problem Statement =
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

=== What needs to be done ===
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Design =
== Problems and planned changes (need to change the content) ==

=== Problem 1: Review_bids_others_work is a DRY violation ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 2: Run_bidding algorithm should be assign_reviewers ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 3: Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 4: Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case? ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 5: Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 6: Ability to allow the algorithm to run again after running once. ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 7: Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers? ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 8: In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

=== Problem 9: Test whether the topic changes color depending on the number of outstanding bids ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

= Diagram =
'''Author's View''' : The flow for authors to email reviewers regarding the work they have been reviewed for:

[[File:E2231.jpg|1000px]] 

= Testing (need to change the content) =
; RSpec
: As such no functionality changed in any function, only refactoring done. All the refactoring was carefully verified by running rspec tests. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb

; Physical Testing

We found that add_signup_topics_staggered was simply calling add_signup_topics function. So we eliminated the add_signup_topics_staggered function and manually checked and found that it is working perfectly fine.

Delete signup and delete signup as instructor method successfully broken down to remove the dry code by creating a new helper function. This functionality has not been broken due to any changes and has been checked by running rspec and testing manually.
:
=== Edge Cases and Pre-Conditions ===
# When dropping topic if submission already done.
# When deadline from dropping topic has passed.
# Deleting topic when topic cannot be found.
# Signup in case when user cannot be found.
:
= Reference =
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/expertiza/expertiza Expertiza on GitHub]

File:E2231.jpg

2022-04-06T01:15:13Z

Jkini:

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-05T23:53:35Z

Jkini:

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-05T23:40:36Z

Jkini: /* What needs to be done(need to rephrase these points) */

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-05T23:39:50Z

Jkini:

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-05T23:37:41Z

Jkini:

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
== Team ==
=== Mentor ===
* Divyang Doshi (ddoshi2)

=== Team Members ===
* Vijaya Durga Kona (vkona)
* Anand Morlaw (asmorlaw)
* Varun Garg (vgarg4)
* Jagdish Kini (jkini)

== Introduction ==
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

== Problem Statement ==
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

=== What needs to be done(need to rephrase these points) ===
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

== Design ==
== Problems and planned changes (need to change the content) ==

=== Problem: The method get_data_for_review_report violates the Expert pattern ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

== Diagram ==

== Testing (need to change the content) ==
; RSpec
: As such no functionality changed in any function, only refactoring done. All the refactoring was carefully verified by running rspec tests. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb

; Physical Testing

We found that add_signup_topics_staggered was simply calling add_signup_topics function. So we eliminated the add_signup_topics_staggered function and manually checked and found that it is working perfectly fine.

Delete signup and delete signup as instructor method successfully broken down to remove the dry code by creating a new helper function. This functionality has not been broken due to any changes and has been checked by running rspec and testing manually.
:
=== Edge Cases and Pre-Conditions ===
# When dropping topic if submission already done.
# When deadline from dropping topic has passed.
# Deleting topic when topic cannot be found.
# Signup in case when user cannot be found.
:

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-05T23:36:25Z

Jkini: /* What needs to be done(need to rephrae these points) */

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
== Team ==
=== Mentor ===
* Divyang Doshi (ddoshi2)

=== Team Members ===
* Vijaya Durga Kona (vkona)
* Anand Morlaw (asmorlaw)
* Varun Garg (vgarg4)
* Jagdish Kini (jkini)

== Introduction ==
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

== Problem Statement ==
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

=== What needs to be done(need to rephrase these points) ===
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Design =
== Problems and planned changes (need to change the content) ==

=== Problem: The method get_data_for_review_report violates the Expert pattern ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

== Diagram ==

== Testing (need to change the content) ==
; RSpec
: As such no functionality changed in any function, only refactoring done. All the refactoring was carefully verified by running rspec tests. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb

; Physical Testing

We found that add_signup_topics_staggered was simply calling add_signup_topics function. So we eliminated the add_signup_topics_staggered function and manually checked and found that it is working perfectly fine.

Delete signup and delete signup as instructor method successfully broken down to remove the dry code by creating a new helper function. This functionality has not been broken due to any changes and has been checked by running rspec and testing manually.
:
=== Edge Cases and Pre-Conditions ===
# When dropping topic if submission already done.
# When deadline from dropping topic has passed.
# Deleting topic when topic cannot be found.
# Signup in case when user cannot be found.
:

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-05T23:36:09Z

Jkini:

This wiki page is for the information regarding the changes made for the E2231 OSS assignment for Spring 2022, CSC/ECE 517.
== Team ==
=== Mentor ===
* Divyang Doshi (ddoshi2)

=== Team Members ===
* Vijaya Durga Kona (vkona)
* Anand Morlaw (asmorlaw)
* Varun Garg (vgarg4)
* Jagdish Kini (jkini)

== Introduction ==
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

== Problem Statement ==
Assigning reviews to users is a complicated process. Currently, as per previous year’s implementation on Expertiza’s beta branch, reviews are assigned using the bidding algorithm. Although, the functionality works, but has some bugs which needs to be fixed before we can take it to production.

=== What needs to be done(need to rephrae these points) ===
* Review_bids_others_work is a DRY violation
* Run_bidding algorithm should be assign_reviewers
* Currently it doesn't work if some student does not bid. In this case, algorithm needs to be fixed in order to assign arbitrary reviews to anyone who didn’t bid
* Figure out why running the bidding algorithm only works on assignment with teams. What if the assignment does not have a team? Can we tweak the code to make it work in this case?
* Include a flag to say how many students have submitted their bids, when the students should submit the bid by to make the functionality more intuitive
* Ability to allow the algorithm to run again after running once.
* Why are the methods in review_bid.rb class methods? Can we change them to instance methods or move it to helpers?
* In the previous implementation wiki, there are edge cases which are not exhaustively tested. Should test those edge cases thoroughly and add more edge case testing
* Test whether the topic changes color depending on the number of outstanding bids

= Design =
== Problems and planned changes (need to change the content) ==

=== Problem: The method get_data_for_review_report violates the Expert pattern ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

== Diagram ==

== Testing (need to change the content) ==
; RSpec
: As such no functionality changed in any function, only refactoring done. All the refactoring was carefully verified by running rspec tests. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb

; Physical Testing

We found that add_signup_topics_staggered was simply calling add_signup_topics function. So we eliminated the add_signup_topics_staggered function and manually checked and found that it is working perfectly fine.

Delete signup and delete signup as instructor method successfully broken down to remove the dry code by creating a new helper function. This functionality has not been broken due to any changes and has been checked by running rspec and testing manually.
:
=== Edge Cases and Pre-Conditions ===
# When dropping topic if submission already done.
# When deadline from dropping topic has passed.
# Deleting topic when topic cannot be found.
# Signup in case when user cannot be found.
:

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-05T23:35:20Z

Jkini:

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-05T23:33:39Z

Jkini:

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-05T23:33:23Z

Jkini:

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-05T23:32:21Z

Jkini:

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-05T23:32:03Z

Jkini:

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-05T23:31:22Z

Jkini:

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-05T23:23:46Z

Jkini:

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-05T23:21:26Z

Jkini:

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-05T23:19:39Z

Jkini:

This wiki page is for the information regarding the changes made for the E2223 OSS assignment for Spring 2022, CSC/ECE 517.
== Team ==
=== Mentor ===
* Divyang Doshi (ddoshi2)

=== Team Members ===
* Vijaya Durga Kona (vkona)
* Anand Morlaw (asmorlaw)
* Varun Garg (vgarg4)
* Jagdish Kini (jkini)

== Introduction ==
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

= Design =
== Problems and planned changes ==

=== Problem: The method get_data_for_review_report violates the Expert pattern ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

== Solutions ==
1. Changed the name of the controller from sign_up_sheet_controller.rb --> signup_sheet_controller.rb. Also changed several method names that had 'sign_up' being used as an adjective or a noun to 'signup'.

https://github.com/palvitgarg99/expertiza/commit/9e99f56c9f8051fa5ee6b6a4bdf3659ec50852dc
https://github.com/palvitgarg99/expertiza/commit/66fc8bc5fc3850639306ad2be79afaa3de1fad70

2. The requirement that deadlines be submitted is no longer implemented and therefore a separate function for "staggered" is no longer needed.

https://github.com/palvitgarg99/expertiza/commit/db12bf9c05831576183363b6bfe68bbad64e9c5a

3. Renaming function ad_info

https://github.com/palvitgarg99/expertiza/commit/6507f15f6d23f44900465536a91cc6c80f90ad75

4. Remove signup_as_instructor, since its not being used anywhere as such.

https://github.com/palvitgarg99/expertiza/commit/e92e704f5cb6c549d440784339bcce6eba408a6b

5. The list method is broken into 2 functions. The small part of computing signup topics is created. Also comments has been added to understand the function better.

https://github.com/palvitgarg99/expertiza/commit/4b7bb6113dfb8984d7aa4dca467b55f67de3c93a
https://github.com/palvitgarg99/expertiza/commit/bd86f5a4ec8aa02c27a0cd34c85bd21776feca2c
https://github.com/palvitgarg99/expertiza/commit/56be9eed8ac89632041608947108f87dfbcb28ab

6. Signup_as_instructor_action's if-else ladder has been made more elegant.

https://github.com/palvitgarg99/expertiza/commit/50aae43edb7fcec3804deb93df28471db1b31c15

7. delete_signup and delete_signup_as_instructor violated the DRY principle due to both functions using identical if/else statements. To solve this issue, flash_delete_signup_message function was created.

https://github.com/palvitgarg99/expertiza/commit/ddf35e88a2486d5ca748d3d93b15d9f6f4984af9
https://github.com/palvitgarg99/expertiza/commit/df1342b5239bb4e49214149b877a5ccf9c6117ae

8. Flash messages names have been changed and given for meaningful names.

https://github.com/palvitgarg99/expertiza/commit/47b4b11e4b4b2e6793dbd54259ae36749ed113a7

== Testing ==
; RSpec
: As such no functionality changed in any function, only refactoring done. All the refactoring was carefully verified by running rspec tests. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb

; Physical Testing

We found that add_signup_topics_staggered was simply calling add_signup_topics function. So we eliminated the add_signup_topics_staggered function and manually checked and found that it is working perfectly fine.

Delete signup and delete signup as instructor method successfully broken down to remove the dry code by creating a new helper function. This functionality has not been broken due to any changes and has been checked by running rspec and testing manually.
:
=== Edge Cases and Pre-Conditions ===
# When dropping topic if submission already done.
# When deadline from dropping topic has passed.
# Deleting topic when topic cannot be found.
# Signup in case when user cannot be found.
:

=== Login as instructor ===
# Hover on Manage Tab
# Click on Assignments Tab
# Click on Edit Button for "OSS project & documentation" assignment
# Select the Topic Tab
# Click the Green Check for any topic
# Enter a student UnityID and click submit

=== Login as student ===
# Click on OSS project/Writing assignment 2
# Click on Signup sheet
# The list must be visible, which indicates functionality is as before after refactoring list function.

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-05T23:18:06Z

Jkini:

This wiki page is for the information regarding the changes made for the E2223 OSS assignment for Spring 2022, CSC/ECE 517.
== Team ==
=== Mentor ===
* Divyang Doshi (ddoshi2)

=== Team Members ===
* Vijaya Durga Kona (vkona)
* Anand Morlaw (asmorlaw)
* Varun Garg (vgarg4)
* Jagdish Kini (jkini)

== Introduction ==
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

=== '''Design''' ===
== Problems and planned changes ==

=== Problem: The method get_data_for_review_report violates the Expert pattern ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

== Solutions ==
1. Changed the name of the controller from sign_up_sheet_controller.rb --> signup_sheet_controller.rb. Also changed several method names that had 'sign_up' being used as an adjective or a noun to 'signup'.

https://github.com/palvitgarg99/expertiza/commit/9e99f56c9f8051fa5ee6b6a4bdf3659ec50852dc
https://github.com/palvitgarg99/expertiza/commit/66fc8bc5fc3850639306ad2be79afaa3de1fad70

2. The requirement that deadlines be submitted is no longer implemented and therefore a separate function for "staggered" is no longer needed.

https://github.com/palvitgarg99/expertiza/commit/db12bf9c05831576183363b6bfe68bbad64e9c5a

3. Renaming function ad_info

https://github.com/palvitgarg99/expertiza/commit/6507f15f6d23f44900465536a91cc6c80f90ad75

4. Remove signup_as_instructor, since its not being used anywhere as such.

https://github.com/palvitgarg99/expertiza/commit/e92e704f5cb6c549d440784339bcce6eba408a6b

5. The list method is broken into 2 functions. The small part of computing signup topics is created. Also comments has been added to understand the function better.

https://github.com/palvitgarg99/expertiza/commit/4b7bb6113dfb8984d7aa4dca467b55f67de3c93a
https://github.com/palvitgarg99/expertiza/commit/bd86f5a4ec8aa02c27a0cd34c85bd21776feca2c
https://github.com/palvitgarg99/expertiza/commit/56be9eed8ac89632041608947108f87dfbcb28ab

6. Signup_as_instructor_action's if-else ladder has been made more elegant.

https://github.com/palvitgarg99/expertiza/commit/50aae43edb7fcec3804deb93df28471db1b31c15

7. delete_signup and delete_signup_as_instructor violated the DRY principle due to both functions using identical if/else statements. To solve this issue, flash_delete_signup_message function was created.

https://github.com/palvitgarg99/expertiza/commit/ddf35e88a2486d5ca748d3d93b15d9f6f4984af9
https://github.com/palvitgarg99/expertiza/commit/df1342b5239bb4e49214149b877a5ccf9c6117ae

8. Flash messages names have been changed and given for meaningful names.

https://github.com/palvitgarg99/expertiza/commit/47b4b11e4b4b2e6793dbd54259ae36749ed113a7

== Testing ==
; RSpec
: As such no functionality changed in any function, only refactoring done. All the refactoring was carefully verified by running rspec tests. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb

; Physical Testing

We found that add_signup_topics_staggered was simply calling add_signup_topics function. So we eliminated the add_signup_topics_staggered function and manually checked and found that it is working perfectly fine.

Delete signup and delete signup as instructor method successfully broken down to remove the dry code by creating a new helper function. This functionality has not been broken due to any changes and has been checked by running rspec and testing manually.
:
=== Edge Cases and Pre-Conditions ===
# When dropping topic if submission already done.
# When deadline from dropping topic has passed.
# Deleting topic when topic cannot be found.
# Signup in case when user cannot be found.
:

=== Login as instructor ===
# Hover on Manage Tab
# Click on Assignments Tab
# Click on Edit Button for "OSS project & documentation" assignment
# Select the Topic Tab
# Click the Green Check for any topic
# Enter a student UnityID and click submit

=== Login as student ===
# Click on OSS project/Writing assignment 2
# Click on Signup sheet
# The list must be visible, which indicates functionality is as before after refactoring list function.

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-05T23:17:29Z

Jkini:

This wiki page is for the information regarding the changes made for the E2223 OSS assignment for Spring 2022, CSC/ECE 517.
== Team ==
=== Mentor ===
* Divyang Doshi (ddoshi2)

=== Team Members ===
* Vijaya Durga Kona (vkona)
* Anand Morlaw (asmorlaw)
* Varun Garg (vgarg4)
* Jagdish Kini (jkini)

== Introduction ==
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

=== Design ===
== Problems and planned changes ==

=== Problem: The method get_data_for_review_report violates the Expert pattern ===
<code>get_data_for_review_report</code> passes back a data structure with multiple <code>response</code> objects to the <code>_review_report.html.erb</code> view. This violates the Expert pattern, because the given view does not know how to break apart the structure passed to it.

*''' Proposed Solution ''': <code>get_data_for_review_report</code> will be refactored to use partials

== Solutions ==
1. Changed the name of the controller from sign_up_sheet_controller.rb --> signup_sheet_controller.rb. Also changed several method names that had 'sign_up' being used as an adjective or a noun to 'signup'.

https://github.com/palvitgarg99/expertiza/commit/9e99f56c9f8051fa5ee6b6a4bdf3659ec50852dc
https://github.com/palvitgarg99/expertiza/commit/66fc8bc5fc3850639306ad2be79afaa3de1fad70

2. The requirement that deadlines be submitted is no longer implemented and therefore a separate function for "staggered" is no longer needed.

https://github.com/palvitgarg99/expertiza/commit/db12bf9c05831576183363b6bfe68bbad64e9c5a

3. Renaming function ad_info

https://github.com/palvitgarg99/expertiza/commit/6507f15f6d23f44900465536a91cc6c80f90ad75

4. Remove signup_as_instructor, since its not being used anywhere as such.

https://github.com/palvitgarg99/expertiza/commit/e92e704f5cb6c549d440784339bcce6eba408a6b

5. The list method is broken into 2 functions. The small part of computing signup topics is created. Also comments has been added to understand the function better.

https://github.com/palvitgarg99/expertiza/commit/4b7bb6113dfb8984d7aa4dca467b55f67de3c93a
https://github.com/palvitgarg99/expertiza/commit/bd86f5a4ec8aa02c27a0cd34c85bd21776feca2c
https://github.com/palvitgarg99/expertiza/commit/56be9eed8ac89632041608947108f87dfbcb28ab

6. Signup_as_instructor_action's if-else ladder has been made more elegant.

https://github.com/palvitgarg99/expertiza/commit/50aae43edb7fcec3804deb93df28471db1b31c15

7. delete_signup and delete_signup_as_instructor violated the DRY principle due to both functions using identical if/else statements. To solve this issue, flash_delete_signup_message function was created.

https://github.com/palvitgarg99/expertiza/commit/ddf35e88a2486d5ca748d3d93b15d9f6f4984af9
https://github.com/palvitgarg99/expertiza/commit/df1342b5239bb4e49214149b877a5ccf9c6117ae

8. Flash messages names have been changed and given for meaningful names.

https://github.com/palvitgarg99/expertiza/commit/47b4b11e4b4b2e6793dbd54259ae36749ed113a7

== Testing ==
; RSpec
: As such no functionality changed in any function, only refactoring done. All the refactoring was carefully verified by running rspec tests. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb

; Physical Testing

We found that add_signup_topics_staggered was simply calling add_signup_topics function. So we eliminated the add_signup_topics_staggered function and manually checked and found that it is working perfectly fine.

Delete signup and delete signup as instructor method successfully broken down to remove the dry code by creating a new helper function. This functionality has not been broken due to any changes and has been checked by running rspec and testing manually.
:
=== Edge Cases and Pre-Conditions ===
# When dropping topic if submission already done.
# When deadline from dropping topic has passed.
# Deleting topic when topic cannot be found.
# Signup in case when user cannot be found.
:

=== Login as instructor ===
# Hover on Manage Tab
# Click on Assignments Tab
# Click on Edit Button for "OSS project & documentation" assignment
# Select the Topic Tab
# Click the Green Check for any topic
# Enter a student UnityID and click submit

=== Login as student ===
# Click on OSS project/Writing assignment 2
# Click on Signup sheet
# The list must be visible, which indicates functionality is as before after refactoring list function.

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-05T23:10:11Z

Jkini:

This wiki page is for the information regarding the changes made for the E2223 OSS assignment for Spring 2022, CSC/ECE 517.
== Team ==
=== Mentor ===
* Divyang Doshi (ddoshi2)

=== Team Members ===
* Vijaya Durga Kona (vkona)
* Anand Morlaw (asmorlaw)
* Varun Garg (vgarg4)
* Jagdish Kini (jkini)

== Introduction ==
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the details are below:
* We have deployed the project http://152.7.98.81:8080/
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5899, password -> password

== About Controller ==
The sign up sheet controller
* Allows an instructor to add/remove topics
* Allows an instructor to assign/remove students to topics
* Allows an student to see the list of available topics which can be bid on for given OSS assignment.

== Issues ==
1. Naming is inconsistent. When used as a verb, “sign up” is two words. When an adjective or a noun, it should be one word, e.g., “signup_sheet_controller.” Cf. “sign_up_as_instructor”. Please make the naming consistent. Of course, this will result in changes in calling methods as well.

2. Add_signup_topics_staggered does not do anything different from add_signup_topics. Separate functions are needed, because add_signup_topics_staggered needs to make sure that the deadlines are set. [Assignment 1042 has staggered deadlines]

3. Several method names can be improved.

4. What are differences between signup_as_instructor and signup_as_instructor_action methods? Investigate if they are needed and improve the method names if both are needed. Provide comments as to what each method does.

5. The list method is too long and is sparsely commented. Provide comments and identify if the method can be split or made cleaner by moving code to models or helper methods.

6. Signup_as_instructor_action has if-else ladder. It can be made more elegant.

7.Delete_signup and delete_signup_as_instructor have much in common and violate the DRY principle. Refactor.

8.Giving elegant and more understandable names to flash in flash_delete_signup_message function

== Solutions ==
1. Changed the name of the controller from sign_up_sheet_controller.rb --> signup_sheet_controller.rb. Also changed several method names that had 'sign_up' being used as an adjective or a noun to 'signup'.

https://github.com/palvitgarg99/expertiza/commit/9e99f56c9f8051fa5ee6b6a4bdf3659ec50852dc
https://github.com/palvitgarg99/expertiza/commit/66fc8bc5fc3850639306ad2be79afaa3de1fad70

2. The requirement that deadlines be submitted is no longer implemented and therefore a separate function for "staggered" is no longer needed.

https://github.com/palvitgarg99/expertiza/commit/db12bf9c05831576183363b6bfe68bbad64e9c5a

3. Renaming function ad_info

https://github.com/palvitgarg99/expertiza/commit/6507f15f6d23f44900465536a91cc6c80f90ad75

4. Remove signup_as_instructor, since its not being used anywhere as such.

https://github.com/palvitgarg99/expertiza/commit/e92e704f5cb6c549d440784339bcce6eba408a6b

5. The list method is broken into 2 functions. The small part of computing signup topics is created. Also comments has been added to understand the function better.

https://github.com/palvitgarg99/expertiza/commit/4b7bb6113dfb8984d7aa4dca467b55f67de3c93a
https://github.com/palvitgarg99/expertiza/commit/bd86f5a4ec8aa02c27a0cd34c85bd21776feca2c
https://github.com/palvitgarg99/expertiza/commit/56be9eed8ac89632041608947108f87dfbcb28ab

6. Signup_as_instructor_action's if-else ladder has been made more elegant.

https://github.com/palvitgarg99/expertiza/commit/50aae43edb7fcec3804deb93df28471db1b31c15

7. delete_signup and delete_signup_as_instructor violated the DRY principle due to both functions using identical if/else statements. To solve this issue, flash_delete_signup_message function was created.

https://github.com/palvitgarg99/expertiza/commit/ddf35e88a2486d5ca748d3d93b15d9f6f4984af9
https://github.com/palvitgarg99/expertiza/commit/df1342b5239bb4e49214149b877a5ccf9c6117ae

8. Flash messages names have been changed and given for meaningful names.

https://github.com/palvitgarg99/expertiza/commit/47b4b11e4b4b2e6793dbd54259ae36749ed113a7

== Testing ==
; RSpec
: As such no functionality changed in any function, only refactoring done. All the refactoring was carefully verified by running rspec tests. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb

; Physical Testing

We found that add_signup_topics_staggered was simply calling add_signup_topics function. So we eliminated the add_signup_topics_staggered function and manually checked and found that it is working perfectly fine.

Delete signup and delete signup as instructor method successfully broken down to remove the dry code by creating a new helper function. This functionality has not been broken due to any changes and has been checked by running rspec and testing manually.
:
=== Edge Cases and Pre-Conditions ===
# When dropping topic if submission already done.
# When deadline from dropping topic has passed.
# Deleting topic when topic cannot be found.
# Signup in case when user cannot be found.
:

=== Login as instructor ===
# Hover on Manage Tab
# Click on Assignments Tab
# Click on Edit Button for "OSS project & documentation" assignment
# Select the Topic Tab
# Click the Green Check for any topic
# Enter a student UnityID and click submit

=== Login as student ===
# Click on OSS project/Writing assignment 2
# Click on Signup sheet
# The list must be visible, which indicates functionality is as before after refactoring list function.

CSC/ECE 517 Spring 2022 - E2231: Allow reviewers to bid on what to review

2022-04-05T23:05:36Z

Jkini: Created page with "This wiki page is for the information regarding the changes made for the E2223 OSS assignment for Spring 2022, CSC/ECE 517. == Team == === Mentor === * Ed Gehringer (efg) ===..."

This wiki page is for the information regarding the changes made for the E2223 OSS assignment for Spring 2022, CSC/ECE 517.
== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Palvit Garg (pgarg5)
* Varun Garg (vgarg4)
* Jagdish Kini (jkini)

== Introduction ==
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the details are below:
* We have deployed the project http://152.7.98.81:8080/
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5899, password -> password

== About Controller ==
The sign up sheet controller
* Allows an instructor to add/remove topics
* Allows an instructor to assign/remove students to topics
* Allows an student to see the list of available topics which can be bid on for given OSS assignment.

== Issues ==
1. Naming is inconsistent. When used as a verb, “sign up” is two words. When an adjective or a noun, it should be one word, e.g., “signup_sheet_controller.” Cf. “sign_up_as_instructor”. Please make the naming consistent. Of course, this will result in changes in calling methods as well.

2. Add_signup_topics_staggered does not do anything different from add_signup_topics. Separate functions are needed, because add_signup_topics_staggered needs to make sure that the deadlines are set. [Assignment 1042 has staggered deadlines]

3. Several method names can be improved.

4. What are differences between signup_as_instructor and signup_as_instructor_action methods? Investigate if they are needed and improve the method names if both are needed. Provide comments as to what each method does.

5. The list method is too long and is sparsely commented. Provide comments and identify if the method can be split or made cleaner by moving code to models or helper methods.

6. Signup_as_instructor_action has if-else ladder. It can be made more elegant.

7.Delete_signup and delete_signup_as_instructor have much in common and violate the DRY principle. Refactor.

8.Giving elegant and more understandable names to flash in flash_delete_signup_message function

== Solutions ==
1. Changed the name of the controller from sign_up_sheet_controller.rb --> signup_sheet_controller.rb. Also changed several method names that had 'sign_up' being used as an adjective or a noun to 'signup'.

https://github.com/palvitgarg99/expertiza/commit/9e99f56c9f8051fa5ee6b6a4bdf3659ec50852dc
https://github.com/palvitgarg99/expertiza/commit/66fc8bc5fc3850639306ad2be79afaa3de1fad70

2. The requirement that deadlines be submitted is no longer implemented and therefore a separate function for "staggered" is no longer needed.

https://github.com/palvitgarg99/expertiza/commit/db12bf9c05831576183363b6bfe68bbad64e9c5a

3. Renaming function ad_info

https://github.com/palvitgarg99/expertiza/commit/6507f15f6d23f44900465536a91cc6c80f90ad75

4. Remove signup_as_instructor, since its not being used anywhere as such.

https://github.com/palvitgarg99/expertiza/commit/e92e704f5cb6c549d440784339bcce6eba408a6b

5. The list method is broken into 2 functions. The small part of computing signup topics is created. Also comments has been added to understand the function better.

https://github.com/palvitgarg99/expertiza/commit/4b7bb6113dfb8984d7aa4dca467b55f67de3c93a
https://github.com/palvitgarg99/expertiza/commit/bd86f5a4ec8aa02c27a0cd34c85bd21776feca2c
https://github.com/palvitgarg99/expertiza/commit/56be9eed8ac89632041608947108f87dfbcb28ab

6. Signup_as_instructor_action's if-else ladder has been made more elegant.

https://github.com/palvitgarg99/expertiza/commit/50aae43edb7fcec3804deb93df28471db1b31c15

7. delete_signup and delete_signup_as_instructor violated the DRY principle due to both functions using identical if/else statements. To solve this issue, flash_delete_signup_message function was created.

https://github.com/palvitgarg99/expertiza/commit/ddf35e88a2486d5ca748d3d93b15d9f6f4984af9
https://github.com/palvitgarg99/expertiza/commit/df1342b5239bb4e49214149b877a5ccf9c6117ae

8. Flash messages names have been changed and given for meaningful names.

https://github.com/palvitgarg99/expertiza/commit/47b4b11e4b4b2e6793dbd54259ae36749ed113a7

== Testing ==
; RSpec
: As such no functionality changed in any function, only refactoring done. All the refactoring was carefully verified by running rspec tests. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb

; Physical Testing

We found that add_signup_topics_staggered was simply calling add_signup_topics function. So we eliminated the add_signup_topics_staggered function and manually checked and found that it is working perfectly fine.

Delete signup and delete signup as instructor method successfully broken down to remove the dry code by creating a new helper function. This functionality has not been broken due to any changes and has been checked by running rspec and testing manually.
:
=== Edge Cases and Pre-Conditions ===
# When dropping topic if submission already done.
# When deadline from dropping topic has passed.
# Deleting topic when topic cannot be found.
# Signup in case when user cannot be found.
:

=== Login as instructor ===
# Hover on Manage Tab
# Click on Assignments Tab
# Click on Edit Button for "OSS project & documentation" assignment
# Select the Topic Tab
# Click the Green Check for any topic
# Enter a student UnityID and click submit

=== Login as student ===
# Click on OSS project/Writing assignment 2
# Click on Signup sheet
# The list must be visible, which indicates functionality is as before after refactoring list function.

CSC/ECE 517 Spring 2022

2022-04-05T23:04:08Z

Jkini: /* Final Projects */

== OSS Projects ==

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

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

CSC/ECE 517 Spring 2022

2022-04-05T23:03:42Z

Jkini: /* Final Projects */

== OSS Projects ==

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

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

CSC/ECE 517 Spring 2022

2022-04-05T23:03:24Z

Jkini: /* Final Projects */

== OSS Projects ==

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

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

CSC/ECE 517 Spring 2022 - E2223. Refactor sign up sheet controller.rb

2022-03-22T00:26:05Z

Jkini: /* Peer Review Information */

This wiki page is for the information regarding the changes made for the E2223 OSS assignment for Spring 2022, CSC/ECE 517.
== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Palvit Garg (pgarg5)
* Varun Garg (vgarg4)
* Jagdish Kini (jkini)

== Introduction ==
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the details are below:
* We have deployed the project http://152.7.98.81:8080/
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5899, password -> password

== About Controller ==
The sign up sheet controller
* Allows an instructor to add/remove topics
* Allows an instructor to assign/remove students to topics
* Allows an student to see the list of available topics which can be bid on for given OSS assignment.

== Issues ==
1. Naming is inconsistent. When used as a verb, “sign up” is two words. When an adjective or a noun, it should be one word, e.g., “signup_sheet_controller.” Cf. “sign_up_as_instructor”. Please make the naming consistent. Of course, this will result in changes in calling methods as well.

2. Add_signup_topics_staggered does not do anything different from add_signup_topics. Separate functions are needed, because add_signup_topics_staggered needs to make sure that the deadlines are set. [Assignment 1042 has staggered deadlines]

3. Several method names can be improved.

4. What are differences between signup_as_instructor and signup_as_instructor_action methods? Investigate if they are needed and improve the method names if both are needed. Provide comments as to what each method does.

5. The list method is too long and is sparsely commented. Provide comments and identify if the method can be split or made cleaner by moving code to models or helper methods.

6. Signup_as_instructor_action has if-else ladder. It can be made more elegant.

7.Delete_signup and delete_signup_as_instructor have much in common and violate the DRY principle. Refactor.

8.Giving elegant and more understandable names to flash in flash_delete_signup_message function

== Solutions ==
1. Changed the name of the controller from sign_up_sheet_controller.rb --> signup_sheet_controller.rb. Also changed several method names that had 'sign_up' being used as an adjective or a noun to 'signup'.

https://github.com/palvitgarg99/expertiza/commit/9e99f56c9f8051fa5ee6b6a4bdf3659ec50852dc
https://github.com/palvitgarg99/expertiza/commit/66fc8bc5fc3850639306ad2be79afaa3de1fad70

2. The requirement that deadlines be submitted is no longer implemented and therefore a separate function for "staggered" is no longer needed.

https://github.com/palvitgarg99/expertiza/commit/db12bf9c05831576183363b6bfe68bbad64e9c5a

3. Renaming function ad_info

https://github.com/palvitgarg99/expertiza/commit/6507f15f6d23f44900465536a91cc6c80f90ad75

4. Remove signup_as_instructor, since its not being used anywhere as such.

https://github.com/palvitgarg99/expertiza/commit/e92e704f5cb6c549d440784339bcce6eba408a6b

5. The list method is broken into 2 functions. The small part of computing signup topics is created. Also comments has been added to understand the function better.

https://github.com/palvitgarg99/expertiza/commit/4b7bb6113dfb8984d7aa4dca467b55f67de3c93a
https://github.com/palvitgarg99/expertiza/commit/bd86f5a4ec8aa02c27a0cd34c85bd21776feca2c
https://github.com/palvitgarg99/expertiza/commit/56be9eed8ac89632041608947108f87dfbcb28ab

6. Signup_as_instructor_action's if-else ladder has been made more elegant.

https://github.com/palvitgarg99/expertiza/commit/50aae43edb7fcec3804deb93df28471db1b31c15

7. delete_signup and delete_signup_as_instructor violated the DRY principle due to both functions using identical if/else statements. To solve this issue, flash_delete_signup_message function was created.

https://github.com/palvitgarg99/expertiza/commit/ddf35e88a2486d5ca748d3d93b15d9f6f4984af9
https://github.com/palvitgarg99/expertiza/commit/df1342b5239bb4e49214149b877a5ccf9c6117ae

8. Flash messages names have been changed and given for meaningful names.

https://github.com/palvitgarg99/expertiza/commit/47b4b11e4b4b2e6793dbd54259ae36749ed113a7

== Testing ==
; RSpec
: As such no functionality changed in any function, only refactoring done. All the refactoring was carefully verified by running rspec tests. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb

; Physical Testing

We found that add_signup_topics_staggered was simply calling add_signup_topics function. So we eliminated the add_signup_topics_staggered function and manually checked and found that it is working perfectly fine.

Delete signup and delete signup as instructor method successfully broken down to remove the dry code by creating a new helper function. This functionality has not been broken due to any changes and has been checked by running rspec and testing manually.
:
=== Login as instructor ===
# Hover on Manage Tab
# Click on Assignments Tab
# Click on Edit Button for "OSS project & documentation" assignment
# Select the Topic Tab
# Click the Green Check for any topic
# Enter a student UnityID and click submit

=== Login as student ===
# Click on OSS project/Writing assignment 2
# Click on Signup sheet
# The list must be visible, which indicates functionality is as before after refactoring list function.

CSC/ECE 517 Spring 2022 - E2223. Refactor sign up sheet controller.rb

2022-03-22T00:25:09Z

Jkini: /* Mentor */

This wiki page is for the information regarding the changes made for the E2223 OSS assignment for Spring 2022, CSC/ECE 517.
== Team ==
=== Mentor ===
* Ed Gehringer (efg)

=== Team Members ===
* Palvit Garg (pgarg5)
* Varun Garg (vgarg4)
* Jagdish Kini (jkini)

== Introduction ==
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5899, password -> password

== About Controller ==
The sign up sheet controller
* Allows an instructor to add/remove topics
* Allows an instructor to assign/remove students to topics
* Allows an student to see the list of available topics which can be bid on for given OSS assignment.

== Issues ==
1. Naming is inconsistent. When used as a verb, “sign up” is two words. When an adjective or a noun, it should be one word, e.g., “signup_sheet_controller.” Cf. “sign_up_as_instructor”. Please make the naming consistent. Of course, this will result in changes in calling methods as well.

2. Add_signup_topics_staggered does not do anything different from add_signup_topics. Separate functions are needed, because add_signup_topics_staggered needs to make sure that the deadlines are set. [Assignment 1042 has staggered deadlines]

3. Several method names can be improved.

4. What are differences between signup_as_instructor and signup_as_instructor_action methods? Investigate if they are needed and improve the method names if both are needed. Provide comments as to what each method does.

5. The list method is too long and is sparsely commented. Provide comments and identify if the method can be split or made cleaner by moving code to models or helper methods.

6. Signup_as_instructor_action has if-else ladder. It can be made more elegant.

7.Delete_signup and delete_signup_as_instructor have much in common and violate the DRY principle. Refactor.

8.Giving elegant and more understandable names to flash in flash_delete_signup_message function

== Solutions ==
1. Changed the name of the controller from sign_up_sheet_controller.rb --> signup_sheet_controller.rb. Also changed several method names that had 'sign_up' being used as an adjective or a noun to 'signup'.

https://github.com/palvitgarg99/expertiza/commit/9e99f56c9f8051fa5ee6b6a4bdf3659ec50852dc
https://github.com/palvitgarg99/expertiza/commit/66fc8bc5fc3850639306ad2be79afaa3de1fad70

2. The requirement that deadlines be submitted is no longer implemented and therefore a separate function for "staggered" is no longer needed.

https://github.com/palvitgarg99/expertiza/commit/db12bf9c05831576183363b6bfe68bbad64e9c5a

3. Renaming function ad_info

https://github.com/palvitgarg99/expertiza/commit/6507f15f6d23f44900465536a91cc6c80f90ad75

4. Remove signup_as_instructor, since its not being used anywhere as such.

https://github.com/palvitgarg99/expertiza/commit/e92e704f5cb6c549d440784339bcce6eba408a6b

5. The list method is broken into 2 functions. The small part of computing signup topics is created. Also comments has been added to understand the function better.

https://github.com/palvitgarg99/expertiza/commit/4b7bb6113dfb8984d7aa4dca467b55f67de3c93a
https://github.com/palvitgarg99/expertiza/commit/bd86f5a4ec8aa02c27a0cd34c85bd21776feca2c
https://github.com/palvitgarg99/expertiza/commit/56be9eed8ac89632041608947108f87dfbcb28ab

6. Signup_as_instructor_action's if-else ladder has been made more elegant.

https://github.com/palvitgarg99/expertiza/commit/50aae43edb7fcec3804deb93df28471db1b31c15

7. delete_signup and delete_signup_as_instructor violated the DRY principle due to both functions using identical if/else statements. To solve this issue, flash_delete_signup_message function was created.

https://github.com/palvitgarg99/expertiza/commit/ddf35e88a2486d5ca748d3d93b15d9f6f4984af9
https://github.com/palvitgarg99/expertiza/commit/df1342b5239bb4e49214149b877a5ccf9c6117ae

8. Flash messages names have been changed and given for meaningful names.

https://github.com/palvitgarg99/expertiza/commit/47b4b11e4b4b2e6793dbd54259ae36749ed113a7

== Testing ==
; RSpec
: As such no functionality changed in any function, only refactoring done. All the refactoring was carefully verified by running rspec tests. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb

; Physical Testing

We found that add_signup_topics_staggered was simply calling add_signup_topics function. So we eliminated the add_signup_topics_staggered function and manually checked and found that it is working perfectly fine.

Delete signup and delete signup as instructor method successfully broken down to remove the dry code by creating a new helper function. This functionality has not been broken due to any changes and has been checked by running rspec and testing manually.
:
=== Login as instructor ===
# Hover on Manage Tab
# Click on Assignments Tab
# Click on Edit Button for "OSS project & documentation" assignment
# Select the Topic Tab
# Click the Green Check for any topic
# Enter a student UnityID and click submit

=== Login as student ===
# Click on OSS project/Writing assignment 2
# Click on Signup sheet
# The list must be visible, which indicates functionality is as before after refactoring list function.

CSC/ECE 517 Spring 2022 - E2223. Refactor sign up sheet controller.rb

2022-03-22T00:24:53Z

Jkini:

This wiki page is for the information regarding the changes made for the E2223 OSS assignment for Spring 2022, CSC/ECE 517.
== Team ==
=== Mentor ===
* Ed Gehringer (efg@ncsu.edu)
=== Team Members ===
* Palvit Garg (pgarg5)
* Varun Garg (vgarg4)
* Jagdish Kini (jkini)

== Introduction ==
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5899, password -> password

== About Controller ==
The sign up sheet controller
* Allows an instructor to add/remove topics
* Allows an instructor to assign/remove students to topics
* Allows an student to see the list of available topics which can be bid on for given OSS assignment.

== Issues ==
1. Naming is inconsistent. When used as a verb, “sign up” is two words. When an adjective or a noun, it should be one word, e.g., “signup_sheet_controller.” Cf. “sign_up_as_instructor”. Please make the naming consistent. Of course, this will result in changes in calling methods as well.

2. Add_signup_topics_staggered does not do anything different from add_signup_topics. Separate functions are needed, because add_signup_topics_staggered needs to make sure that the deadlines are set. [Assignment 1042 has staggered deadlines]

3. Several method names can be improved.

4. What are differences between signup_as_instructor and signup_as_instructor_action methods? Investigate if they are needed and improve the method names if both are needed. Provide comments as to what each method does.

5. The list method is too long and is sparsely commented. Provide comments and identify if the method can be split or made cleaner by moving code to models or helper methods.

6. Signup_as_instructor_action has if-else ladder. It can be made more elegant.

7.Delete_signup and delete_signup_as_instructor have much in common and violate the DRY principle. Refactor.

8.Giving elegant and more understandable names to flash in flash_delete_signup_message function

== Solutions ==
1. Changed the name of the controller from sign_up_sheet_controller.rb --> signup_sheet_controller.rb. Also changed several method names that had 'sign_up' being used as an adjective or a noun to 'signup'.

https://github.com/palvitgarg99/expertiza/commit/9e99f56c9f8051fa5ee6b6a4bdf3659ec50852dc
https://github.com/palvitgarg99/expertiza/commit/66fc8bc5fc3850639306ad2be79afaa3de1fad70

2. The requirement that deadlines be submitted is no longer implemented and therefore a separate function for "staggered" is no longer needed.

https://github.com/palvitgarg99/expertiza/commit/db12bf9c05831576183363b6bfe68bbad64e9c5a

3. Renaming function ad_info

https://github.com/palvitgarg99/expertiza/commit/6507f15f6d23f44900465536a91cc6c80f90ad75

4. Remove signup_as_instructor, since its not being used anywhere as such.

https://github.com/palvitgarg99/expertiza/commit/e92e704f5cb6c549d440784339bcce6eba408a6b

5. The list method is broken into 2 functions. The small part of computing signup topics is created. Also comments has been added to understand the function better.

https://github.com/palvitgarg99/expertiza/commit/4b7bb6113dfb8984d7aa4dca467b55f67de3c93a
https://github.com/palvitgarg99/expertiza/commit/bd86f5a4ec8aa02c27a0cd34c85bd21776feca2c
https://github.com/palvitgarg99/expertiza/commit/56be9eed8ac89632041608947108f87dfbcb28ab

6. Signup_as_instructor_action's if-else ladder has been made more elegant.

https://github.com/palvitgarg99/expertiza/commit/50aae43edb7fcec3804deb93df28471db1b31c15

7. delete_signup and delete_signup_as_instructor violated the DRY principle due to both functions using identical if/else statements. To solve this issue, flash_delete_signup_message function was created.

https://github.com/palvitgarg99/expertiza/commit/ddf35e88a2486d5ca748d3d93b15d9f6f4984af9
https://github.com/palvitgarg99/expertiza/commit/df1342b5239bb4e49214149b877a5ccf9c6117ae

8. Flash messages names have been changed and given for meaningful names.

https://github.com/palvitgarg99/expertiza/commit/47b4b11e4b4b2e6793dbd54259ae36749ed113a7

== Testing ==
; RSpec
: As such no functionality changed in any function, only refactoring done. All the refactoring was carefully verified by running rspec tests. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb

; Physical Testing

We found that add_signup_topics_staggered was simply calling add_signup_topics function. So we eliminated the add_signup_topics_staggered function and manually checked and found that it is working perfectly fine.

Delete signup and delete signup as instructor method successfully broken down to remove the dry code by creating a new helper function. This functionality has not been broken due to any changes and has been checked by running rspec and testing manually.
:
=== Login as instructor ===
# Hover on Manage Tab
# Click on Assignments Tab
# Click on Edit Button for "OSS project & documentation" assignment
# Select the Topic Tab
# Click the Green Check for any topic
# Enter a student UnityID and click submit

=== Login as student ===
# Click on OSS project/Writing assignment 2
# Click on Signup sheet
# The list must be visible, which indicates functionality is as before after refactoring list function.

CSC/ECE 517 Spring 2022 - E2223. Refactor sign up sheet controller.rb

2022-03-22T00:18:17Z

Jkini: /* Testing */

CSC/ECE 517 Spring 2022 - E2223. Refactor sign up sheet controller.rb

2022-03-21T23:57:24Z

Jkini: /* Testing */

CSC/ECE 517 Spring 2022 - E2223. Refactor sign up sheet controller.rb

2022-03-21T23:06:54Z

Jkini: /* Solutions */

CSC/ECE 517 Spring 2022 - E2223. Refactor sign up sheet controller.rb

2022-03-21T23:04:26Z

Jkini: /* Solutions */

CSC/ECE 517 Spring 2022 - E2223. Refactor sign up sheet controller.rb

2022-03-21T23:01:15Z

Jkini: /* Solutions */

CSC/ECE 517 Spring 2022 - E2223. Refactor sign up sheet controller.rb

2022-03-21T22:59:56Z

Jkini: /* Solutions */

This wiki page is for the information regarding the changes made for the E2223 OSS assignment for Spring 2022, CSC/ECE 517.

== Introduction ==
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5899, password -> password

== About Controller ==
The sign up sheet controller
* Allows an instructor to add/remove topics
* Allows an instructor to assign/remove students to topics
* Allows an student to see the list of available topics which can be bid on for given OSS assignment.

== Issues ==
1. Naming is inconsistent. When used as a verb, “sign up” is two words. When an adjective or a noun, it should be one word, e.g., “signup_sheet_controller.” Cf. “sign_up_as_instructor”. Please make the naming consistent. Of course, this will result in changes in calling methods as well.

2. Add_signup_topics_staggered does not do anything different from add_signup_topics. Separate functions are needed, because add_signup_topics_staggered needs to make sure that the deadlines are set. [Assignment 1042 has staggered deadlines]

3. Several method names can be improved (including: load_add_signup_topics, list, ad_info etc.)

4. What are differences between signup_as_instructor and signup_as_instructor_action methods? Investigate if they are needed and improve the method names if both are needed. Provide comments as to what each method does.

5. The list method is too long and is sparsely commented. Provide comments and identify if the method can be split or made cleaner by moving code to models or helper methods.

6. Signup_as_instructor_action has if-else ladder. It can be made more elegant.

7. Delete_signup and delete_signup_as_instructor have much in common and violate the DRY principle. Refactor.

== Solutions ==
1. Changed the name of the controller from sign_up_sheet_controller.rb --> signup_sheet_controller.rb. Also changed several method names that had 'sign_up' being used as an adjective or a noun to 'signup'.

https://github.com/palvitgarg99/expertiza/commit/9e99f56c9f8051fa5ee6b6a4bdf3659ec50852dc

2. Changed the create method to only create a new topic if that topic doesn't already exist. If it does exist, the program flashes an error message and backs out.

3. Used a single update_attributes method in place of the many instance variables.

'''Before'''
<pre>
https://github.com/palvitgarg99/expertiza/commit/9e99f56c9f8051fa5ee6b6a4bdf3659ec50852dc
https://github.com/palvitgarg99/expertiza/commit/66fc8bc5fc3850639306ad2be79afaa3de1fad70
def update
@topic = SignUpTopic.find(params[:id])
if @topic
@topic.topic_identifier = params[:topic][:topic_identifier]
update_max_choosers @topic
@topic.category = params[:topic][:category]
@topic.topic_name = params[:topic][:topic_name]
@topic.micropayment = params[:topic][:micropayment]
@topic.description = params[:topic][:description]
@topic.link = params[:topic][:link]
@topic.save
params[:topic][:topic_name], micropayment: params[:topic][:micropayment], description: params[:topic][:description], link: params[:topic][:link])
undo_link("The topic: \"#{@topic.topic_name}\" has been successfully updated. ")
else
flash[:error] = "The topic could not be updated."
end
# Akshay - correctly changing the redirection url to topics tab in edit assignment view.
redirect_to edit_assignment_path(params[:assignment_id]) + "#tabs-2"
end
</pre>

'''After'''
<pre>
def update
@topic = SignUpTopic.find(params[:id])
if @topic
update_max_choosers @topic
updated_max_choosers = @topic.max_choosers
@topic.update_attributes(topic_identifier: params[:topic][:topic_identifier], max_choosers: updated_max_choosers, category: params[:topic][:category], topic_name: params[:topic][:topic_name], micropayment: params[:topic][:micropayment], description: params[:topic][:description], link: params[:topic][:link])
undo_link("The topic: \"#{@topic.topic_name}\" has been successfully updated. ")
else
flash[:error] = "The topic could not be updated."
end
# Akshay - correctly changing the redirection url to topics tab in edit assignment view.
redirect_to edit_assignment_path(params[:assignment_id]) + "#tabs-2"
end
</pre>

4. The requirement that deadlines be submitted is no longer implemented and therefore a separate function for "staggered" is no longer needed.

5. Ad_info was renamed to ads_for_partners_info to give better picture of what function does.
https://github.com/palvitgarg99/expertiza/commit/6507f15f6d23f44900465536a91cc6c80f90ad75

6. signup_as_instructor is not needed and has been removed.

7. The list method is broken into 2 functions. The small part of computing signup topics is created. Also comments has been added to understand the functio better.
https://github.com/palvitgarg99/expertiza/commit/4b7bb6113dfb8984d7aa4dca467b55f67de3c93a
https://github.com/palvitgarg99/expertiza/commit/bd86f5a4ec8aa02c27a0cd34c85bd21776feca2c
https://github.com/palvitgarg99/expertiza/commit/56be9eed8ac89632041608947108f87dfbcb28ab

8. Refactored the participants variable and improved readability.

'''Before'''
<pre>
@participants = SignedUpTeam.find_team_participants(assignment_id, session[:ip])
</pre>

'''After'''
<pre>
ip = session[:ip]
@participants = SignedUpTeam.find_team_participants(@id, ip)
</pre>

9. Previously signup_as_instructor_action provided unhelpful feedback to the instructor by only stating if the instructor could/couldn't assign a topic for a student. The refactored code provides the instructor with the student id of the person that they are assigning, the team that the student is on, and the topic that the instructor is assigning to the team.

'''Before'''
<pre>
def signup_as_instructor_action
user = User.find_by(name: params[:username])
if user.nil? # validate invalid user
flash[:error] = "That student does not exist!"
else
if AssignmentParticipant.exists? user_id: user.id, parent_id: params[:assignment_id]
if SignUpSheet.signup_team(params[:assignment_id], user.id, params[:topic_id])
flash[:success] = "You have successfully signed up the student for the topic!"
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'Instructor signed up student for topic: ' + params[:topic_id].to_s)
else
flash[:error] = "The student has already signed up for a topic!"
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'Instructor is signing up a student who already has a topic')
end
else
flash[:error] = "The student is not registered for the assignment!"
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'The student is not registered for the assignment: ' << user.id)
end
end
redirect_to controller: 'assignments', action: 'edit', id: params[:assignment_id]
end
</pre>

'''After'''
<pre>
def signup_as_instructor_action
#put name of student and team in log
# flash name of student and team
user = User.find_by(name: params[:username])
team = Team.find_team_for_assignment_and_user(params[:assignment_id], user.id).first
assignment = Assignment.find(params[:assignment_id])
if user.nil? # validate invalid user
flash[:error] = user.name + " does not exist!"
else #If the user is not null and the student exists then sign up student for topic
if AssignmentParticipant.exists? user_id: user.id, parent_id: params[:assignment_id]
if SignUpSheet.signup_team(params[:assignment_id], user.id, params[:topic_id])
flash[:success] = "You have successfully signed up " + user.name + " on " + team.name + " for the topic " + params[:topic_id].to_s
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'Instructor signed up ' + user.name + ' on team ' + team.name + ' for topic: ' + params[:topic_id].to_s)
else #If the students team already has a topic then cancel the sign up
flash[:error] = user.name + " on " + team.name + " has already signed up for a topic!"
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'Instructor is signing up a ' + user.name + 'on ' + team.name + ' who already has a topic')
end
else #If the student isn't a part of the assignment then cancel the sign up
flash[:error] = user.name + " is not registered for the assignment!"
ExpertizaLogger.info LoggerMessage.new(controller_name, '', user.name + ' is not registered for the assignment: ' + assignment.name)
end
end
redirect_to controller: 'assignments', action: 'edit', id: params[:assignment_id]
end
</pre>

10. delete_signup and delete_signup_as_instructor violated the DRY principle due to both functions using identical if/else statements. To solve this issue, delete_signup_heleper function was created.

'''Before'''
<pre>
def delete_signup
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
drop_topic_deadline = assignment.due_dates.find_by(deadline_type_id: 6)
# A student who has already submitted work should not be allowed to drop his/her topic!
# (A student/team has submitted if participant directory_num is non-null or submitted_hyperlinks is non-null.)
# If there is no drop topic deadline, student can drop topic at any time (if all the submissions are deleted)
# If there is a drop topic deadline, student cannot drop topic after this deadline.
if !participant.team.submitted_files.empty? or !participant.team.hyperlinks.empty?
flash[:error] = "You have already submitted your work, so you are not allowed to drop your topic."
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Dropping topic for already submitted a work: ' + params[:topic_id].to_s)
elsif !drop_topic_deadline.nil? and Time.now > drop_topic_deadline.due_at
flash[:error] = "You cannot drop your topic after the drop topic deadline!"
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Dropping topic for ended work: ' + params[:topic_id].to_s)
else
delete_signup_for_topic(assignment.id, params[:topic_id], session[:user].id)
flash[:success] = "You have successfully dropped your topic!"
ExpertizaLogger.info LoggerMessage.new(controller_name, session[:user].id, 'Student has dropped the topic: ' + params[:topic_id].to_s)
end
redirect_to action: 'list', id: params[:id]
end

def delete_signup_as_instructor
# find participant using assignment using team and topic ids
team = Team.find(params[:id])
assignment = Assignment.find(team.parent_id)
user = TeamsUser.find_by(team_id: team.id).user
participant = AssignmentParticipant.find_by(user_id: user.id, parent_id: assignment.id)
drop_topic_deadline = assignment.due_dates.find_by(deadline_type_id: 6)
if !participant.team.submitted_files.empty? or !participant.team.hyperlinks.empty?
flash[:error] = "The student has already submitted their work, so you are not allowed to remove them."
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Drop failed for already submitted work: ' + params[:topic_id].to_s)
elsif !drop_topic_deadline.nil? and Time.now > drop_topic_deadline.due_at
flash[:error] = "You cannot drop a student after the drop topic deadline!"
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Drop failed for ended work: ' + params[:topic_id].to_s)
else
delete_signup_for_topic(assignment.id, params[:topic_id], participant.user_id)
flash[:success] = "You have successfully dropped the student from the topic!"
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Student has been dropped from the topic: ' + params[:topic_id].to_s)
end
redirect_to controller: 'assignments', action: 'edit', id: assignment.id
end
</pre>

'''After'''
<pre>
def delete_signup_helper(isInstructor, participant, assignment, drop_topic_deadline)
messages = ["You have already submitted your work, so you are not allowed to drop your topic.",
"You cannot drop your topic after the drop topic deadline!",
"You have successfully dropped your topic!",
"The team has already submitted their work, so you are not allowed to remove them.",
"You cannot drop a student after the drop topic deadline!",
"You have successfully dropped the student from the topic!"
]
if isInstructor == false
flash1 = messages[0]
flash2 = messages[1]
flash3 = messages[2]
id_param = session[:user]
else
flash1 = messages[3]
flash2 = messages[4]
flash3 = messages[5]
id_param = participant
end

if !participant.team.submitted_files.empty? or !participant.team.hyperlinks.empty?
flash[:error] = flash1
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Dropping failed for already submitted a work: ' + params[:topic_id].to_s)
elsif !drop_topic_deadline.nil? and Time.now > drop_topic_deadline.due_at
flash[:error] = flash2
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Dropping failed for ended work: ' + params[:topic_id].to_s)
else
delete_signup_for_topic(assignment.id, params[:topic_id], id_param.id)
flash[:success] = flash3
ExpertizaLogger.info LoggerMessage.new(controller_name, session[:user].id, 'Student has dropped the topic: ' + params[:topic_id].to_s)
end
end

# this function is used to delete a previous signup
def delete_signup
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
drop_topic_deadline = assignment.due_dates.find_by(deadline_type_id: 6)
# A student who has already submitted work should not be allowed to drop his/her topic!
# (A student/team has submitted if participant directory_num is non-null or submitted_hyperlinks is non-null.)
# If there is no drop topic deadline, student can drop topic at any time (if all the submissions are deleted)
# If there is a drop topic deadline, student cannot drop topic after this deadline.
delete_signup_helper(false, participant, assignment, drop_topic_deadline)
redirect_to action: 'list', id: params[:id]
end

def delete_signup_as_instructor
# find participant using assignment using team and topic ids
team = Team.find(params[:id])
assignment = Assignment.find(team.parent_id)
user = TeamsUser.find_by(team_id: team.id).user
participant = AssignmentParticipant.find_by(user_id: user.id, parent_id: assignment.id)
drop_topic_deadline = assignment.due_dates.find_by(deadline_type_id: 6)
delete_signup_helper(true, participant, assignment, drop_topic_deadline)
redirect_to controller: 'assignments', action: 'edit', id: assignment.id
end
</pre>

== Testing ==
; RSpec
: signup_as_instructor_action is the only function updated. All other functions has remained the same. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb
; Physical Testing
:
# Login as instructor
# Hover on Manage Tab
# Click on Assignments Tab
# Click on Edit Button for "OSS project & documentation" assignment
# Select the Topic Tab
# Click the Green Check for any topic
# Enter a student UnityID and click submit

# Login as student
# Click on OSS project/Writing assignment 2
# Click on Signup sheet
# The list must be visible, which indiactes functionality is as before after refactoring list fucntion.

CSC/ECE 517 Spring 2022 - E2223. Refactor sign up sheet controller.rb

2022-03-21T22:59:44Z

Jkini: /* Solutions */

This wiki page is for the information regarding the changes made for the E2223 OSS assignment for Spring 2022, CSC/ECE 517.

== Introduction ==
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5899, password -> password

== About Controller ==
The sign up sheet controller
* Allows an instructor to add/remove topics
* Allows an instructor to assign/remove students to topics
* Allows an student to see the list of available topics which can be bid on for given OSS assignment.

== Issues ==
1. Naming is inconsistent. When used as a verb, “sign up” is two words. When an adjective or a noun, it should be one word, e.g., “signup_sheet_controller.” Cf. “sign_up_as_instructor”. Please make the naming consistent. Of course, this will result in changes in calling methods as well.

2. Add_signup_topics_staggered does not do anything different from add_signup_topics. Separate functions are needed, because add_signup_topics_staggered needs to make sure that the deadlines are set. [Assignment 1042 has staggered deadlines]

3. Several method names can be improved (including: load_add_signup_topics, list, ad_info etc.)

4. What are differences between signup_as_instructor and signup_as_instructor_action methods? Investigate if they are needed and improve the method names if both are needed. Provide comments as to what each method does.

5. The list method is too long and is sparsely commented. Provide comments and identify if the method can be split or made cleaner by moving code to models or helper methods.

6. Signup_as_instructor_action has if-else ladder. It can be made more elegant.

7. Delete_signup and delete_signup_as_instructor have much in common and violate the DRY principle. Refactor.

== Solutions ==
1. Changed the name of the controller from sign_up_sheet_controller.rb --> signup_sheet_controller.rb. Also changed several method names that had 'sign_up' being used as an adjective or a noun to 'signup'.
https://github.com/palvitgarg99/expertiza/commit/9e99f56c9f8051fa5ee6b6a4bdf3659ec50852dc

2. Changed the create method to only create a new topic if that topic doesn't already exist. If it does exist, the program flashes an error message and backs out.

3. Used a single update_attributes method in place of the many instance variables.

'''Before'''
<pre>
https://github.com/palvitgarg99/expertiza/commit/9e99f56c9f8051fa5ee6b6a4bdf3659ec50852dc
https://github.com/palvitgarg99/expertiza/commit/66fc8bc5fc3850639306ad2be79afaa3de1fad70
def update
@topic = SignUpTopic.find(params[:id])
if @topic
@topic.topic_identifier = params[:topic][:topic_identifier]
update_max_choosers @topic
@topic.category = params[:topic][:category]
@topic.topic_name = params[:topic][:topic_name]
@topic.micropayment = params[:topic][:micropayment]
@topic.description = params[:topic][:description]
@topic.link = params[:topic][:link]
@topic.save
params[:topic][:topic_name], micropayment: params[:topic][:micropayment], description: params[:topic][:description], link: params[:topic][:link])
undo_link("The topic: \"#{@topic.topic_name}\" has been successfully updated. ")
else
flash[:error] = "The topic could not be updated."
end
# Akshay - correctly changing the redirection url to topics tab in edit assignment view.
redirect_to edit_assignment_path(params[:assignment_id]) + "#tabs-2"
end
</pre>

'''After'''
<pre>
def update
@topic = SignUpTopic.find(params[:id])
if @topic
update_max_choosers @topic
updated_max_choosers = @topic.max_choosers
@topic.update_attributes(topic_identifier: params[:topic][:topic_identifier], max_choosers: updated_max_choosers, category: params[:topic][:category], topic_name: params[:topic][:topic_name], micropayment: params[:topic][:micropayment], description: params[:topic][:description], link: params[:topic][:link])
undo_link("The topic: \"#{@topic.topic_name}\" has been successfully updated. ")
else
flash[:error] = "The topic could not be updated."
end
# Akshay - correctly changing the redirection url to topics tab in edit assignment view.
redirect_to edit_assignment_path(params[:assignment_id]) + "#tabs-2"
end
</pre>

4. The requirement that deadlines be submitted is no longer implemented and therefore a separate function for "staggered" is no longer needed.

5. Ad_info was renamed to ads_for_partners_info to give better picture of what function does.
https://github.com/palvitgarg99/expertiza/commit/6507f15f6d23f44900465536a91cc6c80f90ad75

6. signup_as_instructor is not needed and has been removed.

7. The list method is broken into 2 functions. The small part of computing signup topics is created. Also comments has been added to understand the functio better.
https://github.com/palvitgarg99/expertiza/commit/4b7bb6113dfb8984d7aa4dca467b55f67de3c93a
https://github.com/palvitgarg99/expertiza/commit/bd86f5a4ec8aa02c27a0cd34c85bd21776feca2c
https://github.com/palvitgarg99/expertiza/commit/56be9eed8ac89632041608947108f87dfbcb28ab

8. Refactored the participants variable and improved readability.

'''Before'''
<pre>
@participants = SignedUpTeam.find_team_participants(assignment_id, session[:ip])
</pre>

'''After'''
<pre>
ip = session[:ip]
@participants = SignedUpTeam.find_team_participants(@id, ip)
</pre>

9. Previously signup_as_instructor_action provided unhelpful feedback to the instructor by only stating if the instructor could/couldn't assign a topic for a student. The refactored code provides the instructor with the student id of the person that they are assigning, the team that the student is on, and the topic that the instructor is assigning to the team.

'''Before'''
<pre>
def signup_as_instructor_action
user = User.find_by(name: params[:username])
if user.nil? # validate invalid user
flash[:error] = "That student does not exist!"
else
if AssignmentParticipant.exists? user_id: user.id, parent_id: params[:assignment_id]
if SignUpSheet.signup_team(params[:assignment_id], user.id, params[:topic_id])
flash[:success] = "You have successfully signed up the student for the topic!"
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'Instructor signed up student for topic: ' + params[:topic_id].to_s)
else
flash[:error] = "The student has already signed up for a topic!"
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'Instructor is signing up a student who already has a topic')
end
else
flash[:error] = "The student is not registered for the assignment!"
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'The student is not registered for the assignment: ' << user.id)
end
end
redirect_to controller: 'assignments', action: 'edit', id: params[:assignment_id]
end
</pre>

'''After'''
<pre>
def signup_as_instructor_action
#put name of student and team in log
# flash name of student and team
user = User.find_by(name: params[:username])
team = Team.find_team_for_assignment_and_user(params[:assignment_id], user.id).first
assignment = Assignment.find(params[:assignment_id])
if user.nil? # validate invalid user
flash[:error] = user.name + " does not exist!"
else #If the user is not null and the student exists then sign up student for topic
if AssignmentParticipant.exists? user_id: user.id, parent_id: params[:assignment_id]
if SignUpSheet.signup_team(params[:assignment_id], user.id, params[:topic_id])
flash[:success] = "You have successfully signed up " + user.name + " on " + team.name + " for the topic " + params[:topic_id].to_s
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'Instructor signed up ' + user.name + ' on team ' + team.name + ' for topic: ' + params[:topic_id].to_s)
else #If the students team already has a topic then cancel the sign up
flash[:error] = user.name + " on " + team.name + " has already signed up for a topic!"
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'Instructor is signing up a ' + user.name + 'on ' + team.name + ' who already has a topic')
end
else #If the student isn't a part of the assignment then cancel the sign up
flash[:error] = user.name + " is not registered for the assignment!"
ExpertizaLogger.info LoggerMessage.new(controller_name, '', user.name + ' is not registered for the assignment: ' + assignment.name)
end
end
redirect_to controller: 'assignments', action: 'edit', id: params[:assignment_id]
end
</pre>

10. delete_signup and delete_signup_as_instructor violated the DRY principle due to both functions using identical if/else statements. To solve this issue, delete_signup_heleper function was created.

'''Before'''
<pre>
def delete_signup
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
drop_topic_deadline = assignment.due_dates.find_by(deadline_type_id: 6)
# A student who has already submitted work should not be allowed to drop his/her topic!
# (A student/team has submitted if participant directory_num is non-null or submitted_hyperlinks is non-null.)
# If there is no drop topic deadline, student can drop topic at any time (if all the submissions are deleted)
# If there is a drop topic deadline, student cannot drop topic after this deadline.
if !participant.team.submitted_files.empty? or !participant.team.hyperlinks.empty?
flash[:error] = "You have already submitted your work, so you are not allowed to drop your topic."
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Dropping topic for already submitted a work: ' + params[:topic_id].to_s)
elsif !drop_topic_deadline.nil? and Time.now > drop_topic_deadline.due_at
flash[:error] = "You cannot drop your topic after the drop topic deadline!"
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Dropping topic for ended work: ' + params[:topic_id].to_s)
else
delete_signup_for_topic(assignment.id, params[:topic_id], session[:user].id)
flash[:success] = "You have successfully dropped your topic!"
ExpertizaLogger.info LoggerMessage.new(controller_name, session[:user].id, 'Student has dropped the topic: ' + params[:topic_id].to_s)
end
redirect_to action: 'list', id: params[:id]
end

def delete_signup_as_instructor
# find participant using assignment using team and topic ids
team = Team.find(params[:id])
assignment = Assignment.find(team.parent_id)
user = TeamsUser.find_by(team_id: team.id).user
participant = AssignmentParticipant.find_by(user_id: user.id, parent_id: assignment.id)
drop_topic_deadline = assignment.due_dates.find_by(deadline_type_id: 6)
if !participant.team.submitted_files.empty? or !participant.team.hyperlinks.empty?
flash[:error] = "The student has already submitted their work, so you are not allowed to remove them."
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Drop failed for already submitted work: ' + params[:topic_id].to_s)
elsif !drop_topic_deadline.nil? and Time.now > drop_topic_deadline.due_at
flash[:error] = "You cannot drop a student after the drop topic deadline!"
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Drop failed for ended work: ' + params[:topic_id].to_s)
else
delete_signup_for_topic(assignment.id, params[:topic_id], participant.user_id)
flash[:success] = "You have successfully dropped the student from the topic!"
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Student has been dropped from the topic: ' + params[:topic_id].to_s)
end
redirect_to controller: 'assignments', action: 'edit', id: assignment.id
end
</pre>

'''After'''
<pre>
def delete_signup_helper(isInstructor, participant, assignment, drop_topic_deadline)
messages = ["You have already submitted your work, so you are not allowed to drop your topic.",
"You cannot drop your topic after the drop topic deadline!",
"You have successfully dropped your topic!",
"The team has already submitted their work, so you are not allowed to remove them.",
"You cannot drop a student after the drop topic deadline!",
"You have successfully dropped the student from the topic!"
]
if isInstructor == false
flash1 = messages[0]
flash2 = messages[1]
flash3 = messages[2]
id_param = session[:user]
else
flash1 = messages[3]
flash2 = messages[4]
flash3 = messages[5]
id_param = participant
end

if !participant.team.submitted_files.empty? or !participant.team.hyperlinks.empty?
flash[:error] = flash1
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Dropping failed for already submitted a work: ' + params[:topic_id].to_s)
elsif !drop_topic_deadline.nil? and Time.now > drop_topic_deadline.due_at
flash[:error] = flash2
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Dropping failed for ended work: ' + params[:topic_id].to_s)
else
delete_signup_for_topic(assignment.id, params[:topic_id], id_param.id)
flash[:success] = flash3
ExpertizaLogger.info LoggerMessage.new(controller_name, session[:user].id, 'Student has dropped the topic: ' + params[:topic_id].to_s)
end
end

# this function is used to delete a previous signup
def delete_signup
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
drop_topic_deadline = assignment.due_dates.find_by(deadline_type_id: 6)
# A student who has already submitted work should not be allowed to drop his/her topic!
# (A student/team has submitted if participant directory_num is non-null or submitted_hyperlinks is non-null.)
# If there is no drop topic deadline, student can drop topic at any time (if all the submissions are deleted)
# If there is a drop topic deadline, student cannot drop topic after this deadline.
delete_signup_helper(false, participant, assignment, drop_topic_deadline)
redirect_to action: 'list', id: params[:id]
end

def delete_signup_as_instructor
# find participant using assignment using team and topic ids
team = Team.find(params[:id])
assignment = Assignment.find(team.parent_id)
user = TeamsUser.find_by(team_id: team.id).user
participant = AssignmentParticipant.find_by(user_id: user.id, parent_id: assignment.id)
drop_topic_deadline = assignment.due_dates.find_by(deadline_type_id: 6)
delete_signup_helper(true, participant, assignment, drop_topic_deadline)
redirect_to controller: 'assignments', action: 'edit', id: assignment.id
end
</pre>

== Testing ==
; RSpec
: signup_as_instructor_action is the only function updated. All other functions has remained the same. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb
; Physical Testing
:
# Login as instructor
# Hover on Manage Tab
# Click on Assignments Tab
# Click on Edit Button for "OSS project & documentation" assignment
# Select the Topic Tab
# Click the Green Check for any topic
# Enter a student UnityID and click submit

# Login as student
# Click on OSS project/Writing assignment 2
# Click on Signup sheet
# The list must be visible, which indiactes functionality is as before after refactoring list fucntion.

CSC/ECE 517 Spring 2022 - E2223. Refactor sign up sheet controller.rb

2022-03-21T22:57:12Z

Jkini: /* Solutions */

This wiki page is for the information regarding the changes made for the E2223 OSS assignment for Spring 2022, CSC/ECE 517.

== Introduction ==
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5899, password -> password

== About Controller ==
The sign up sheet controller
* Allows an instructor to add/remove topics
* Allows an instructor to assign/remove students to topics
* Allows an student to see the list of available topics which can be bid on for given OSS assignment.

== Issues ==
1. Naming is inconsistent. When used as a verb, “sign up” is two words. When an adjective or a noun, it should be one word, e.g., “signup_sheet_controller.” Cf. “sign_up_as_instructor”. Please make the naming consistent. Of course, this will result in changes in calling methods as well.

2. Add_signup_topics_staggered does not do anything different from add_signup_topics. Separate functions are needed, because add_signup_topics_staggered needs to make sure that the deadlines are set. [Assignment 1042 has staggered deadlines]

3. Several method names can be improved (including: load_add_signup_topics, list, ad_info etc.)

4. What are differences between signup_as_instructor and signup_as_instructor_action methods? Investigate if they are needed and improve the method names if both are needed. Provide comments as to what each method does.

5. The list method is too long and is sparsely commented. Provide comments and identify if the method can be split or made cleaner by moving code to models or helper methods.

6. Signup_as_instructor_action has if-else ladder. It can be made more elegant.

7. Delete_signup and delete_signup_as_instructor have much in common and violate the DRY principle. Refactor.

== Solutions ==
1. Changed the name of the controller from sign_up_sheet_controller.rb --> signup_sheet_controller.rb. Also changed several method names that had 'sign_up' being used as an adjective or a noun to 'signup'.
https://github.com/expertiza/expertiza/pull/2339/commits/9e99f56c9f8051fa5ee6b6a4bdf3659ec50852dc

2. Changed the create method to only create a new topic if that topic doesn't already exist. If it does exist, the program flashes an error message and backs out.

3. Used a single update_attributes method in place of the many instance variables.

'''Before'''
<pre>
def update
@topic = SignUpTopic.find(params[:id])
if @topic
@topic.topic_identifier = params[:topic][:topic_identifier]
update_max_choosers @topic
@topic.category = params[:topic][:category]
@topic.topic_name = params[:topic][:topic_name]
@topic.micropayment = params[:topic][:micropayment]
@topic.description = params[:topic][:description]
@topic.link = params[:topic][:link]
@topic.save
params[:topic][:topic_name], micropayment: params[:topic][:micropayment], description: params[:topic][:description], link: params[:topic][:link])
undo_link("The topic: \"#{@topic.topic_name}\" has been successfully updated. ")
else
flash[:error] = "The topic could not be updated."
end
# Akshay - correctly changing the redirection url to topics tab in edit assignment view.
redirect_to edit_assignment_path(params[:assignment_id]) + "#tabs-2"
end
</pre>

'''After'''
<pre>
def update
@topic = SignUpTopic.find(params[:id])
if @topic
update_max_choosers @topic
updated_max_choosers = @topic.max_choosers
@topic.update_attributes(topic_identifier: params[:topic][:topic_identifier], max_choosers: updated_max_choosers, category: params[:topic][:category], topic_name: params[:topic][:topic_name], micropayment: params[:topic][:micropayment], description: params[:topic][:description], link: params[:topic][:link])
undo_link("The topic: \"#{@topic.topic_name}\" has been successfully updated. ")
else
flash[:error] = "The topic could not be updated."
end
# Akshay - correctly changing the redirection url to topics tab in edit assignment view.
redirect_to edit_assignment_path(params[:assignment_id]) + "#tabs-2"
end
</pre>

4. The requirement that deadlines be submitted is no longer implemented and therefore a separate function for "staggered" is no longer needed.

5. Ad_info was renamed to ads_for_partners_info to give better picture of what function does.
https://github.com/palvitgarg99/expertiza/commit/6507f15f6d23f44900465536a91cc6c80f90ad75

6. signup_as_instructor is not needed and has been removed.

7. The list method is broken into 2 functions. The small part of computing signup topics is created. Also comments has been added to understand the functio better.
https://github.com/palvitgarg99/expertiza/commit/4b7bb6113dfb8984d7aa4dca467b55f67de3c93a
https://github.com/palvitgarg99/expertiza/commit/bd86f5a4ec8aa02c27a0cd34c85bd21776feca2c
https://github.com/palvitgarg99/expertiza/commit/56be9eed8ac89632041608947108f87dfbcb28ab

8. Refactored the participants variable and improved readability.

'''Before'''
<pre>
@participants = SignedUpTeam.find_team_participants(assignment_id, session[:ip])
</pre>

'''After'''
<pre>
ip = session[:ip]
@participants = SignedUpTeam.find_team_participants(@id, ip)
</pre>

9. Previously signup_as_instructor_action provided unhelpful feedback to the instructor by only stating if the instructor could/couldn't assign a topic for a student. The refactored code provides the instructor with the student id of the person that they are assigning, the team that the student is on, and the topic that the instructor is assigning to the team.

'''Before'''
<pre>
def signup_as_instructor_action
user = User.find_by(name: params[:username])
if user.nil? # validate invalid user
flash[:error] = "That student does not exist!"
else
if AssignmentParticipant.exists? user_id: user.id, parent_id: params[:assignment_id]
if SignUpSheet.signup_team(params[:assignment_id], user.id, params[:topic_id])
flash[:success] = "You have successfully signed up the student for the topic!"
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'Instructor signed up student for topic: ' + params[:topic_id].to_s)
else
flash[:error] = "The student has already signed up for a topic!"
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'Instructor is signing up a student who already has a topic')
end
else
flash[:error] = "The student is not registered for the assignment!"
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'The student is not registered for the assignment: ' << user.id)
end
end
redirect_to controller: 'assignments', action: 'edit', id: params[:assignment_id]
end
</pre>

'''After'''
<pre>
def signup_as_instructor_action
#put name of student and team in log
# flash name of student and team
user = User.find_by(name: params[:username])
team = Team.find_team_for_assignment_and_user(params[:assignment_id], user.id).first
assignment = Assignment.find(params[:assignment_id])
if user.nil? # validate invalid user
flash[:error] = user.name + " does not exist!"
else #If the user is not null and the student exists then sign up student for topic
if AssignmentParticipant.exists? user_id: user.id, parent_id: params[:assignment_id]
if SignUpSheet.signup_team(params[:assignment_id], user.id, params[:topic_id])
flash[:success] = "You have successfully signed up " + user.name + " on " + team.name + " for the topic " + params[:topic_id].to_s
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'Instructor signed up ' + user.name + ' on team ' + team.name + ' for topic: ' + params[:topic_id].to_s)
else #If the students team already has a topic then cancel the sign up
flash[:error] = user.name + " on " + team.name + " has already signed up for a topic!"
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'Instructor is signing up a ' + user.name + 'on ' + team.name + ' who already has a topic')
end
else #If the student isn't a part of the assignment then cancel the sign up
flash[:error] = user.name + " is not registered for the assignment!"
ExpertizaLogger.info LoggerMessage.new(controller_name, '', user.name + ' is not registered for the assignment: ' + assignment.name)
end
end
redirect_to controller: 'assignments', action: 'edit', id: params[:assignment_id]
end
</pre>

10. delete_signup and delete_signup_as_instructor violated the DRY principle due to both functions using identical if/else statements. To solve this issue, delete_signup_heleper function was created.

'''Before'''
<pre>
def delete_signup
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
drop_topic_deadline = assignment.due_dates.find_by(deadline_type_id: 6)
# A student who has already submitted work should not be allowed to drop his/her topic!
# (A student/team has submitted if participant directory_num is non-null or submitted_hyperlinks is non-null.)
# If there is no drop topic deadline, student can drop topic at any time (if all the submissions are deleted)
# If there is a drop topic deadline, student cannot drop topic after this deadline.
if !participant.team.submitted_files.empty? or !participant.team.hyperlinks.empty?
flash[:error] = "You have already submitted your work, so you are not allowed to drop your topic."
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Dropping topic for already submitted a work: ' + params[:topic_id].to_s)
elsif !drop_topic_deadline.nil? and Time.now > drop_topic_deadline.due_at
flash[:error] = "You cannot drop your topic after the drop topic deadline!"
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Dropping topic for ended work: ' + params[:topic_id].to_s)
else
delete_signup_for_topic(assignment.id, params[:topic_id], session[:user].id)
flash[:success] = "You have successfully dropped your topic!"
ExpertizaLogger.info LoggerMessage.new(controller_name, session[:user].id, 'Student has dropped the topic: ' + params[:topic_id].to_s)
end
redirect_to action: 'list', id: params[:id]
end

def delete_signup_as_instructor
# find participant using assignment using team and topic ids
team = Team.find(params[:id])
assignment = Assignment.find(team.parent_id)
user = TeamsUser.find_by(team_id: team.id).user
participant = AssignmentParticipant.find_by(user_id: user.id, parent_id: assignment.id)
drop_topic_deadline = assignment.due_dates.find_by(deadline_type_id: 6)
if !participant.team.submitted_files.empty? or !participant.team.hyperlinks.empty?
flash[:error] = "The student has already submitted their work, so you are not allowed to remove them."
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Drop failed for already submitted work: ' + params[:topic_id].to_s)
elsif !drop_topic_deadline.nil? and Time.now > drop_topic_deadline.due_at
flash[:error] = "You cannot drop a student after the drop topic deadline!"
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Drop failed for ended work: ' + params[:topic_id].to_s)
else
delete_signup_for_topic(assignment.id, params[:topic_id], participant.user_id)
flash[:success] = "You have successfully dropped the student from the topic!"
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Student has been dropped from the topic: ' + params[:topic_id].to_s)
end
redirect_to controller: 'assignments', action: 'edit', id: assignment.id
end
</pre>

'''After'''
<pre>
def delete_signup_helper(isInstructor, participant, assignment, drop_topic_deadline)
messages = ["You have already submitted your work, so you are not allowed to drop your topic.",
"You cannot drop your topic after the drop topic deadline!",
"You have successfully dropped your topic!",
"The team has already submitted their work, so you are not allowed to remove them.",
"You cannot drop a student after the drop topic deadline!",
"You have successfully dropped the student from the topic!"
]
if isInstructor == false
flash1 = messages[0]
flash2 = messages[1]
flash3 = messages[2]
id_param = session[:user]
else
flash1 = messages[3]
flash2 = messages[4]
flash3 = messages[5]
id_param = participant
end

if !participant.team.submitted_files.empty? or !participant.team.hyperlinks.empty?
flash[:error] = flash1
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Dropping failed for already submitted a work: ' + params[:topic_id].to_s)
elsif !drop_topic_deadline.nil? and Time.now > drop_topic_deadline.due_at
flash[:error] = flash2
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Dropping failed for ended work: ' + params[:topic_id].to_s)
else
delete_signup_for_topic(assignment.id, params[:topic_id], id_param.id)
flash[:success] = flash3
ExpertizaLogger.info LoggerMessage.new(controller_name, session[:user].id, 'Student has dropped the topic: ' + params[:topic_id].to_s)
end
end

# this function is used to delete a previous signup
def delete_signup
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
drop_topic_deadline = assignment.due_dates.find_by(deadline_type_id: 6)
# A student who has already submitted work should not be allowed to drop his/her topic!
# (A student/team has submitted if participant directory_num is non-null or submitted_hyperlinks is non-null.)
# If there is no drop topic deadline, student can drop topic at any time (if all the submissions are deleted)
# If there is a drop topic deadline, student cannot drop topic after this deadline.
delete_signup_helper(false, participant, assignment, drop_topic_deadline)
redirect_to action: 'list', id: params[:id]
end

def delete_signup_as_instructor
# find participant using assignment using team and topic ids
team = Team.find(params[:id])
assignment = Assignment.find(team.parent_id)
user = TeamsUser.find_by(team_id: team.id).user
participant = AssignmentParticipant.find_by(user_id: user.id, parent_id: assignment.id)
drop_topic_deadline = assignment.due_dates.find_by(deadline_type_id: 6)
delete_signup_helper(true, participant, assignment, drop_topic_deadline)
redirect_to controller: 'assignments', action: 'edit', id: assignment.id
end
</pre>

== Testing ==
; RSpec
: signup_as_instructor_action is the only function updated. All other functions has remained the same. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb
; Physical Testing
:
# Login as instructor
# Hover on Manage Tab
# Click on Assignments Tab
# Click on Edit Button for "OSS project & documentation" assignment
# Select the Topic Tab
# Click the Green Check for any topic
# Enter a student UnityID and click submit

# Login as student
# Click on OSS project/Writing assignment 2
# Click on Signup sheet
# The list must be visible, which indiactes functionality is as before after refactoring list fucntion.

CSC/ECE 517 Spring 2022 - E2223. Refactor sign up sheet controller.rb

2022-03-21T22:57:01Z

Jkini: /* Solutions */

This wiki page is for the information regarding the changes made for the E2223 OSS assignment for Spring 2022, CSC/ECE 517.

== Introduction ==
Expertiza is a open source project developed on Ruby on Rails. This web application is maintained by the student and faculty at NC State. This application gives complete control to the instructor to maintain the assignments in their class. With multiple functionalities such as adding topics, creating groups, and peer reviews, Expertiza is a well developed application that can handle all types of assignments. To learn more about the full functionality Expertiza has to offer, visit the Expertiza wiki.

== Peer Review Information ==

For users intending to view the deployed Expertiza associated with this assignment, the credentials are below:
* Instructor login: username -> instructor6, password -> password
* Student login: username -> student5899, password -> password

== About Controller ==
The sign up sheet controller
* Allows an instructor to add/remove topics
* Allows an instructor to assign/remove students to topics
* Allows an student to see the list of available topics which can be bid on for given OSS assignment.

== Issues ==
1. Naming is inconsistent. When used as a verb, “sign up” is two words. When an adjective or a noun, it should be one word, e.g., “signup_sheet_controller.” Cf. “sign_up_as_instructor”. Please make the naming consistent. Of course, this will result in changes in calling methods as well.

2. Add_signup_topics_staggered does not do anything different from add_signup_topics. Separate functions are needed, because add_signup_topics_staggered needs to make sure that the deadlines are set. [Assignment 1042 has staggered deadlines]

3. Several method names can be improved (including: load_add_signup_topics, list, ad_info etc.)

4. What are differences between signup_as_instructor and signup_as_instructor_action methods? Investigate if they are needed and improve the method names if both are needed. Provide comments as to what each method does.

5. The list method is too long and is sparsely commented. Provide comments and identify if the method can be split or made cleaner by moving code to models or helper methods.

6. Signup_as_instructor_action has if-else ladder. It can be made more elegant.

7. Delete_signup and delete_signup_as_instructor have much in common and violate the DRY principle. Refactor.

== Solutions ==
1. Changed the name of the controller from sign_up_sheet_controller.rb --> signup_sheet_controller.rb. Also changed several method names that had 'sign_up' being used as an adjective or a noun to 'signup'.

https://github.com/expertiza/expertiza/pull/2339/commits/9e99f56c9f8051fa5ee6b6a4bdf3659ec50852dc

2. Changed the create method to only create a new topic if that topic doesn't already exist. If it does exist, the program flashes an error message and backs out.

3. Used a single update_attributes method in place of the many instance variables.

'''Before'''
<pre>
def update
@topic = SignUpTopic.find(params[:id])
if @topic
@topic.topic_identifier = params[:topic][:topic_identifier]
update_max_choosers @topic
@topic.category = params[:topic][:category]
@topic.topic_name = params[:topic][:topic_name]
@topic.micropayment = params[:topic][:micropayment]
@topic.description = params[:topic][:description]
@topic.link = params[:topic][:link]
@topic.save
params[:topic][:topic_name], micropayment: params[:topic][:micropayment], description: params[:topic][:description], link: params[:topic][:link])
undo_link("The topic: \"#{@topic.topic_name}\" has been successfully updated. ")
else
flash[:error] = "The topic could not be updated."
end
# Akshay - correctly changing the redirection url to topics tab in edit assignment view.
redirect_to edit_assignment_path(params[:assignment_id]) + "#tabs-2"
end
</pre>

'''After'''
<pre>
def update
@topic = SignUpTopic.find(params[:id])
if @topic
update_max_choosers @topic
updated_max_choosers = @topic.max_choosers
@topic.update_attributes(topic_identifier: params[:topic][:topic_identifier], max_choosers: updated_max_choosers, category: params[:topic][:category], topic_name: params[:topic][:topic_name], micropayment: params[:topic][:micropayment], description: params[:topic][:description], link: params[:topic][:link])
undo_link("The topic: \"#{@topic.topic_name}\" has been successfully updated. ")
else
flash[:error] = "The topic could not be updated."
end
# Akshay - correctly changing the redirection url to topics tab in edit assignment view.
redirect_to edit_assignment_path(params[:assignment_id]) + "#tabs-2"
end
</pre>

4. The requirement that deadlines be submitted is no longer implemented and therefore a separate function for "staggered" is no longer needed.

5. Ad_info was renamed to ads_for_partners_info to give better picture of what function does.
https://github.com/palvitgarg99/expertiza/commit/6507f15f6d23f44900465536a91cc6c80f90ad75

6. signup_as_instructor is not needed and has been removed.

7. The list method is broken into 2 functions. The small part of computing signup topics is created. Also comments has been added to understand the functio better.
https://github.com/palvitgarg99/expertiza/commit/4b7bb6113dfb8984d7aa4dca467b55f67de3c93a
https://github.com/palvitgarg99/expertiza/commit/bd86f5a4ec8aa02c27a0cd34c85bd21776feca2c
https://github.com/palvitgarg99/expertiza/commit/56be9eed8ac89632041608947108f87dfbcb28ab

8. Refactored the participants variable and improved readability.

'''Before'''
<pre>
@participants = SignedUpTeam.find_team_participants(assignment_id, session[:ip])
</pre>

'''After'''
<pre>
ip = session[:ip]
@participants = SignedUpTeam.find_team_participants(@id, ip)
</pre>

9. Previously signup_as_instructor_action provided unhelpful feedback to the instructor by only stating if the instructor could/couldn't assign a topic for a student. The refactored code provides the instructor with the student id of the person that they are assigning, the team that the student is on, and the topic that the instructor is assigning to the team.

'''Before'''
<pre>
def signup_as_instructor_action
user = User.find_by(name: params[:username])
if user.nil? # validate invalid user
flash[:error] = "That student does not exist!"
else
if AssignmentParticipant.exists? user_id: user.id, parent_id: params[:assignment_id]
if SignUpSheet.signup_team(params[:assignment_id], user.id, params[:topic_id])
flash[:success] = "You have successfully signed up the student for the topic!"
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'Instructor signed up student for topic: ' + params[:topic_id].to_s)
else
flash[:error] = "The student has already signed up for a topic!"
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'Instructor is signing up a student who already has a topic')
end
else
flash[:error] = "The student is not registered for the assignment!"
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'The student is not registered for the assignment: ' << user.id)
end
end
redirect_to controller: 'assignments', action: 'edit', id: params[:assignment_id]
end
</pre>

'''After'''
<pre>
def signup_as_instructor_action
#put name of student and team in log
# flash name of student and team
user = User.find_by(name: params[:username])
team = Team.find_team_for_assignment_and_user(params[:assignment_id], user.id).first
assignment = Assignment.find(params[:assignment_id])
if user.nil? # validate invalid user
flash[:error] = user.name + " does not exist!"
else #If the user is not null and the student exists then sign up student for topic
if AssignmentParticipant.exists? user_id: user.id, parent_id: params[:assignment_id]
if SignUpSheet.signup_team(params[:assignment_id], user.id, params[:topic_id])
flash[:success] = "You have successfully signed up " + user.name + " on " + team.name + " for the topic " + params[:topic_id].to_s
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'Instructor signed up ' + user.name + ' on team ' + team.name + ' for topic: ' + params[:topic_id].to_s)
else #If the students team already has a topic then cancel the sign up
flash[:error] = user.name + " on " + team.name + " has already signed up for a topic!"
ExpertizaLogger.info LoggerMessage.new(controller_name, '', 'Instructor is signing up a ' + user.name + 'on ' + team.name + ' who already has a topic')
end
else #If the student isn't a part of the assignment then cancel the sign up
flash[:error] = user.name + " is not registered for the assignment!"
ExpertizaLogger.info LoggerMessage.new(controller_name, '', user.name + ' is not registered for the assignment: ' + assignment.name)
end
end
redirect_to controller: 'assignments', action: 'edit', id: params[:assignment_id]
end
</pre>

10. delete_signup and delete_signup_as_instructor violated the DRY principle due to both functions using identical if/else statements. To solve this issue, delete_signup_heleper function was created.

'''Before'''
<pre>
def delete_signup
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
drop_topic_deadline = assignment.due_dates.find_by(deadline_type_id: 6)
# A student who has already submitted work should not be allowed to drop his/her topic!
# (A student/team has submitted if participant directory_num is non-null or submitted_hyperlinks is non-null.)
# If there is no drop topic deadline, student can drop topic at any time (if all the submissions are deleted)
# If there is a drop topic deadline, student cannot drop topic after this deadline.
if !participant.team.submitted_files.empty? or !participant.team.hyperlinks.empty?
flash[:error] = "You have already submitted your work, so you are not allowed to drop your topic."
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Dropping topic for already submitted a work: ' + params[:topic_id].to_s)
elsif !drop_topic_deadline.nil? and Time.now > drop_topic_deadline.due_at
flash[:error] = "You cannot drop your topic after the drop topic deadline!"
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Dropping topic for ended work: ' + params[:topic_id].to_s)
else
delete_signup_for_topic(assignment.id, params[:topic_id], session[:user].id)
flash[:success] = "You have successfully dropped your topic!"
ExpertizaLogger.info LoggerMessage.new(controller_name, session[:user].id, 'Student has dropped the topic: ' + params[:topic_id].to_s)
end
redirect_to action: 'list', id: params[:id]
end

def delete_signup_as_instructor
# find participant using assignment using team and topic ids
team = Team.find(params[:id])
assignment = Assignment.find(team.parent_id)
user = TeamsUser.find_by(team_id: team.id).user
participant = AssignmentParticipant.find_by(user_id: user.id, parent_id: assignment.id)
drop_topic_deadline = assignment.due_dates.find_by(deadline_type_id: 6)
if !participant.team.submitted_files.empty? or !participant.team.hyperlinks.empty?
flash[:error] = "The student has already submitted their work, so you are not allowed to remove them."
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Drop failed for already submitted work: ' + params[:topic_id].to_s)
elsif !drop_topic_deadline.nil? and Time.now > drop_topic_deadline.due_at
flash[:error] = "You cannot drop a student after the drop topic deadline!"
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Drop failed for ended work: ' + params[:topic_id].to_s)
else
delete_signup_for_topic(assignment.id, params[:topic_id], participant.user_id)
flash[:success] = "You have successfully dropped the student from the topic!"
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Student has been dropped from the topic: ' + params[:topic_id].to_s)
end
redirect_to controller: 'assignments', action: 'edit', id: assignment.id
end
</pre>

'''After'''
<pre>
def delete_signup_helper(isInstructor, participant, assignment, drop_topic_deadline)
messages = ["You have already submitted your work, so you are not allowed to drop your topic.",
"You cannot drop your topic after the drop topic deadline!",
"You have successfully dropped your topic!",
"The team has already submitted their work, so you are not allowed to remove them.",
"You cannot drop a student after the drop topic deadline!",
"You have successfully dropped the student from the topic!"
]
if isInstructor == false
flash1 = messages[0]
flash2 = messages[1]
flash3 = messages[2]
id_param = session[:user]
else
flash1 = messages[3]
flash2 = messages[4]
flash3 = messages[5]
id_param = participant
end

if !participant.team.submitted_files.empty? or !participant.team.hyperlinks.empty?
flash[:error] = flash1
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Dropping failed for already submitted a work: ' + params[:topic_id].to_s)
elsif !drop_topic_deadline.nil? and Time.now > drop_topic_deadline.due_at
flash[:error] = flash2
ExpertizaLogger.error LoggerMessage.new(controller_name, session[:user].id, 'Dropping failed for ended work: ' + params[:topic_id].to_s)
else
delete_signup_for_topic(assignment.id, params[:topic_id], id_param.id)
flash[:success] = flash3
ExpertizaLogger.info LoggerMessage.new(controller_name, session[:user].id, 'Student has dropped the topic: ' + params[:topic_id].to_s)
end
end

# this function is used to delete a previous signup
def delete_signup
participant = AssignmentParticipant.find(params[:id])
assignment = participant.assignment
drop_topic_deadline = assignment.due_dates.find_by(deadline_type_id: 6)
# A student who has already submitted work should not be allowed to drop his/her topic!
# (A student/team has submitted if participant directory_num is non-null or submitted_hyperlinks is non-null.)
# If there is no drop topic deadline, student can drop topic at any time (if all the submissions are deleted)
# If there is a drop topic deadline, student cannot drop topic after this deadline.
delete_signup_helper(false, participant, assignment, drop_topic_deadline)
redirect_to action: 'list', id: params[:id]
end

def delete_signup_as_instructor
# find participant using assignment using team and topic ids
team = Team.find(params[:id])
assignment = Assignment.find(team.parent_id)
user = TeamsUser.find_by(team_id: team.id).user
participant = AssignmentParticipant.find_by(user_id: user.id, parent_id: assignment.id)
drop_topic_deadline = assignment.due_dates.find_by(deadline_type_id: 6)
delete_signup_helper(true, participant, assignment, drop_topic_deadline)
redirect_to controller: 'assignments', action: 'edit', id: assignment.id
end
</pre>

== Testing ==
; RSpec
: signup_as_instructor_action is the only function updated. All other functions has remained the same. To run the spec file, run:
: rspec spec/controllers/signup_sheet_controller_spec.rb
; Physical Testing
:
# Login as instructor
# Hover on Manage Tab
# Click on Assignments Tab
# Click on Edit Button for "OSS project & documentation" assignment
# Select the Topic Tab
# Click the Green Check for any topic
# Enter a student UnityID and click submit

# Login as student
# Click on OSS project/Writing assignment 2
# Click on Signup sheet
# The list must be visible, which indiactes functionality is as before after refactoring list fucntion.