Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-24T16:36:57Z

Kprawat: /* Test Scenarios for E2147(Role based reviewing) */

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-24T16:34:46Z

Kprawat:

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-22T08:12:45Z

Kprawat: /* Brief Overview of E2147 and E2026 Projects */

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-22T08:12:14Z

Kprawat: /* Brief Overview of E2147 and E2026 Projects */

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-22T08:08:37Z

Kprawat:

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-22T08:08:09Z

Kprawat: /* Brief Overview of E2147 and E2026 Projects */

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-22T08:06:49Z

Kprawat: /* Brief Overview of E2147 and E2026 Projects */

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-22T08:04:50Z

Kprawat:

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-22T08:03:56Z

Kprawat:

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-22T08:02:39Z

Kprawat: /* Test Scenarios for E2147(Role based reviewing) */

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-22T07:58:15Z

Kprawat: /* Test Scenarios for E2147(Role based reviewing) */

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-22T07:57:26Z

Kprawat: /* Test Scenarios for E2147(Role based reviewing) */

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-22T07:56:28Z

Kprawat: /* Test Scenarios for E2147(Role based reviewing) */

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-22T07:55:42Z

Kprawat: /* Test Scenarios for E2147(Role based reviewing)= */

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-22T07:55:26Z

Kprawat: /* Test Scenarios for E2026(Specialized rubrics for different topics)= */

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-22T07:55:09Z

Kprawat: /* Testing Plan */

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-22T07:53:59Z

Kprawat: /* Develop New RSpec Tests */

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-22T07:53:19Z

Kprawat: /* Develop New RSpec Tests */

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-22T07:42:10Z

Kprawat:

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-20T06:41:37Z

Kprawat: /* Purpose */

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing with the existing E2026-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Spring_2020_-_E2026._Specialized_rubrics_for_different_topic_types. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Design Strategy==
This feature was previously implemented and was detailed [http://wiki.expertiza.ncsu.edu/index.php/E1936_Specialized_Rubrics here]. The feature concluded with allowing 4 rubric scenarios for an assignment:
*Rubric does not vary by round or by topic.
*Rubric varies by round, but not by topic.
*Rubric varies by topic, but not by round.
*Rubric varies by both round and topic.
However, there were two issues with the implementation:
*Rubrics in the dropdown were only those created by the logged-in instructor, so the TA wouldn’t be able to see them
*Rubrics would not be saved after selecting them and saving.
In light of these issues, [https://github.com/gabalmat/expertiza/commit/23ed2cca2976f55515ea8980646e4432858bf446 changes] to expertiza were made as follows:
*Two additional columns are added into the Assignment table that determines whether Rubrics varies by either Round or Topic with default values False
*'''update_assignment_questionnaires''' method is re-implemented
**Having extra column in the assignment questionnaire table topic_id, no need for deleting all the data and re-writing it again every single time in the DB (this caused the previous implementation to have a delay when selecting **rubrics)
**The only varying value is questionnaire_id, the rest values may not change from Topics or Rubrics tabs, but can be added
*There are 4 (four) possible cases for saving and updating data:
**used_in_round = null and topic_id = null
**used_in_round = integer and topic_id = null
**used_in_round = null and topic_id = integer
**used_in_round = integer and topic_id = integer
This solved the issue of having rubrics save
===Problem===
The feature we have to implement was not fully committed due to the previously mentioned problems, so we have to reincorporate the missing code. However, a resulting issue is the inability for an instructor or TA to use rubrics that they did not create. The current problem can be broken down into the following parts:
# Integrate the changes made from the original implementation into the current version of Expertiza
# Allow an instructor/TA to chose rubrics that aren’t only theirs
# Create and update tests to reflect the changes as needed
===Proposed Solution===
Our proposed solution keeps the previous implementation, but changes rubric filtering to allow instructors/TAs to use filters that are not theirs. Alongside the changes in the original implementation we propose:
*Allow an instructor to choose different rubrics for different topics
**PROBLEM: The drop-downs for selecting rubrics show only those rubrics created by the currently-logged in instructor (per project mentor).
***SOLUTION: Change the filtering in the questionnaire_options method to reflect the desired filtering.
***FILE: app/helpers/assignment_helper.rb

==UML Diagram==
Following the [https://expertiza.csc.ncsu.edu/index.php/E1936_Specialized_Rubrics previous implementations's] footsteps, this diagram depicts the interactions between an instructor and an assignment. The instructor may edit, delete, copy, and other stuff (already existing in Expertiza). Alongside editing topics and due dates, the instructor can edit what rubrics are assigned to an assignment. The highlighted portions are of interest. The topics tab allows instructors to specify which rubric associates with each topic while the rubrics tab lets the instructor determine if the assignment will vary by topic or not.

[[File:Use_case_diagram_1936.png]]

==Files to be modified==

Since our project is to improve upon a previous implementation that was slightly flawed, we will be modifying all of the same files that they previously modified (even if we don’t choose to alter their implementation in that file).

The major modified files from the previous implementation include:
*'''Controllers'''
**''assignments_controller.rb'': To refresh the topics list when changing tabs
**''popup_controller.rb'': To add a potential error message to the rubric view scores popup

*'''Models'''
**''assignment.rb'': Add methods to determine if an assignment varies by rubric/topic. (will be refactored as part of our change, however)
**''assignment_form.rb'': Add topic ids to created assignment questionnaires
**''assignment_questionnaire.rb'': Add topic id to assignment questionnaire model
**''review_response_map.rb'': To allow finding review questionnaires by topic id
**''sign_up_topic.rb'': To allow a topic to have many assignment questionnaires attach to it (via topic id)

*'''Views'''
**''assignments/edit.html.erb'': To move topic editing view to its own file that is rendered as part of assignment edit
**''edit/_rubrics.html.erb'': Factor out common code into a function, update to use topic id
**''edit/_topics.html.erb'': Topic editing view that was moved from assignment edit view
**''popup/view_review_scores_popup.html.erb'': Assignments that vary by topic should not be displayed, instead getting error
**''sign_up_sheet/_table_line.html.erb'': Add questionnaires to signup sheet table if assignment varies by topic

*'''Helpers'''
**''assignment_helper.rb'': To add a topic id to the searchable fields for a questionnaire

*'''DB Migrate'''
**''XXXXXXXXXXX_add_topic_id_to_assignment_questionnaires.rb'': Migration to add topic id to assignment questionnaire schema

*'''All of the related test files to accommodate the above changes'''

To address the issues brought up with the previous implementation, we will also make the following major modifications:
*'''Controllers'''
**''assignments_controller.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''grades_controller.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''popup_controller.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods

*'''Models'''
**''assignment.rb'': Add persisted fields to the assignment for varying by topic/round instead of using methods to determine it
**''assignment_form.rb'': No longer delete all existing questionnaires on update, update them instead. Now find questionnaire by assignment questionnaire and type rather than assignment/type/round_number/topic_id.
**''assignment_participant.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''feedback_response_map.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''on_the_fly_calc.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''self_review_response_map.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''tag_prompt_deployment.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods

*'''Views'''
**''edit/_rubrics.html.erb'': Modify to set assignment vary by round/topic fields instead of non persisted flags

*'''Helpers'''
**''assignment_helper.rb'': Refactor by moving function to find questionnaire / assignment questionnaire to assignment_form.rb. Remove filters that only allow instructors to see rubrics.
**''grades_helper.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''summary_helper.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods

*'''DB Migrate'''
**''XXXXXXXXX_add_vary_by_topic_to_assignments.rb'': Migration to add “vary by topic” field to assignment
**''XXXXXXXXX_add_vary_by_round_to_assignments.rb'': Migration to add “vary by round” field to assignment

*'''All of the related test files to accommodate the above changes'''

==Database Flow==
We will be re-adding the database flow that was added in the previous implementation, linking ''sign_up_topic'' to ''assignment_questionnaire'' via a '''topic_id''' field.
[[File:HW04_table.PNG]]

In addition to that, we will be adding two additional boolean fields to the ''assignment'' schema: '''vary_by_round''' and '''vary_by_topic'''. As discussed earlier, in the previous implementation, these were methods that were called to determine if an assignment varied by round/topic rather than a persisted value.

[[File:E2026DatabaseFlow.png]]

Only a subset of the fields for each table is shown in the diagram because most of the fields are not relevant to these changes and would only serve to distract from the relevant changes. Additions are shown in bold.

==New Implementation==
While trying to integrate the previous team's implementation of this feature, we discovered that their method for querying AssignmentQuestionnaires (AQs) was flawed.

It would always query for the AQs by assignment id, current round number, and current topic id.

However, if the assignment did not have reviews that vary by round or topic, these values would be nil on the AQ, and the previous query would fail.

To fix this, we modified the ''assignment_questionnaire'' function in the AssignmentForm model to check the Assignment's ''vary_by_round'' and ''vary_by_topic'' flags, and then add the corresponding fields to the query.

This means that:
* If an assignment does not vary by round or by topic, the query for AQs will be by assignment id only.
* If the assignment varies by round but not topic, the query for AQs will be by assignment id and round number.

[[File:AQNewImpl.PNG]]

==Testing Plan==
As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):
===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*As part of previous implementation, the team had introduced the following new RSpec test files. We have retained those file.
**spec/helpers/assignment_helper_spec.rb
**spec/models/self_review_response_map_spec.rb
*All these rspec tests passed.

===Manual Testing in Expertiza UI===
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-20T06:40:51Z

Kprawat: /* Purpose */

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-https://expertiza.csc.ncsu.edu/index.php/CSC/ECE_517_Fall_2021_-_E2147._Role-based_reviewing#E2147._Role-based_reviewing with the existing E2026-Specialized Rubrics for different topics. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Design Strategy==
This feature was previously implemented and was detailed [http://wiki.expertiza.ncsu.edu/index.php/E1936_Specialized_Rubrics here]. The feature concluded with allowing 4 rubric scenarios for an assignment:
*Rubric does not vary by round or by topic.
*Rubric varies by round, but not by topic.
*Rubric varies by topic, but not by round.
*Rubric varies by both round and topic.
However, there were two issues with the implementation:
*Rubrics in the dropdown were only those created by the logged-in instructor, so the TA wouldn’t be able to see them
*Rubrics would not be saved after selecting them and saving.
In light of these issues, [https://github.com/gabalmat/expertiza/commit/23ed2cca2976f55515ea8980646e4432858bf446 changes] to expertiza were made as follows:
*Two additional columns are added into the Assignment table that determines whether Rubrics varies by either Round or Topic with default values False
*'''update_assignment_questionnaires''' method is re-implemented
**Having extra column in the assignment questionnaire table topic_id, no need for deleting all the data and re-writing it again every single time in the DB (this caused the previous implementation to have a delay when selecting **rubrics)
**The only varying value is questionnaire_id, the rest values may not change from Topics or Rubrics tabs, but can be added
*There are 4 (four) possible cases for saving and updating data:
**used_in_round = null and topic_id = null
**used_in_round = integer and topic_id = null
**used_in_round = null and topic_id = integer
**used_in_round = integer and topic_id = integer
This solved the issue of having rubrics save
===Problem===
The feature we have to implement was not fully committed due to the previously mentioned problems, so we have to reincorporate the missing code. However, a resulting issue is the inability for an instructor or TA to use rubrics that they did not create. The current problem can be broken down into the following parts:
# Integrate the changes made from the original implementation into the current version of Expertiza
# Allow an instructor/TA to chose rubrics that aren’t only theirs
# Create and update tests to reflect the changes as needed
===Proposed Solution===
Our proposed solution keeps the previous implementation, but changes rubric filtering to allow instructors/TAs to use filters that are not theirs. Alongside the changes in the original implementation we propose:
*Allow an instructor to choose different rubrics for different topics
**PROBLEM: The drop-downs for selecting rubrics show only those rubrics created by the currently-logged in instructor (per project mentor).
***SOLUTION: Change the filtering in the questionnaire_options method to reflect the desired filtering.
***FILE: app/helpers/assignment_helper.rb

==UML Diagram==
Following the [https://expertiza.csc.ncsu.edu/index.php/E1936_Specialized_Rubrics previous implementations's] footsteps, this diagram depicts the interactions between an instructor and an assignment. The instructor may edit, delete, copy, and other stuff (already existing in Expertiza). Alongside editing topics and due dates, the instructor can edit what rubrics are assigned to an assignment. The highlighted portions are of interest. The topics tab allows instructors to specify which rubric associates with each topic while the rubrics tab lets the instructor determine if the assignment will vary by topic or not.

[[File:Use_case_diagram_1936.png]]

==Files to be modified==

Since our project is to improve upon a previous implementation that was slightly flawed, we will be modifying all of the same files that they previously modified (even if we don’t choose to alter their implementation in that file).

The major modified files from the previous implementation include:
*'''Controllers'''
**''assignments_controller.rb'': To refresh the topics list when changing tabs
**''popup_controller.rb'': To add a potential error message to the rubric view scores popup

*'''Models'''
**''assignment.rb'': Add methods to determine if an assignment varies by rubric/topic. (will be refactored as part of our change, however)
**''assignment_form.rb'': Add topic ids to created assignment questionnaires
**''assignment_questionnaire.rb'': Add topic id to assignment questionnaire model
**''review_response_map.rb'': To allow finding review questionnaires by topic id
**''sign_up_topic.rb'': To allow a topic to have many assignment questionnaires attach to it (via topic id)

*'''Views'''
**''assignments/edit.html.erb'': To move topic editing view to its own file that is rendered as part of assignment edit
**''edit/_rubrics.html.erb'': Factor out common code into a function, update to use topic id
**''edit/_topics.html.erb'': Topic editing view that was moved from assignment edit view
**''popup/view_review_scores_popup.html.erb'': Assignments that vary by topic should not be displayed, instead getting error
**''sign_up_sheet/_table_line.html.erb'': Add questionnaires to signup sheet table if assignment varies by topic

*'''Helpers'''
**''assignment_helper.rb'': To add a topic id to the searchable fields for a questionnaire

*'''DB Migrate'''
**''XXXXXXXXXXX_add_topic_id_to_assignment_questionnaires.rb'': Migration to add topic id to assignment questionnaire schema

*'''All of the related test files to accommodate the above changes'''

To address the issues brought up with the previous implementation, we will also make the following major modifications:
*'''Controllers'''
**''assignments_controller.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''grades_controller.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''popup_controller.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods

*'''Models'''
**''assignment.rb'': Add persisted fields to the assignment for varying by topic/round instead of using methods to determine it
**''assignment_form.rb'': No longer delete all existing questionnaires on update, update them instead. Now find questionnaire by assignment questionnaire and type rather than assignment/type/round_number/topic_id.
**''assignment_participant.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''feedback_response_map.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''on_the_fly_calc.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''self_review_response_map.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''tag_prompt_deployment.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods

*'''Views'''
**''edit/_rubrics.html.erb'': Modify to set assignment vary by round/topic fields instead of non persisted flags

*'''Helpers'''
**''assignment_helper.rb'': Refactor by moving function to find questionnaire / assignment questionnaire to assignment_form.rb. Remove filters that only allow instructors to see rubrics.
**''grades_helper.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''summary_helper.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods

*'''DB Migrate'''
**''XXXXXXXXX_add_vary_by_topic_to_assignments.rb'': Migration to add “vary by topic” field to assignment
**''XXXXXXXXX_add_vary_by_round_to_assignments.rb'': Migration to add “vary by round” field to assignment

*'''All of the related test files to accommodate the above changes'''

==Database Flow==
We will be re-adding the database flow that was added in the previous implementation, linking ''sign_up_topic'' to ''assignment_questionnaire'' via a '''topic_id''' field.
[[File:HW04_table.PNG]]

In addition to that, we will be adding two additional boolean fields to the ''assignment'' schema: '''vary_by_round''' and '''vary_by_topic'''. As discussed earlier, in the previous implementation, these were methods that were called to determine if an assignment varied by round/topic rather than a persisted value.

[[File:E2026DatabaseFlow.png]]

Only a subset of the fields for each table is shown in the diagram because most of the fields are not relevant to these changes and would only serve to distract from the relevant changes. Additions are shown in bold.

==New Implementation==
While trying to integrate the previous team's implementation of this feature, we discovered that their method for querying AssignmentQuestionnaires (AQs) was flawed.

It would always query for the AQs by assignment id, current round number, and current topic id.

However, if the assignment did not have reviews that vary by round or topic, these values would be nil on the AQ, and the previous query would fail.

To fix this, we modified the ''assignment_questionnaire'' function in the AssignmentForm model to check the Assignment's ''vary_by_round'' and ''vary_by_topic'' flags, and then add the corresponding fields to the query.

This means that:
* If an assignment does not vary by round or by topic, the query for AQs will be by assignment id only.
* If the assignment varies by round but not topic, the query for AQs will be by assignment id and round number.

[[File:AQNewImpl.PNG]]

==Testing Plan==
As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):
===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*As part of previous implementation, the team had introduced the following new RSpec test files. We have retained those file.
**spec/helpers/assignment_helper_spec.rb
**spec/models/self_review_response_map_spec.rb
*All these rspec tests passed.

===Manual Testing in Expertiza UI===
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-20T06:35:49Z

Kprawat: /* Purpose */

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-Role based reviewing(OSS Project) with the existing E2026-Specialized Rubrics for different topics. While merging, we found out that the code for E2026 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2026.

==Design Strategy==
This feature was previously implemented and was detailed [http://wiki.expertiza.ncsu.edu/index.php/E1936_Specialized_Rubrics here]. The feature concluded with allowing 4 rubric scenarios for an assignment:
*Rubric does not vary by round or by topic.
*Rubric varies by round, but not by topic.
*Rubric varies by topic, but not by round.
*Rubric varies by both round and topic.
However, there were two issues with the implementation:
*Rubrics in the dropdown were only those created by the logged-in instructor, so the TA wouldn’t be able to see them
*Rubrics would not be saved after selecting them and saving.
In light of these issues, [https://github.com/gabalmat/expertiza/commit/23ed2cca2976f55515ea8980646e4432858bf446 changes] to expertiza were made as follows:
*Two additional columns are added into the Assignment table that determines whether Rubrics varies by either Round or Topic with default values False
*'''update_assignment_questionnaires''' method is re-implemented
**Having extra column in the assignment questionnaire table topic_id, no need for deleting all the data and re-writing it again every single time in the DB (this caused the previous implementation to have a delay when selecting **rubrics)
**The only varying value is questionnaire_id, the rest values may not change from Topics or Rubrics tabs, but can be added
*There are 4 (four) possible cases for saving and updating data:
**used_in_round = null and topic_id = null
**used_in_round = integer and topic_id = null
**used_in_round = null and topic_id = integer
**used_in_round = integer and topic_id = integer
This solved the issue of having rubrics save
===Problem===
The feature we have to implement was not fully committed due to the previously mentioned problems, so we have to reincorporate the missing code. However, a resulting issue is the inability for an instructor or TA to use rubrics that they did not create. The current problem can be broken down into the following parts:
# Integrate the changes made from the original implementation into the current version of Expertiza
# Allow an instructor/TA to chose rubrics that aren’t only theirs
# Create and update tests to reflect the changes as needed
===Proposed Solution===
Our proposed solution keeps the previous implementation, but changes rubric filtering to allow instructors/TAs to use filters that are not theirs. Alongside the changes in the original implementation we propose:
*Allow an instructor to choose different rubrics for different topics
**PROBLEM: The drop-downs for selecting rubrics show only those rubrics created by the currently-logged in instructor (per project mentor).
***SOLUTION: Change the filtering in the questionnaire_options method to reflect the desired filtering.
***FILE: app/helpers/assignment_helper.rb

==UML Diagram==
Following the [https://expertiza.csc.ncsu.edu/index.php/E1936_Specialized_Rubrics previous implementations's] footsteps, this diagram depicts the interactions between an instructor and an assignment. The instructor may edit, delete, copy, and other stuff (already existing in Expertiza). Alongside editing topics and due dates, the instructor can edit what rubrics are assigned to an assignment. The highlighted portions are of interest. The topics tab allows instructors to specify which rubric associates with each topic while the rubrics tab lets the instructor determine if the assignment will vary by topic or not.

[[File:Use_case_diagram_1936.png]]

==Files to be modified==

Since our project is to improve upon a previous implementation that was slightly flawed, we will be modifying all of the same files that they previously modified (even if we don’t choose to alter their implementation in that file).

The major modified files from the previous implementation include:
*'''Controllers'''
**''assignments_controller.rb'': To refresh the topics list when changing tabs
**''popup_controller.rb'': To add a potential error message to the rubric view scores popup

*'''Models'''
**''assignment.rb'': Add methods to determine if an assignment varies by rubric/topic. (will be refactored as part of our change, however)
**''assignment_form.rb'': Add topic ids to created assignment questionnaires
**''assignment_questionnaire.rb'': Add topic id to assignment questionnaire model
**''review_response_map.rb'': To allow finding review questionnaires by topic id
**''sign_up_topic.rb'': To allow a topic to have many assignment questionnaires attach to it (via topic id)

*'''Views'''
**''assignments/edit.html.erb'': To move topic editing view to its own file that is rendered as part of assignment edit
**''edit/_rubrics.html.erb'': Factor out common code into a function, update to use topic id
**''edit/_topics.html.erb'': Topic editing view that was moved from assignment edit view
**''popup/view_review_scores_popup.html.erb'': Assignments that vary by topic should not be displayed, instead getting error
**''sign_up_sheet/_table_line.html.erb'': Add questionnaires to signup sheet table if assignment varies by topic

*'''Helpers'''
**''assignment_helper.rb'': To add a topic id to the searchable fields for a questionnaire

*'''DB Migrate'''
**''XXXXXXXXXXX_add_topic_id_to_assignment_questionnaires.rb'': Migration to add topic id to assignment questionnaire schema

*'''All of the related test files to accommodate the above changes'''

To address the issues brought up with the previous implementation, we will also make the following major modifications:
*'''Controllers'''
**''assignments_controller.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''grades_controller.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''popup_controller.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods

*'''Models'''
**''assignment.rb'': Add persisted fields to the assignment for varying by topic/round instead of using methods to determine it
**''assignment_form.rb'': No longer delete all existing questionnaires on update, update them instead. Now find questionnaire by assignment questionnaire and type rather than assignment/type/round_number/topic_id.
**''assignment_participant.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''feedback_response_map.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''on_the_fly_calc.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''self_review_response_map.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''tag_prompt_deployment.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods

*'''Views'''
**''edit/_rubrics.html.erb'': Modify to set assignment vary by round/topic fields instead of non persisted flags

*'''Helpers'''
**''assignment_helper.rb'': Refactor by moving function to find questionnaire / assignment questionnaire to assignment_form.rb. Remove filters that only allow instructors to see rubrics.
**''grades_helper.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''summary_helper.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods

*'''DB Migrate'''
**''XXXXXXXXX_add_vary_by_topic_to_assignments.rb'': Migration to add “vary by topic” field to assignment
**''XXXXXXXXX_add_vary_by_round_to_assignments.rb'': Migration to add “vary by round” field to assignment

*'''All of the related test files to accommodate the above changes'''

==Database Flow==
We will be re-adding the database flow that was added in the previous implementation, linking ''sign_up_topic'' to ''assignment_questionnaire'' via a '''topic_id''' field.
[[File:HW04_table.PNG]]

In addition to that, we will be adding two additional boolean fields to the ''assignment'' schema: '''vary_by_round''' and '''vary_by_topic'''. As discussed earlier, in the previous implementation, these were methods that were called to determine if an assignment varied by round/topic rather than a persisted value.

[[File:E2026DatabaseFlow.png]]

Only a subset of the fields for each table is shown in the diagram because most of the fields are not relevant to these changes and would only serve to distract from the relevant changes. Additions are shown in bold.

==New Implementation==
While trying to integrate the previous team's implementation of this feature, we discovered that their method for querying AssignmentQuestionnaires (AQs) was flawed.

It would always query for the AQs by assignment id, current round number, and current topic id.

However, if the assignment did not have reviews that vary by round or topic, these values would be nil on the AQ, and the previous query would fail.

To fix this, we modified the ''assignment_questionnaire'' function in the AssignmentForm model to check the Assignment's ''vary_by_round'' and ''vary_by_topic'' flags, and then add the corresponding fields to the query.

This means that:
* If an assignment does not vary by round or by topic, the query for AQs will be by assignment id only.
* If the assignment varies by round but not topic, the query for AQs will be by assignment id and round number.

[[File:AQNewImpl.PNG]]

==Testing Plan==
As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):
===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*As part of previous implementation, the team had introduced the following new RSpec test files. We have retained those file.
**spec/helpers/assignment_helper_spec.rb
**spec/models/self_review_response_map_spec.rb
*All these rspec tests passed.

===Manual Testing in Expertiza UI===
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-20T06:34:18Z

Kprawat: /* Coverage */

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-Role based reviewing(OSS Project) with the existing E2161-Specialized Rubrics for different topics. While merging, we found out that the code for E2161 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2161.

==Design Strategy==
This feature was previously implemented and was detailed [http://wiki.expertiza.ncsu.edu/index.php/E1936_Specialized_Rubrics here]. The feature concluded with allowing 4 rubric scenarios for an assignment:
*Rubric does not vary by round or by topic.
*Rubric varies by round, but not by topic.
*Rubric varies by topic, but not by round.
*Rubric varies by both round and topic.
However, there were two issues with the implementation:
*Rubrics in the dropdown were only those created by the logged-in instructor, so the TA wouldn’t be able to see them
*Rubrics would not be saved after selecting them and saving.
In light of these issues, [https://github.com/gabalmat/expertiza/commit/23ed2cca2976f55515ea8980646e4432858bf446 changes] to expertiza were made as follows:
*Two additional columns are added into the Assignment table that determines whether Rubrics varies by either Round or Topic with default values False
*'''update_assignment_questionnaires''' method is re-implemented
**Having extra column in the assignment questionnaire table topic_id, no need for deleting all the data and re-writing it again every single time in the DB (this caused the previous implementation to have a delay when selecting **rubrics)
**The only varying value is questionnaire_id, the rest values may not change from Topics or Rubrics tabs, but can be added
*There are 4 (four) possible cases for saving and updating data:
**used_in_round = null and topic_id = null
**used_in_round = integer and topic_id = null
**used_in_round = null and topic_id = integer
**used_in_round = integer and topic_id = integer
This solved the issue of having rubrics save
===Problem===
The feature we have to implement was not fully committed due to the previously mentioned problems, so we have to reincorporate the missing code. However, a resulting issue is the inability for an instructor or TA to use rubrics that they did not create. The current problem can be broken down into the following parts:
# Integrate the changes made from the original implementation into the current version of Expertiza
# Allow an instructor/TA to chose rubrics that aren’t only theirs
# Create and update tests to reflect the changes as needed
===Proposed Solution===
Our proposed solution keeps the previous implementation, but changes rubric filtering to allow instructors/TAs to use filters that are not theirs. Alongside the changes in the original implementation we propose:
*Allow an instructor to choose different rubrics for different topics
**PROBLEM: The drop-downs for selecting rubrics show only those rubrics created by the currently-logged in instructor (per project mentor).
***SOLUTION: Change the filtering in the questionnaire_options method to reflect the desired filtering.
***FILE: app/helpers/assignment_helper.rb

==UML Diagram==
Following the [https://expertiza.csc.ncsu.edu/index.php/E1936_Specialized_Rubrics previous implementations's] footsteps, this diagram depicts the interactions between an instructor and an assignment. The instructor may edit, delete, copy, and other stuff (already existing in Expertiza). Alongside editing topics and due dates, the instructor can edit what rubrics are assigned to an assignment. The highlighted portions are of interest. The topics tab allows instructors to specify which rubric associates with each topic while the rubrics tab lets the instructor determine if the assignment will vary by topic or not.

[[File:Use_case_diagram_1936.png]]

==Files to be modified==

Since our project is to improve upon a previous implementation that was slightly flawed, we will be modifying all of the same files that they previously modified (even if we don’t choose to alter their implementation in that file).

The major modified files from the previous implementation include:
*'''Controllers'''
**''assignments_controller.rb'': To refresh the topics list when changing tabs
**''popup_controller.rb'': To add a potential error message to the rubric view scores popup

*'''Models'''
**''assignment.rb'': Add methods to determine if an assignment varies by rubric/topic. (will be refactored as part of our change, however)
**''assignment_form.rb'': Add topic ids to created assignment questionnaires
**''assignment_questionnaire.rb'': Add topic id to assignment questionnaire model
**''review_response_map.rb'': To allow finding review questionnaires by topic id
**''sign_up_topic.rb'': To allow a topic to have many assignment questionnaires attach to it (via topic id)

*'''Views'''
**''assignments/edit.html.erb'': To move topic editing view to its own file that is rendered as part of assignment edit
**''edit/_rubrics.html.erb'': Factor out common code into a function, update to use topic id
**''edit/_topics.html.erb'': Topic editing view that was moved from assignment edit view
**''popup/view_review_scores_popup.html.erb'': Assignments that vary by topic should not be displayed, instead getting error
**''sign_up_sheet/_table_line.html.erb'': Add questionnaires to signup sheet table if assignment varies by topic

*'''Helpers'''
**''assignment_helper.rb'': To add a topic id to the searchable fields for a questionnaire

*'''DB Migrate'''
**''XXXXXXXXXXX_add_topic_id_to_assignment_questionnaires.rb'': Migration to add topic id to assignment questionnaire schema

*'''All of the related test files to accommodate the above changes'''

To address the issues brought up with the previous implementation, we will also make the following major modifications:
*'''Controllers'''
**''assignments_controller.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''grades_controller.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''popup_controller.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods

*'''Models'''
**''assignment.rb'': Add persisted fields to the assignment for varying by topic/round instead of using methods to determine it
**''assignment_form.rb'': No longer delete all existing questionnaires on update, update them instead. Now find questionnaire by assignment questionnaire and type rather than assignment/type/round_number/topic_id.
**''assignment_participant.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''feedback_response_map.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''on_the_fly_calc.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''self_review_response_map.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''tag_prompt_deployment.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods

*'''Views'''
**''edit/_rubrics.html.erb'': Modify to set assignment vary by round/topic fields instead of non persisted flags

*'''Helpers'''
**''assignment_helper.rb'': Refactor by moving function to find questionnaire / assignment questionnaire to assignment_form.rb. Remove filters that only allow instructors to see rubrics.
**''grades_helper.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''summary_helper.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods

*'''DB Migrate'''
**''XXXXXXXXX_add_vary_by_topic_to_assignments.rb'': Migration to add “vary by topic” field to assignment
**''XXXXXXXXX_add_vary_by_round_to_assignments.rb'': Migration to add “vary by round” field to assignment

*'''All of the related test files to accommodate the above changes'''

==Database Flow==
We will be re-adding the database flow that was added in the previous implementation, linking ''sign_up_topic'' to ''assignment_questionnaire'' via a '''topic_id''' field.
[[File:HW04_table.PNG]]

In addition to that, we will be adding two additional boolean fields to the ''assignment'' schema: '''vary_by_round''' and '''vary_by_topic'''. As discussed earlier, in the previous implementation, these were methods that were called to determine if an assignment varied by round/topic rather than a persisted value.

[[File:E2026DatabaseFlow.png]]

Only a subset of the fields for each table is shown in the diagram because most of the fields are not relevant to these changes and would only serve to distract from the relevant changes. Additions are shown in bold.

==New Implementation==
While trying to integrate the previous team's implementation of this feature, we discovered that their method for querying AssignmentQuestionnaires (AQs) was flawed.

It would always query for the AQs by assignment id, current round number, and current topic id.

However, if the assignment did not have reviews that vary by round or topic, these values would be nil on the AQ, and the previous query would fail.

To fix this, we modified the ''assignment_questionnaire'' function in the AssignmentForm model to check the Assignment's ''vary_by_round'' and ''vary_by_topic'' flags, and then add the corresponding fields to the query.

This means that:
* If an assignment does not vary by round or by topic, the query for AQs will be by assignment id only.
* If the assignment varies by round but not topic, the query for AQs will be by assignment id and round number.

[[File:AQNewImpl.PNG]]

==Testing Plan==
As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):
===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*As part of previous implementation, the team had introduced the following new RSpec test files. We have retained those file.
**spec/helpers/assignment_helper_spec.rb
**spec/models/self_review_response_map_spec.rb
*All these rspec tests passed.

===Manual Testing in Expertiza UI===
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-20T06:33:59Z

Kprawat: /* Future Work */

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-Role based reviewing(OSS Project) with the existing E2161-Specialized Rubrics for different topics. While merging, we found out that the code for E2161 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2161.

==Design Strategy==
This feature was previously implemented and was detailed [http://wiki.expertiza.ncsu.edu/index.php/E1936_Specialized_Rubrics here]. The feature concluded with allowing 4 rubric scenarios for an assignment:
*Rubric does not vary by round or by topic.
*Rubric varies by round, but not by topic.
*Rubric varies by topic, but not by round.
*Rubric varies by both round and topic.
However, there were two issues with the implementation:
*Rubrics in the dropdown were only those created by the logged-in instructor, so the TA wouldn’t be able to see them
*Rubrics would not be saved after selecting them and saving.
In light of these issues, [https://github.com/gabalmat/expertiza/commit/23ed2cca2976f55515ea8980646e4432858bf446 changes] to expertiza were made as follows:
*Two additional columns are added into the Assignment table that determines whether Rubrics varies by either Round or Topic with default values False
*'''update_assignment_questionnaires''' method is re-implemented
**Having extra column in the assignment questionnaire table topic_id, no need for deleting all the data and re-writing it again every single time in the DB (this caused the previous implementation to have a delay when selecting **rubrics)
**The only varying value is questionnaire_id, the rest values may not change from Topics or Rubrics tabs, but can be added
*There are 4 (four) possible cases for saving and updating data:
**used_in_round = null and topic_id = null
**used_in_round = integer and topic_id = null
**used_in_round = null and topic_id = integer
**used_in_round = integer and topic_id = integer
This solved the issue of having rubrics save
===Problem===
The feature we have to implement was not fully committed due to the previously mentioned problems, so we have to reincorporate the missing code. However, a resulting issue is the inability for an instructor or TA to use rubrics that they did not create. The current problem can be broken down into the following parts:
# Integrate the changes made from the original implementation into the current version of Expertiza
# Allow an instructor/TA to chose rubrics that aren’t only theirs
# Create and update tests to reflect the changes as needed
===Proposed Solution===
Our proposed solution keeps the previous implementation, but changes rubric filtering to allow instructors/TAs to use filters that are not theirs. Alongside the changes in the original implementation we propose:
*Allow an instructor to choose different rubrics for different topics
**PROBLEM: The drop-downs for selecting rubrics show only those rubrics created by the currently-logged in instructor (per project mentor).
***SOLUTION: Change the filtering in the questionnaire_options method to reflect the desired filtering.
***FILE: app/helpers/assignment_helper.rb

==UML Diagram==
Following the [https://expertiza.csc.ncsu.edu/index.php/E1936_Specialized_Rubrics previous implementations's] footsteps, this diagram depicts the interactions between an instructor and an assignment. The instructor may edit, delete, copy, and other stuff (already existing in Expertiza). Alongside editing topics and due dates, the instructor can edit what rubrics are assigned to an assignment. The highlighted portions are of interest. The topics tab allows instructors to specify which rubric associates with each topic while the rubrics tab lets the instructor determine if the assignment will vary by topic or not.

[[File:Use_case_diagram_1936.png]]

==Files to be modified==

Since our project is to improve upon a previous implementation that was slightly flawed, we will be modifying all of the same files that they previously modified (even if we don’t choose to alter their implementation in that file).

The major modified files from the previous implementation include:
*'''Controllers'''
**''assignments_controller.rb'': To refresh the topics list when changing tabs
**''popup_controller.rb'': To add a potential error message to the rubric view scores popup

*'''Models'''
**''assignment.rb'': Add methods to determine if an assignment varies by rubric/topic. (will be refactored as part of our change, however)
**''assignment_form.rb'': Add topic ids to created assignment questionnaires
**''assignment_questionnaire.rb'': Add topic id to assignment questionnaire model
**''review_response_map.rb'': To allow finding review questionnaires by topic id
**''sign_up_topic.rb'': To allow a topic to have many assignment questionnaires attach to it (via topic id)

*'''Views'''
**''assignments/edit.html.erb'': To move topic editing view to its own file that is rendered as part of assignment edit
**''edit/_rubrics.html.erb'': Factor out common code into a function, update to use topic id
**''edit/_topics.html.erb'': Topic editing view that was moved from assignment edit view
**''popup/view_review_scores_popup.html.erb'': Assignments that vary by topic should not be displayed, instead getting error
**''sign_up_sheet/_table_line.html.erb'': Add questionnaires to signup sheet table if assignment varies by topic

*'''Helpers'''
**''assignment_helper.rb'': To add a topic id to the searchable fields for a questionnaire

*'''DB Migrate'''
**''XXXXXXXXXXX_add_topic_id_to_assignment_questionnaires.rb'': Migration to add topic id to assignment questionnaire schema

*'''All of the related test files to accommodate the above changes'''

To address the issues brought up with the previous implementation, we will also make the following major modifications:
*'''Controllers'''
**''assignments_controller.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''grades_controller.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''popup_controller.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods

*'''Models'''
**''assignment.rb'': Add persisted fields to the assignment for varying by topic/round instead of using methods to determine it
**''assignment_form.rb'': No longer delete all existing questionnaires on update, update them instead. Now find questionnaire by assignment questionnaire and type rather than assignment/type/round_number/topic_id.
**''assignment_participant.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''feedback_response_map.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''on_the_fly_calc.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''self_review_response_map.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''tag_prompt_deployment.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods

*'''Views'''
**''edit/_rubrics.html.erb'': Modify to set assignment vary by round/topic fields instead of non persisted flags

*'''Helpers'''
**''assignment_helper.rb'': Refactor by moving function to find questionnaire / assignment questionnaire to assignment_form.rb. Remove filters that only allow instructors to see rubrics.
**''grades_helper.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''summary_helper.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods

*'''DB Migrate'''
**''XXXXXXXXX_add_vary_by_topic_to_assignments.rb'': Migration to add “vary by topic” field to assignment
**''XXXXXXXXX_add_vary_by_round_to_assignments.rb'': Migration to add “vary by round” field to assignment

*'''All of the related test files to accommodate the above changes'''

==Database Flow==
We will be re-adding the database flow that was added in the previous implementation, linking ''sign_up_topic'' to ''assignment_questionnaire'' via a '''topic_id''' field.
[[File:HW04_table.PNG]]

In addition to that, we will be adding two additional boolean fields to the ''assignment'' schema: '''vary_by_round''' and '''vary_by_topic'''. As discussed earlier, in the previous implementation, these were methods that were called to determine if an assignment varied by round/topic rather than a persisted value.

[[File:E2026DatabaseFlow.png]]

Only a subset of the fields for each table is shown in the diagram because most of the fields are not relevant to these changes and would only serve to distract from the relevant changes. Additions are shown in bold.

==New Implementation==
While trying to integrate the previous team's implementation of this feature, we discovered that their method for querying AssignmentQuestionnaires (AQs) was flawed.

It would always query for the AQs by assignment id, current round number, and current topic id.

However, if the assignment did not have reviews that vary by round or topic, these values would be nil on the AQ, and the previous query would fail.

To fix this, we modified the ''assignment_questionnaire'' function in the AssignmentForm model to check the Assignment's ''vary_by_round'' and ''vary_by_topic'' flags, and then add the corresponding fields to the query.

This means that:
* If an assignment does not vary by round or by topic, the query for AQs will be by assignment id only.
* If the assignment varies by round but not topic, the query for AQs will be by assignment id and round number.

[[File:AQNewImpl.PNG]]

==Testing Plan==
As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):
===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*As part of previous implementation, the team had introduced the following new RSpec test files. We have retained those file.
**spec/helpers/assignment_helper_spec.rb
**spec/models/self_review_response_map_spec.rb
*All these rspec tests passed.

===Manual Testing in Expertiza UI===
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

===Coverage===
All rspec tests part of [https://travis-ci.org/github/expertiza/expertiza/builds/679301186 Travis CI build] has passed. The [https://coveralls.io/jobs/61850924 code coverage] has increased by 10.9% to 41.425%.

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-20T06:29:25Z

Kprawat: /* Previous Implementation */

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-Role based reviewing(OSS Project) with the existing E2161-Specialized Rubrics for different topics. While merging, we found out that the code for E2161 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2161.

==Design Strategy==
This feature was previously implemented and was detailed [http://wiki.expertiza.ncsu.edu/index.php/E1936_Specialized_Rubrics here]. The feature concluded with allowing 4 rubric scenarios for an assignment:
*Rubric does not vary by round or by topic.
*Rubric varies by round, but not by topic.
*Rubric varies by topic, but not by round.
*Rubric varies by both round and topic.
However, there were two issues with the implementation:
*Rubrics in the dropdown were only those created by the logged-in instructor, so the TA wouldn’t be able to see them
*Rubrics would not be saved after selecting them and saving.
In light of these issues, [https://github.com/gabalmat/expertiza/commit/23ed2cca2976f55515ea8980646e4432858bf446 changes] to expertiza were made as follows:
*Two additional columns are added into the Assignment table that determines whether Rubrics varies by either Round or Topic with default values False
*'''update_assignment_questionnaires''' method is re-implemented
**Having extra column in the assignment questionnaire table topic_id, no need for deleting all the data and re-writing it again every single time in the DB (this caused the previous implementation to have a delay when selecting **rubrics)
**The only varying value is questionnaire_id, the rest values may not change from Topics or Rubrics tabs, but can be added
*There are 4 (four) possible cases for saving and updating data:
**used_in_round = null and topic_id = null
**used_in_round = integer and topic_id = null
**used_in_round = null and topic_id = integer
**used_in_round = integer and topic_id = integer
This solved the issue of having rubrics save
===Problem===
The feature we have to implement was not fully committed due to the previously mentioned problems, so we have to reincorporate the missing code. However, a resulting issue is the inability for an instructor or TA to use rubrics that they did not create. The current problem can be broken down into the following parts:
# Integrate the changes made from the original implementation into the current version of Expertiza
# Allow an instructor/TA to chose rubrics that aren’t only theirs
# Create and update tests to reflect the changes as needed
===Proposed Solution===
Our proposed solution keeps the previous implementation, but changes rubric filtering to allow instructors/TAs to use filters that are not theirs. Alongside the changes in the original implementation we propose:
*Allow an instructor to choose different rubrics for different topics
**PROBLEM: The drop-downs for selecting rubrics show only those rubrics created by the currently-logged in instructor (per project mentor).
***SOLUTION: Change the filtering in the questionnaire_options method to reflect the desired filtering.
***FILE: app/helpers/assignment_helper.rb

==UML Diagram==
Following the [https://expertiza.csc.ncsu.edu/index.php/E1936_Specialized_Rubrics previous implementations's] footsteps, this diagram depicts the interactions between an instructor and an assignment. The instructor may edit, delete, copy, and other stuff (already existing in Expertiza). Alongside editing topics and due dates, the instructor can edit what rubrics are assigned to an assignment. The highlighted portions are of interest. The topics tab allows instructors to specify which rubric associates with each topic while the rubrics tab lets the instructor determine if the assignment will vary by topic or not.

[[File:Use_case_diagram_1936.png]]

==Files to be modified==

Since our project is to improve upon a previous implementation that was slightly flawed, we will be modifying all of the same files that they previously modified (even if we don’t choose to alter their implementation in that file).

The major modified files from the previous implementation include:
*'''Controllers'''
**''assignments_controller.rb'': To refresh the topics list when changing tabs
**''popup_controller.rb'': To add a potential error message to the rubric view scores popup

*'''Models'''
**''assignment.rb'': Add methods to determine if an assignment varies by rubric/topic. (will be refactored as part of our change, however)
**''assignment_form.rb'': Add topic ids to created assignment questionnaires
**''assignment_questionnaire.rb'': Add topic id to assignment questionnaire model
**''review_response_map.rb'': To allow finding review questionnaires by topic id
**''sign_up_topic.rb'': To allow a topic to have many assignment questionnaires attach to it (via topic id)

*'''Views'''
**''assignments/edit.html.erb'': To move topic editing view to its own file that is rendered as part of assignment edit
**''edit/_rubrics.html.erb'': Factor out common code into a function, update to use topic id
**''edit/_topics.html.erb'': Topic editing view that was moved from assignment edit view
**''popup/view_review_scores_popup.html.erb'': Assignments that vary by topic should not be displayed, instead getting error
**''sign_up_sheet/_table_line.html.erb'': Add questionnaires to signup sheet table if assignment varies by topic

*'''Helpers'''
**''assignment_helper.rb'': To add a topic id to the searchable fields for a questionnaire

*'''DB Migrate'''
**''XXXXXXXXXXX_add_topic_id_to_assignment_questionnaires.rb'': Migration to add topic id to assignment questionnaire schema

*'''All of the related test files to accommodate the above changes'''

To address the issues brought up with the previous implementation, we will also make the following major modifications:
*'''Controllers'''
**''assignments_controller.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''grades_controller.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''popup_controller.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods

*'''Models'''
**''assignment.rb'': Add persisted fields to the assignment for varying by topic/round instead of using methods to determine it
**''assignment_form.rb'': No longer delete all existing questionnaires on update, update them instead. Now find questionnaire by assignment questionnaire and type rather than assignment/type/round_number/topic_id.
**''assignment_participant.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''feedback_response_map.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''on_the_fly_calc.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''self_review_response_map.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''tag_prompt_deployment.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods

*'''Views'''
**''edit/_rubrics.html.erb'': Modify to set assignment vary by round/topic fields instead of non persisted flags

*'''Helpers'''
**''assignment_helper.rb'': Refactor by moving function to find questionnaire / assignment questionnaire to assignment_form.rb. Remove filters that only allow instructors to see rubrics.
**''grades_helper.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''summary_helper.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods

*'''DB Migrate'''
**''XXXXXXXXX_add_vary_by_topic_to_assignments.rb'': Migration to add “vary by topic” field to assignment
**''XXXXXXXXX_add_vary_by_round_to_assignments.rb'': Migration to add “vary by round” field to assignment

*'''All of the related test files to accommodate the above changes'''

==Database Flow==
We will be re-adding the database flow that was added in the previous implementation, linking ''sign_up_topic'' to ''assignment_questionnaire'' via a '''topic_id''' field.
[[File:HW04_table.PNG]]

In addition to that, we will be adding two additional boolean fields to the ''assignment'' schema: '''vary_by_round''' and '''vary_by_topic'''. As discussed earlier, in the previous implementation, these were methods that were called to determine if an assignment varied by round/topic rather than a persisted value.

[[File:E2026DatabaseFlow.png]]

Only a subset of the fields for each table is shown in the diagram because most of the fields are not relevant to these changes and would only serve to distract from the relevant changes. Additions are shown in bold.

==New Implementation==
While trying to integrate the previous team's implementation of this feature, we discovered that their method for querying AssignmentQuestionnaires (AQs) was flawed.

It would always query for the AQs by assignment id, current round number, and current topic id.

However, if the assignment did not have reviews that vary by round or topic, these values would be nil on the AQ, and the previous query would fail.

To fix this, we modified the ''assignment_questionnaire'' function in the AssignmentForm model to check the Assignment's ''vary_by_round'' and ''vary_by_topic'' flags, and then add the corresponding fields to the query.

This means that:
* If an assignment does not vary by round or by topic, the query for AQs will be by assignment id only.
* If the assignment varies by round but not topic, the query for AQs will be by assignment id and round number.

[[File:AQNewImpl.PNG]]

==Testing Plan==
As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):
===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*As part of previous implementation, the team had introduced the following new RSpec test files. We have retained those file.
**spec/helpers/assignment_helper_spec.rb
**spec/models/self_review_response_map_spec.rb
*All these rspec tests passed.

===Manual Testing in Expertiza UI===
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

===Coverage===
All rspec tests part of [https://travis-ci.org/github/expertiza/expertiza/builds/679301186 Travis CI build] has passed. The [https://coveralls.io/jobs/61850924 code coverage] has increased by 10.9% to 41.425%.

== Future Work==
After merging the previous team's work with expertiza, several RSpec tests failed.
*This was due to how questionnaires were retrieved/found for an assignment. Staggered deadlines also rely on finding questionnaires using topic id, which isn't handled until after an assignment is made.
*'''Resolved'''
However, undoing filtering results in even more errors across models, controllers, and forms. This feature, however is a quality of life improvement and is less of a priority.
* '''Unresolved'''
Another quality of life improvement is that staggered deadlines and topics cannot be added to an assignment until after the assignment has been created and saved.
* This issue exists on expertiza's beta branch itself, separate from our changes.
*'''Unresolved'''

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2161. Merge code for role based reviewing with code for topic specific rubrics

2021-11-20T06:29:01Z

Kprawat: /* Purpose */

This wiki page contains description of changes designed and implemented for [https://docs.google.com/document/d/1slx4HPIbgTH-psIKMSCF-HDF9brxf-FuYhzVT9ZiIrM/edit#heading=h.8s6o9jnnxj0p E2161. Merge code for role-based reviewing with code for topic-specific rubrics], a Final Project for CSC/ECE 517, Fall 2021.
== Purpose==
In CSC/ECE 517, there are Expertiza-based course projects, Mozilla-based course projects, etc. However, currently, we can only specify one kind of rubric for all kinds of course projects. This means that refactoring projects, testing projects, and Mozilla projects need to use the same rubric. We hope we could specify different rubrics to be used with different kinds of course projects.

The project objective is to merge E2147-Role based reviewing(OSS Project) with the existing E2161-Specialized Rubrics for different topics. While merging, we found out that the code for E2161 has already been merged on Expertiza beta branch and so now the actual implementation is to write test cases for both E2147 and E2161.

== Previous Implementation==
All aspects of previous implementation were good, and their design was well appreciated. Their changes were also merged to '''expertiza:beta''' branch, but were later reverted since the specialized rubrics weren’t saved in the database. This [https://github.com/expertiza/expertiza/issues/1475 github issue] provides a detailed explanation to the problem.

For us to get started, we were provided with following links from previous implementation:
*http://wiki.expertiza.ncsu.edu/index.php/E1936_Specialized_Rubrics
*https://github.com/gabalmat/expertiza/tree/beta
*https://github.com/expertiza/expertiza/pull/1444
*https://www.youtube.com/watch?v=F7nQsIUspQM

==Design Strategy==
This feature was previously implemented and was detailed [http://wiki.expertiza.ncsu.edu/index.php/E1936_Specialized_Rubrics here]. The feature concluded with allowing 4 rubric scenarios for an assignment:
*Rubric does not vary by round or by topic.
*Rubric varies by round, but not by topic.
*Rubric varies by topic, but not by round.
*Rubric varies by both round and topic.
However, there were two issues with the implementation:
*Rubrics in the dropdown were only those created by the logged-in instructor, so the TA wouldn’t be able to see them
*Rubrics would not be saved after selecting them and saving.
In light of these issues, [https://github.com/gabalmat/expertiza/commit/23ed2cca2976f55515ea8980646e4432858bf446 changes] to expertiza were made as follows:
*Two additional columns are added into the Assignment table that determines whether Rubrics varies by either Round or Topic with default values False
*'''update_assignment_questionnaires''' method is re-implemented
**Having extra column in the assignment questionnaire table topic_id, no need for deleting all the data and re-writing it again every single time in the DB (this caused the previous implementation to have a delay when selecting **rubrics)
**The only varying value is questionnaire_id, the rest values may not change from Topics or Rubrics tabs, but can be added
*There are 4 (four) possible cases for saving and updating data:
**used_in_round = null and topic_id = null
**used_in_round = integer and topic_id = null
**used_in_round = null and topic_id = integer
**used_in_round = integer and topic_id = integer
This solved the issue of having rubrics save
===Problem===
The feature we have to implement was not fully committed due to the previously mentioned problems, so we have to reincorporate the missing code. However, a resulting issue is the inability for an instructor or TA to use rubrics that they did not create. The current problem can be broken down into the following parts:
# Integrate the changes made from the original implementation into the current version of Expertiza
# Allow an instructor/TA to chose rubrics that aren’t only theirs
# Create and update tests to reflect the changes as needed
===Proposed Solution===
Our proposed solution keeps the previous implementation, but changes rubric filtering to allow instructors/TAs to use filters that are not theirs. Alongside the changes in the original implementation we propose:
*Allow an instructor to choose different rubrics for different topics
**PROBLEM: The drop-downs for selecting rubrics show only those rubrics created by the currently-logged in instructor (per project mentor).
***SOLUTION: Change the filtering in the questionnaire_options method to reflect the desired filtering.
***FILE: app/helpers/assignment_helper.rb

==UML Diagram==
Following the [https://expertiza.csc.ncsu.edu/index.php/E1936_Specialized_Rubrics previous implementations's] footsteps, this diagram depicts the interactions between an instructor and an assignment. The instructor may edit, delete, copy, and other stuff (already existing in Expertiza). Alongside editing topics and due dates, the instructor can edit what rubrics are assigned to an assignment. The highlighted portions are of interest. The topics tab allows instructors to specify which rubric associates with each topic while the rubrics tab lets the instructor determine if the assignment will vary by topic or not.

[[File:Use_case_diagram_1936.png]]

==Files to be modified==

Since our project is to improve upon a previous implementation that was slightly flawed, we will be modifying all of the same files that they previously modified (even if we don’t choose to alter their implementation in that file).

The major modified files from the previous implementation include:
*'''Controllers'''
**''assignments_controller.rb'': To refresh the topics list when changing tabs
**''popup_controller.rb'': To add a potential error message to the rubric view scores popup

*'''Models'''
**''assignment.rb'': Add methods to determine if an assignment varies by rubric/topic. (will be refactored as part of our change, however)
**''assignment_form.rb'': Add topic ids to created assignment questionnaires
**''assignment_questionnaire.rb'': Add topic id to assignment questionnaire model
**''review_response_map.rb'': To allow finding review questionnaires by topic id
**''sign_up_topic.rb'': To allow a topic to have many assignment questionnaires attach to it (via topic id)

*'''Views'''
**''assignments/edit.html.erb'': To move topic editing view to its own file that is rendered as part of assignment edit
**''edit/_rubrics.html.erb'': Factor out common code into a function, update to use topic id
**''edit/_topics.html.erb'': Topic editing view that was moved from assignment edit view
**''popup/view_review_scores_popup.html.erb'': Assignments that vary by topic should not be displayed, instead getting error
**''sign_up_sheet/_table_line.html.erb'': Add questionnaires to signup sheet table if assignment varies by topic

*'''Helpers'''
**''assignment_helper.rb'': To add a topic id to the searchable fields for a questionnaire

*'''DB Migrate'''
**''XXXXXXXXXXX_add_topic_id_to_assignment_questionnaires.rb'': Migration to add topic id to assignment questionnaire schema

*'''All of the related test files to accommodate the above changes'''

To address the issues brought up with the previous implementation, we will also make the following major modifications:
*'''Controllers'''
**''assignments_controller.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''grades_controller.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''popup_controller.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods

*'''Models'''
**''assignment.rb'': Add persisted fields to the assignment for varying by topic/round instead of using methods to determine it
**''assignment_form.rb'': No longer delete all existing questionnaires on update, update them instead. Now find questionnaire by assignment questionnaire and type rather than assignment/type/round_number/topic_id.
**''assignment_participant.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''feedback_response_map.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''on_the_fly_calc.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''self_review_response_map.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''tag_prompt_deployment.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods

*'''Views'''
**''edit/_rubrics.html.erb'': Modify to set assignment vary by round/topic fields instead of non persisted flags

*'''Helpers'''
**''assignment_helper.rb'': Refactor by moving function to find questionnaire / assignment questionnaire to assignment_form.rb. Remove filters that only allow instructors to see rubrics.
**''grades_helper.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods
**''summary_helper.rb'': Refactor to use the persisted assignment fields for varying by topic/round instead of using methods

*'''DB Migrate'''
**''XXXXXXXXX_add_vary_by_topic_to_assignments.rb'': Migration to add “vary by topic” field to assignment
**''XXXXXXXXX_add_vary_by_round_to_assignments.rb'': Migration to add “vary by round” field to assignment

*'''All of the related test files to accommodate the above changes'''

==Database Flow==
We will be re-adding the database flow that was added in the previous implementation, linking ''sign_up_topic'' to ''assignment_questionnaire'' via a '''topic_id''' field.
[[File:HW04_table.PNG]]

In addition to that, we will be adding two additional boolean fields to the ''assignment'' schema: '''vary_by_round''' and '''vary_by_topic'''. As discussed earlier, in the previous implementation, these were methods that were called to determine if an assignment varied by round/topic rather than a persisted value.

[[File:E2026DatabaseFlow.png]]

Only a subset of the fields for each table is shown in the diagram because most of the fields are not relevant to these changes and would only serve to distract from the relevant changes. Additions are shown in bold.

==New Implementation==
While trying to integrate the previous team's implementation of this feature, we discovered that their method for querying AssignmentQuestionnaires (AQs) was flawed.

It would always query for the AQs by assignment id, current round number, and current topic id.

However, if the assignment did not have reviews that vary by round or topic, these values would be nil on the AQ, and the previous query would fail.

To fix this, we modified the ''assignment_questionnaire'' function in the AssignmentForm model to check the Assignment's ''vary_by_round'' and ''vary_by_topic'' flags, and then add the corresponding fields to the query.

This means that:
* If an assignment does not vary by round or by topic, the query for AQs will be by assignment id only.
* If the assignment varies by round but not topic, the query for AQs will be by assignment id and round number.

[[File:AQNewImpl.PNG]]

==Testing Plan==
As part of our implementation, we modified existing code as well as added new code. To ensure that existing functionality was not broken, and new functionality worked as expected, we used the following Test Strategy (which was also used by previous team):
===Run and pass existing RSpec Tests===
*The following existing RSpec test files have been modified and they pass as part of testing:
**spec/controllers/assignments_controller_spec.rb
**spec/controllers/questionnaires_controller_spec.rb
**spec/controllers/response_controller_spec.rb
**spec/factories/factories.rb
**spec/features/assignment_creation_spec.rb
**spec/features/quiz_spec.rb
**spec/features/staggered_deadline_spec.rb
**spec/models/assignment_form_spec.rb
**spec/models/assignment_spec.rb
**spec/models/on_the_fly_calc_spec.rb
**spec/models/response_spec.rb
**spec/models/review_response_map_spec.rb

===Develop New RSpec Tests===
*As part of previous implementation, the team had introduced the following new RSpec test files. We have retained those file.
**spec/helpers/assignment_helper_spec.rb
**spec/models/self_review_response_map_spec.rb
*All these rspec tests passed.

===Manual Testing in Expertiza UI===
Here we describe manual UI Testing steps to edit an existing assignment to allow it have to specialized rubrics for different topic types. These steps are also shown in recorded demo video.
*Login to Expertiza using instructor account (For testing, username: '''instructor6''', password: '''password''')
*Click on Manage > Assignments
*Click on Edit option for any assignment, you should get following view. Make sure '''Has topics?''' box is checked.
[[File:Assignment edit 3.png]]
*Click on Rubrics tab. You will see 2 checkboxes ('''Review rubric varies by round?''', '''Review rubric varies by topic?''')
*Check the box for '''Review rubric varies by topic?'''
*Go to Topics tab and verify that there is dropdown menu beside each Topic.
*Select a rubric from dropdown menu, and click '''Save'''
[[File:Topics rubric 2.png]]
*Go back to Home, and select the same assignment to edit. When you click on Topics tab, you should see the rubric you had selected.

===Coverage===
All rspec tests part of [https://travis-ci.org/github/expertiza/expertiza/builds/679301186 Travis CI build] has passed. The [https://coveralls.io/jobs/61850924 code coverage] has increased by 10.9% to 41.425%.

== Future Work==
After merging the previous team's work with expertiza, several RSpec tests failed.
*This was due to how questionnaires were retrieved/found for an assignment. Staggered deadlines also rely on finding questionnaires using topic id, which isn't handled until after an assignment is made.
*'''Resolved'''
However, undoing filtering results in even more errors across models, controllers, and forms. This feature, however is a quality of life improvement and is less of a priority.
* '''Unresolved'''
Another quality of life improvement is that staggered deadlines and topics cannot be added to an assignment until after the assignment has been created and saved.
* This issue exists on expertiza's beta branch itself, separate from our changes.
*'''Unresolved'''

==Team Information==
* Naman Shrimali
* Kanchan Rawat
* Subodh Thota
* Andrew Shipman
Mentor : Prof. Edward F. Gehringer

CSC/ECE 517 Fall 2021 - E2147. Role-based reviewing

2021-11-04T02:15:08Z

Kprawat:

==E2147. Role-based reviewing==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

----

Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

====Peer Review Information====

----

Login credentials for peer review.

* Instructor login:
** Username: instructor6
** Password: password

* Student login:
** Username: student4340
** Password: password

===Problem Statement===

----

In various agile methodologies, such as Scrum, different team members take on different roles, such as architect, facilitator, and implementer. One might want to use a different rubric for evaluating the contribution of members with different roles. Thus, this would not be separate from teammate review, but it would be a specialization of teammate review.

The following tasks were accomplished in this project:

* Created a new database table, model, view, and controller for duties.
* Allow assignments to be marked for role-based reviewing.
* Certain users can add and edit roles for assignments.

Due to naming issues all of the backend components for role-based reviewing are known as duty or duties. When referring to the backend this documentation will refer to them as duty or duties and when referring to frontend components they will be called role or roles.

===About Current Reviewing===

----

Currently reviewing does not allow students to have different rubrics for an assignment based on their role in the team.

===UML Diagram for the Solution Implemented===
[[File:E2147.png]]

===Solutions Implemented and Delivered===

----

''Below we have listed the solutions that we implemented, why we did certain design decisions, and explanations on how they were implemented.''

'''Created a new database table, model, view, and controller for duties.'''

----

''Database''

We created a new duty table using scaffolding. In the database, each duty entry has an assignment_id, a max_duty_limit, and a duty_name.

* The assignment_id is the id of the assignment to which this duty belongs to.
* The max_duty_limit field is an integer and is the maximum number of students who are allowed to have a specific duty (e.g. 1 scrum master but 5 developers are allowed).
* The duty_name is the name of the duty and will be displayed as Role name on the frontend.

''Model''

The model for duty is simple and simply marks a duty as belonging to assignment:

<pre>
class Duty < ActiveRecord::Base
belongs_to :assignment
end
</pre>

''Views''

There were quite a few new views added for the implementation, they will simply be mentioned in this section and then explained in the corresponding solution description.

The new views were:

* actions
* add_duties
* add_duty
* checkbox
* duty
* table_header
* table_line
* edit
* new

''Controller''

We created a new duties controller which allows for creation, editing, and deletion of duties from an assignment. The controller has a check to see if the current user is authorized to make the request.

'''Allow assignments to be marked for role-based reviewing.'''

----

Under the Review Strategy Tab of an assignment a checkbox was added that when clicked marks the assignment as role-based reviewing and displays an interface for adding, editing, and deleting roles.

In the Review Strategy Tab under the self review checkbox we added a render call to the checkbox view:

<pre>
<% if current_page?(action: 'edit') %>

<tr>
<td id='is_duty_based_assignment'>
<input name="assignment_form[assignment][is_duty_based_assignment]" type="hidden" value="false"/>
<%= check_box_tag('assignment_form[assignment][is_duty_based_assignment]', 'true', @assignment_form.assignment.is_duty_based_assignment, {:id => "is_duty_checkbox", :onChange => 'hasDutiesChanged()'}) %>
<%= label_tag('duty_assignment', 'Is Role-Based Reviewing?') %>
<img src="/assets/info.png" title='Check the box if this assignment allows role assignments within the team'>

<div id="add_duties" <%= "hidden" if not @assignment_form.assignment.is_duty_based_assignment %> >
<br>

<%= render '/duties/add_duties' %>
</div>
</td>
</tr>
<% end %>
</pre>

The checkbox view checks if the current page is being edited rather than created since duties rely on an assignment existing to link via id. This functionality is similar to how topics are added to the assignment.

If the checkbox is checked and saved the assignment will be marked as a role-based reviewing assignment via the database column is_duty_based_assignment in the assignment table. When the checkbox is checked the add_duties view is rendered and displayed as well. When unchecked the view is hidden and the is_duty_based_assignment is marked as false when saved.

[[File:Unchecked-Role-Based-Reviewing.png]]

If the assignment has no duties in the backend the add_duties view will display a note with the text "Roles have not yet been created.".

[[File:Checked-Role-Based-Reviewing-no-roles.png]]

If there are duties linked to the currently edited assignment then the view will render a table header from the table_header view and a line for each duty from the table_line view. At the end of this view, the add_duty partial view is rendered.

The table_header view displays a table header with three items. Role name, Maximum member limit, and Actions, each with respective widths of 45%, 45%, and 10%.

The table_line view crafts a table row based on the duty that was passed to it. The first column is the duty's duty_name with a link to the editing page for the duty if clicked. The next column is the duty's max_duty_limit, and the final column is a list of actions for the current duty which is rendered using the actions view.

[[File:Display-duties.png]]

The actions view displays two linked images, these are named "Edit Role" and "Delete Role", and are linked to their respective actions. The icons used for these actions are in line with other parts of expertiza for the actions that they represent.

The add_duty view is a link to the new view and is labelled "New role".

When clicked the user is directed to the new duty view:

[[File:New-Duty.png]]

Selecting back or create link back to the original assignment and upon successful creation there is a notification stating "Role was successfully created.".

[[File:Duty-creation-success.png]]

'''Certain users can add and edit roles for assignments.'''

----

Users with TA privileges are able to add a role (added as duty to backend for clarity) to an assignment.

An authorized user can select the edit role icon or the name of a duty on the Review Strategy tab and will be redirected to a form (duty view) that is auto populated by the edit view for the duty they are attempting to edit:

[[File:Edit-duty.png]]

After successfully updating the duty the user is redirected back to the assignment edit page and get a notification of the change:

[[File:Edit-duty-confirmation.png]]

An authorized user can also delete an existing duty, after deletion they will get another notification:

[[File:Duty-deletion-confirmation.png]]

===Testing===

----

====RSPEC====

----

Since duties_controller was a brand new file we created a new spec files "duties_controller_spec.rb" which covers creation, editing, and deletion of duties in the system. To run this file use the following command while in the top level of the expertiza directory:

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

====UI====

----

'''The following steps need to be performed to test this code from the UI:'''

1. Login as an instructor. Create a course and an assignment or navigate to an existing course with assignments.

2. Mark the assignment as a team assignment and navigate to the Review Strategy tab.

3. Check the Is Role-Based Reviewing checkbox and save the assignment.

4. Click New Role and fill out the information for creating a new duty.

5. Save and exit the assignment.

6. Login as a student and attempt to apply to the duty.

'''To test editing of a duty:'''

1. Login as an instructor. Create a course and an assignment or navigate to an existing course with assignments.

2. Mark the assignment as a team assignment and navigate to the Review Strategy tab.

3. Check the Is Role-Based Reviewing checkbox and save the assignment.

4. Click New Role and fill out the information for creating a new duty.

5. Click create and navigate to the Review Strategy tab again.

6. Click either the edit icon or the duty name listed under Role name.

7. Edit the duty, press Update and navigate to the Review Strategy tab again.

'''To test deleting of a duty:'''

1. Login as an instructor. Create a course and an assignment or navigate to an existing course with assignments.

2. Mark the assignment as a team assignment and navigate to the Review Strategy tab.

3. Check the Is Role-Based Reviewing checkbox and save the assignment.

4. Click New Role and fill out the information for creating a new duty.

5. Click create and navigate to the Review Strategy tab again.

6. Click either the delete icon.

===Scope for Future Improvement===

----

1. If a duty's maximum member limit is changed to be below the current number of students who are assigned to that duty nothing happens. We feel that a good future improvement would be to notify the students of the change and require them to select which students are dropped from the duty.

2. We believe that the checkbox for role-based reviewing can be moved to the general tab and only be displayed when the assignment is team based. This is due to dole-based reviewing being only available when an assignment is team based.

3. We believe that a possible future improvement would be to allow a user to import duties and their corresponding rubrics into other assignments.

===References===

----

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

CSC/ECE 517 Fall 2021 - E2147. Role-based reviewing

2021-11-04T02:14:32Z

Kprawat:

==E2147. Role-based reviewing==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

----

Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

====Peer Review Information====

----

Login credentials for peer review.

* Instructor login:
** Username: instructor6
** Password: password

* Student login:
** Username: student4340
** Password: password

===Problem Statement===

----

In various agile methodologies, such as Scrum, different team members take on different roles, such as architect, facilitator, and implementer. One might want to use a different rubric for evaluating the contribution of members with different roles. Thus, this would not be separate from teammate review, but it would be a specialization of teammate review.

The following tasks were accomplished in this project:

* Created a new database table, model, view, and controller for duties.
* Allow assignments to be marked for role-based reviewing.
* Certain users can add and edit roles for assignments.

Due to naming issues all of the backend components for role-based reviewing are known as duty or duties. When referring to the backend this documentation will refer to them as duty or duties and when referring to frontend components they will be called role or roles.

===About Current Reviewing===

----

Currently reviewing does not allow students to have different rubrics for an assignment based on their role in the team.

===UML Diagram for the Solution Implemented===
[[File:E2147.png]]
In a UML Class Diagram, The relationships depicted are as follows:

===Solutions Implemented and Delivered===

----

''Below we have listed the solutions that we implemented, why we did certain design decisions, and explanations on how they were implemented.''

'''Created a new database table, model, view, and controller for duties.'''

----

''Database''

We created a new duty table using scaffolding. In the database, each duty entry has an assignment_id, a max_duty_limit, and a duty_name.

* The assignment_id is the id of the assignment to which this duty belongs to.
* The max_duty_limit field is an integer and is the maximum number of students who are allowed to have a specific duty (e.g. 1 scrum master but 5 developers are allowed).
* The duty_name is the name of the duty and will be displayed as Role name on the frontend.

''Model''

The model for duty is simple and simply marks a duty as belonging to assignment:

<pre>
class Duty < ActiveRecord::Base
belongs_to :assignment
end
</pre>

''Views''

There were quite a few new views added for the implementation, they will simply be mentioned in this section and then explained in the corresponding solution description.

The new views were:

* actions
* add_duties
* add_duty
* checkbox
* duty
* table_header
* table_line
* edit
* new

''Controller''

We created a new duties controller which allows for creation, editing, and deletion of duties from an assignment. The controller has a check to see if the current user is authorized to make the request.

'''Allow assignments to be marked for role-based reviewing.'''

----

Under the Review Strategy Tab of an assignment a checkbox was added that when clicked marks the assignment as role-based reviewing and displays an interface for adding, editing, and deleting roles.

In the Review Strategy Tab under the self review checkbox we added a render call to the checkbox view:

<pre>
<% if current_page?(action: 'edit') %>

<tr>
<td id='is_duty_based_assignment'>
<input name="assignment_form[assignment][is_duty_based_assignment]" type="hidden" value="false"/>
<%= check_box_tag('assignment_form[assignment][is_duty_based_assignment]', 'true', @assignment_form.assignment.is_duty_based_assignment, {:id => "is_duty_checkbox", :onChange => 'hasDutiesChanged()'}) %>
<%= label_tag('duty_assignment', 'Is Role-Based Reviewing?') %>
<img src="/assets/info.png" title='Check the box if this assignment allows role assignments within the team'>

<div id="add_duties" <%= "hidden" if not @assignment_form.assignment.is_duty_based_assignment %> >
<br>

<%= render '/duties/add_duties' %>
</div>
</td>
</tr>
<% end %>
</pre>

The checkbox view checks if the current page is being edited rather than created since duties rely on an assignment existing to link via id. This functionality is similar to how topics are added to the assignment.

If the checkbox is checked and saved the assignment will be marked as a role-based reviewing assignment via the database column is_duty_based_assignment in the assignment table. When the checkbox is checked the add_duties view is rendered and displayed as well. When unchecked the view is hidden and the is_duty_based_assignment is marked as false when saved.

[[File:Unchecked-Role-Based-Reviewing.png]]

If the assignment has no duties in the backend the add_duties view will display a note with the text "Roles have not yet been created.".

[[File:Checked-Role-Based-Reviewing-no-roles.png]]

If there are duties linked to the currently edited assignment then the view will render a table header from the table_header view and a line for each duty from the table_line view. At the end of this view, the add_duty partial view is rendered.

The table_header view displays a table header with three items. Role name, Maximum member limit, and Actions, each with respective widths of 45%, 45%, and 10%.

The table_line view crafts a table row based on the duty that was passed to it. The first column is the duty's duty_name with a link to the editing page for the duty if clicked. The next column is the duty's max_duty_limit, and the final column is a list of actions for the current duty which is rendered using the actions view.

[[File:Display-duties.png]]

The actions view displays two linked images, these are named "Edit Role" and "Delete Role", and are linked to their respective actions. The icons used for these actions are in line with other parts of expertiza for the actions that they represent.

The add_duty view is a link to the new view and is labelled "New role".

When clicked the user is directed to the new duty view:

[[File:New-Duty.png]]

Selecting back or create link back to the original assignment and upon successful creation there is a notification stating "Role was successfully created.".

[[File:Duty-creation-success.png]]

'''Certain users can add and edit roles for assignments.'''

----

Users with TA privileges are able to add a role (added as duty to backend for clarity) to an assignment.

An authorized user can select the edit role icon or the name of a duty on the Review Strategy tab and will be redirected to a form (duty view) that is auto populated by the edit view for the duty they are attempting to edit:

[[File:Edit-duty.png]]

After successfully updating the duty the user is redirected back to the assignment edit page and get a notification of the change:

[[File:Edit-duty-confirmation.png]]

An authorized user can also delete an existing duty, after deletion they will get another notification:

[[File:Duty-deletion-confirmation.png]]

===Testing===

----

====RSPEC====

----

Since duties_controller was a brand new file we created a new spec files "duties_controller_spec.rb" which covers creation, editing, and deletion of duties in the system. To run this file use the following command while in the top level of the expertiza directory:

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

====UI====

----

'''The following steps need to be performed to test this code from the UI:'''

1. Login as an instructor. Create a course and an assignment or navigate to an existing course with assignments.

2. Mark the assignment as a team assignment and navigate to the Review Strategy tab.

3. Check the Is Role-Based Reviewing checkbox and save the assignment.

4. Click New Role and fill out the information for creating a new duty.

5. Save and exit the assignment.

6. Login as a student and attempt to apply to the duty.

'''To test editing of a duty:'''

1. Login as an instructor. Create a course and an assignment or navigate to an existing course with assignments.

2. Mark the assignment as a team assignment and navigate to the Review Strategy tab.

3. Check the Is Role-Based Reviewing checkbox and save the assignment.

4. Click New Role and fill out the information for creating a new duty.

5. Click create and navigate to the Review Strategy tab again.

6. Click either the edit icon or the duty name listed under Role name.

7. Edit the duty, press Update and navigate to the Review Strategy tab again.

'''To test deleting of a duty:'''

1. Login as an instructor. Create a course and an assignment or navigate to an existing course with assignments.

2. Mark the assignment as a team assignment and navigate to the Review Strategy tab.

3. Check the Is Role-Based Reviewing checkbox and save the assignment.

4. Click New Role and fill out the information for creating a new duty.

5. Click create and navigate to the Review Strategy tab again.

6. Click either the delete icon.

===Scope for Future Improvement===

----

1. If a duty's maximum member limit is changed to be below the current number of students who are assigned to that duty nothing happens. We feel that a good future improvement would be to notify the students of the change and require them to select which students are dropped from the duty.

2. We believe that the checkbox for role-based reviewing can be moved to the general tab and only be displayed when the assignment is team based. This is due to dole-based reviewing being only available when an assignment is team based.

3. We believe that a possible future improvement would be to allow a user to import duties and their corresponding rubrics into other assignments.

===References===

----

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

File:E2147.png

2021-11-04T02:11:24Z

Kprawat: Kprawat uploaded a new version of File:E2147.png

File:E2147.png

2021-11-04T02:09:53Z

Kprawat:

CSC/ECE 517 Fall 2021 - E2147. Role-based reviewing

2021-11-04T02:09:42Z

Kprawat: /* UML Diagram for the Solution Implemented */

CSC/ECE 517 Fall 2021 - E2147. Role-based reviewing

2021-11-04T01:52:47Z

Kprawat:

==E2147. Role-based reviewing==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

----

Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

====Peer Review Information====

----

Login credentials for peer review.

* Instructor login:
** Username: instructor6
** Password: password

* Student login:
** Username: student4340
** Password: password

===Problem Statement===

----

In various agile methodologies, such as Scrum, different team members take on different roles, such as architect, facilitator, and implementer. One might want to use a different rubric for evaluating the contribution of members with different roles. Thus, this would not be separate from teammate review, but it would be a specialization of teammate review.

The following tasks were accomplished in this project:

* Created a new database table, model, view, and controller for duties.
* Allow assignments to be marked for role-based reviewing.
* Certain users can add and edit roles for assignments.

Due to naming issues all of the backend components for role-based reviewing are known as duty or duties. When referring to the backend this documentation will refer to them as duty or duties and when referring to frontend components they will be called role or roles.

===About Current Reviewing===

----

Currently reviewing does not allow students to have different rubrics for an assignment based on their role in the team.

===UML Diagram for the Solution Implemented===
[[File:E2147.jpg]]

===Solutions Implemented and Delivered===

----

''Below we have listed the solutions that we implemented, why we did certain design decisions, and explanations on how they were implemented.''

'''Created a new database table, model, view, and controller for duties.'''

----

''Database''

We created a new duty table using scaffolding. In the database, each duty entry has an assignment_id, a max_duty_limit, and a duty_name.

* The assignment_id is the id of the assignment to which this duty belongs to.
* The max_duty_limit field is an integer and is the maximum number of students who are allowed to have a specific duty (e.g. 1 scrum master but 5 developers are allowed).
* The duty_name is the name of the duty and will be displayed as Role name on the frontend.

''Model''

The model for duty is simple and simply marks a duty as belonging to assignment:

<pre>
class Duty < ActiveRecord::Base
belongs_to :assignment
end
</pre>

''Views''

There were quite a few new views added for the implementation, they will simply be mentioned in this section and then explained in the corresponding solution description.

The new views were:

* actions
* add_duties
* add_duty
* checkbox
* duty
* table_header
* table_line
* edit
* new

''Controller''

We created a new duties controller which allows for creation, editing, and deletion of duties from an assignment. The controller has a check to see if the current user is authorized to make the request.

'''Allow assignments to be marked for role-based reviewing.'''

----

Under the Review Strategy Tab of an assignment a checkbox was added that when clicked marks the assignment as role-based reviewing and displays an interface for adding, editing, and deleting roles.

In the Review Strategy Tab under the self review checkbox we added a render call to the checkbox view:

<pre>
<% if current_page?(action: 'edit') %>

<tr>
<td id='is_duty_based_assignment'>
<input name="assignment_form[assignment][is_duty_based_assignment]" type="hidden" value="false"/>
<%= check_box_tag('assignment_form[assignment][is_duty_based_assignment]', 'true', @assignment_form.assignment.is_duty_based_assignment, {:id => "is_duty_checkbox", :onChange => 'hasDutiesChanged()'}) %>
<%= label_tag('duty_assignment', 'Is Role-Based Reviewing?') %>
<img src="/assets/info.png" title='Check the box if this assignment allows role assignments within the team'>

<div id="add_duties" <%= "hidden" if not @assignment_form.assignment.is_duty_based_assignment %> >
<br>

<%= render '/duties/add_duties' %>
</div>
</td>
</tr>
<% end %>
</pre>

The checkbox view checks if the current page is being edited rather than created since duties rely on an assignment existing to link via id. This functionality is similar to how topics are added to the assignment.

If the checkbox is checked and saved the assignment will be marked as a role-based reviewing assignment via the database column is_duty_based_assignment in the assignment table. When the checkbox is checked the add_duties view is rendered and displayed as well. When unchecked the view is hidden and the is_duty_based_assignment is marked as false when saved.

[[File:Unchecked-Role-Based-Reviewing.png]]

If the assignment has no duties in the backend the add_duties view will display a note with the text "Roles have not yet been created.".

[[File:Checked-Role-Based-Reviewing-no-roles.png]]

If there are duties linked to the currently edited assignment then the view will render a table header from the table_header view and a line for each duty from the table_line view. At the end of this view, the add_duty partial view is rendered.

The table_header view displays a table header with three items. Role name, Maximum member limit, and Actions, each with respective widths of 45%, 45%, and 10%.

The table_line view crafts a table row based on the duty that was passed to it. The first column is the duty's duty_name with a link to the editing page for the duty if clicked. The next column is the duty's max_duty_limit, and the final column is a list of actions for the current duty which is rendered using the actions view.

[[File:Display-duties.png]]

The actions view displays two linked images, these are named "Edit Role" and "Delete Role", and are linked to their respective actions. The icons used for these actions are in line with other parts of expertiza for the actions that they represent.

The add_duty view is a link to the new view and is labelled "New role".

When clicked the user is directed to the new duty view:

[[File:New-Duty.png]]

Selecting back or create link back to the original assignment and upon successful creation there is a notification stating "Role was successfully created.".

[[File:Duty-creation-success.png]]

'''Certain users can add and edit roles for assignments.'''

----

Users with TA privileges are able to add a role (added as duty to backend for clarity) to an assignment.

An authorized user can select the edit role icon or the name of a duty on the Review Strategy tab and will be redirected to a form (duty view) that is auto populated by the edit view for the duty they are attempting to edit:

[[File:Edit-duty.png]]

After successfully updating the duty the user is redirected back to the assignment edit page and get a notification of the change:

[[File:Edit-duty-confirmation.png]]

An authorized user can also delete an existing duty, after deletion they will get another notification:

[[File:Duty-deletion-confirmation.png]]

===Testing===

----

====RSPEC====

----

Since duties_controller was a brand new file we created a new spec files "duties_controller_spec.rb" which covers creation, editing, and deletion of duties in the system. To run this file use the following command while in the top level of the expertiza directory:

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

====UI====

----

'''The following steps need to be performed to test this code from the UI:'''

1. Login as an instructor. Create a course and an assignment or navigate to an existing course with assignments.

2. Mark the assignment as a team assignment and navigate to the Review Strategy tab.

3. Check the Is Role-Based Reviewing checkbox and save the assignment.

4. Click New Role and fill out the information for creating a new duty.

5. Save and exit the assignment.

6. Login as a student and attempt to apply to the duty.

'''To test editing of a duty:'''

1. Login as an instructor. Create a course and an assignment or navigate to an existing course with assignments.

2. Mark the assignment as a team assignment and navigate to the Review Strategy tab.

3. Check the Is Role-Based Reviewing checkbox and save the assignment.

4. Click New Role and fill out the information for creating a new duty.

5. Click create and navigate to the Review Strategy tab again.

6. Click either the edit icon or the duty name listed under Role name.

7. Edit the duty, press Update and navigate to the Review Strategy tab again.

'''To test deleting of a duty:'''

1. Login as an instructor. Create a course and an assignment or navigate to an existing course with assignments.

2. Mark the assignment as a team assignment and navigate to the Review Strategy tab.

3. Check the Is Role-Based Reviewing checkbox and save the assignment.

4. Click New Role and fill out the information for creating a new duty.

5. Click create and navigate to the Review Strategy tab again.

6. Click either the delete icon.

===Scope for Future Improvement===

----

1. If a duty's maximum member limit is changed to be below the current number of students who are assigned to that duty nothing happens. We feel that a good future improvement would be to notify the students of the change and require them to select which students are dropped from the duty.

2. We believe that the checkbox for role-based reviewing can be moved to the general tab and only be displayed when the assignment is team based. This is due to dole-based reviewing being only available when an assignment is team based.

3. We believe that a possible future improvement would be to allow a user to import duties and their corresponding rubrics into other assignments.

===References===

----

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

CSC/ECE 517 Fall 2021 - E2147. Role-based reviewing

2021-11-04T01:49:45Z

Kprawat:

==E2147. Role-based reviewing==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

----

Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

====Peer Review Information====

----

Login credentials for peer review.

* Instructor login:
** Username: instructor6
** Password: password

* Student login:
** Username: student4340
** Password: password

===Problem Statement===

----

In various agile methodologies, such as Scrum, different team members take on different roles, such as architect, facilitator, and implementer. One might want to use a different rubric for evaluating the contribution of members with different roles. Thus, this would not be separate from teammate review, but it would be a specialization of teammate review.

The following tasks were accomplished in this project:

* Created a new database table, model, view, and controller for duties.
* Allow assignments to be marked for role-based reviewing.
* Certain users can add and edit roles for assignments.

Due to naming issues all of the backend components for role-based reviewing are known as duty or duties. When referring to the backend this documentation will refer to them as duty or duties and when referring to frontend components they will be called role or roles.

===About Current Reviewing===

----

Currently reviewing does not allow students to have different rubrics for an assignment based on their role in the team.

===UML Diagram for the Solution Implemented===

===Solutions Implemented and Delivered===

----

''Below we have listed the solutions that we implemented, why we did certain design decisions, and explanations on how they were implemented.''

'''Created a new database table, model, view, and controller for duties.'''

----

''Database''

We created a new duty table using scaffolding. In the database, each duty entry has an assignment_id, a max_duty_limit, and a duty_name.

* The assignment_id is the id of the assignment to which this duty belongs to.
* The max_duty_limit field is an integer and is the maximum number of students who are allowed to have a specific duty (e.g. 1 scrum master but 5 developers are allowed).
* The duty_name is the name of the duty and will be displayed as Role name on the frontend.

''Model''

The model for duty is simple and simply marks a duty as belonging to assignment:

<pre>
class Duty < ActiveRecord::Base
belongs_to :assignment
end
</pre>

''Views''

There were quite a few new views added for the implementation, they will simply be mentioned in this section and then explained in the corresponding solution description.

The new views were:

* actions
* add_duties
* add_duty
* checkbox
* duty
* table_header
* table_line
* edit
* new

''Controller''

We created a new duties controller which allows for creation, editing, and deletion of duties from an assignment. The controller has a check to see if the current user is authorized to make the request.

'''Allow assignments to be marked for role-based reviewing.'''

----

Under the Review Strategy Tab of an assignment a checkbox was added that when clicked marks the assignment as role-based reviewing and displays an interface for adding, editing, and deleting roles.

In the Review Strategy Tab under the self review checkbox we added a render call to the checkbox view:

<pre>
<% if current_page?(action: 'edit') %>

<tr>
<td id='is_duty_based_assignment'>
<input name="assignment_form[assignment][is_duty_based_assignment]" type="hidden" value="false"/>
<%= check_box_tag('assignment_form[assignment][is_duty_based_assignment]', 'true', @assignment_form.assignment.is_duty_based_assignment, {:id => "is_duty_checkbox", :onChange => 'hasDutiesChanged()'}) %>
<%= label_tag('duty_assignment', 'Is Role-Based Reviewing?') %>
<img src="/assets/info.png" title='Check the box if this assignment allows role assignments within the team'>

<div id="add_duties" <%= "hidden" if not @assignment_form.assignment.is_duty_based_assignment %> >
<br>

<%= render '/duties/add_duties' %>
</div>
</td>
</tr>
<% end %>
</pre>

The checkbox view checks if the current page is being edited rather than created since duties rely on an assignment existing to link via id. This functionality is similar to how topics are added to the assignment.

If the checkbox is checked and saved the assignment will be marked as a role-based reviewing assignment via the database column is_duty_based_assignment in the assignment table. When the checkbox is checked the add_duties view is rendered and displayed as well. When unchecked the view is hidden and the is_duty_based_assignment is marked as false when saved.

[[File:Unchecked-Role-Based-Reviewing.png]]

If the assignment has no duties in the backend the add_duties view will display a note with the text "Roles have not yet been created.".

[[File:Checked-Role-Based-Reviewing-no-roles.png]]

If there are duties linked to the currently edited assignment then the view will render a table header from the table_header view and a line for each duty from the table_line view. At the end of this view, the add_duty partial view is rendered.

The table_header view displays a table header with three items. Role name, Maximum member limit, and Actions, each with respective widths of 45%, 45%, and 10%.

The table_line view crafts a table row based on the duty that was passed to it. The first column is the duty's duty_name with a link to the editing page for the duty if clicked. The next column is the duty's max_duty_limit, and the final column is a list of actions for the current duty which is rendered using the actions view.

[[File:Display-duties.png]]

The actions view displays two linked images, these are named "Edit Role" and "Delete Role", and are linked to their respective actions. The icons used for these actions are in line with other parts of expertiza for the actions that they represent.

The add_duty view is a link to the new view and is labelled "New role".

When clicked the user is directed to the new duty view:

[[File:New-Duty.png]]

Selecting back or create link back to the original assignment and upon successful creation there is a notification stating "Role was successfully created.".

[[File:Duty-creation-success.png]]

'''Certain users can add and edit roles for assignments.'''

----

Users with TA privileges are able to add a role (added as duty to backend for clarity) to an assignment.

An authorized user can select the edit role icon or the name of a duty on the Review Strategy tab and will be redirected to a form (duty view) that is auto populated by the edit view for the duty they are attempting to edit:

[[File:Edit-duty.png]]

After successfully updating the duty the user is redirected back to the assignment edit page and get a notification of the change:

[[File:Edit-duty-confirmation.png]]

An authorized user can also delete an existing duty, after deletion they will get another notification:

[[File:Duty-deletion-confirmation.png]]

===Testing===

----

====RSPEC====

----

Since duties_controller was a brand new file we created a new spec files "duties_controller_spec.rb" which covers creation, editing, and deletion of duties in the system. To run this file use the following command while in the top level of the expertiza directory:

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

====UI====

----

'''The following steps need to be performed to test this code from the UI:'''

1. Login as an instructor. Create a course and an assignment or navigate to an existing course with assignments.

2. Mark the assignment as a team assignment and navigate to the Review Strategy tab.

3. Check the Is Role-Based Reviewing checkbox and save the assignment.

4. Click New Role and fill out the information for creating a new duty.

5. Save and exit the assignment.

6. Login as a student and attempt to apply to the duty.

'''To test editing of a duty:'''

1. Login as an instructor. Create a course and an assignment or navigate to an existing course with assignments.

2. Mark the assignment as a team assignment and navigate to the Review Strategy tab.

3. Check the Is Role-Based Reviewing checkbox and save the assignment.

4. Click New Role and fill out the information for creating a new duty.

5. Click create and navigate to the Review Strategy tab again.

6. Click either the edit icon or the duty name listed under Role name.

7. Edit the duty, press Update and navigate to the Review Strategy tab again.

'''To test deleting of a duty:'''

1. Login as an instructor. Create a course and an assignment or navigate to an existing course with assignments.

2. Mark the assignment as a team assignment and navigate to the Review Strategy tab.

3. Check the Is Role-Based Reviewing checkbox and save the assignment.

4. Click New Role and fill out the information for creating a new duty.

5. Click create and navigate to the Review Strategy tab again.

6. Click either the delete icon.

===Scope for Future Improvement===

----

1. If a duty's maximum member limit is changed to be below the current number of students who are assigned to that duty nothing happens. We feel that a good future improvement would be to notify the students of the change and require them to select which students are dropped from the duty.

2. We believe that the checkbox for role-based reviewing can be moved to the general tab and only be displayed when the assignment is team based. This is due to dole-based reviewing being only available when an assignment is team based.

3. We believe that a possible future improvement would be to allow a user to import duties and their corresponding rubrics into other assignments.

===References===

----

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

CSC/ECE 517 Fall 2021 - E2147. Role-based reviewing

2021-11-04T01:48:36Z

Kprawat:

==E2147. Role-based reviewing==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

----

Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc). The Expertiza project is supported by the National Science Foundation.

====Peer Review Information====

----

Login credentials for peer review.

* Instructor login:
** Username: instructor6
** Password: password

* Student login:
** Username: student4340
** Password: password

===Problem Statement===

----

In various agile methodologies, such as Scrum, different team members take on different roles, such as architect, facilitator, and implementer. One might want to use a different rubric for evaluating the contribution of members with different roles. Thus, this would not be separate from teammate review, but it would be a specialization of teammate review.

The following tasks were accomplished in this project:

* Created a new database table, model, view, and controller for duties.
* Allow assignments to be marked for role-based reviewing.
* Certain users can add and edit roles for assignments.

Due to naming issues all of the backend components for role-based reviewing are known as duty or duties. When referring to the backend this documentation will refer to them as duty or duties and when referring to frontend components they will be called role or roles.

===About Current Reviewing===

----

Currently reviewing does not allow students to have different rubrics for an assignment based on their role in the team.

===UML Diagram for the solution implemented===

===Solutions Implemented and Delivered===

----

''Below we have listed the solutions that we implemented, why we did certain design decisions, and explanations on how they were implemented.''

'''Created a new database table, model, view, and controller for duties.'''

----

''Database''

We created a new duty table using scaffolding. In the database, each duty entry has an assignment_id, a max_duty_limit, and a duty_name.

* The assignment_id is the id of the assignment to which this duty belongs to.
* The max_duty_limit field is an integer and is the maximum number of students who are allowed to have a specific duty (e.g. 1 scrum master but 5 developers are allowed).
* The duty_name is the name of the duty and will be displayed as Role name on the frontend.

''Model''

The model for duty is simple and simply marks a duty as belonging to assignment:

<pre>
class Duty < ActiveRecord::Base
belongs_to :assignment
end
</pre>

''Views''

There were quite a few new views added for the implementation, they will simply be mentioned in this section and then explained in the corresponding solution description.

The new views were:

* actions
* add_duties
* add_duty
* checkbox
* duty
* table_header
* table_line
* edit
* new

''Controller''

We created a new duties controller which allows for creation, editing, and deletion of duties from an assignment. The controller has a check to see if the current user is authorized to make the request.

'''Allow assignments to be marked for role-based reviewing.'''

----

Under the Review Strategy Tab of an assignment a checkbox was added that when clicked marks the assignment as role-based reviewing and displays an interface for adding, editing, and deleting roles.

In the Review Strategy Tab under the self review checkbox we added a render call to the checkbox view:

<pre>
<% if current_page?(action: 'edit') %>

<tr>
<td id='is_duty_based_assignment'>
<input name="assignment_form[assignment][is_duty_based_assignment]" type="hidden" value="false"/>
<%= check_box_tag('assignment_form[assignment][is_duty_based_assignment]', 'true', @assignment_form.assignment.is_duty_based_assignment, {:id => "is_duty_checkbox", :onChange => 'hasDutiesChanged()'}) %>
<%= label_tag('duty_assignment', 'Is Role-Based Reviewing?') %>
<img src="/assets/info.png" title='Check the box if this assignment allows role assignments within the team'>

<div id="add_duties" <%= "hidden" if not @assignment_form.assignment.is_duty_based_assignment %> >
<br>

<%= render '/duties/add_duties' %>
</div>
</td>
</tr>
<% end %>
</pre>

The checkbox view checks if the current page is being edited rather than created since duties rely on an assignment existing to link via id. This functionality is similar to how topics are added to the assignment.

If the checkbox is checked and saved the assignment will be marked as a role-based reviewing assignment via the database column is_duty_based_assignment in the assignment table. When the checkbox is checked the add_duties view is rendered and displayed as well. When unchecked the view is hidden and the is_duty_based_assignment is marked as false when saved.

[[File:Unchecked-Role-Based-Reviewing.png]]

If the assignment has no duties in the backend the add_duties view will display a note with the text "Roles have not yet been created.".

[[File:Checked-Role-Based-Reviewing-no-roles.png]]

If there are duties linked to the currently edited assignment then the view will render a table header from the table_header view and a line for each duty from the table_line view. At the end of this view, the add_duty partial view is rendered.

The table_header view displays a table header with three items. Role name, Maximum member limit, and Actions, each with respective widths of 45%, 45%, and 10%.

The table_line view crafts a table row based on the duty that was passed to it. The first column is the duty's duty_name with a link to the editing page for the duty if clicked. The next column is the duty's max_duty_limit, and the final column is a list of actions for the current duty which is rendered using the actions view.

[[File:Display-duties.png]]

The actions view displays two linked images, these are named "Edit Role" and "Delete Role", and are linked to their respective actions. The icons used for these actions are in line with other parts of expertiza for the actions that they represent.

The add_duty view is a link to the new view and is labelled "New role".

When clicked the user is directed to the new duty view:

[[File:New-Duty.png]]

Selecting back or create link back to the original assignment and upon successful creation there is a notification stating "Role was successfully created.".

[[File:Duty-creation-success.png]]

'''Certain users can add and edit roles for assignments.'''

----

Users with TA privileges are able to add a role (added as duty to backend for clarity) to an assignment.

An authorized user can select the edit role icon or the name of a duty on the Review Strategy tab and will be redirected to a form (duty view) that is auto populated by the edit view for the duty they are attempting to edit:

[[File:Edit-duty.png]]

After successfully updating the duty the user is redirected back to the assignment edit page and get a notification of the change:

[[File:Edit-duty-confirmation.png]]

An authorized user can also delete an existing duty, after deletion they will get another notification:

[[File:Duty-deletion-confirmation.png]]

===Testing===

----

====RSPEC====

----

Since duties_controller was a brand new file we created a new spec files "duties_controller_spec.rb" which covers creation, editing, and deletion of duties in the system. To run this file use the following command while in the top level of the expertiza directory:

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

====UI====

----

'''The following steps need to be performed to test this code from the UI:'''

1. Login as an instructor. Create a course and an assignment or navigate to an existing course with assignments.

2. Mark the assignment as a team assignment and navigate to the Review Strategy tab.

3. Check the Is Role-Based Reviewing checkbox and save the assignment.

4. Click New Role and fill out the information for creating a new duty.

5. Save and exit the assignment.

6. Login as a student and attempt to apply to the duty.

'''To test editing of a duty:'''

1. Login as an instructor. Create a course and an assignment or navigate to an existing course with assignments.

2. Mark the assignment as a team assignment and navigate to the Review Strategy tab.

3. Check the Is Role-Based Reviewing checkbox and save the assignment.

4. Click New Role and fill out the information for creating a new duty.

5. Click create and navigate to the Review Strategy tab again.

6. Click either the edit icon or the duty name listed under Role name.

7. Edit the duty, press Update and navigate to the Review Strategy tab again.

'''To test deleting of a duty:'''

1. Login as an instructor. Create a course and an assignment or navigate to an existing course with assignments.

2. Mark the assignment as a team assignment and navigate to the Review Strategy tab.

3. Check the Is Role-Based Reviewing checkbox and save the assignment.

4. Click New Role and fill out the information for creating a new duty.

5. Click create and navigate to the Review Strategy tab again.

6. Click either the delete icon.

===Scope for Future Improvement===

----

1. If a duty's maximum member limit is changed to be below the current number of students who are assigned to that duty nothing happens. We feel that a good future improvement would be to notify the students of the change and require them to select which students are dropped from the duty.

2. We believe that the checkbox for role-based reviewing can be moved to the general tab and only be displayed when the assignment is team based. This is due to dole-based reviewing being only available when an assignment is team based.

3. We believe that a possible future improvement would be to allow a user to import duties and their corresponding rubrics into other assignments.

===References===

----

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