Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2022 - E2232: Revision planning tool

2022-04-26T02:57:57Z

Lpobrien:

==Project Goal==
The primary objective for this project is to create a tool that can be used for the revision of projects at a time after their original submission upon the delivery of constructive feedback from their peers or instructors. The revision planning tool is an important device that will be used to give students the ability to learn from the mistakes of their submissions, and improve the quality of their work prior to the due date. This will be done by completing the existing implementation for revision planning using the following project plan.

==Project Plan==
Merge code for revision planning into current beta

The functionality of E2152 works well but it was developed based on the previous beta and cannot be merged into the current beta. We will first merge the modification in the following files to the current beta and solve the conflicts.

===Files to be merged===
* app/controllers/revision_plan_questionnaires_controller.rb
* app/models/team.rb
* app/controllers/grades_controller.rb
* app/helpers/grades_helper.rb
* app/models/assignment_participant.rb
* app/models/response_map.rb
* app/views/grades/_participant_charts.html.erb
* app/views/grades/view_team.html.erb
* app/views/student_task/view.html.erb
* app/controllers/response_controller.rb
* app/views/response/response.html.erb
* config/routes.rb
* db/schema.rb
* spec/models/response_spec.rb
* spec/models/review_response_map_spec.rb
* spec/features/assignment_creation_general_tab_spec.rb
* app/models/revision_plan_team_map.rb

Merge code for revision planning with code for role based reviewing and topic specific rubrics

The functionality of E2261 works well and has been merged into the current beta. By merging revision planning tool and topic specific rubrics, in the peer review process,
In the first round of review, the rubric is designed by the instructor and varies by topic
In the second round of review, the rubric includes two parts: part 1 is designed by the instructor and varies by topic, part 2 is designed by the team based on the comments of the first round of review.

[[File:E2232_diagram.png]]

==Current Project Implementation==

The implementation of this now fits within the framework created by E2161 (Fall 2021).

What it does: In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. Authors are now able to leave a plan of work attached to their reviews in order to indicate their plan to move forward with the criticism given by the peer reviews. This is done by utilizing controller classes for advice and response that are tasked with creating the objects, as implemented in the advice and response model classes respectively, saving them to the database and displaying them in the html files. We also ensure that response can only be performed by the appropriate members by indicating that actions are only permitted by those with instructor privilege (teaching assistants, admins, and instructors) as well as the student who has been assigned the review can alter them (seen here).

<pre>
def action_allowed?
questionnaire = Questionnaire.find(params[:id])
if(user_logged_in? && questionnaire.owner?(session[:user].id))
return true
end
current_user_has_ta_privileges?
end
</pre>

Helper methods such as summary_helper.rb are used in order to receive values from existing objects, for example receiving the sentences as broken up into seperate array entries as is needed for the comments of the answers in the reviews.

<pre>
def get_sentences(answer)
if answer.nil?
return nil
end
sentences = answer.comments.split(/[.,?,!]/)
sentences.each{ |sentence| sentence.strip! }

sentences
end
</pre>

===Rationale===
The general workflow will be maintained from the previous iterations working on this project. The workflow used by past semesters is as follows.

[[File:E2152_Rationale.png|410px|center|Image from previous write up]]

===Previous implementation===
This project was last done in Fall 2021 (E2152). However, related merged code from E2161 (link above) means the implementation this semester may need to be changed from how E2152 did it.
* [https://github.com/expertiza/expertiza/pull/2131 Primary Pull Request for E2152]
* [https://github.com/expertiza/expertiza/pull/2152 Second Pull Request for Revision Planning]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2152._Revision_planning_tool Previous write up for E2152]

====Current Flow====
Current flow is dictated by previous iterations. The following content and images are created using those previous write ups.

Prior to the round 2 submission, you can look into your work, but the revision plan.
[[File:211129-2.png|700px|thumb|center]]
If there is a round 2 submission, and we did not deal with the "Revision Planning", then the "Your work" part becomes gray.
[[File:211129-5.png|700px|thumb|center]]
After editing the "Revision Planning", we can submit our work.
[[File:211129-6.png|700px|thumb|center]]

=====Current User Interface=====
Current user interface has been put in place by the previous iterations, the following interface image is from those iterations.

[[File:after1.png|700px|thumb|center|Reviews cannot be done during the submission phase]]

====Design Changes====
Because the changes to the current implementation is limited to specific implementation, the UML design of the project will remain the same as the previous implementation.

[[File:E2152_Design.png|1000px|center]]

==Test Plan==
===Merge existing RSpec tests for revision planning into current beta===
We will first merge the existing RSpec tests of E2152 to the current beta, then run and pass these tests. More comments can be made in rspec tests as well. Observe the coverage of the individual tests.
Existing RSpec tests to be merged
* Controllers
** rspec spec/controllers/grades_controller_spec.rb
** rspec spec/controllers/questionnaires_controller_spec.rb
** rspec spec/controllers/questions_controller_spec.rb
** rspec spec/controllers/student_teams_controller_spec.rb
** spec/controllers/response_controller_spec.rb
** spec/controllers/revision_plan_questionnaires_controller_spec.rb
** spec/factories/revision_plan_factory.rb
* Models
** spec/models/response_spec.rb.
** spec/models/review_response_map_spec.rb
* Helpers
** rspec spec/heplers/grades_helper.rb

===Develop New RSpec Tests===
The RSpec tests are written to test both controllers and models. RSpec testing will be added in order to increase coverage. To do this we will test the flows associated with different user types. Currently the only passing tests are related to student flows and tests may be added that work with instructors. These may include editing the reviews once they are created, and ensuring that an instructor has the ability to make edits.

Testing is done for ensuring actions are allowed for teachers as well as the assigned student:
<pre>
describe '#action_allowed?' do
let(:questionnaire) { build(:questionnaire, id: 1) }
context 'when the role of current user is Super-Admin' do
# Checking for Super-Admin
it 'allows certain action' do
controller.params = { id: '1' }
stub_current_user(super_admin, super_admin.role.name, super_admin.role)
expect(controller.send(:action_allowed?)).to be_truthy
end
end
context 'when the role of current user is Instructor' do
# Checking for Instructor
it 'allows certain action' do
controller.params = { id: '1' }
stub_current_user(instructor1, instructor1.role.name, instructor1.role)
expect(controller.send(:action_allowed?)).to be_truthy
end
end
context 'when the role of current user is Student' do
# Checking for Student
it 'refuses certain action' do
controller.params = { id: '1' }
stub_current_user(student1, student1.role.name, student1.role)
expect(controller.send(:action_allowed?)).to be_falsey
end
end
end
</pre>

Testing is also done in order ensure this in response controllers, and questionnaire controllers. Testing is done for model objects such as displaying as html (below) and ensuring fields are correctly returned
<pre>
context 'when prefix is not nil, which means view_score page in instructor end' do
it 'returns corresponding html code' do
allow(response).to receive(:questionnaire_by_answer).with(answer).and_return(questionnaire)
allow(questionnaire).to receive(:max_question_score).and_return(5)
allow(questionnaire).to receive(:id).and_return(1)
allow(assignment).to receive(:id).and_return(1)
allow(question).to receive(:view_completed_question).with(1, answer, 5, nil, nil).and_return('Question HTML code')
expect(response.display_as_html('Instructor end', 0)).to eq('<h4><B>Review 0</B></h4><B>Reviewer: </B>no one (no name)   '\
"<a href=\"#\" name= \"review_Instructor end_1Link\" onClick=\"toggleElement('review_Instructor end_1','review');return false;\">"\
"hide review</a><BR/><h5>Review Responses</h5><table id=\"review_Instructor end_1\" class=\"table table-bordered\">"\
"<tr class=\"warning\"><td>Question HTML code</td></tr></table><h5>Additional Comment</h5>"\
"<table id=\"review_Instructor end_1\" class=\"table table-bordered\"><tr><td></td></tr></table>")
end
end
</pre>

rspec tests are also needed for validing saves for controller classes, and ensuring model functionality in response objects.

===Manual Testing===

* Instructor
** Can Review rubric varied by topic be enabled?
** Can different roles be chosen for each questionnaire?
** Can an assignment with revision planning enabled be created?
** Can an assignment with 2 rounds of review be set up?

* Assignment participant
** If the revision-planning rubric can be edited or not?
** Are participants allowed to create/edit revision plan when round 1+ (1 or greater than 1) reviews have finished?
** Is revision plan editing disabled when the assignment is in review stage?
** Does participants show a summary of score for revision plan after review deadline has expired?

* Assignment reviewer
** Does the rubric page show the topic-specific rubric?
** Does the rubric page show the revision plan rubric?

==Team Information==
* Lawrence O'Brien (lpobrien)
* Joshua Lin (jlin36)
* Weiqi Sun (wsun23)
* Wyatt Plaga (wgplaga)
* '''Mentor:''' Nicholas Himes (nnhimes)

==Links==
* Pull request: https://github.com/expertiza/expertiza/pull/2395
* Github repo: https://github.com/wsun23/expertiza/tree/E2232
* VCL: http://152.7.99.215:8080/

CSC/ECE 517 Spring 2022 - E2232: Revision planning tool

2022-04-26T02:54:46Z

Lpobrien: /* Implementation By Team */

CSC/ECE 517 Spring 2022 - E2232: Revision planning tool

2022-04-26T02:54:26Z

Lpobrien: /* Develop New RSpec Tests */

==Project Goal==
The primary objective for this project is to create a tool that can be used for the revision of projects at a time after their original submission upon the delivery of constructive feedback from their peers or instructors. The revision planning tool is an important device that will be used to give students the ability to learn from the mistakes of their submissions, and improve the quality of their work prior to the due date. This will be done by completing the existing implementation for revision planning using the following project plan.

==Project Plan==
Merge code for revision planning into current beta

The functionality of E2152 works well but it was developed based on the previous beta and cannot be merged into the current beta. We will first merge the modification in the following files to the current beta and solve the conflicts.

===Files to be merged===
* app/controllers/revision_plan_questionnaires_controller.rb
* app/models/team.rb
* app/controllers/grades_controller.rb
* app/helpers/grades_helper.rb
* app/models/assignment_participant.rb
* app/models/response_map.rb
* app/views/grades/_participant_charts.html.erb
* app/views/grades/view_team.html.erb
* app/views/student_task/view.html.erb
* app/controllers/response_controller.rb
* app/views/response/response.html.erb
* config/routes.rb
* db/schema.rb
* spec/models/response_spec.rb
* spec/models/review_response_map_spec.rb
* spec/features/assignment_creation_general_tab_spec.rb
* app/models/revision_plan_team_map.rb

Merge code for revision planning with code for role based reviewing and topic specific rubrics

The functionality of E2261 works well and has been merged into the current beta. By merging revision planning tool and topic specific rubrics, in the peer review process,
In the first round of review, the rubric is designed by the instructor and varies by topic
In the second round of review, the rubric includes two parts: part 1 is designed by the instructor and varies by topic, part 2 is designed by the team based on the comments of the first round of review.

[[File:E2232_diagram.png]]

==Current Project Implementation==

The implementation of this now fits within the framework created by E2161 (Fall 2021).

What it does: In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. Authors are now able to leave a plan of work attached to their reviews in order to indicate their plan to move forward with the criticism given by the peer reviews. This is done by utilizing controller classes for advice and response that are tasked with creating the objects, as implemented in the advice and response model classes respectively, saving them to the database and displaying them in the html files. We also ensure that response can only be performed by the appropriate members by indicating that actions are only permitted by those with instructor privilege (teaching assistants, admins, and instructors) as well as the student who has been assigned the review can alter them (seen here).

<pre>
def action_allowed?
questionnaire = Questionnaire.find(params[:id])
if(user_logged_in? && questionnaire.owner?(session[:user].id))
return true
end
current_user_has_ta_privileges?
end
</pre>

Helper methods such as summary_helper.rb are used in order to receive values from existing objects, for example receiving the sentences as broken up into seperate array entries as is needed for the comments of the answers in the reviews.

<pre>
def get_sentences(answer)
if answer.nil?
return nil
end
sentences = answer.comments.split(/[.,?,!]/)
sentences.each{ |sentence| sentence.strip! }

sentences
end
</pre>

===Rationale===
The general workflow will be maintained from the previous iterations working on this project. The workflow used by past semesters is as follows.

[[File:E2152_Rationale.png|410px|center|Image from previous write up]]

===Previous implementation===
This project was last done in Fall 2021 (E2152). However, related merged code from E2161 (link above) means the implementation this semester may need to be changed from how E2152 did it.
* [https://github.com/expertiza/expertiza/pull/2131 Primary Pull Request for E2152]
* [https://github.com/expertiza/expertiza/pull/2152 Second Pull Request for Revision Planning]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2152._Revision_planning_tool Previous write up for E2152]

====Current Flow====
Current flow is dictated by previous iterations. The following content and images are created using those previous write ups.

Prior to the round 2 submission, you can look into your work, but the revision plan.
[[File:211129-2.png|700px|thumb|center]]
If there is a round 2 submission, and we did not deal with the "Revision Planning", then the "Your work" part becomes gray.
[[File:211129-5.png|700px|thumb|center]]
After editing the "Revision Planning", we can submit our work.
[[File:211129-6.png|700px|thumb|center]]

=====Current User Interface=====
Current user interface has been put in place by the previous iterations, the following interface image is from those iterations.

[[File:after1.png|700px|thumb|center|Reviews cannot be done during the submission phase]]

====Design Changes====
Because the changes to the current implementation is limited to specific implementation, the UML design of the project will remain the same as the previous implementation.

[[File:E2152_Design.png|1000px|center]]

==Test Plan==
===Merge existing RSpec tests for revision planning into current beta===
We will first merge the existing RSpec tests of E2152 to the current beta, then run and pass these tests. More comments can be made in rspec tests as well. Observe the coverage of the individual tests.
Existing RSpec tests to be merged
* Controllers
** rspec spec/controllers/grades_controller_spec.rb
** rspec spec/controllers/questionnaires_controller_spec.rb
** rspec spec/controllers/questions_controller_spec.rb
** rspec spec/controllers/student_teams_controller_spec.rb
** spec/controllers/response_controller_spec.rb
** spec/controllers/revision_plan_questionnaires_controller_spec.rb
** spec/factories/revision_plan_factory.rb
* Models
** spec/models/response_spec.rb.
** spec/models/review_response_map_spec.rb
* Helpers
** rspec spec/heplers/grades_helper.rb

===Develop New RSpec Tests===
The RSpec tests are written to test both controllers and models. RSpec testing will be added in order to increase coverage. To do this we will test the flows associated with different user types. Currently the only passing tests are related to student flows and tests may be added that work with instructors. These may include editing the reviews once they are created, and ensuring that an instructor has the ability to make edits.

Testing is done for ensuring actions are allowed for teachers as well as the assigned student:
<pre>
describe '#action_allowed?' do
let(:questionnaire) { build(:questionnaire, id: 1) }
context 'when the role of current user is Super-Admin' do
# Checking for Super-Admin
it 'allows certain action' do
controller.params = { id: '1' }
stub_current_user(super_admin, super_admin.role.name, super_admin.role)
expect(controller.send(:action_allowed?)).to be_truthy
end
end
context 'when the role of current user is Instructor' do
# Checking for Instructor
it 'allows certain action' do
controller.params = { id: '1' }
stub_current_user(instructor1, instructor1.role.name, instructor1.role)
expect(controller.send(:action_allowed?)).to be_truthy
end
end
context 'when the role of current user is Student' do
# Checking for Student
it 'refuses certain action' do
controller.params = { id: '1' }
stub_current_user(student1, student1.role.name, student1.role)
expect(controller.send(:action_allowed?)).to be_falsey
end
end
end
</pre>

Testing is also done in order ensure this in response controllers, and questionnaire controllers. Testing is done for model objects such as displaying as html (below) and ensuring fields are correctly returned
<pre>
context 'when prefix is not nil, which means view_score page in instructor end' do
it 'returns corresponding html code' do
allow(response).to receive(:questionnaire_by_answer).with(answer).and_return(questionnaire)
allow(questionnaire).to receive(:max_question_score).and_return(5)
allow(questionnaire).to receive(:id).and_return(1)
allow(assignment).to receive(:id).and_return(1)
allow(question).to receive(:view_completed_question).with(1, answer, 5, nil, nil).and_return('Question HTML code')
expect(response.display_as_html('Instructor end', 0)).to eq('<h4><B>Review 0</B></h4><B>Reviewer: </B>no one (no name)   '\
"<a href=\"#\" name= \"review_Instructor end_1Link\" onClick=\"toggleElement('review_Instructor end_1','review');return false;\">"\
"hide review</a><BR/><h5>Review Responses</h5><table id=\"review_Instructor end_1\" class=\"table table-bordered\">"\
"<tr class=\"warning\"><td>Question HTML code</td></tr></table><h5>Additional Comment</h5>"\
"<table id=\"review_Instructor end_1\" class=\"table table-bordered\"><tr><td></td></tr></table>")
end
end
</pre>

rspec tests are also needed for validing saves for controller classes, and ensuring model functionality in response objects.

===Manual Testing===

* Instructor
** Can Review rubric varied by topic be enabled?
** Can different roles be chosen for each questionnaire?
** Can an assignment with revision planning enabled be created?
** Can an assignment with 2 rounds of review be set up?

* Assignment participant
** If the revision-planning rubric can be edited or not?
** Are participants allowed to create/edit revision plan when round 1+ (1 or greater than 1) reviews have finished?
** Is revision plan editing disabled when the assignment is in review stage?
** Does participants show a summary of score for revision plan after review deadline has expired?

* Assignment reviewer
** Does the rubric page show the topic-specific rubric?
** Does the rubric page show the revision plan rubric?

==Implementation By Team==
Halfway through the project deadline, there were new changes that were merged into Expertiza's beta branch. With these new changes in place, our code that was based off the old version of the beta branch started failing tests and causing errors. We fixed these changes that mainly occurred in advice_controller.rb. Some of these failures were also rolled over from the last team's implementation of this same project. Most of these errors occurred in response.rb

==Team Information==
* Lawrence O'Brien (lpobrien)
* Joshua Lin (jlin36)
* Weiqi Sun (wsun23)
* Wyatt Plaga (wgplaga)
* '''Mentor:''' Nicholas Himes (nnhimes)

CSC/ECE 517 Spring 2022 - E2232: Revision planning tool

2022-04-26T02:52:08Z

Lpobrien: /* Test Plan */

==Project Goal==
The primary objective for this project is to create a tool that can be used for the revision of projects at a time after their original submission upon the delivery of constructive feedback from their peers or instructors. The revision planning tool is an important device that will be used to give students the ability to learn from the mistakes of their submissions, and improve the quality of their work prior to the due date. This will be done by completing the existing implementation for revision planning using the following project plan.

==Project Plan==
Merge code for revision planning into current beta

The functionality of E2152 works well but it was developed based on the previous beta and cannot be merged into the current beta. We will first merge the modification in the following files to the current beta and solve the conflicts.

===Files to be merged===
* app/controllers/revision_plan_questionnaires_controller.rb
* app/models/team.rb
* app/controllers/grades_controller.rb
* app/helpers/grades_helper.rb
* app/models/assignment_participant.rb
* app/models/response_map.rb
* app/views/grades/_participant_charts.html.erb
* app/views/grades/view_team.html.erb
* app/views/student_task/view.html.erb
* app/controllers/response_controller.rb
* app/views/response/response.html.erb
* config/routes.rb
* db/schema.rb
* spec/models/response_spec.rb
* spec/models/review_response_map_spec.rb
* spec/features/assignment_creation_general_tab_spec.rb
* app/models/revision_plan_team_map.rb

Merge code for revision planning with code for role based reviewing and topic specific rubrics

The functionality of E2261 works well and has been merged into the current beta. By merging revision planning tool and topic specific rubrics, in the peer review process,
In the first round of review, the rubric is designed by the instructor and varies by topic
In the second round of review, the rubric includes two parts: part 1 is designed by the instructor and varies by topic, part 2 is designed by the team based on the comments of the first round of review.

[[File:E2232_diagram.png]]

==Current Project Implementation==

The implementation of this now fits within the framework created by E2161 (Fall 2021).

What it does: In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. Authors are now able to leave a plan of work attached to their reviews in order to indicate their plan to move forward with the criticism given by the peer reviews. This is done by utilizing controller classes for advice and response that are tasked with creating the objects, as implemented in the advice and response model classes respectively, saving them to the database and displaying them in the html files. We also ensure that response can only be performed by the appropriate members by indicating that actions are only permitted by those with instructor privilege (teaching assistants, admins, and instructors) as well as the student who has been assigned the review can alter them (seen here).

<pre>
def action_allowed?
questionnaire = Questionnaire.find(params[:id])
if(user_logged_in? && questionnaire.owner?(session[:user].id))
return true
end
current_user_has_ta_privileges?
end
</pre>

Helper methods such as summary_helper.rb are used in order to receive values from existing objects, for example receiving the sentences as broken up into seperate array entries as is needed for the comments of the answers in the reviews.

<pre>
def get_sentences(answer)
if answer.nil?
return nil
end
sentences = answer.comments.split(/[.,?,!]/)
sentences.each{ |sentence| sentence.strip! }

sentences
end
</pre>

===Rationale===
The general workflow will be maintained from the previous iterations working on this project. The workflow used by past semesters is as follows.

[[File:E2152_Rationale.png|410px|center|Image from previous write up]]

===Previous implementation===
This project was last done in Fall 2021 (E2152). However, related merged code from E2161 (link above) means the implementation this semester may need to be changed from how E2152 did it.
* [https://github.com/expertiza/expertiza/pull/2131 Primary Pull Request for E2152]
* [https://github.com/expertiza/expertiza/pull/2152 Second Pull Request for Revision Planning]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2152._Revision_planning_tool Previous write up for E2152]

====Current Flow====
Current flow is dictated by previous iterations. The following content and images are created using those previous write ups.

Prior to the round 2 submission, you can look into your work, but the revision plan.
[[File:211129-2.png|700px|thumb|center]]
If there is a round 2 submission, and we did not deal with the "Revision Planning", then the "Your work" part becomes gray.
[[File:211129-5.png|700px|thumb|center]]
After editing the "Revision Planning", we can submit our work.
[[File:211129-6.png|700px|thumb|center]]

=====Current User Interface=====
Current user interface has been put in place by the previous iterations, the following interface image is from those iterations.

[[File:after1.png|700px|thumb|center|Reviews cannot be done during the submission phase]]

====Design Changes====
Because the changes to the current implementation is limited to specific implementation, the UML design of the project will remain the same as the previous implementation.

[[File:E2152_Design.png|1000px|center]]

==Test Plan==
===Merge existing RSpec tests for revision planning into current beta===
We will first merge the existing RSpec tests of E2152 to the current beta, then run and pass these tests. More comments can be made in rspec tests as well. Observe the coverage of the individual tests.
Existing RSpec tests to be merged
* Controllers
** rspec spec/controllers/grades_controller_spec.rb
** rspec spec/controllers/questionnaires_controller_spec.rb
** rspec spec/controllers/questions_controller_spec.rb
** rspec spec/controllers/student_teams_controller_spec.rb
** spec/controllers/response_controller_spec.rb
** spec/controllers/revision_plan_questionnaires_controller_spec.rb
** spec/factories/revision_plan_factory.rb
* Models
** spec/models/response_spec.rb.
** spec/models/review_response_map_spec.rb
* Helpers
** rspec spec/heplers/grades_helper.rb

===Develop New RSpec Tests===
The RSpec tests are written to test both controllers and models. RSpec testing will be added in order to increase coverage. To do this we will test the flows associated with different user types. Currently the only passing tests are related to student flows and tests may be added that work with instructors. These may include editing the reviews once they are created, and ensuring that an instructor has the ability to make edits.

Testing is done for ensuring actions are allowed for teachers as well as the assigned student:
<pre>
describe '#action_allowed?' do
let(:questionnaire) { build(:questionnaire, id: 1) }
context 'when the role of current user is Super-Admin' do
# Checking for Super-Admin
it 'allows certain action' do
controller.params = { id: '1' }
stub_current_user(super_admin, super_admin.role.name, super_admin.role)
expect(controller.send(:action_allowed?)).to be_truthy
end
end
context 'when the role of current user is Instructor' do
# Checking for Instructor
it 'allows certain action' do
controller.params = { id: '1' }
stub_current_user(instructor1, instructor1.role.name, instructor1.role)
expect(controller.send(:action_allowed?)).to be_truthy
end
end
context 'when the role of current user is Student' do
# Checking for Student
it 'refuses certain action' do
controller.params = { id: '1' }
stub_current_user(student1, student1.role.name, student1.role)
expect(controller.send(:action_allowed?)).to be_falsey
end
end
end
</pre>

Testing is also done in order ensure this in response controllers, and questionnaire controllers. Testing is done for model objects such as displaying as html (below) and ensuring fields are correctly returned
<pre>
context 'when prefix is not nil, which means view_score page in instructor end' do
it 'returns corresponding html code' do
allow(response).to receive(:questionnaire_by_answer).with(answer).and_return(questionnaire)
allow(questionnaire).to receive(:max_question_score).and_return(5)
allow(questionnaire).to receive(:id).and_return(1)
allow(assignment).to receive(:id).and_return(1)
allow(question).to receive(:view_completed_question).with(1, answer, 5, nil, nil).and_return('Question HTML code')
expect(response.display_as_html('Instructor end', 0)).to eq('<h4><B>Review 0</B></h4><B>Reviewer: </B>no one (no name)   '\
"<a href=\"#\" name= \"review_Instructor end_1Link\" onClick=\"toggleElement('review_Instructor end_1','review');return false;\">"\
"hide review</a><BR/><h5>Review Responses</h5><table id=\"review_Instructor end_1\" class=\"table table-bordered\">"\
"<tr class=\"warning\"><td>Question HTML code</td></tr></table><h5>Additional Comment</h5>"\
"<table id=\"review_Instructor end_1\" class=\"table table-bordered\"><tr><td></td></tr></table>")
end
end
</pre>

===Manual Testing===

* Instructor
** Can Review rubric varied by topic be enabled?
** Can different roles be chosen for each questionnaire?
** Can an assignment with revision planning enabled be created?
** Can an assignment with 2 rounds of review be set up?

* Assignment participant
** If the revision-planning rubric can be edited or not?
** Are participants allowed to create/edit revision plan when round 1+ (1 or greater than 1) reviews have finished?
** Is revision plan editing disabled when the assignment is in review stage?
** Does participants show a summary of score for revision plan after review deadline has expired?

* Assignment reviewer
** Does the rubric page show the topic-specific rubric?
** Does the rubric page show the revision plan rubric?

==Implementation By Team==
Halfway through the project deadline, there were new changes that were merged into Expertiza's beta branch. With these new changes in place, our code that was based off the old version of the beta branch started failing tests and causing errors. We fixed these changes that mainly occurred in advice_controller.rb. Some of these failures were also rolled over from the last team's implementation of this same project. Most of these errors occurred in response.rb

==Team Information==
* Lawrence O'Brien (lpobrien)
* Joshua Lin (jlin36)
* Weiqi Sun (wsun23)
* Wyatt Plaga (wgplaga)
* '''Mentor:''' Nicholas Himes (nnhimes)

CSC/ECE 517 Spring 2022 - E2232: Revision planning tool

2022-04-26T02:47:51Z

Lpobrien: /* Current Project Implementation */

==Project Goal==
The primary objective for this project is to create a tool that can be used for the revision of projects at a time after their original submission upon the delivery of constructive feedback from their peers or instructors. The revision planning tool is an important device that will be used to give students the ability to learn from the mistakes of their submissions, and improve the quality of their work prior to the due date. This will be done by completing the existing implementation for revision planning using the following project plan.

==Project Plan==
Merge code for revision planning into current beta

The functionality of E2152 works well but it was developed based on the previous beta and cannot be merged into the current beta. We will first merge the modification in the following files to the current beta and solve the conflicts.

===Files to be merged===
* app/controllers/revision_plan_questionnaires_controller.rb
* app/models/team.rb
* app/controllers/grades_controller.rb
* app/helpers/grades_helper.rb
* app/models/assignment_participant.rb
* app/models/response_map.rb
* app/views/grades/_participant_charts.html.erb
* app/views/grades/view_team.html.erb
* app/views/student_task/view.html.erb
* app/controllers/response_controller.rb
* app/views/response/response.html.erb
* config/routes.rb
* db/schema.rb
* spec/models/response_spec.rb
* spec/models/review_response_map_spec.rb
* spec/features/assignment_creation_general_tab_spec.rb
* app/models/revision_plan_team_map.rb

Merge code for revision planning with code for role based reviewing and topic specific rubrics

The functionality of E2261 works well and has been merged into the current beta. By merging revision planning tool and topic specific rubrics, in the peer review process,
In the first round of review, the rubric is designed by the instructor and varies by topic
In the second round of review, the rubric includes two parts: part 1 is designed by the instructor and varies by topic, part 2 is designed by the team based on the comments of the first round of review.

[[File:E2232_diagram.png]]

==Current Project Implementation==

The implementation of this now fits within the framework created by E2161 (Fall 2021).

What it does: In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. Authors are now able to leave a plan of work attached to their reviews in order to indicate their plan to move forward with the criticism given by the peer reviews. This is done by utilizing controller classes for advice and response that are tasked with creating the objects, as implemented in the advice and response model classes respectively, saving them to the database and displaying them in the html files. We also ensure that response can only be performed by the appropriate members by indicating that actions are only permitted by those with instructor privilege (teaching assistants, admins, and instructors) as well as the student who has been assigned the review can alter them (seen here).

<pre>
def action_allowed?
questionnaire = Questionnaire.find(params[:id])
if(user_logged_in? && questionnaire.owner?(session[:user].id))
return true
end
current_user_has_ta_privileges?
end
</pre>

Helper methods such as summary_helper.rb are used in order to receive values from existing objects, for example receiving the sentences as broken up into seperate array entries as is needed for the comments of the answers in the reviews.

<pre>
def get_sentences(answer)
if answer.nil?
return nil
end
sentences = answer.comments.split(/[.,?,!]/)
sentences.each{ |sentence| sentence.strip! }

sentences
end
</pre>

===Rationale===
The general workflow will be maintained from the previous iterations working on this project. The workflow used by past semesters is as follows.

[[File:E2152_Rationale.png|410px|center|Image from previous write up]]

===Previous implementation===
This project was last done in Fall 2021 (E2152). However, related merged code from E2161 (link above) means the implementation this semester may need to be changed from how E2152 did it.
* [https://github.com/expertiza/expertiza/pull/2131 Primary Pull Request for E2152]
* [https://github.com/expertiza/expertiza/pull/2152 Second Pull Request for Revision Planning]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2152._Revision_planning_tool Previous write up for E2152]

====Current Flow====
Current flow is dictated by previous iterations. The following content and images are created using those previous write ups.

Prior to the round 2 submission, you can look into your work, but the revision plan.
[[File:211129-2.png|700px|thumb|center]]
If there is a round 2 submission, and we did not deal with the "Revision Planning", then the "Your work" part becomes gray.
[[File:211129-5.png|700px|thumb|center]]
After editing the "Revision Planning", we can submit our work.
[[File:211129-6.png|700px|thumb|center]]

=====Current User Interface=====
Current user interface has been put in place by the previous iterations, the following interface image is from those iterations.

[[File:after1.png|700px|thumb|center|Reviews cannot be done during the submission phase]]

====Design Changes====
Because the changes to the current implementation is limited to specific implementation, the UML design of the project will remain the same as the previous implementation.

[[File:E2152_Design.png|1000px|center]]

==Test Plan==
===Merge existing RSpec tests for revision planning into current beta===
We will first merge the existing RSpec tests of E2152 to the current beta, then run and pass these tests. More comments can be made in rspec tests as well. Observe the coverage of the individual tests.
Existing RSpec tests to be merged
* Controllers
** rspec spec/controllers/grades_controller_spec.rb
** rspec spec/controllers/questionnaires_controller_spec.rb
** rspec spec/controllers/questions_controller_spec.rb
** rspec spec/controllers/student_teams_controller_spec.rb
** spec/controllers/response_controller_spec.rb
** spec/controllers/revision_plan_questionnaires_controller_spec.rb
** spec/factories/revision_plan_factory.rb
* Models
** spec/models/response_spec.rb.
** spec/models/review_response_map_spec.rb
* Helpers
** rspec spec/heplers/grades_helper.rb

===Develop New RSpec Tests===
The RSpec tests are written to test both controllers and models. RSpec testing will be added in order to increase coverage. To do this we will test the flows associated with different user types. Currently the only passing tests are related to student flows and tests may be added that work with instructors. These may include editing the reviews once they are created, and ensuring that an instructor has the ability to make edits.

===Manual Testing===

* Instructor
** Can Review rubric varied by topic be enabled?
** Can different roles be chosen for each questionnaire?
** Can an assignment with revision planning enabled be created?
** Can an assignment with 2 rounds of review be set up?

* Assignment participant
** If the revision-planning rubric can be edited or not?
** Are participants allowed to create/edit revision plan when round 1+ (1 or greater than 1) reviews have finished?
** Is revision plan editing disabled when the assignment is in review stage?
** Does participants show a summary of score for revision plan after review deadline has expired?

* Assignment reviewer
** Does the rubric page show the topic-specific rubric?
** Does the rubric page show the revision plan rubric?

==Implementation By Team==
Halfway through the project deadline, there were new changes that were merged into Expertiza's beta branch. With these new changes in place, our code that was based off the old version of the beta branch started failing tests and causing errors. We fixed these changes that mainly occurred in advice_controller.rb. Some of these failures were also rolled over from the last team's implementation of this same project. Most of these errors occurred in response.rb

==Team Information==
* Lawrence O'Brien (lpobrien)
* Joshua Lin (jlin36)
* Weiqi Sun (wsun23)
* Wyatt Plaga (wgplaga)
* '''Mentor:''' Nicholas Himes (nnhimes)

CSC/ECE 517 Spring 2022 - E2232: Revision planning tool

2022-04-12T01:33:57Z

Lpobrien:

==Project Goal==
The primary objective for this project is to create a tool that can be used for the revision of projects at a time after their original submission upon the delivery of constructive feedback from their peers or instructors. The revision planning tool is an important device that will be used to give students the ability to learn from the mistakes of their submissions, and improve the quality of their work prior to the due date. This will be done by completing the existing implementation for revision planning using the following project plan.

==Project Plan==
Merge code for revision planning into current beta

The functionality of E2152 works well but it was developed based on the previous beta and cannot be merged into the current beta. We will first merge the modification in the following files to the current beta and solve the conflicts.

===Files to be merged===
* app/controllers/revision_plan_questionnaires_controller.rb
* app/models/team.rb
* app/controllers/grades_controller.rb
* app/helpers/grades_helper.rb
* app/models/assignment_participant.rb
* app/models/response_map.rb
* app/views/grades/_participant_charts.html.erb
* app/views/grades/view_team.html.erb
* app/views/student_task/view.html.erb
* app/controllers/response_controller.rb
* app/views/response/response.html.erb
* config/routes.rb
* db/schema.rb
* spec/models/response_spec.rb
* spec/models/review_response_map_spec.rb
* spec/features/assignment_creation_general_tab_spec.rb
* app/models/revision_plan_team_map.rb

Merge code for revision planning with code for role based reviewing and topic specific rubrics

The functionality of E2261 works well and has been merged into the current beta. By merging revision planning tool and topic specific rubrics, in the peer review process,
In the first round of review, the rubric is designed by the instructor and varies by topic
In the second round of review, the rubric includes two parts: part 1 is designed by the instructor and varies by topic, part 2 is designed by the team based on the comments of the first round of review.

[[File:E2232_diagram.png]]

==Current Project Implementation==

The implementation of this needs to fit within the framework created by E2161 (Fall 2021).

What it does: In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

===Rationale===
The general workflow will be maintained from the previous iterations working on this project. The workflow used by past semesters is as follows.

[[File:E2152_Rationale.png|410px|center|Image from previous write up]]

===Previous implementation===
This project was last done in Fall 2021 (E2152). However, related merged code from E2161 (link above) means the implementation this semester may need to be changed from how E2152 did it.
* [https://github.com/expertiza/expertiza/pull/2131 Primary Pull Request for E2152]
* [https://github.com/expertiza/expertiza/pull/2152 Second Pull Request for Revision Planning]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2152._Revision_planning_tool Previous write up for E2152]

====Current Flow====
Current flow is dictated by previous iterations. The following content and images are created using those previous write ups.

Prior to the round 2 submission, you can look into your work, but the revision plan.
[[File:211129-2.png|700px|thumb|center]]
If there is a round 2 submission, and we did not deal with the "Revision Planning", then the "Your work" part becomes gray.
[[File:211129-5.png|700px|thumb|center]]
After editing the "Revision Planning", we can submit our work.
[[File:211129-6.png|700px|thumb|center]]

=====Current User Interface=====
Current user interface has been put in place by the previous iterations, the following interface image is from those iterations.

[[File:after1.png|700px|thumb|center|Reviews cannot be done during the submission phase]]

===Implementation to be completed===
There are actually two E2152 pull requests in Expertiza right now - the PR we saw in the demo has less recent commits than the other. And the PR we did not see has less files changed as well. They started with last year's project, so the beta they started with was the beta from last year. The changes since then will show up as merge conflicts if this project is merged.

The functionality of this project seems to work well and would be a valuable addition to Expertiza, but it cannot be merged in its current state. There are many artifacts in their PR from an old version of beta. This is because the team merged the previous teams' code into current beta, but did not remove the differences unrelated to their project. The team knew of these problems before the demo, but did not fix them.

Because the existing functionality encompasses the intended instructions fairly clearly the work that needs to be done for our purposes would be to pass rspec tests that currently cause the build to fail. This functionality would involve us causing different flows based upon the type of user completing the review. Shown below. HTML changes must also be made in order to pass, specifically needing a change to the display_as_html, done_by_staff_participant and participant_scores methods to return the correct html values. Currently display_as_html is returning an unknown error causing a msitake in the html delivered. The done_by_staff_participant is not present in the code and therefore returns a method not found error. particpant_scores is returning an error that is the result of an incorrect calculation for total_scores. More work will need to be done for each of these bugs to investigate the root cause and establish a solution.

Pull request E2131 is failing rspec tests in ReviewMappingHelper due to a currently unknown OpenSSL error. More work will be needed to determine the specific cause and nature of this error.

More comments can be made in rspec tests as well. It is unclear what the coverage is of the individual tests. The file revision_plan_team_map_test.rb has nothing substantial in it.

[[File:Failing_rspec.PNG|1000px|center]]

====Design Changes====
Because the changes to the current implementation is limited to specific implementation, the UML design of the project will remain the same as the previous implementation.

[[File:E2152_Design.png|1000px|center]]

==Test Plan==
===Merge existing RSpec tests for revision planning into current beta===
We will first merge the existing RSpec tests of E2152 to the current beta, then run and pass these tests. More comments can be made in rspec tests as well. Observe the coverage of the individual tests.
Existing RSpec tests to be merged
* Controllers
** rspec spec/controllers/grades_controller_spec.rb
** rspec spec/controllers/questionnaires_controller_spec.rb
** rspec spec/controllers/questions_controller_spec.rb
** rspec spec/controllers/student_teams_controller_spec.rb
** spec/controllers/response_controller_spec.rb
** spec/controllers/revision_plan_questionnaires_controller_spec.rb
** spec/factories/revision_plan_factory.rb
* Models
** spec/models/response_spec.rb.
** spec/models/review_response_map_spec.rb
* Helpers
** rspec spec/heplers/grades_helper.rb

===Develop New RSpec Tests===
The RSpec tests are written to test both controllers and models. RSpec testing will be added in order to increase coverage. To do this we will test the flows associated with different user types. Currently the only passing tests are related to student flows and tests may be added that work with instructors. These may include editing the reviews once they are created, and ensuring that an instructor has the ability to make edits.

===Manual Testing===

* Instructor
** Can Review rubric varied by topic be enabled?
** Can different roles be chosen for each questionnaire?
** Can an assignment with revision planning enabled be created?
** Can an assignment with 2 rounds of review be set up?

* Assignment participant
** If the revision-planning rubric can be edited or not?
** Are participants allowed to create/edit revision plan when round 1+ (1 or greater than 1) reviews have finished?
** Is revision plan editing disabled when the assignment is in review stage?
** Does participants show a summary of score for revision plan after review deadline has expired?

* Assignment reviewer
** Does the rubric page show the topic-specific rubric?
** Does the rubric page show the revision plan rubric?

==Team Information==
* Lawrence O'Brien (lpobrien)
* Joshua Lin (jlin36)
* Weiqi Sun (wsun23)
* Wyatt Plaga (wgplaga)
* '''Mentor:''' Nicholas Himes (nnhimes)

CSC/ECE 517 Spring 2022 - E2232: Revision planning tool

2022-04-11T21:17:03Z

Lpobrien:

==Project Goal==
The primary objective for this project is to create a tool that can be used for the revision of projects at a time after their original submission upon the delivery of constructive feedback from their peers or instructors.

==Project Plan==
Merge code for revision planning into current beta

The functionality of E2152 works well but it was developed based on the previous beta and cannot be merged into the current beta. We will first merge the modification in the following files to the current beta and solve the conflicts.

===Files to be merged===
* app/controllers/revision_plan_questionnaires_controller.rb
* app/models/team.rb
* app/controllers/grades_controller.rb
* app/helpers/grades_helper.rb
* app/models/assignment_participant.rb
* app/models/response_map.rb
* app/views/grades/_participant_charts.html.erb
* app/views/grades/view_team.html.erb
* app/views/student_task/view.html.erb
* app/controllers/response_controller.rb
* app/views/response/response.html.erb
* config/routes.rb
* db/schema.rb
* spec/models/response_spec.rb
* spec/models/review_response_map_spec.rb
* spec/features/assignment_creation_general_tab_spec.rb
* app/models/revision_plan_team_map.rb

Merge code for revision planning with code for role based reviewing and topic specific rubrics

The functionality of E2261 works well and has been merged into the current beta. By merging revision planning tool and topic specific rubrics, in the peer review process,
In the first round of review, the rubric is designed by the instructor and varies by topic
In the second round of review, the rubric includes two parts: part 1 is designed by the instructor and varies by topic, par2 2 is designed by the team based on the comments of the first round of review.

[[File:E2232_diagram.png]]

==Current Project Implementation==

The implementation of this needs to fit within the framework created by E2161 (Fall 2021).

What it does: In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

===Rationale===
The general workflow will be maintained from the previous iterations working on this project

[[File:E2152_Rationale.png|410px|center]]

===Previous implementation===
This project was last done in Fall 2021 (E2152). However, related merged code from E2161 (link above) means the implementation this semester may need to be changed from how E2152 did it.
* [https://github.com/expertiza/expertiza/pull/2131 Primary Pull Request for E2152]
* [https://github.com/expertiza/expertiza/pull/2152 Second Pull Request for Revision Planning]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2152._Revision_planning_tool Previous write up for E2152]

====Current Flow====
Firstly, before the round 2 submission, you can look into your work, but the revision plan.
[[File:211129-2.png|700px|thumb|center]]
And then, when it comes to the round 2 submission, if we didn't deal with the "Revision Planning", then the "Your work" part becomes gray.
[[File:211129-5.png|700px|thumb|center]]
After editing the "Revision Planning", we can submit our work.
[[File:211129-6.png|700px|thumb|center]]

=====Current User Interface=====
[[File:after1.png|700px|thumb|center|Reviews cannot be done during the submission phase]]

===Implementation to be completed===
There are actually two E2152 pull requests in Expertiza right now - the PR we saw in the demo has less recent commits than the other. And the PR we did not see has less files changed as well. They started with last year's project, so the beta they started with was the beta from last year. The changes since then will show up as merge conflicts if this project is merged.

The functionality of this project seems to work well and would be a valuable addition to Expertiza, but it cannot be merged in its current state. There are many artifacts in their PR from an old version of beta. This is because the team merged the previous teams' code into current beta, but did not remove the differences unrelated to their project. The team knew of these problems before the demo, but did not fix them.

Because the existing functionality encompasses the intended instructions fairly clearly the work that needs to be done for our purposes would be to pass rspec tests that currently cause the build to fail. This functionality would involve us causing different flows based upon the type of user completing the review. Shown below. HTML changes must also be made in order to pass, specifically needing a change to the display_as_html and participant_scores methods to return the correct html values.

More comments can be made in rspec tests as well. It is unclear what the coverage is of the individual tests. The file revision_plan_team_map_test.rb has nothing substantial in it.

[[File:Failing_rspec.PNG|1000px|center]]

====Design Changes====
Because the changes to the current implementation is limited to specific implementation, the UML design of the project will remain the same as the previous implementation.

[[File:E2152_Design.png|1000px|center]]

==Test Plan==
===Merge existing RSpec tests for revision planning into current beta===
We will first merge the existing RSpec tests of E2152 to the current beta, then run and pass these tests. More comments can be made in rspec tests as well. Observe the coverage of the individual tests.
Existing RSpec tests to be merged
* Controllers
** rspec spec/controllers/grades_controller_spec.rb
** rspec spec/controllers/questionnaires_controller_spec.rb
** rspec spec/controllers/questions_controller_spec.rb
** rspec spec/controllers/student_teams_controller_spec.rb
** spec/controllers/response_controller_spec.rb
** spec/controllers/revision_plan_questionnaires_controller_spec.rb
** spec/factories/revision_plan_factory.rb
* Models
** spec/models/response_spec.rb.
** spec/models/review_response_map_spec.rb
* Helpers
** rspec spec/heplers/grades_helper.rb

===Develop New RSpec Tests===
The RSpec tests are written to test both controllers and models. RSpec testing will be added in order to increase coverage. To do this we will test the flows associated with different user types. Currently the only passing tests are related to student flows and tests may be added that work with instructors. These may include editing the reviews once they are created, and ensuring that an instructor has the ability to make edits.

===Manual Testing===

* Instructor
** Can Review rubric varied by topic be enabled?
** Can different roles be chosen for each questionnaire?
** Can an assignment with revision planning enabled be created?
** Can an assignment with 2 rounds of review be set up?

* Assignment participant
** If the revision-planning rubric can be edited or not?
** Are participants allowed to create/edit revision plan when round 1+ (1 or greater than 1) reviews have finished?
** Is revision plan editing disabled when the assignment is in review stage?
** Does participants show a summary of score for revision plan after review deadline has expired?

* Assignment reviewer
** Does the rubric page show the topic-specific rubric?
** Does the rubric page show the revision plan rubric?

==Team Information==
* Lawrence O'Brien (lpobrien)
* Joshua Lin (jlin36)
* Weiqi Sun (wsun23)
* Wyatt Plaga (wgplaga)
* '''Mentor:''' Nicholas Himes (nnhimes)

CSC/ECE 517 Spring 2022 - E2232: Revision planning tool

2022-04-11T21:12:07Z

Lpobrien:

==Project Goal==
The primary objective for this project is to create a tool that can be used for the revision of projects at a time after their original submission upon the delivery of constructive feedback from their peers or instructors.

==Project Plan==
Merge code for revision planning into current beta

The functionality of E2152 works well but it was developed based on the previous beta and cannot be merged into the current beta. We will first merge the modification in the following files to the current beta and solve the conflicts.

===Files to be merged===
* app/controllers/revision_plan_questionnaires_controller.rb
* app/models/team.rb
* app/controllers/grades_controller.rb
* app/helpers/grades_helper.rb
* app/models/assignment_participant.rb
* app/models/response_map.rb
* app/views/grades/_participant_charts.html.erb
* app/views/grades/view_team.html.erb
* app/views/student_task/view.html.erb
* app/controllers/response_controller.rb
* app/views/response/response.html.erb
* config/routes.rb
* db/schema.rb
* spec/models/response_spec.rb
* spec/models/review_response_map_spec.rb
* spec/features/assignment_creation_general_tab_spec.rb
* app/models/revision_plan_team_map.rb

Merge code for revision planning with code for role based reviewing and topic specific rubrics

The functionality of E2261 works well and has been merged into the current beta. By merging revision planning tool and topic specific rubrics, in the peer review process,
In the first round of review, the rubric is designed by the instructor and varies by topic
In the second round of review, the rubric includes two parts: part 1 is designed by the instructor and varies by topic, par2 2 is designed by the team based on the comments of the first round of review.

[[File:E2232_diagram.png]]

==Current Project Implementation==

The implementation of this needs to fit within the framework created by E2161 (Fall 2021).

What it does: In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

===Rationale===
The general workflow will be maintained from the previous iterations working on this project

[[File:E2152_Rationale.png|410px|center]]

===Previous implementation===
This project was last done in Fall 2021 (E2152). However, related merged code from E2161 (link above) means the implementation this semester may need to be changed from how E2152 did it.
* [https://github.com/expertiza/expertiza/pull/2131 Primary Pull Request for E2152]
* [https://github.com/expertiza/expertiza/pull/2152 Second Pull Request for Revision Planning]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2152._Revision_planning_tool Previous write up for E2152]

====Current Flow====
Firstly, before the round 2 submission, you can look into your work, but the revision plan.
[[File:211129-2.png|700px|thumb|center]]
And then, when it comes to the round 2 submission, if we didn't deal with the "Revision Planning", then the "Your work" part becomes gray.
[[File:211129-5.png|700px|thumb|center]]
After editing the "Revision Planning", we can submit our work.
[[File:211129-6.png|700px|thumb|center]]

=====Current User Interface=====
[[File:after1.png|700px|thumb|center|Reviews cannot be done during the submission phase]]

===Implementation to be completed===
There are actually two E2152 pull requests in Expertiza right now - the PR we saw in the demo has less recent commits than the other. And the PR we did not see has less files changed as well. They started with last year's project, so the beta they started with was the beta from last year. The changes since then will show up as merge conflicts if this project is merged.

The functionality of this project seems to work well and would be a valuable addition to Expertiza, but it cannot be merged in its current state. There are many artifacts in their PR from an old version of beta. This is because the team merged the previous teams' code into current beta, but did not remove the differences unrelated to their project. The team knew of these problems before the demo, but did not fix them.

Because the existing functionality encompasses the intended instructions fairly clearly the work that needs to be done for our purposes would be to pass rspec tests that currently cause the build to fail. This functionality would involve us causing different flows based upon the type of user completing the review. Shown below. HTML changes must also be made in order to pass, specifically needing a change to the display_as_html and participant_scores methods to return the correct html values.

More comments can be made in rspec tests as well. It is unclear what the coverage is of the individual tests. The file revision_plan_team_map_test.rb has nothing substantial in it.

[[File:Failing_rspec.PNG|1000px|center]]

====Design Changes====
Because the changes to the current implementation is limited to specific implementation, the UML design of the project will remain the same as the previous implementation.

[[File:E2152_Design.png|1000px|center]]

==Test Plan==
===Merge existing RSpec tests for revision planning into current beta===
We will first merge the existing RSpec tests of E2152 to the current beta, then run and pass these tests. More comments can be made in rspec tests as well. Observe the coverage of the individual tests.
Existing RSpec tests to be merged
* Controllers
** rspec spec/controllers/grades_controller_spec.rb
** rspec spec/controllers/questionnaires_controller_spec.rb
** rspec spec/controllers/questions_controller_spec.rb
** rspec spec/controllers/student_teams_controller_spec.rb
** spec/controllers/response_controller_spec.rb
** spec/controllers/revision_plan_questionnaires_controller_spec.rb
** spec/factories/revision_plan_factory.rb
* Models
** spec/models/response_spec.rb.
** spec/models/review_response_map_spec.rb
* Helpers
** rspec spec/heplers/grades_helper.rb

===Develop New RSpec Tests===
The RSpec tests are written to test both controllers and models. RSpec testing will be added in order to increase coverage. To do this we will test the flows associated with different user types. Currently the only passing tests are related to student flows and tests may be added that work with instructors. These may include editing the reviews once they are created, and ensuring that an instructor has the ability to make edits.

===Manual Testing===

* Instructor
** Can Review rubric varied by topic be enabled?
** Can different roles be chosen for each questionnaire?
** Can an assignment with revision planning enabled be created?
** Can an assignment with 2 rounds of review be set up?

* Assignment participant
** If the revision-planning rubric can be edited or not?
** Are participants allowed to create/edit revision plan when round 1+ (1 or greater than 1) reviews have finished?
** Is revision plan editing disabled when the assignment is in review stage?
** Does participants show a summary of score for revision plan after review deadline has expired?

* Assignment reviewer
** Does the rubric page show the topic-specific rubric?
** Does the rubric page show the revision plan rubric?

CSC/ECE 517 Spring 2022 - E2232: Revision planning tool

2022-04-11T21:07:09Z

Lpobrien:

==Project Goal==
The primary objective for this project is to create a tool that can be used for the revision of projects at a time after their original submission upon the delivery of constructive feedback from their peers or instructors.

==Project Plan==
Merge code for revision planning into current beta

The functionality of E2152 works well but it was developed based on the previous beta and cannot be merged into the current beta. We will first merge the modification in the following files to the current beta and solve the conflicts.

===Files to be merged===
* app/controllers/revision_plan_questionnaires_controller.rb
* app/models/team.rb
* app/controllers/grades_controller.rb
* app/helpers/grades_helper.rb
* app/models/assignment_participant.rb
* app/models/response_map.rb
* app/views/grades/_participant_charts.html.erb
* app/views/grades/view_team.html.erb
* app/views/student_task/view.html.erb
* app/controllers/response_controller.rb
* app/views/response/response.html.erb
* config/routes.rb
* db/schema.rb
* spec/models/response_spec.rb
* spec/models/review_response_map_spec.rb
* spec/features/assignment_creation_general_tab_spec.rb
* app/models/revision_plan_team_map.rb

Merge code for revision planning with code for role based reviewing and topic specific rubrics

The functionality of E2261 works well and has been merged into the current beta. By merging revision planning tool and topic specific rubrics, in the peer review process,
In the first round of review, the rubric is designed by the instructor and varies by topic
In the second round of review, the rubric includes two parts: part 1 is designed by the instructor and varies by topic, par2 2 is designed by the team based on the comments of the first round of review.

[[File:E2232_diagram.png]]

==Current Project Implementation==

The implementation of this needs to fit within the framework created by E2161 (Fall 2021).

What it does: In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

===Rationale===
The general workflow will be maintained from the previous iterations working on this project

[[File:E2152_Rationale.png|410px|center]]

===Previous implementation===
This project was last done in Fall 2021 (E2152). However, related merged code from E2161 (link above) means the implementation this semester may need to be changed from how E2152 did it.
* [https://github.com/expertiza/expertiza/pull/2131 Primary Pull Request for E2152]
* [https://github.com/expertiza/expertiza/pull/2152 Second Pull Request for Revision Planning]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2152._Revision_planning_tool Previous write up for E2152]

====Current Flow====
Firstly, before the round 2 submission, you can look into your work, but the revision plan.
[[File:211129-2.png|700px|thumb|center]]
And then, when it comes to the round 2 submission, if we didn't deal with the "Revision Planning", then the "Your work" part becomes gray.
[[File:211129-5.png|700px|thumb|center]]
After editing the "Revision Planning", we can submit our work.
[[File:211129-6.png|700px|thumb|center]]

=====Current User Interface=====
[[File:after1.png|700px|thumb|center|Reviews cannot be done during the submission phase]]

===Implementation to be completed===
There are actually two E2152 pull requests in Expertiza right now - the PR we saw in the demo has less recent commits than the other. And the PR we did not see has less files changed as well. They started with last year's project, so the beta they started with was the beta from last year. The changes since then will show up as merge conflicts if this project is merged.

The functionality of this project seems to work well and would be a valuable addition to Expertiza, but it cannot be merged in its current state. There are many artifacts in their PR from an old version of beta. This is because the team merged the previous teams' code into current beta, but did not remove the differences unrelated to their project. The team knew of these problems before the demo, but did not fix them.

Because the existing functionality encompasses the intended instructions fairly clearly the work that needs to be done for our purposes would be to pass rspec tests that currently cause the build to fail. This functionality would involve us causing different flows based upon the type of user completing the review. Shown below. HTML changes must also be made in order to pass, specifically needing a change to the display_as_html and participant_scores methods to return the correct html values.

More comments can be made in rspec tests as well. It is unclear what the coverage is of the individual tests. The file revision_plan_team_map_test.rb has nothing substantial in it.

[[File:Failing_rspec.PNG]]

====Design Changes====
Because the changes to the current implementation is limited to specific implementation, the UML design of the project will remain the same as the previous implementation.

[[File:E2152_Design.png|1000px|center]]

==Test Plan==
===Merge existing RSpec tests for revision planning into current beta===
We will first merge the existing RSpec tests of E2152 to the current beta, then run and pass these tests. More comments can be made in rspec tests as well. Observe the coverage of the individual tests.
Existing RSpec tests to be merged
* Controllers
** rspec spec/controllers/grades_controller_spec.rb
** rspec spec/controllers/questionnaires_controller_spec.rb
** rspec spec/controllers/questions_controller_spec.rb
** rspec spec/controllers/student_teams_controller_spec.rb
** spec/controllers/response_controller_spec.rb
** spec/controllers/revision_plan_questionnaires_controller_spec.rb
** spec/factories/revision_plan_factory.rb
* Models
** spec/models/response_spec.rb.
** spec/models/review_response_map_spec.rb
* Helpers
** rspec spec/heplers/grades_helper.rb

===Develop New RSpec Tests===
The RSpec tests are written to test both controllers and models.

===Manual Testing===

* Instructor
** Can Review rubric varied by topic be enabled?
** Can different roles be chosen for each questionnaire?
** Can an assignment with revision planning enabled be created?
** Can an assignment with 2 rounds of review be set up?

* Assignment participant
** If the revision-planning rubric can be edited or not?
** Are participants allowed to create/edit revision plan when round 1+ (1 or greater than 1) reviews have finished?
** Is revision plan editing disabled when the assignment is in review stage?
** Does participants show a summary of score for revision plan after review deadline has expired?

* Assignment reviewer
** Does the rubric page show the topic-specific rubric?
** Does the rubric page show the revision plan rubric?

CSC/ECE 517 Spring 2022 - E2232: Revision planning tool

2022-04-11T20:57:35Z

Lpobrien:

==Project Goal==
The primary objective for this project is to create a tool that can be used for the revision of projects at a time after their original submission upon the delivery of constructive feedback from their peers or instructors.

==Project Plan==
Merge code for revision planning into current beta

The functionality of E2152 works well but it was developed based on the previous beta and cannot be merged into the current beta. We will first merge the modification in the following files to the current beta and solve the conflicts.

===Files to be merged===
* app/controllers/revision_plan_questionnaires_controller.rb
* app/models/team.rb
* app/controllers/grades_controller.rb
* app/helpers/grades_helper.rb
* app/models/assignment_participant.rb
* app/models/response_map.rb
* app/views/grades/_participant_charts.html.erb
* app/views/grades/view_team.html.erb
* app/views/student_task/view.html.erb
* app/controllers/response_controller.rb
* app/views/response/response.html.erb
* config/routes.rb
* db/schema.rb
* spec/models/response_spec.rb
* spec/models/review_response_map_spec.rb
* spec/features/assignment_creation_general_tab_spec.rb
* app/models/revision_plan_team_map.rb

Merge code for revision planning with code for role based reviewing and topic specific rubrics

The functionality of E2261 works well and has been merged into the current beta. By merging revision planning tool and topic specific rubrics, in the peer review process,
In the first round of review, the rubric is designed by the instructor and varies by topic
In the second round of review, the rubric includes two parts: part 1 is designed by the instructor and varies by topic, par2 2 is designed by the team based on the comments of the first round of review.

[[File:E2232_diagram.png]]

==Current Project Implementation==

The implementation of this needs to fit within the framework created by E2161 (Fall 2021).

What it does: In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

===Previous implementation===
This project was last done in Fall 2021 (E2152). However, related merged code from E2161 (link above) means the implementation this semester may need to be changed from how E2152 did it.
* [https://github.com/expertiza/expertiza/pull/2131 Primary Pull Request for E2152]
* [https://github.com/expertiza/expertiza/pull/2152 Second Pull Request for Revision Planning]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2152._Revision_planning_tool Previous write up for E2152]

===Implementation to be completed===
There are actually two E2152 pull requests in Expertiza right now - the PR we saw in the demo has less recent commits than the other. And the PR we did not see has less files changed as well. They started with last year's project, so the beta they started with was the beta from last year. The changes since then will show up as merge conflicts if this project is merged.

The functionality of this project seems to work well and would be a valuable addition to Expertiza, but it cannot be merged in its current state. There are many artifacts in their PR from an old version of beta. This is because the team merged the previous teams' code into current beta, but did not remove the differences unrelated to their project. The team knew of these problems before the demo, but did not fix them.

Because the existing functionality encompasses the intended instructions fairly clearly the work that needs to be done for our purposes would be to pass rspec tests that currently cause the build to fail. This functionality would involve us causing different flows based upon the type of user completing the review. Shown below. HTML changes must also be made in order to pass, specifically needing a change to the display_as_html and participant_scores methods to return the correct html values.

More comments can be made in rspec tests as well. It is unclear what the coverage is of the individual tests. The file revision_plan_team_map_test.rb has nothing substantial in it.

[[File:Failing_rspec.PNG]]

====Design Changes====
Because the changes to the current implementation is limited to specific implementation, the UML design of the project will remain the same as the previous implementation.

[[File:E2152_Design.png|1000px|center]]

==Test Plan==
===Merge existing RSpec tests for revision planning into current beta===
We will first merge the existing RSpec tests of E2152 to the current beta, then run and pass these tests. More comments can be made in rspec tests as well. Observe the coverage of the individual tests.
Existing RSpec tests to be merged
* Controllers
** rspec spec/controllers/grades_controller_spec.rb
** rspec spec/controllers/questionnaires_controller_spec.rb
** rspec spec/controllers/questions_controller_spec.rb
** rspec spec/controllers/student_teams_controller_spec.rb
** spec/controllers/response_controller_spec.rb
** spec/controllers/revision_plan_questionnaires_controller_spec.rb
** spec/factories/revision_plan_factory.rb
* Models
** spec/models/response_spec.rb.
** spec/models/review_response_map_spec.rb
* Helpers
** rspec spec/heplers/grades_helper.rb

===Develop New RSpec Tests===
The RSpec tests are written to test both controllers and models.

===Manual Testing===

* Instructor
** Can Review rubric varied by topic be enabled?
** Can different roles be chosen for each questionnaire?
** Can an assignment with revision planning enabled be created?
** Can an assignment with 2 rounds of review be set up?

* Assignment participant
** If the revision-planning rubric can be edited or not?
** Are participants allowed to create/edit revision plan when round 1+ (1 or greater than 1) reviews have finished?
** Is revision plan editing disabled when the assignment is in review stage?
** Does participants show a summary of score for revision plan after review deadline has expired?

* Assignment reviewer
** Does the rubric page show the topic-specific rubric?
** Does the rubric page show the revision plan rubric?

CSC/ECE 517 Spring 2022 - E2232: Revision planning tool

2022-04-11T20:55:56Z

Lpobrien:

==Project Goal==
The primary objective for this project is to create a tool that can be used for the revision of projects at a time after their original submission upon the delivery of constructive feedback from their peers or instructors.

==Project Plan==
Merge code for revision planning into current beta

The functionality of E2152 works well but it was developed based on the previous beta and cannot be merged into the current beta. We will first merge the modification in the following files to the current beta and solve the conflicts.

===Files to be merged===
* app/controllers/revision_plan_questionnaires_controller.rb
* app/models/team.rb
* app/controllers/grades_controller.rb
* app/helpers/grades_helper.rb
* app/models/assignment_participant.rb
* app/models/response_map.rb
* app/views/grades/_participant_charts.html.erb
* app/views/grades/view_team.html.erb
* app/views/student_task/view.html.erb
* app/controllers/response_controller.rb
* app/views/response/response.html.erb
* config/routes.rb
* db/schema.rb
* spec/models/response_spec.rb
* spec/models/review_response_map_spec.rb
* spec/features/assignment_creation_general_tab_spec.rb
* app/models/revision_plan_team_map.rb

Merge code for revision planning with code for role based reviewing and topic specific rubrics

The functionality of E2261 works well and has been merged into the current beta. By merging revision planning tool and topic specific rubrics, in the peer review process,
In the first round of review, the rubric is designed by the instructor and varies by topic
In the second round of review, the rubric includes two parts: part 1 is designed by the instructor and varies by topic, par2 2 is designed by the team based on the comments of the first round of review.

[[File:E2232_diagram.png]]

==Current Project Implementation==

The implementation of this needs to fit within the framework created by E2161 (Fall 2021).

What it does: In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

===Previous implementation===
This project was last done in Fall 2021 (E2152). However, related merged code from E2161 (link above) means the implementation this semester may need to be changed from how E2152 did it.
* [https://github.com/expertiza/expertiza/pull/2131 Primary Pull Request for E2152]
* [https://github.com/expertiza/expertiza/pull/2152 Second Pull Request for Revision Planning]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2152._Revision_planning_tool Previous write up for E2152]

===Implementation to be completed===
There are actually two E2152 pull requests in Expertiza right now - the PR we saw in the demo has less recent commits than the other. And the PR we did not see has less files changed as well. They started with last year's project, so the beta they started with was the beta from last year. The changes since then will show up as merge conflicts if this project is merged.

The functionality of this project seems to work well and would be a valuable addition to Expertiza, but it cannot be merged in its current state. There are many artifacts in their PR from an old version of beta. This is because the team merged the previous teams' code into current beta, but did not remove the differences unrelated to their project. The team knew of these problems before the demo, but did not fix them.

Because the existing functionality encompasses the intended instructions fairly clearly the work that needs to be done for our purposes would be to pass rspec tests that currently cause the build to fail. This functionality would involve us causing different flows based upon the type of user completing the review. Shown below. HTML changes must also be made in order to pass, specifically needing a change to the display_as_html and participant_scores methods to return the correct html values.

More comments can be made in rspec tests as well. It is unclear what the coverage is of the individual tests. The file revision_plan_team_map_test.rb has nothing substantial in it.

[[File:Failing_rspec.PNG]]

====Design Changes====
Because the changes to the current implementation is limited to specific implementation, the UML design of the project will remain the same as the previous implementation.

[[File:E2152_Design.png]]

==Test Plan==
===Merge existing RSpec tests for revision planning into current beta===
We will first merge the existing RSpec tests of E2152 to the current beta, then run and pass these tests. More comments can be made in rspec tests as well. Observe the coverage of the individual tests.
Existing RSpec tests to be merged
* Controllers
** rspec spec/controllers/grades_controller_spec.rb
** rspec spec/controllers/questionnaires_controller_spec.rb
** rspec spec/controllers/questions_controller_spec.rb
** rspec spec/controllers/student_teams_controller_spec.rb
** spec/controllers/response_controller_spec.rb
** spec/controllers/revision_plan_questionnaires_controller_spec.rb
** spec/factories/revision_plan_factory.rb
* Models
** spec/models/response_spec.rb.
** spec/models/review_response_map_spec.rb
* Helpers
** rspec spec/heplers/grades_helper.rb

===Develop New RSpec Tests===
The RSpec tests are written to test both controllers and models.

===Manual Testing===

* Instructor
** Can Review rubric varied by topic be enabled?
** Can different roles be chosen for each questionnaire?
** Can an assignment with revision planning enabled be created?
** Can an assignment with 2 rounds of review be set up?

* Assignment participant
** If the revision-planning rubric can be edited or not?
** Are participants allowed to create/edit revision plan when round 1+ (1 or greater than 1) reviews have finished?
** Is revision plan editing disabled when the assignment is in review stage?
** Does participants show a summary of score for revision plan after review deadline has expired?

* Assignment reviewer
** Does the rubric page show the topic-specific rubric?
** Does the rubric page show the revision plan rubric?

File:E2152 Design.png

2022-04-11T20:55:51Z

Lpobrien: Lpobrien uploaded a new version of File:E2152 Design.png

File:Failing rspec.PNG

2022-04-11T20:48:40Z

Lpobrien:

CSC/ECE 517 Spring 2022

2022-04-11T20:38:48Z

Lpobrien:

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

== 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 - E2232: Revision planning tool]]
* [[CSC/ECE 517 Spring 2022 - E2233. Improving search facility in Expertiza]]
* [[CSC/ECE 517 Spring 2022 - E2234. Calibration submissions should be copied along with calibration assignments]]
* [[CSC/ECE 517 Spring 2022 - E2244. Support for saying your team pair-programmed]]
* [[CSC/ECE 517 Spring 2022 - E2246: Email your authors/reviewers, with complete tests]]
* [[CSC/ECE 517 Spring 2022 - E2229: Track the time students look at other submissions]]
* [[CSC/ECE 517 Spring 2022 - E2239: Further refactoring and improvement of review mapping helper.rb ]]
* [[CSC/ECE 517 Spring 2022 - E2240. Re-write waitlist functionality ]]
* [[CSC/ECE 517 Spring 2022 - E2242. Fix teammate-review view ]]
* [[CSC/ECE 517 Spring 2022 - E2243. Refactor student_teams functionality]]
* [[CSC/ECE 517 Spring 2022 - E2235. Issues related to meta-reviewing]]
* [[CSC/ECE 517 Spring 2022 - E2230. Integrate Suggestion Detection Algorithm]]
* [[CSC/ECE 517 Spring 2022 - E2238. Implementing and testing Import & Export controllers]]
* [[CSC/ECE 517 Spring 2022 - E2228. Refactor JavaScript on Expertiza]]

CSC/ECE 517 Spring 2022 - E2232: Revision planning tool

2022-04-07T15:46:12Z

Lpobrien:

==Project Goal==
The primary objective for this project is to create a tool that can be used for the revision of projects at a time after their original submission upon the delivery of constructive feedback from their peers or instructors.

==Project Plan==
Merge code for revision planning into current beta

The functionality of E2152 works well but it was developed based on the previous beta and cannot be merged into the current beta. We will first merge the modification in the following files to the current beta and solve the conflicts.

===Files to be merged===
* app/controllers/revision_plan_questionnaires_controller.rb
* app/models/team.rb
* app/controllers/grades_controller.rb
* app/helpers/grades_helper.rb
* app/models/assignment_participant.rb
* app/models/response_map.rb
* app/views/grades/_participant_charts.html.erb
* app/views/grades/view_team.html.erb
* app/views/student_task/view.html.erb
* app/controllers/response_controller.rb
* app/views/response/response.html.erb
* config/routes.rb
* db/schema.rb
* spec/models/response_spec.rb
* spec/models/review_response_map_spec.rb
* spec/features/assignment_creation_general_tab_spec.rb
* app/models/revision_plan_team_map.rb

Merge code for revision planning with code for role based reviewing and topic specific rubrics

The functionality of E2261 works well and has been merged into the current beta. By merging revision planning tool and topic specific rubrics, in the peer review process,
In the first round of review, the rubric is designed by the instructor and varies by topic
In the second round of review, the rubric includes two parts: part 1 is designed by the instructor and varies by topic, par2 2 is designed by the team based on the comments of the first round of review.

==Current Project Implementation==

What it does: In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

The implementation of this needs to fit within the framework created by E2161 (Fall 2021).

===Previous implementation===
This project was last done in Fall 2021 (E2152). However, related merged code from E2161 (link above) means the implementation this semester may need to be changed from how E2152 did it.
* [https://github.com/expertiza/expertiza/pull/2131 Primary Pull Request for E2152]
* [https://github.com/expertiza/expertiza/pull/2152 Second Pull Request for Revision Planning]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2152._Revision_planning_tool Previous write up for E2152]

===Implementation===
There are actually two E2152 pull requests in Expertiza right now - the PR we saw in the demo has less recent commits than the other. And the PR we did not see has less files changed as well. They started with last year's project, so the beta they started with was the beta from last year. The changes since then will show up as merge conflicts if this project is merged.

The functionality of this project seems to work well and would be a valuable addition to Expertiza, but it cannot be merged in its current state. There are many artifacts in their PR from an old version of beta. This is because the team merged the previous teams' code into current beta, but did not remove the differences unrelated to their project. The team knew of these problems before the demo, but did not fix them.

More comments can be made in rspec tests as well. It is unclear what the coverage is of the individual tests. The file revision_plan_team_map_test.rb has nothing substantial in it.

==Test Plan==
===Merge existing RSpec tests for revision planning into current beta===
We will first merge the existing RSpec tests of E2152 to the current beta, then run and pass these tests. More comments can be made in rspec tests as well. Observe the coverage of the individual tests.
Existing RSpec tests to be merged
* Controllers
** rspec spec/controllers/grades_controller_spec.rb
** rspec spec/controllers/questionnaires_controller_spec.rb
** rspec spec/controllers/questions_controller_spec.rb
** rspec spec/controllers/student_teams_controller_spec.rb
** spec/controllers/response_controller_spec.rb
** spec/controllers/revision_plan_questionnaires_controller_spec.rb
** spec/factories/revision_plan_factory.rb
* Models
** spec/models/response_spec.rb.
** spec/models/review_response_map_spec.rb
* Helpers
** rspec spec/heplers/grades_helper.rb

===Develop New RSpec Tests===
The RSpec tests are written to test both controllers and models.

===Manual Testing===

* Instructor
** Can Review rubric varied by topic be enabled?
** Can different roles be chosen for each questionnaire?
** Can an assignment with revision planning enabled be created?
** Can an assignment with 2 rounds of review be set up?

* Assignment participant
** If the revision-planning rubric can be edited or not?
** Are participants allowed to create/edit revision plan when round 1+ (1 or greater than 1) reviews have finished?
** Is revision plan editing disabled when the assignment is in review stage?
** Does participants show a summary of score for revision plan after review deadline has expired?

* Assignment reviewer
** Does the rubric page show the topic-specific rubric?
** Does the rubric page show the revision plan rubric?

CSC/ECE 517 Spring 2022 - E2232: Revision planning tool

2022-04-07T03:29:34Z

Lpobrien:

==Project Goal==
The primary objective for this project is to create a tool that can be used for the revision of projects at a time after their original submission upon the delivery of constructive feedback from their peers or instructors.

Manual testing:
* Create an assignment with revisions enabled, check to see it is created and visible from student
* Create an assignment with two rounds enabled, see if it is visible to student
* Create assignment with rubric, see if it visible

==Current Project Implementation==

What it does: In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

The implementation of this needs to fit within the framework created by E2161 (Fall 2021).

===Previous implementation===
This project was last done in Fall 2021 (E2152). However, related merged code from E2161 (link above) means the implementation this semester may need to be changed from how E2152 did it.
* [https://github.com/expertiza/expertiza/pull/2131 Primary Pull Request for E2152]
* [https://github.com/expertiza/expertiza/pull/2152 Second Pull Request for Revision Planning]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2152._Revision_planning_tool Previous write up for E2152]

===Implementation===
There are actually two E2152 pull requests in Expertiza right now - the PR we saw in the demo has less recent commits than the other. And the PR we did not see has less files changed as well. They started with last year's project, so the beta they started with was the beta from last year. The changes since then will show up as merge conflicts if this project is merged.

The functionality of this project seems to work well and would be a valuable addition to Expertiza, but it cannot be merged in its current state. There are many artifacts in their PR from an old version of beta. This is because the team merged the previous teams' code into current beta, but did not remove the differences unrelated to their project. The team knew of these problems before the demo, but did not fix them.

More comments can be made in rspec tests as well. It is unclear what the coverage is of the individual tests. The file revision_plan_team_map_test.rb has nothing substantial in it.

==Test Plan==
We need to be able to test all of the edge cases and main flows of the planned functionality. To do that we will add tests in rspec. Testing is needed to ensure that the added functionality is fully operational.

* Test creating an assignment that has revision enabled
* Test creating an assignment with two rounds of revisions
* Test delivering the rubric associated with an assignment with revisions
* Test creating an assignment with an invalid number of revisions (-1)

CSC/ECE 517 Spring 2022 - E2232: Revision planning tool

2022-04-07T03:24:16Z

Lpobrien:

==Project Goal==
The primary objective for this project is to create a tool that can be used for the revision of projects at a time after their original submission upon the delivery of constructive feedback from their peers or instructors.

==Test Plan==
We need to be able to test all of the edge cases and main flows of the planned functionality. To do that we will add tests in rspec. Testing is needed to ensure that the added functionality is fully operational.

* Test creating an assignment that has revision enabled
* Test creating an assignment with two rounds of revisions
* Test delivering the rubric associated with an assignment with revisions
* Test creating an assignment with an invalid number of revisions (-1)

Manual testing:
* Create an assignment with revisions enabled, check to see it is created and visible from student
* Create an assignment with two rounds enabled, see if it is visible to student
* Create assignment with rubric, see if it visible

==Current Project State==

What it does: In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

The implementation of this needs to fit within the framework created by E2161 (Fall 2021).

===Previous implementation===
This project was last done in Fall 2021 (E2152). However, related merged code from E2161 (link above) means the implementation this semester may need to be changed from how E2152 did it.
* [https://github.com/expertiza/expertiza/pull/2131 Primary Pull Request for E2152]
* [https://github.com/expertiza/expertiza/pull/2152 Second Pull Request for Revision Planning]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2152._Revision_planning_tool Previous write up for E2152]

===Implementation===
There are actually two E2152 pull requests in Expertiza right now - the PR we saw in the demo has less recent commits than the other. And the PR we did not see has less files changed as well. They started with last year's project, so the beta they started with was the beta from last year. The changes since then will show up as merge conflicts if this project is merged.

The functionality of this project seems to work well and would be a valuable addition to Expertiza, but it cannot be merged in its current state. There are many artifacts in their PR from an old version of beta. This is because the team merged the previous teams' code into current beta, but did not remove the differences unrelated to their project. The team knew of these problems before the demo, but did not fix them.

More comments can be made in rspec tests as well. It is unclear what the coverage is of the individual tests. The file revision_plan_team_map_test.rb has nothing substantial in it.

CSC/ECE 517 Spring 2022 - E2232: Revision planning tool

2022-04-07T03:23:37Z

Lpobrien:

==Project Goal==
The primary objective for this project is to create a tool that can be used for the revision of projects at a time after their original submission upon the delivery of constructive feedback from their peers or instructors.

==Test Plan==
We need to be able to test all of the edge cases and main flows of the planned functionality. To do that we will add tests in rspec.
* Test creating an assignment that has revision enabled
* Test creating an assignment with two rounds of revisions
* Test delivering the rubric associated with an assignment with revisions
* Test creating an assignment with an invalid number of revisions (-1)
*

Manual testing:
* Create an assignment with revisions enabled, check to see it is created and visible from student
* Create an assignment with two rounds enabled, see if it is visible to student
* Create assignment with rubric, see if it visible

==Current Project State==

What it does: In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

The implementation of this needs to fit within the framework created by E2161 (Fall 2021).

===Previous implementation===
This project was last done in Fall 2021 (E2152). However, related merged code from E2161 (link above) means the implementation this semester may need to be changed from how E2152 did it.
* [https://github.com/expertiza/expertiza/pull/2131 Primary Pull Request for E2152]
* [https://github.com/expertiza/expertiza/pull/2152 Second Pull Request for Revision Planning]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2152._Revision_planning_tool Previous write up for E2152]

===Implementation===
There are actually two E2152 pull requests in Expertiza right now - the PR we saw in the demo has less recent commits than the other. And the PR we did not see has less files changed as well. They started with last year's project, so the beta they started with was the beta from last year. The changes since then will show up as merge conflicts if this project is merged.

The functionality of this project seems to work well and would be a valuable addition to Expertiza, but it cannot be merged in its current state. There are many artifacts in their PR from an old version of beta. This is because the team merged the previous teams' code into current beta, but did not remove the differences unrelated to their project. The team knew of these problems before the demo, but did not fix them.

More comments can be made in rspec tests as well. It is unclear what the coverage is of the individual tests. The file revision_plan_team_map_test.rb has nothing substantial in it.

CSC/ECE 517 Spring 2022 - E2232: Revision planning tool

2022-04-07T02:56:01Z

Lpobrien:

==Project Goal==
The primary objective for this project is to create a tool that can be used for the revision of projects at a time after their original submission upon the delivery of constructive feedback from their peers or instructors.

==Project Plan==

==Test Plan==
We need to be able to test all of the edge cases and main flows of the planned functionality. To do that we will add tests in rspec.
* Test creating an assignment that has revision enabled
* Test creating an assignment with two rounds of revisions
* Test delivering the rubric associated with an assignment with revisions

==Current Project State==

What it does: In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

The implementation of this needs to fit within the framework created by E2161 (Fall 2021).

===Previous implementation===
This project was last done in Fall 2021 (E2152). However, related merged code from E2161 (link above) means the implementation this semester may need to be changed from how E2152 did it.
* [https://github.com/expertiza/expertiza/pull/2131 Primary Pull Request for E2152]
* [https://github.com/expertiza/expertiza/pull/2152 Second Pull Request for Revision Planning]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2152._Revision_planning_tool Previous write up for E2152]

===Implementation===
There are actually two E2152 pull requests in Expertiza right now - the PR we saw in the demo has less recent commits than the other. And the PR we did not see has less files changed as well. They started with last year's project, so the beta they started with was the beta from last year. The changes since then will show up as merge conflicts if this project is merged.

The functionality of this project seems to work well and would be a valuable addition to Expertiza, but it cannot be merged in its current state. There are many artifacts in their PR from an old version of beta. This is because the team merged the previous teams' code into current beta, but did not remove the differences unrelated to their project. The team knew of these problems before the demo, but did not fix them.

More comments can be made in rspec tests as well. It is unclear what the coverage is of the individual tests. The file revision_plan_team_map_test.rb has nothing substantial in it.

CSC/ECE 517 Spring 2022 - E2232: Revision planning tool

2022-04-06T00:31:15Z

Lpobrien:

==Project Goal==
The primary objective for this project is to create a tool that can be used for the revision of projects at a time after their original submission upon the delivery of constructive feedback from their peers or instructors.

==Project Plan==

==Test Plan==

==Current Project State==

What it does: In the first round of Expertiza reviews, we ask reviewers to give authors some guidance on how to improve their work. Then in the second round, reviewers rate how well authors have followed their suggestions. We could carry the interaction one step further if we asked authors to make up a revision plan based on the first-round reviews. That is, authors would say what they were planning to do to improve their work. Then second-round reviewers would assess how well they did it. In essence, this means that authors would be adding criteria to the second-round rubric that applied only to their submission. We are interested in having this implemented and used in a class so that we can study its effect.

The implementation of this needs to fit within the framework created by E2161 (Fall 2021).

===Previous implementation===
This project was last done in Fall 2021 (E2152). However, related merged code from E2161 (link above) means the implementation this semester may need to be changed from how E2152 did it.
* [https://github.com/expertiza/expertiza/pull/2131 Primary Pull Request for E2152]
* [https://github.com/expertiza/expertiza/pull/2152 Second Pull Request for Revision Planning]
* [https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2152._Revision_planning_tool Previous write up for E2152]

===Implementation===
There are actually two E2152 pull requests in Expertiza right now - the PR we saw in the demo has less recent commits than the other. And the PR we did not see has less files changed as well. They started with last year's project, so the beta they started with was the beta from last year. The changes since then will show up as merge conflicts if this project is merged.

The functionality of this project seems to work well and would be a valuable addition to Expertiza, but it cannot be merged in its current state. There are many artifacts in their PR from an old version of beta. This is because the team merged the previous teams' code into current beta, but did not remove the differences unrelated to their project. The team knew of these problems before the demo, but did not fix them.

More comments can be made in rspec tests as well. It is unclear what the coverage is of the individual tests. The file revision_plan_team_map_test.rb has nothing substantial in it.

CSC/ECE 517 Spring 2022 - E2227: SQL Injection Fix

2022-03-27T19:21:01Z

Lpobrien:

This page details project documentation for the CSC/ECE 517 Spring 2022, "E2227 SQL Injection Fix" project.

== Background ==

Expertiza is an open source software system that is used in order to assign projects to students as well as provide a place to submit and review peers.

Many software projects such as expertiza rely on user interactions in order to accomplish the tasks given by their users. With this information input by the users, the software system often must access points in the database. Because of this, it is possible to access parts of the database even if you are not given direct access by inputting SQL language queries to unvalidated inputs. The reason in which this is possible is because many SQL queries rely on Boolean logic. This is a serious security risk for the software system and causes privacy concerns for any and all involved users. This SQL injection risk is present in the controller class sign_up_sheet_controller.rb, which is a class that is responsible for controlling actions surrounding signing up for specific topic for a project.

=== Mentor ===

Nicholas Himes

=== Team Members ===

* Lawrence O'Brien
* David Glymph
* Jacob Anderson

== Code Modifications ==
Described below are the code refactoring tasks and issues addressed by this team. We have also included any pertinent details, reasonings, comments, warnings, etc., corresponding to each task.

=== Dynamic Finders ===
The SQL injection issue present in the expertiza source code is caused by an unvalidated SQL query when when searching for sign up topics for assignments requiring topics. The system used the static "find" method which does not validate or in any protect against malicious input. In order to solve this issue we used a find_by method, which forces all input to be used in searching for one specific key in the database rather than allowing additional keys to be accessed using string terminating characters. This solves the issue by preventing unauthorized database access through SQL injection.

== Modified Files ==
* sign_up_sheet_controller.rb
* sign_up_sheet_controller_spec.rb

== Test Plan ==

We plan to rely on the existing GitHub bots to test for functionality and style, but will add tests that correlate to inputting the SQL injections into the system and ensure they are dealth with.

=== Github Bots ===
Github bots were used to facilitate the majority of the checks that were used for expertiza outside of our unit testing, as well as the style guidelines. Brakeman was used as the functionality checking bot for this repository.

[[File:Test.png]]

=== Running Tests ===
Tests were altered in order to accomodate the change in implementation. We tested for a command that previously would have invoked a data breach via SQL injection to ensure it was no longer present. Tests are needed in order to verify that the SQL injection risk has been effectively dealt with.

[[File:Tests_running.png]]

<pre>
rspec spec/controllers/sign_up_sheet_controller_spec.rb
</pre>

== GitHub links and Pull Request==
Link to Expertiza repository: [https://github.com/expertiza/expertiza here]

Link to the forked repository: [https://github.com/lobrien6588/expertiza here]

Link to Pull Request: [https://github.com/expertiza/expertiza/pull/2323 here]

== Images ==
[[File:SQL_Injection_Location.png]]

CSC/ECE 517 Spring 2022 - E2227: SQL Injection Fix

2022-03-27T19:04:55Z

Lpobrien:

This page details project documentation for the CSC/ECE 517 Spring 2022, "E2227 SQL Injection Fix" project.

== Background ==

Expertiza is an open source software system that is used in order to assign projects to students as well as provide a place to submit and review peers.

Many software projects such as expertiza rely on user interactions in order to accomplish the tasks given by their users. With this information input by the users, the software system often must access points in the database. Because of this, it is possible to access parts of the database even if you are not given direct access by inputting SQL language queries to unvalidated inputs. The reason in which this is possible is because many SQL queries rely on Boolean logic. This is a serious security risk for the software system and causes privacy concerns for any and all involved users.

=== Mentor ===

Nicholas Himes

=== Team Members ===

* Lawrence O'Brien
* David Glymph
* Jacob Anderson

== Code Modifications ==
Described below are the code refactoring tasks and issues addressed by this team. We have also included any pertinent details, reasonings, comments, warnings, etc., corresponding to each task.

=== Dynamic Finders ===
The SQL injection issue present in the expertiza source code is caused by an unvalidated SQL query when when searching for sign up topics for assignments requiring topics. The system used the static "find" method which does not validate or in any protect against malicious input. In order to solve this issue we used a find_by method, which forces all input to be used in searching for one specific key in the database rather than allowing additional keys to be accessed using string terminating characters. This solves the issue by preventing unauthorized database access through SQL injection.

== Modified Files ==
* sign_up_sheet_controller.rb
* sign_up_sheet_controller_spec.rb

== Test Plan ==

=== Github Bots ===
Github bots were used to facilitate the majority of the checks that were used for expertiza outside of our unit testing, as well as the style guidelines. Brakeman was used as the functionality checking bot for this repository.

[[File:Test.png]]

=== Running Tests ===
Tests were altered in order to accomodate the change in implementation. We tested for a command that previously would have invoked a data breach via SQL injection to ensure it was no longer present.

[[File:Tests_running.png]]

<pre>
rspec spec/controllers/sign_up_sheet_controller_spec.rb
</pre>

== GitHub links and Pull Request==
Link to Expertiza repository: [https://github.com/expertiza/expertiza here]

Link to the forked repository: [https://github.com/lobrien6588/expertiza here]

Link to Pull Request: [https://github.com/expertiza/expertiza/pull/2323 here]

== Images ==
[[File:SQL_Injection_Location.png]]

File:Tests running.png

2022-03-27T19:04:14Z

Lpobrien:

CSC/ECE 517 Spring 2022 - E2227: SQL Injection Fix

2022-03-27T19:03:48Z

Lpobrien:

This page details project documentation for the CSC/ECE 517 Spring 2022, "E2227 SQL Injection Fix" project.

== Background ==

Expertiza is an open source software system that is used in order to assign projects to students as well as provide a place to submit and review peers.

Many software projects such as expertiza rely on user interactions in order to accomplish the tasks given by their users. With this information input by the users, the software system often must access points in the database. Because of this, it is possible to access parts of the database even if you are not given direct access by inputting SQL language queries to unvalidated inputs. The reason in which this is possible is because many SQL queries rely on Boolean logic. This is a serious security risk for the software system and causes privacy concerns for any and all involved users.

=== Mentor ===

Nicholas Himes

=== Team Members ===

* Lawrence O'Brien
* David Glymph
* Jacob Anderson

== Code Modifications ==
Described below are the code refactoring tasks and issues addressed by this team. We have also included any pertinent details, reasonings, comments, warnings, etc., corresponding to each task.

=== Dynamic Finders ===
The SQL injection issue present in the expertiza source code is caused by an unvalidated SQL query when when searching for sign up topics for assignments requiring topics. The system used the static "find" method which does not validate or in any protect against malicious input. In order to solve this issue we used a find_by method, which forces all input to be used in searching for one specific key in the database rather than allowing additional keys to be accessed using string terminating characters. This solves the issue by preventing unauthorized database access through SQL injection.

== Modified Files ==
* sign_up_sheet_controller.rb
* sign_up_sheet_controller_spec.rb

== Test Plan ==

=== Github Bots ===
Github bots were used to facilitate the majority of the checks that were used for expertiza outside of our unit testing, as well as the style guidelines. Brakeman was used as the functionality checking bot for this repository.

[[File:Test.png]]

=== Running Tests ===
Tests were altered in order to accomodate the change in implementation. We tested for a command that previously would have invoked a data breach via SQL injection to ensure it was no longer present.

[[File:tests_running.png]]

<pre>
rspec spec/controllers/sign_up_sheet_controller_spec.rb
</pre>

== GitHub links and Pull Request==
Link to Expertiza repository: [https://github.com/expertiza/expertiza here]

Link to the forked repository: [https://github.com/lobrien6588/expertiza here]

Link to Pull Request: [https://github.com/expertiza/expertiza/pull/2323 here]

== Images ==
[[File:SQL_Injection_Location.png]]

CSC/ECE 517 Spring 2022 - E2227: SQL Injection Fix

2022-03-22T02:27:20Z

Lpobrien:

This page details project documentation for the CSC/ECE 517 Spring 2022, "E2227 SQL Injection Fix" project.

== Background ==

Expertiza is an open source software system that is used in order to assign projects to students as well as provide a place to submit and review peers.

Many software projects such as expertiza rely on user interactions in order to accomplish the tasks given by their users. With this information input by the users, the software system often must access points in the database. Because of this, it is possible to access parts of the database even if you are not given direct access by inputting SQL language queries to unvalidated inputs. The reason in which this is possible is because many SQL queries rely on Boolean logic. This is a serious security risk for the software system and causes privacy concerns for any and all involved users.

=== Example ===

=== Mentor ===

Nicholas Himes

=== Team Members ===

* Lawrence O'Brien
* David Glymph
* Jacob Anderson

== Code Modifications ==
Described below are the code refactoring tasks and issues addressed by this team. We have also included any pertinent details, reasonings, comments, warnings, etc., corresponding to each task.

=== Dynamic Finders ===
The SQL injection issue present in the expertiza source code is caused by an unvalidated SQL query when when searching for sign up topics for assignments requiring topics. The system used the static "find" method which does not validate or in any protect against malicious input. In order to solve this issue we used a find_by method, which forces all input to be used in searching for one specific key in the database rather than allowing additional keys to be accessed using string terminating characters. This solves the issue by preventing unauthorized database access through SQL injection.

== Modified Files ==
* sign_up_sheet_controller.rb
* sign_up_sheet_controller_spec.rb

== Testing ==

=== Github Bots ===

[[File:Test.png]]

=== Running Tests ===
<pre>
rspec spec/controllers/sign_up_sheet_controller_spec.rb
</pre>

== GitHub links and Pull Request==
Link to Expertiza repository: [https://github.com/expertiza/expertiza here]

Link to the forked repository: [https://github.com/lobrien6588/expertiza here]

Link to Pull Request: [https://github.com/expertiza/expertiza/pull/2323 here]

== Images ==
[[File:SQL_Injection_Location.png]]

File:Test.png

2022-03-22T02:26:33Z

Lpobrien: Lpobrien uploaded a new version of File:Test.png

CSC/ECE 517 Spring 2022 - E2227: SQL Injection Fix

2022-03-21T20:46:34Z

Lpobrien:

This page details project documentation for the CSC/ECE 517 Spring 2022, "E2227 SQL Injection Fix" project.

== Background ==

Expertiza is an open source software system that is used in order to assign projects to students as well as provide a place to submit and review peers.

Many software projects such as expertiza rely on user interactions in order to accomplish the tasks given by their users. With this information input by the users, the software system often must access points in the database. Because of this, it is possible to access parts of the database even if you are not given direct access by inputting SQL language queries to unvalidated inputs. The reason in which this is possible is because many SQL queries rely on Boolean logic. This is a serious security risk for the software system and causes privacy concerns for any and all involved users.

=== Example ===

=== Mentor ===

Nicholas Himes

=== Team Members ===

* Lawrence O'Brien
* David Glymph
* Jacob Anderson

== Code Modifications ==
Described below are the code refactoring tasks and issues addressed by this team. We have also included any pertinent details, reasonings, comments, warnings, etc., corresponding to each task.

=== Dynamic Finders ===
The SQL injection issue present in the expertiza source code is caused by an unvalidated SQL query when when searching for sign up topics for assignments requiring topics. The system used the static "find" method which does not validate or in any protect against malicious input. In order to solve this issue we used a find_by method, which forces all input to be used in searching for one specific key in the database rather than allowing additional keys to be accessed using string terminating characters. This solves the issue by preventing unauthorized database access through SQL injection.

== Modified Files ==
* sign_up_sheet_controller.rb
* sign_up_sheet_controller_spec.rb

== Testing ==

=== Running Tests ===
<pre>
rspec spec/controllers/sign_up_sheet_controller_spec.rb
</pre>

== GitHub links and Pull Request==
Link to Expertiza repository: [https://github.com/expertiza/expertiza here]

Link to the forked repository: [https://github.com/lobrien6588/expertiza here]

Link to Pull Request: [https://github.com/expertiza/expertiza/pull/2323 here]

== Images ==
[[File:SQL_Injection_Location.png]]

File:SQL Injection Location.png

2022-03-21T20:45:51Z

Lpobrien:

CSC/ECE 517 Spring 2022 - E2227: SQL Injection Fix

2022-03-21T20:43:15Z

Lpobrien:

CSC/ECE 517 Spring 2022

2022-03-21T20:40:28Z

Lpobrien:

[[Link title]]== OSS Projects ==

* [[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 - E2203: 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 - 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]]

== Final Projects ==

CSC/ECE 517 Spring 2022 - E2227: SQL Injection Fix

2022-03-21T20:40:08Z

Lpobrien:

CSC/ECE 517 Spring 2022

2022-03-21T20:35:12Z

Lpobrien:

CSC/ECE 517 Spring 2022 - E2207: SQL Injection Fix

2022-03-21T19:10:48Z

Lpobrien:

This page details project documentation for the CSC/ECE 517 Spring 2022, "E2218 SQL Injection Fix" project.

== Background ==

Expertiza is an open source software system that is used in order to assign projects to students as well as provide a place to submit and review peers.

Many software projects such as expertiza rely on user interactions in order to accomplish the tasks given by their users. With this information input by the users, the software system often must access points in the database. Because of this, it is possible to access parts of the database even if you are not given direct access by inputting SQL language queries to unvalidated inputs. The reason in which this is possible is because many SQL queries rely on Boolean logic. This is a serious security risk for the software system and causes privacy concerns for any and all involved users.

=== Example ===

=== Mentor ===

Nicolas Himes

=== Team Members ===

* Lawrence O'Brien
* David Glymph
* Jacob Anderson

== Code Modifications ==
Described below are the code refactoring tasks and issues addressed by this team. We have also included any pertinent details, reasonings, comments, warnings, etc., corresponding to each task.

=== Dynamic Finders ===
The SQL injection issue present in the expertiza source code is caused by an unvalidated SQL query when when searching for sign up topics for assignments requiring topics. The system used the static "find" method which does not validate or in any protect against malicious input. In order to solve this issue we used a find_by method, which forces all input to be used in searching for one specific key in the database rather than allowing additional keys to be accessed using string terminating characters. This solves the issue by preventing unauthorized database access through SQL injection.

== Modified Files ==
* sign_up_sheet_controller.rb

== Testing ==

=== Running Tests ===
<pre>
rspec spec/controllers/sign_up_sheet_controller_spec.rb
</pre>

==GitHub links and Pull Request==
Link to Expertiza repository: [https://github.com/expertiza/expertiza here]

Link to the forked repository: [https://github.com/lobrien6588/expertiza here]

Link to Pull Request: [https://github.com/expertiza/expertiza/pull/2323 here]

CSC/ECE 517 Spring 2022 - E2207: SQL Injection Fix

2022-03-21T18:53:08Z

Lpobrien: Created page with "This page details project documentation for the CSC/ECE 517 Spring 2022, "E2218 SQL Injection Fix" project. == Background == Many software projects rely on user interaction..."

This page details project documentation for the CSC/ECE 517 Spring 2022, "E2218 SQL Injection Fix" project.

== Background ==

Many software projects rely on user interactions in order to accomplish the tasks given by

=== Mentor ===

Nicolas Himes

=== Team Members ===

* Lawrence Patrick O'Brien
* David Glymph

== Code Modifications and Refactorization ==
Described below are the code refactoring tasks and issues addressed by this team. We have also included any pertinent details, reasonings, comments, warnings, etc., corresponding to each task.

=== METHOD: def set_response ===
@response and @map instance variables are initialized the same way across multiple methods. In order to avoid duplication, we created a
before_action action which will be called first before calling the corresponding methods.

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

== Modified Files ==
<code>response_controller.rb</code>

<code>response_helper.rb</code>

<code>assignment_questionnaire.rb</code>

<code>awarded_badge.rb</code>

<code>cake.rb</code>

<code>response.rb</code>
== Testing ==

=== Running Tests ===
<pre>
rspec spec/controllers/questionnaires_controller_spec.rb
</pre>

==GitHub links and Pull Request==
Link to Expertiza repository: [https://github.com/expertiza/expertiza here]

Link to the forked repository: [https://github.com/vamshi-chidara/expertiza here]

Link to Pull Request: [https://github.com/expertiza/expertiza/pull/2327 here]

CSC/ECE 517 Spring 2022 - E2227: SQL Injection Fix

2022-03-16T19:48:48Z

Lpobrien: Created page with "== About Expertiza== [http://expertiza.ncsu.edu/ Expertiza] is a software used for the purposes of allowing students to submit projects for review by instructors as well as ot..."

== About Expertiza==
[http://expertiza.ncsu.edu/ Expertiza] is a software used for the purposes of allowing students to submit projects for review by instructors as well as other students in the form of peer reviews. It is used primarily by North Carolina State University, and is an open source platform developed in ruby using the rails framework in this [https://github.com/expertiza/expertiza/ repository].

== Description of project ==
The issue addressed by this wiki page is the presence of [https://en.wikipedia.org/wiki/SQL_injection/ SQL injection] points. Meaning there are points in the Expertiza system in which it is possible to input strings that allow malicious SQL statements to be run on the project database and give a user access to parts of the system in which they should not be able too.

=== Example ===
Should there be a space available for input requesting a name field for a user, the user may be able to input [[John]] in order to access a user named John. However if this input area is not validated or protected against SQL injections, a user may be able to input [[' OR '1'='1]] in order to gain access to information related to a user with primary key id of 1.

=== Files involved ===
Changes made solely to sign_up_sheet_controller.rb

== Solution ==