Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

2019-12-07T04:27:02Z

Smyoder: /* Rspec */

== Introduction - Purpose & Problem ==
Currently, reviews of other student’s work can only be performed by individual students in Expertiza, not by groups of students. Since doing reviews together could help students learn more than by doing them alone, it has been requested that reviews must now have the option to be done by teams instead of individual participants. Therefore, there should be an option when creating assignments that allows the creator to select whether the assignment will use team reviewers or individual reviewers. For simplification, we were allowed to assume that the teams that worked on an assignment together would review together. Each participant should be able to make individual changes to the review (while logged in from their account), but these changes should apply to the team’s collective review. This creates an issue where teammates could accidentally overwrite each other’s work if they edit the review at once. Therefore, it has been decided that the review should be locked while one edits it so that only one participant can edit it at once. Locking the review presents its own challenges.

== Proposed Solution ==
* Modification to Response Map Classes
** A field should be added to ResponseMap which indicates whether responses are done by teams or by individuals.
* Modification to Assignment Class
** A field indicating if the assignment is to be done with team or individuals. This is necessary because part of the suggested requirements is to add a drop down on the review strategy section of the assignment.
* Locking Solution
** Research needs to be done as to whether a rails mechanism already exists to facilitate a lock on page edits
** A solution can be implemented from scratch by storing a flag in the database on the review’s table entry. This would require an additional migration.
**The ability to have a lock on a review requires the implementation of some kind of auto-unlock feature. If a user never unlocks a review, his/her teammates still need to be able to modify the review.
*** We should be able to use the “updated at” field to check if the lock has been held for too long and needs to be released.

== More on Locks ==
The locking solution we added works as a general locking solution. It adds a new table in the database called locks which create a mapping between a user and a resource. This database change does not force a lock on the resource. Just because there exists a lock between some resource and some user, does not mean that other users cannot edit that resource. The actual prevention of edits, be it redirecting or preventing access to controller methods, is the responsibility of you, the programmer. This class just provides an easy interface to facilitate that behavior.

=== Database Changes ===
Locks created the following changes:
* locks
** timeout_period
** created_at
** updated_at
** user_id
** lockable_id
** lockable_type

=== Code Changes ===
[[File:E1973_lock_uml.png]]

=== How to implement ===
Whichever model needs to be able to be locked must include this line:
include Lockable
See app/models/response.rb

To check to see if a resource is locked, use
resource = Lock.get_lock(resource, user, timeout_period)
If the resource is nil, it has been locked. If it's not nil, the given user owns the lock over the current resource.
See app/controllers/response_controller.rb#edit

To unlock a resource after it is done being used, use
Lock.release_lock(resource)
See app/controllers/lock_controller.rb#release_lock

To check to see if a lock exists between a user and a resource, use
Lock.lock_between?(resource, user)
See app/controllers/response_controller.rb#update
Because locks can time out, if user1 makes changes and stalls on a page, user2 could get the lock, make edits, and release it. If that's the case, we may not want to keep user1's changes. The way to check for that scenario is by seeing if the user still has a lock on this object.

=== About lock timeouts ===
Lock.get_lock takes a timeout_period. Timeout_period minutes after a user gets a lock, any user who calls get_lock on a resource will acquire a lock.

As the code stands, you MUST include a timeout period if you wish to get a lock. The rationale being that permanently preventing access to a resource is a heavy price for forgetting to unlock a resource. If you wish to do away with this feature, you will need to add the code yourself. (Perhaps using -1 for no time limit). Though I would heavily recommend using the timeout feature.

== Changes to Code ==
* review_response_map.rb (migration required)
** Field - reviewer_is_team: boolean
def after_initialize
# If an assignment supports team reviews, it is marked in each mapping
reviewer_is_team = assignment.reviewer_is_team
end
* assignment.rb (migration required)
** Field - has_team_reviews: boolean
* assignments/edit/_review_strategy.html.erb - added check box for has_team_reviews
<tr>
<td id='reviewer_is_team'>
<input name="assignment_form[assignment][reviewer_is_team]" type="hidden" value="false"/>
<%= check_box_tag('assignment_form[assignment][reviewer_is_team]', 'true', @assignment_form.assignment.reviewer_is_team) %>
<%= label_tag('assignment_form[assignment][reviewer_is_team]', 'Is Review done by Teams?') %>
<img src="/assets/info.png" title='You can select whether the reviews should be done by individual students or teams'>
</td>
</tr>
* assignment_participant.rb
** Method - get_reviewer
*** Returns the participant's team if the reviews for the assignment are done by teams.
*** Several lines of code treated reviewers explicitly as participants. In order to avoid changing too much functionality, and to go with Dr. Gehringer's request that the changes be polymorphic, we just inserted this method whenever the code treated a participant as a reviewer.
*** Example (review_mapping_controller.rb):
*** Reviewer used to be retrieved by the call to AssignmentParticipant.where. Now, reviewer and participant are treated seperately.
def assign_reviewer_dynamically
assignment = Assignment.find(params[:assignment_id])
participant = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
reviewer = participant.get_reviewer
...
* Added lock.rb, lock_controller.rb, and lockable.rb
* app/views/responses/response.html.erb
** Javascript was added to get locks to be released when the page is exited:
function release_lock() {
$.post("../../../lock/release_lock?id=<%= @response.id %>,&type=Response");
}
window.onbeforeunload = release_lock;

== Changes Represented in UML ==
[[File:E1973_Uml_1.png]]

== UI Changes ==
=== Assignment Review Strategy ===
==== Before ====
[[File:E1973_Editing_before.png]]

==== After ====
[[File:E1973_Editing_after.png]]

=== Assign Reviewers ===
==== Before ====
[[File:E1973_Participants_before.png]]

==== After ====
[[File:E1973_Participants_after.png]]

== Test Plan ==
=== Rspec ===
* Tests were added in response_controller_spec.rb to test that the controller methods properly handle locks and redirect when responses are locked:
it 'Does not allow a user to update a response if a lock exists on the response' do
allow(ResponseMap).to receive(:find).with(2).and_return(team_response_map)
allow(Lock).to receive(:get_lock).and_return(nil)
params = {
id: 2,
review: {
comments: 'some comments'
},
responses: {
'0' => {score: 98, comment: 'LGTM'}
},
isSubmit: 'No'
}
session = {user: instructor}
post :update, params, session
expect(response).not_to redirect_to('/response/save?id=1&msg=&review%5Bcomments%5D=some+comments')
end
* Tests were created for lock.rb to ensure that all database functionality is handled properly, locks time out, and locks correctly handle requests from multiple users:
it 'Should create new locks when a user requests them' do
# smyoder should have a lock on the response for 10 minutes
expect(Lock.get_lock(@response, @smyoder, 10)).to eq(@response)
firstLock = Lock.find_by(user: @smyoder, lockable: @response)
expect(firstLock).not_to be_nil
# A user with a lock on a resource should be able to renew the lock
expect(Lock.get_lock(@response, @smyoder, 8)).to eq(@response)
secondLock = Lock.find_by(user: @smyoder, lockable: @response)
expect(secondLock).not_to eq(firstLock)
end

* Since many of expertiza's tests use mocks, several lines in other tests needed to be added since previously un-called methods were now being called:
** Example from review_response_map_spec.rb
allow(participant1).to receive(:get_reviewer).and_return(participant1)

=== UI Testing ===

Our UI tests aim to capture the following core pieces of functionality: 

'''Students on the same team can view/edit the same response: '''

''Prerequisites: we use our fixture to ensure that an assignment has been created, and that students 9 and 10 are on a team together. ''

# Login as student10.
# Navigate to assignments, and click on an assignment.
# Request a new submission to review.
# In the review, leave the comment "Excellent work done!" and click save.
# Logout and login as student 9. Repeat step 2.
# Click View. Notice that the review already says "Excellent work done!".
# Go back to the review and click Edit. Change the message to "Decent work here".
# Logout and login as student 10. Repeat step 2.
# Click View. Notice that the review now says "Decent work here".

This test was implemented in the file 'teams_as_reviewers_spec.rb':
[[File:Team_mates_spec.png]]

=== Manual Testing ===
'''Students cannot edit the response at the same time: '''
''Prerequisites: Same as the above test.''
# Repeat steps 1-4 (inclusive) from the above UI test. However, remain on the edit page. 
# Open another browser and navigate to Expertiza. Then, login as student9 in another browser. 
# Navigate to the assignment and click "Edit". Verify that you are redirected and unable to edit the review response since student10 is already editing it. 

We leave a manual testing section here to cover a scenario we previously planned to add to our feature tests, but realized to be unfeasible. We have functionality that checks that 2 users on the same team cannot edit a response at the same time. However, Expertiza only uses one browser while testing currently. Setting up 2 of them to run at once was deemed beyond the scope of this project.

CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

2019-12-07T04:19:28Z

Smyoder: /* Changes to Code */

== Introduction - Purpose & Problem ==
Currently, reviews of other student’s work can only be performed by individual students in Expertiza, not by groups of students. Since doing reviews together could help students learn more than by doing them alone, it has been requested that reviews must now have the option to be done by teams instead of individual participants. Therefore, there should be an option when creating assignments that allows the creator to select whether the assignment will use team reviewers or individual reviewers. For simplification, we were allowed to assume that the teams that worked on an assignment together would review together. Each participant should be able to make individual changes to the review (while logged in from their account), but these changes should apply to the team’s collective review. This creates an issue where teammates could accidentally overwrite each other’s work if they edit the review at once. Therefore, it has been decided that the review should be locked while one edits it so that only one participant can edit it at once. Locking the review presents its own challenges.

== Proposed Solution ==
* Modification to Response Map Classes
** A field should be added to ResponseMap which indicates whether responses are done by teams or by individuals.
* Modification to Assignment Class
** A field indicating if the assignment is to be done with team or individuals. This is necessary because part of the suggested requirements is to add a drop down on the review strategy section of the assignment.
* Locking Solution
** Research needs to be done as to whether a rails mechanism already exists to facilitate a lock on page edits
** A solution can be implemented from scratch by storing a flag in the database on the review’s table entry. This would require an additional migration.
**The ability to have a lock on a review requires the implementation of some kind of auto-unlock feature. If a user never unlocks a review, his/her teammates still need to be able to modify the review.
*** We should be able to use the “updated at” field to check if the lock has been held for too long and needs to be released.

== More on Locks ==
The locking solution we added works as a general locking solution. It adds a new table in the database called locks which create a mapping between a user and a resource. This database change does not force a lock on the resource. Just because there exists a lock between some resource and some user, does not mean that other users cannot edit that resource. The actual prevention of edits, be it redirecting or preventing access to controller methods, is the responsibility of you, the programmer. This class just provides an easy interface to facilitate that behavior.

=== Database Changes ===
Locks created the following changes:
* locks
** timeout_period
** created_at
** updated_at
** user_id
** lockable_id
** lockable_type

=== Code Changes ===
[[File:E1973_lock_uml.png]]

=== How to implement ===
Whichever model needs to be able to be locked must include this line:
include Lockable
See app/models/response.rb

To check to see if a resource is locked, use
resource = Lock.get_lock(resource, user, timeout_period)
If the resource is nil, it has been locked. If it's not nil, the given user owns the lock over the current resource.
See app/controllers/response_controller.rb#edit

To unlock a resource after it is done being used, use
Lock.release_lock(resource)
See app/controllers/lock_controller.rb#release_lock

To check to see if a lock exists between a user and a resource, use
Lock.lock_between?(resource, user)
See app/controllers/response_controller.rb#update
Because locks can time out, if user1 makes changes and stalls on a page, user2 could get the lock, make edits, and release it. If that's the case, we may not want to keep user1's changes. The way to check for that scenario is by seeing if the user still has a lock on this object.

=== About lock timeouts ===
Lock.get_lock takes a timeout_period. Timeout_period minutes after a user gets a lock, any user who calls get_lock on a resource will acquire a lock.

As the code stands, you MUST include a timeout period if you wish to get a lock. The rationale being that permanently preventing access to a resource is a heavy price for forgetting to unlock a resource. If you wish to do away with this feature, you will need to add the code yourself. (Perhaps using -1 for no time limit). Though I would heavily recommend using the timeout feature.

== Changes to Code ==
* review_response_map.rb (migration required)
** Field - reviewer_is_team: boolean
def after_initialize
# If an assignment supports team reviews, it is marked in each mapping
reviewer_is_team = assignment.reviewer_is_team
end
* assignment.rb (migration required)
** Field - has_team_reviews: boolean
* assignments/edit/_review_strategy.html.erb - added check box for has_team_reviews
<tr>
<td id='reviewer_is_team'>
<input name="assignment_form[assignment][reviewer_is_team]" type="hidden" value="false"/>
<%= check_box_tag('assignment_form[assignment][reviewer_is_team]', 'true', @assignment_form.assignment.reviewer_is_team) %>
<%= label_tag('assignment_form[assignment][reviewer_is_team]', 'Is Review done by Teams?') %>
<img src="/assets/info.png" title='You can select whether the reviews should be done by individual students or teams'>
</td>
</tr>
* assignment_participant.rb
** Method - get_reviewer
*** Returns the participant's team if the reviews for the assignment are done by teams.
*** Several lines of code treated reviewers explicitly as participants. In order to avoid changing too much functionality, and to go with Dr. Gehringer's request that the changes be polymorphic, we just inserted this method whenever the code treated a participant as a reviewer.
*** Example (review_mapping_controller.rb):
*** Reviewer used to be retrieved by the call to AssignmentParticipant.where. Now, reviewer and participant are treated seperately.
def assign_reviewer_dynamically
assignment = Assignment.find(params[:assignment_id])
participant = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
reviewer = participant.get_reviewer
...
* Added lock.rb, lock_controller.rb, and lockable.rb
* app/views/responses/response.html.erb
** Javascript was added to get locks to be released when the page is exited:
function release_lock() {
$.post("../../../lock/release_lock?id=<%= @response.id %>,&type=Response");
}
window.onbeforeunload = release_lock;

== Changes Represented in UML ==
[[File:E1973_Uml_1.png]]

== UI Changes ==
=== Assignment Review Strategy ===
==== Before ====
[[File:E1973_Editing_before.png]]

==== After ====
[[File:E1973_Editing_after.png]]

=== Assign Reviewers ===
==== Before ====
[[File:E1973_Participants_before.png]]

==== After ====
[[File:E1973_Participants_after.png]]

== Test Plan ==
=== Rspec ===
Our primary purpose for rspec testing will involve ensuring that we haven't broken any existing functionality.
Since our new functionality doesn't involve any model/view/controller additions, our tests will be appended to existing rspec tests inside of:

* assignments_controller_spec.rb
* response_controller_spec.rb
* review_mapping_controller_spec.rb

The new functionality we need to test should primarily ensure that:

* Students on the same team can see each other's review responses
* No two students can edit a review at the same time
* Reviews submitted by teams are treated identically to reviews submitted by individuals

=== UI Testing ===

Our UI tests aim to capture the following core pieces of functionality: 

'''Students on the same team can view/edit the same response: '''

''Prerequisites: we use our fixture to ensure that an assignment has been created, and that students 9 and 10 are on a team together. ''

# Login as student10.
# Navigate to assignments, and click on an assignment.
# Request a new submission to review.
# In the review, leave the comment "Excellent work done!" and click save.
# Logout and login as student 9. Repeat step 2.
# Click View. Notice that the review already says "Excellent work done!".
# Go back to the review and click Edit. Change the message to "Decent work here".
# Logout and login as student 10. Repeat step 2.
# Click View. Notice that the review now says "Decent work here".

=== Manual Testing ===
'''Students cannot edit the response at the same time: '''
''Prerequisites: Same as the above test.''
# Repeat steps 1-4 (inclusive) from the above UI test. However, remain on the edit page. 
# Open another browser and navigate to Expertiza. Then, login as student9 in another browser. 
# Navigate to the assignment and click "Edit". Verify that you are redirected and unable to edit the review response since student10 is already editing it. 

We leave a manual testing section here to cover a scenario we previously planned to add to our feature tests, but realized to be unfeasible. We have functionality that checks that 2 users on the same team cannot edit a response at the same time. However, Expertiza only uses one browser while testing currently. Setting up 2 of them to run at once was deemed beyond the scope of this project.

CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

2019-12-07T04:18:05Z

Smyoder: /* Changes to Code */

== Introduction - Purpose & Problem ==
Currently, reviews of other student’s work can only be performed by individual students in Expertiza, not by groups of students. Since doing reviews together could help students learn more than by doing them alone, it has been requested that reviews must now have the option to be done by teams instead of individual participants. Therefore, there should be an option when creating assignments that allows the creator to select whether the assignment will use team reviewers or individual reviewers. For simplification, we were allowed to assume that the teams that worked on an assignment together would review together. Each participant should be able to make individual changes to the review (while logged in from their account), but these changes should apply to the team’s collective review. This creates an issue where teammates could accidentally overwrite each other’s work if they edit the review at once. Therefore, it has been decided that the review should be locked while one edits it so that only one participant can edit it at once. Locking the review presents its own challenges.

== Proposed Solution ==
* Modification to Response Map Classes
** A field should be added to ResponseMap which indicates whether responses are done by teams or by individuals.
* Modification to Assignment Class
** A field indicating if the assignment is to be done with team or individuals. This is necessary because part of the suggested requirements is to add a drop down on the review strategy section of the assignment.
* Locking Solution
** Research needs to be done as to whether a rails mechanism already exists to facilitate a lock on page edits
** A solution can be implemented from scratch by storing a flag in the database on the review’s table entry. This would require an additional migration.
**The ability to have a lock on a review requires the implementation of some kind of auto-unlock feature. If a user never unlocks a review, his/her teammates still need to be able to modify the review.
*** We should be able to use the “updated at” field to check if the lock has been held for too long and needs to be released.

== More on Locks ==
The locking solution we added works as a general locking solution. It adds a new table in the database called locks which create a mapping between a user and a resource. This database change does not force a lock on the resource. Just because there exists a lock between some resource and some user, does not mean that other users cannot edit that resource. The actual prevention of edits, be it redirecting or preventing access to controller methods, is the responsibility of you, the programmer. This class just provides an easy interface to facilitate that behavior.

=== Database Changes ===
Locks created the following changes:
* locks
** timeout_period
** created_at
** updated_at
** user_id
** lockable_id
** lockable_type

=== Code Changes ===
[[File:E1973_lock_uml.png]]

=== How to implement ===
Whichever model needs to be able to be locked must include this line:
include Lockable
See app/models/response.rb

To check to see if a resource is locked, use
resource = Lock.get_lock(resource, user, timeout_period)
If the resource is nil, it has been locked. If it's not nil, the given user owns the lock over the current resource.
See app/controllers/response_controller.rb#edit

To unlock a resource after it is done being used, use
Lock.release_lock(resource)
See app/controllers/lock_controller.rb#release_lock

To check to see if a lock exists between a user and a resource, use
Lock.lock_between?(resource, user)
See app/controllers/response_controller.rb#update
Because locks can time out, if user1 makes changes and stalls on a page, user2 could get the lock, make edits, and release it. If that's the case, we may not want to keep user1's changes. The way to check for that scenario is by seeing if the user still has a lock on this object.

=== About lock timeouts ===
Lock.get_lock takes a timeout_period. Timeout_period minutes after a user gets a lock, any user who calls get_lock on a resource will acquire a lock.

As the code stands, you MUST include a timeout period if you wish to get a lock. The rationale being that permanently preventing access to a resource is a heavy price for forgetting to unlock a resource. If you wish to do away with this feature, you will need to add the code yourself. (Perhaps using -1 for no time limit). Though I would heavily recommend using the timeout feature.

== Changes to Code ==
* review_response_map.rb (migration required)
** Field - reviewer_is_team: boolean
def after_initialize
# If an assignment supports team reviews, it is marked in each mapping
reviewer_is_team = assignment.reviewer_is_team
end
* assignment.rb (migration required)
** Field - has_team_reviews: boolean
* assignments/edit/_review_strategy.html.erb - added check box for has_team_reviews
<tr>
<td id='reviewer_is_team'>
<input name="assignment_form[assignment][reviewer_is_team]" type="hidden" value="false"/>
<%= check_box_tag('assignment_form[assignment][reviewer_is_team]', 'true', @assignment_form.assignment.reviewer_is_team) %>
<%= label_tag('assignment_form[assignment][reviewer_is_team]', 'Is Review done by Teams?') %>
<img src="/assets/info.png" title='You can select whether the reviews should be done by individual students or teams'>
</td>
</tr>
* assignment_participant.rb
** Method - get_reviewer
*** Returns the participant's team if the reviews for the assignment are done by teams.
*** Several lines of code treated reviewers explicitly as participants. In order to avoid changing too much functionality, and to go with Dr. Gehringer's request that the changes be polymorphic, we just inserted this method whenever the code treated a participant as a reviewer.
*** Example (review_mapping_controller.rb):
*** Reviewer used to be retrieved by the call to AssignmentParticipant.where. Now, reviewer and participant are treated seperately.
def assign_reviewer_dynamically
assignment = Assignment.find(params[:assignment_id])
participant = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
reviewer = participant.get_reviewer
...
* Added lock.rb, lock_controller.rb, and lockable.rb

== Changes Represented in UML ==
[[File:E1973_Uml_1.png]]

== UI Changes ==
=== Assignment Review Strategy ===
==== Before ====
[[File:E1973_Editing_before.png]]

==== After ====
[[File:E1973_Editing_after.png]]

=== Assign Reviewers ===
==== Before ====
[[File:E1973_Participants_before.png]]

==== After ====
[[File:E1973_Participants_after.png]]

== Test Plan ==
=== Rspec ===
Our primary purpose for rspec testing will involve ensuring that we haven't broken any existing functionality.
Since our new functionality doesn't involve any model/view/controller additions, our tests will be appended to existing rspec tests inside of:

* assignments_controller_spec.rb
* response_controller_spec.rb
* review_mapping_controller_spec.rb

The new functionality we need to test should primarily ensure that:

* Students on the same team can see each other's review responses
* No two students can edit a review at the same time
* Reviews submitted by teams are treated identically to reviews submitted by individuals

=== UI Testing ===

Our UI tests aim to capture the following core pieces of functionality: 

'''Students on the same team can view/edit the same response: '''

''Prerequisites: we use our fixture to ensure that an assignment has been created, and that students 9 and 10 are on a team together. ''

# Login as student10.
# Navigate to assignments, and click on an assignment.
# Request a new submission to review.
# In the review, leave the comment "Excellent work done!" and click save.
# Logout and login as student 9. Repeat step 2.
# Click View. Notice that the review already says "Excellent work done!".
# Go back to the review and click Edit. Change the message to "Decent work here".
# Logout and login as student 10. Repeat step 2.
# Click View. Notice that the review now says "Decent work here".

=== Manual Testing ===
'''Students cannot edit the response at the same time: '''
''Prerequisites: Same as the above test.''
# Repeat steps 1-4 (inclusive) from the above UI test. However, remain on the edit page. 
# Open another browser and navigate to Expertiza. Then, login as student9 in another browser. 
# Navigate to the assignment and click "Edit". Verify that you are redirected and unable to edit the review response since student10 is already editing it. 

We leave a manual testing section here to cover a scenario we previously planned to add to our feature tests, but realized to be unfeasible. We have functionality that checks that 2 users on the same team cannot edit a response at the same time. However, Expertiza only uses one browser while testing currently. Setting up 2 of them to run at once was deemed beyond the scope of this project.

CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

2019-12-07T04:10:05Z

Smyoder: /* Changes to Code */

== Introduction - Purpose & Problem ==
Currently, reviews of other student’s work can only be performed by individual students in Expertiza, not by groups of students. Since doing reviews together could help students learn more than by doing them alone, it has been requested that reviews must now have the option to be done by teams instead of individual participants. Therefore, there should be an option when creating assignments that allows the creator to select whether the assignment will use team reviewers or individual reviewers. For simplification, we were allowed to assume that the teams that worked on an assignment together would review together. Each participant should be able to make individual changes to the review (while logged in from their account), but these changes should apply to the team’s collective review. This creates an issue where teammates could accidentally overwrite each other’s work if they edit the review at once. Therefore, it has been decided that the review should be locked while one edits it so that only one participant can edit it at once. Locking the review presents its own challenges.

== Proposed Solution ==
* Modification to Response Map Classes
** A field should be added to ResponseMap which indicates whether responses are done by teams or by individuals.
* Modification to Assignment Class
** A field indicating if the assignment is to be done with team or individuals. This is necessary because part of the suggested requirements is to add a drop down on the review strategy section of the assignment.
* Locking Solution
** Research needs to be done as to whether a rails mechanism already exists to facilitate a lock on page edits
** A solution can be implemented from scratch by storing a flag in the database on the review’s table entry. This would require an additional migration.
**The ability to have a lock on a review requires the implementation of some kind of auto-unlock feature. If a user never unlocks a review, his/her teammates still need to be able to modify the review.
*** We should be able to use the “updated at” field to check if the lock has been held for too long and needs to be released.

== More on Locks ==
The locking solution we added works as a general locking solution. It adds a new table in the database called locks which create a mapping between a user and a resource. This database change does not force a lock on the resource. Just because there exists a lock between some resource and some user, does not mean that other users cannot edit that resource. The actual prevention of edits, be it redirecting or preventing access to controller methods, is the responsibility of you, the programmer. This class just provides an easy interface to facilitate that behavior.

=== Database Changes ===
Locks created the following changes:
* locks
** timeout_period
** created_at
** updated_at
** user_id
** lockable_id
** lockable_type

=== Code Changes ===
[[File:E1973_lock_uml.png]]

=== How to implement ===
Whichever model needs to be able to be locked must include this line:
include Lockable
See app/models/response.rb

To check to see if a resource is locked, use
resource = Lock.get_lock(resource, user, timeout_period)
If the resource is nil, it has been locked. If it's not nil, the given user owns the lock over the current resource.
See app/controllers/response_controller.rb#edit

To unlock a resource after it is done being used, use
Lock.release_lock(resource)
See app/controllers/lock_controller.rb#release_lock

To check to see if a lock exists between a user and a resource, use
Lock.lock_between?(resource, user)
See app/controllers/response_controller.rb#update
Because locks can time out, if user1 makes changes and stalls on a page, user2 could get the lock, make edits, and release it. If that's the case, we may not want to keep user1's changes. The way to check for that scenario is by seeing if the user still has a lock on this object.

=== About lock timeouts ===
Lock.get_lock takes a timeout_period. Timeout_period minutes after a user gets a lock, any user who calls get_lock on a resource will acquire a lock.

As the code stands, you MUST include a timeout period if you wish to get a lock. The rationale being that permanently preventing access to a resource is a heavy price for forgetting to unlock a resource. If you wish to do away with this feature, you will need to add the code yourself. (Perhaps using -1 for no time limit). Though I would heavily recommend using the timeout feature.

== Changes to Code ==
* review_response_map.rb (migration required)
** Field - reviewer_is_team: boolean
* review_mapping_controller.rb - update the following methods to use AssignmentTeam as well as AssignmentParticipant as the reviewer
** automatic_review_mapping()
** add_calibration()
** assign_reviewer_dynamically()
** get_reviewer()
* assignment.rb (migration required)
** Field - has_team_reviews: boolean
* assignment_controller.rb
** updated new() and create() methods to handle new field has_team_reviews
* assignments/edit/_review_strategy.html.erb - added check box for has_team_reviews
<tr>
<td id='reviewer_is_team'>
<input name="assignment_form[assignment][reviewer_is_team]" type="hidden" value="false"/>
<%= check_box_tag('assignment_form[assignment][reviewer_is_team]', 'true', @assignment_form.assignment.reviewer_is_team) %>
<%= label_tag('assignment_form[assignment][reviewer_is_team]', 'Is Review done by Teams?') %>
<img src="/assets/info.png" title='You can select whether the reviews should be done by individual students or teams'>
</td>
</tr>
* assignment_participant.rb
** Method - get_reviewer
*** Returns the participant's team if the reviews for the assignment are done by teams.
*** Several lines of code treated reviewers explicitly as participants. In order to avoid changing too much functionality, and to go with Dr. Gehringer's request that the changes be polymorphic, we just inserted this method whenever the code treated a participant as a reviewer.
*** Example (review_mapping_controller.rb):
*** Reviewer used to be retrieved by the call to AssignmentParticipant.where. Now, reviewer and participant are treated seperately.
def assign_reviewer_dynamically
assignment = Assignment.find(params[:assignment_id])
participant = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
reviewer = participant.get_reviewer
...
* Added lock.rb, lock_controller.rb, and lockable.rb

== Changes Represented in UML ==
[[File:E1973_Uml_1.png]]

== UI Changes ==
=== Assignment Review Strategy ===
==== Before ====
[[File:E1973_Editing_before.png]]

==== After ====
[[File:E1973_Editing_after.png]]

=== Assign Reviewers ===
==== Before ====
[[File:E1973_Participants_before.png]]

==== After ====
[[File:E1973_Participants_after.png]]

== Test Plan ==
=== Rspec ===
Our primary purpose for rspec testing will involve ensuring that we haven't broken any existing functionality.
Since our new functionality doesn't involve any model/view/controller additions, our tests will be appended to existing rspec tests inside of:

* assignments_controller_spec.rb
* response_controller_spec.rb
* review_mapping_controller_spec.rb

The new functionality we need to test should primarily ensure that:

* Students on the same team can see each other's review responses
* No two students can edit a review at the same time
* Reviews submitted by teams are treated identically to reviews submitted by individuals

=== UI Testing ===

Our UI tests aim to capture the following core pieces of functionality: 

'''Students on the same team can view/edit the same response: '''

''Prerequisites: instructor6, student7339, student7340, and student7341 exist in the system. This test assumes student7340 and 7341 are on a team. ''
# Login as instructor6 with password "password".
# Navigate to Manage -> Assignments and click to add a new assignment.
# Fill in the neccessary fields for rubrics by setting Review to "Peer Review Rubric Example" and Author Feedback to "Area of Focus". Under Review Strategy, check the box "Are Reviewers Teams?". Finally, under Due Dates, set number of rounds to 1. Set due dates such that all are in the future. Make sure to give the assignment a unique name you will remember.
# Click back to return to the manage assignments page. Then, click add participants on the assignment you have created. Add student7339 and student7340 to the assignment with the role as participant.
# Logout and log in as student7339 (password is "password").
# Click on the assignment you created as instructor, and select "Your work". Upload a random link, such as "google.com". Click submit.
# Repeat steps 5 through 7, except with student7340 (password is "password").
# Logout and login as instructor6. Navigate to Manage -> Assignment and edit the assignment you created previously.
# Set the assignment's submission1 date to yesterday and submit. This will allow other students to update the assignment.
# Logout and login as student7340.
# Now navigate to the assignment, and click "Other's work". Select "Request new review". Click "Begin" on the review.
# Fill in dummy values for the review, and click save review.
# Logout and login as student7341 (password is "password").
# Navigate to the assignment, and click "Other's work". You should be able to see the review response that student7340 was working on. Click on view.
# Verify that the information is the same as it entered by student7340.
# Click back and then click edit on the review response. Verify that the proper information is prefilled here too. Make a change to one of the response boxes.
# Logout and login as student7340. Navigate back to the review response and click "View".
# Verify that the changes made by student7341 are present in the response.

 
'''Students cannot edit the response at the same time: '''
''Prerequisites: Same as the above test.''
# Repeat steps 1-11 (inclusive) from the above test. 
# Open another browser and navigate to Expertiza. Then, login as student7341. 
# Navigate to the assignment and click "Edit". Verify that you are redirected and unable to edit the review response since student7340 is already editing it. 
# Try clicking "View". Verify that you are unable to view the review response here either.

CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

2019-12-07T04:01:14Z

Smyoder: /* Changes to Code */

== Introduction - Purpose & Problem ==
Currently, reviews of other student’s work can only be performed by individual students in Expertiza, not by groups of students. Since doing reviews together could help students learn more than by doing them alone, it has been requested that reviews must now have the option to be done by teams instead of individual participants. Therefore, there should be an option when creating assignments that allows the creator to select whether the assignment will use team reviewers or individual reviewers. For simplification, we were allowed to assume that the teams that worked on an assignment together would review together. Each participant should be able to make individual changes to the review (while logged in from their account), but these changes should apply to the team’s collective review. This creates an issue where teammates could accidentally overwrite each other’s work if they edit the review at once. Therefore, it has been decided that the review should be locked while one edits it so that only one participant can edit it at once. Locking the review presents its own challenges.

== Proposed Solution ==
* Modification to Response Map Classes
** A field should be added to ResponseMap which indicates whether responses are done by teams or by individuals.
* Modification to Assignment Class
** A field indicating if the assignment is to be done with team or individuals. This is necessary because part of the suggested requirements is to add a drop down on the review strategy section of the assignment.
* Locking Solution
** Research needs to be done as to whether a rails mechanism already exists to facilitate a lock on page edits
** A solution can be implemented from scratch by storing a flag in the database on the review’s table entry. This would require an additional migration.
**The ability to have a lock on a review requires the implementation of some kind of auto-unlock feature. If a user never unlocks a review, his/her teammates still need to be able to modify the review.
*** We should be able to use the “updated at” field to check if the lock has been held for too long and needs to be released.

== More on Locks ==
The locking solution we added works as a general locking solution. It adds a new table in the database called locks which create a mapping between a user and a resource. This database change does not force a lock on the resource. Just because there exists a lock between some resource and some user, does not mean that other users cannot edit that resource. The actual prevention of edits, be it redirecting or preventing access to controller methods, is the responsibility of you, the programmer. This class just provides an easy interface to facilitate that behavior.

=== Database Changes ===
Locks created the following changes:
* locks
** timeout_period
** created_at
** updated_at
** user_id
** lockable_id
** lockable_type

=== Code Changes ===
[[File:E1973_lock_uml.png]]

=== How to implement ===
Whichever model needs to be able to be locked must include this line:
include Lockable
See app/models/response.rb

To check to see if a resource is locked, use
resource = Lock.get_lock(resource, user, timeout_period)
If the resource is nil, it has been locked. If it's not nil, the given user owns the lock over the current resource.
See app/controllers/response_controller.rb#edit

To unlock a resource after it is done being used, use
Lock.release_lock(resource)
See app/controllers/lock_controller.rb#release_lock

To check to see if a lock exists between a user and a resource, use
Lock.lock_between?(resource, user)
See app/controllers/response_controller.rb#update
Because locks can time out, if user1 makes changes and stalls on a page, user2 could get the lock, make edits, and release it. If that's the case, we may not want to keep user1's changes. The way to check for that scenario is by seeing if the user still has a lock on this object.

=== About lock timeouts ===
Lock.get_lock takes a timeout_period. Timeout_period minutes after a user gets a lock, any user who calls get_lock on a resource will acquire a lock.

As the code stands, you MUST include a timeout period if you wish to get a lock. The rationale being that permanently preventing access to a resource is a heavy price for forgetting to unlock a resource. If you wish to do away with this feature, you will need to add the code yourself. (Perhaps using -1 for no time limit). Though I would heavily recommend using the timeout feature.

== Changes to Code ==
* review_response_map.rb (migration required)
** Field - reviewer_is_team: boolean
* review_mapping_controller.rb - update the following methods to use AssignmentTeam as well as AssignmentParticipant as the reviewer
** automatic_review_mapping()
** add_calibration()
** assign_reviewer_dynamically()
** get_reviewer()
* assignment.rb (migration required)
** Field - has_team_reviews: boolean
* assignment_controller.rb
** updated new() and create() methods to handle new field has_team_reviews
* assignments/edit/_review_strategy.html.erb - added check box for has_team_reviews
* assignment_participant.rb
** Method - get_reviewer
*** Returns the participant's team if the reviews for the assignment are done by teams.
*** Several lines of code treated reviewers explicitly as participants. In order to avoid changing too much functionality, and to go with Dr. Gehringer's request that the changes be polymorphic, we just inserted this method whenever the code treated a participant as a reviewer.
*** Example (review_mapping_controller.rb):
def assign_reviewer_dynamically
assignment = Assignment.find(params[:assignment_id])
participant = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
reviewer = participant.get_reviewer
...
*** Reviewer used to be retrieved by the call to AssignmentParticipant.where. Now, reviewer and participant are treated seperately.

== Changes Represented in UML ==
[[File:E1973_Uml_1.png]]

== UI Changes ==
=== Assignment Review Strategy ===
==== Before ====
[[File:E1973_Editing_before.png]]

==== After ====
[[File:E1973_Editing_after.png]]

=== Assign Reviewers ===
==== Before ====
[[File:E1973_Participants_before.png]]

==== After ====
[[File:E1973_Participants_after.png]]

== Test Plan ==
=== Rspec ===
Our primary purpose for rspec testing will involve ensuring that we haven't broken any existing functionality.
Since our new functionality doesn't involve any model/view/controller additions, our tests will be appended to existing rspec tests inside of:

* assignments_controller_spec.rb
* response_controller_spec.rb
* review_mapping_controller_spec.rb

The new functionality we need to test should primarily ensure that:

* Students on the same team can see each other's review responses
* No two students can edit a review at the same time
* Reviews submitted by teams are treated identically to reviews submitted by individuals

=== UI Testing ===

Our UI tests aim to capture the following core pieces of functionality: 

'''Students on the same team can view/edit the same response: '''

''Prerequisites: instructor6, student7339, student7340, and student7341 exist in the system. This test assumes student7340 and 7341 are on a team. ''
# Login as instructor6 with password "password".
# Navigate to Manage -> Assignments and click to add a new assignment.
# Fill in the neccessary fields for rubrics by setting Review to "Peer Review Rubric Example" and Author Feedback to "Area of Focus". Under Review Strategy, check the box "Are Reviewers Teams?". Finally, under Due Dates, set number of rounds to 1. Set due dates such that all are in the future. Make sure to give the assignment a unique name you will remember.
# Click back to return to the manage assignments page. Then, click add participants on the assignment you have created. Add student7339 and student7340 to the assignment with the role as participant.
# Logout and log in as student7339 (password is "password").
# Click on the assignment you created as instructor, and select "Your work". Upload a random link, such as "google.com". Click submit.
# Repeat steps 5 through 7, except with student7340 (password is "password").
# Logout and login as instructor6. Navigate to Manage -> Assignment and edit the assignment you created previously.
# Set the assignment's submission1 date to yesterday and submit. This will allow other students to update the assignment.
# Logout and login as student7340.
# Now navigate to the assignment, and click "Other's work". Select "Request new review". Click "Begin" on the review.
# Fill in dummy values for the review, and click save review.
# Logout and login as student7341 (password is "password").
# Navigate to the assignment, and click "Other's work". You should be able to see the review response that student7340 was working on. Click on view.
# Verify that the information is the same as it entered by student7340.
# Click back and then click edit on the review response. Verify that the proper information is prefilled here too. Make a change to one of the response boxes.
# Logout and login as student7340. Navigate back to the review response and click "View".
# Verify that the changes made by student7341 are present in the response.

 
'''Students cannot edit the response at the same time: '''
''Prerequisites: Same as the above test.''
# Repeat steps 1-11 (inclusive) from the above test. 
# Open another browser and navigate to Expertiza. Then, login as student7341. 
# Navigate to the assignment and click "Edit". Verify that you are redirected and unable to edit the review response since student7340 is already editing it. 
# Try clicking "View". Verify that you are unable to view the review response here either.

CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

2019-12-07T03:54:42Z

Smyoder: /* Changes to Code */

== Introduction - Purpose & Problem ==
Currently, reviews of other student’s work can only be performed by individual students in Expertiza, not by groups of students. Since doing reviews together could help students learn more than by doing them alone, it has been requested that reviews must now have the option to be done by teams instead of individual participants. Therefore, there should be an option when creating assignments that allows the creator to select whether the assignment will use team reviewers or individual reviewers. For simplification, we were allowed to assume that the teams that worked on an assignment together would review together. Each participant should be able to make individual changes to the review (while logged in from their account), but these changes should apply to the team’s collective review. This creates an issue where teammates could accidentally overwrite each other’s work if they edit the review at once. Therefore, it has been decided that the review should be locked while one edits it so that only one participant can edit it at once. Locking the review presents its own challenges.

== Proposed Solution ==
* Modification to Response Map Classes
** A field should be added to ResponseMap which indicates whether responses are done by teams or by individuals.
* Modification to Assignment Class
** A field indicating if the assignment is to be done with team or individuals. This is necessary because part of the suggested requirements is to add a drop down on the review strategy section of the assignment.
* Locking Solution
** Research needs to be done as to whether a rails mechanism already exists to facilitate a lock on page edits
** A solution can be implemented from scratch by storing a flag in the database on the review’s table entry. This would require an additional migration.
**The ability to have a lock on a review requires the implementation of some kind of auto-unlock feature. If a user never unlocks a review, his/her teammates still need to be able to modify the review.
*** We should be able to use the “updated at” field to check if the lock has been held for too long and needs to be released.

== More on Locks ==
The locking solution we added works as a general locking solution. It adds a new table in the database called locks which create a mapping between a user and a resource. This database change does not force a lock on the resource. Just because there exists a lock between some resource and some user, does not mean that other users cannot edit that resource. The actual prevention of edits, be it redirecting or preventing access to controller methods, is the responsibility of you, the programmer. This class just provides an easy interface to facilitate that behavior.

=== Database Changes ===
Locks created the following changes:
* locks
** timeout_period
** created_at
** updated_at
** user_id
** lockable_id
** lockable_type

=== Code Changes ===
[[File:E1973_lock_uml.png]]

=== How to implement ===
Whichever model needs to be able to be locked must include this line:
include Lockable
See app/models/response.rb

To check to see if a resource is locked, use
resource = Lock.get_lock(resource, user, timeout_period)
If the resource is nil, it has been locked. If it's not nil, the given user owns the lock over the current resource.
See app/controllers/response_controller.rb#edit

To unlock a resource after it is done being used, use
Lock.release_lock(resource)
See app/controllers/lock_controller.rb#release_lock

To check to see if a lock exists between a user and a resource, use
Lock.lock_between?(resource, user)
See app/controllers/response_controller.rb#update
Because locks can time out, if user1 makes changes and stalls on a page, user2 could get the lock, make edits, and release it. If that's the case, we may not want to keep user1's changes. The way to check for that scenario is by seeing if the user still has a lock on this object.

=== About lock timeouts ===
Lock.get_lock takes a timeout_period. Timeout_period minutes after a user gets a lock, any user who calls get_lock on a resource will acquire a lock.

As the code stands, you MUST include a timeout period if you wish to get a lock. The rationale being that permanently preventing access to a resource is a heavy price for forgetting to unlock a resource. If you wish to do away with this feature, you will need to add the code yourself. (Perhaps using -1 for no time limit). Though I would heavily recommend using the timeout feature.

== Changes to Code ==
* review_response_map.rb (migration required)
** Field - reviewer_is_team: boolean
* review_mapping_controller.rb - update the following methods to use AssignmentTeam as well as AssignmentParticipant as the reviewer
** automatic_review_mapping()
** add_calibration()
** assign_reviewer_dynamically()
** get_reviewer()
* assignment.rb (migration required)
** Field - has_team_reviews: boolean
* assignment_controller.rb
** update new() and create() methods to handle new field has_team_reviews
* assignments/edit/_review_strategy.html.erb - add check box for has_team_reviews
* assignment_participant.rb
** Method - get_reviewer
*** Several lines of code treated reviewers explicitly as participants. In order to avoid changing too much functionality, and to go with Dr. Gehringer's request that the changes be polymorphic, we just inserted this method whenever the code treated a participant as a reviewer
*** Example (review_mapping_controller.rb):
def assign_reviewer_dynamically
assignment = Assignment.find(params[:assignment_id])
participant = AssignmentParticipant.where(user_id: params[:reviewer_id], parent_id: assignment.id).first
reviewer = participant.get_reviewer

== Changes Represented in UML ==
[[File:E1973_Uml_1.png]]

== UI Changes ==
=== Assignment Review Strategy ===
==== Before ====
[[File:E1973_Editing_before.png]]

==== After ====
[[File:E1973_Editing_after.png]]

=== Assign Reviewers ===
==== Before ====
[[File:E1973_Participants_before.png]]

==== After ====
[[File:E1973_Participants_after.png]]

== Test Plan ==
=== Rspec ===
Our primary purpose for rspec testing will involve ensuring that we haven't broken any existing functionality.
Since our new functionality doesn't involve any model/view/controller additions, our tests will be appended to existing rspec tests inside of:

* assignments_controller_spec.rb
* response_controller_spec.rb
* review_mapping_controller_spec.rb

The new functionality we need to test should primarily ensure that:

* Students on the same team can see each other's review responses
* No two students can edit a review at the same time
* Reviews submitted by teams are treated identically to reviews submitted by individuals

=== UI Testing ===

Our UI tests aim to capture the following core pieces of functionality: 

'''Students on the same team can view/edit the same response: '''

''Prerequisites: instructor6, student7339, student7340, and student7341 exist in the system. This test assumes student7340 and 7341 are on a team. ''
# Login as instructor6 with password "password".
# Navigate to Manage -> Assignments and click to add a new assignment.
# Fill in the neccessary fields for rubrics by setting Review to "Peer Review Rubric Example" and Author Feedback to "Area of Focus". Under Review Strategy, check the box "Are Reviewers Teams?". Finally, under Due Dates, set number of rounds to 1. Set due dates such that all are in the future. Make sure to give the assignment a unique name you will remember.
# Click back to return to the manage assignments page. Then, click add participants on the assignment you have created. Add student7339 and student7340 to the assignment with the role as participant.
# Logout and log in as student7339 (password is "password").
# Click on the assignment you created as instructor, and select "Your work". Upload a random link, such as "google.com". Click submit.
# Repeat steps 5 through 7, except with student7340 (password is "password").
# Logout and login as instructor6. Navigate to Manage -> Assignment and edit the assignment you created previously.
# Set the assignment's submission1 date to yesterday and submit. This will allow other students to update the assignment.
# Logout and login as student7340.
# Now navigate to the assignment, and click "Other's work". Select "Request new review". Click "Begin" on the review.
# Fill in dummy values for the review, and click save review.
# Logout and login as student7341 (password is "password").
# Navigate to the assignment, and click "Other's work". You should be able to see the review response that student7340 was working on. Click on view.
# Verify that the information is the same as it entered by student7340.
# Click back and then click edit on the review response. Verify that the proper information is prefilled here too. Make a change to one of the response boxes.
# Logout and login as student7340. Navigate back to the review response and click "View".
# Verify that the changes made by student7341 are present in the response.

 
'''Students cannot edit the response at the same time: '''
''Prerequisites: Same as the above test.''
# Repeat steps 1-11 (inclusive) from the above test. 
# Open another browser and navigate to Expertiza. Then, login as student7341. 
# Navigate to the assignment and click "Edit". Verify that you are redirected and unable to edit the review response since student7340 is already editing it. 
# Try clicking "View". Verify that you are unable to view the review response here either.

CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

2019-12-06T23:58:55Z

Smyoder: /* More on Locks */

== Introduction - Purpose & Problem ==
Currently, reviews of other student’s work can only be performed by individual students in Expertiza, not by groups of students. Since doing reviews together could help students learn more than by doing them alone, it has been requested that reviews must now have the option to be done by teams instead of individual participants. Therefore, there should be an option when creating assignments that allows the creator to select whether the assignment will use team reviewers or individual reviewers. For simplification, we were allowed to assume that the teams that worked on an assignment together would review together. Each participant should be able to make individual changes to the review (while logged in from their account), but these changes should apply to the team’s collective review. This creates an issue where teammates could accidentally overwrite each other’s work if they edit the review at once. Therefore, it has been decided that the review should be locked while one edits it so that only one participant can edit it at once. Locking the review presents its own challenges.

== Proposed Solution ==
* Modification to Response Map Classes
** A field should be added to ResponseMap which indicates whether responses are done by teams or by individuals.
* Modification to Assignment Class
** A field indicating if the assignment is to be done with team or individuals. This is necessary because part of the suggested requirements is to add a drop down on the review strategy section of the assignment.
* Locking Solution
** Research needs to be done as to whether a rails mechanism already exists to facilitate a lock on page edits
** A solution can be implemented from scratch by storing a flag in the database on the review’s table entry. This would require an additional migration.
**The ability to have a lock on a review requires the implementation of some kind of auto-unlock feature. If a user never unlocks a review, his/her teammates still need to be able to modify the review.
*** We should be able to use the “updated at” field to check if the lock has been held for too long and needs to be released.

== More on Locks ==
The locking solution we added works as a general locking solution. It adds a new table in the database called locks which create a mapping between a user and a resource. This database change does not force a lock on the resource. Just because there exists a lock between some resource and some user, does not mean that other users cannot edit that resource. The actual prevention of edits, be it redirecting or preventing access to controller methods, is the responsibility of you, the programmer. This class just provides an easy interface to facilitate that behavior.

=== Database Changes ===
Locks created the following changes:
* locks
** timeout_period
** created_at
** updated_at
** user_id
** lockable_id
** lockable_type

=== Code Changes ===
[[File:E1973_lock_uml.png]]

=== How to implement ===
Whichever model needs to be able to be locked must include this line:
include Lockable
See app/models/response.rb

To check to see if a resource is locked, use
resource = Lock.get_lock(resource, user, timeout_period)
If the resource is nil, it has been locked. If it's not nil, the given user owns the lock over the current resource.
See app/controllers/response_controller.rb#edit

To unlock a resource after it is done being used, use
Lock.release_lock(resource)
See app/controllers/lock_controller.rb#release_lock

To check to see if a lock exists between a user and a resource, use
Lock.lock_between?(resource, user)
See app/controllers/response_controller.rb#update
Because locks can time out, if user1 makes changes and stalls on a page, user2 could get the lock, make edits, and release it. If that's the case, we may not want to keep user1's changes. The way to check for that scenario is by seeing if the user still has a lock on this object.

=== About lock timeouts ===
Lock.get_lock takes a timeout_period. Timeout_period minutes after a user gets a lock, any user who calls get_lock on a resource will acquire a lock.

As the code stands, you MUST include a timeout period if you wish to get a lock. The rationale being that permanently preventing access to a resource is a heavy price for forgetting to unlock a resource. If you wish to do away with this feature, you will need to add the code yourself. (Perhaps using -1 for no time limit). Though I would heavily recommend using the timeout feature.

== Changes to Code ==
* review_response_map.rb (migration required)
** Field - reviewer_is_team: boolean
* review_mapping_controller.rb - update the following methods to use AssignmentTeam as well as AssignmentParticipant as the reviewer
** automatic_review_mapping()
** add_calibration()
** assign_reviewer_dynamically()
** get_reviewer()
* assignment.rb (migration required)
** Field - has_team_reviews: boolean
* assignment_controller.rb
** update new() and create() methods to handle new field has_team_reviews
* assignment ui files - add check box for has_team_reviews

== Changes Represented in UML ==
[[File:E1973_Uml_1.png]]

== UI Changes ==
=== Assignment Review Strategy ===
==== Before ====
[[File:E1973_Editing_before.png]]

==== After ====
[[File:E1973_Editing_after.png]]

=== Assign Reviewers ===
==== Before ====
[[File:E1973_Participants_before.png]]

==== After ====
[[File:E1973_Participants_after.png]]

== Test Plan ==
=== Rspec ===
Our primary purpose for rspec testing will involve ensuring that we haven't broken any existing functionality.
Since our new functionality doesn't involve any model/view/controller additions, our tests will be appended to existing rspec tests inside of:

* assignments_controller_spec.rb
* response_controller_spec.rb
* review_mapping_controller_spec.rb

The new functionality we need to test should primarily ensure that:

* Students on the same team can see each other's review responses
* No two students can edit a review at the same time
* Reviews submitted by teams are treated identically to reviews submitted by individuals

=== UI Testing ===

Our UI tests aim to capture the following core pieces of functionality: 

'''Students on the same team can view/edit the same response: '''

''Prerequisites: instructor6, student7339, student7340, and student7341 exist in the system. This test assumes student7340 and 7341 are on a team. ''
# Login as instructor6 with password "password".
# Navigate to Manage -> Assignments and click to add a new assignment.
# Fill in the neccessary fields for rubrics by setting Review to "Peer Review Rubric Example" and Author Feedback to "Area of Focus". Under Review Strategy, check the box "Are Reviewers Teams?". Finally, under Due Dates, set number of rounds to 1. Set due dates such that all are in the future. Make sure to give the assignment a unique name you will remember.
# Click back to return to the manage assignments page. Then, click add participants on the assignment you have created. Add student7339 and student7340 to the assignment with the role as participant.
# Logout and log in as student7339 (password is "password").
# Click on the assignment you created as instructor, and select "Your work". Upload a random link, such as "google.com". Click submit.
# Repeat steps 5 through 7, except with student7340 (password is "password").
# Logout and login as instructor6. Navigate to Manage -> Assignment and edit the assignment you created previously.
# Set the assignment's submission1 date to yesterday and submit. This will allow other students to update the assignment.
# Logout and login as student7340.
# Now navigate to the assignment, and click "Other's work". Select "Request new review". Click "Begin" on the review.
# Fill in dummy values for the review, and click save review.
# Logout and login as student7341 (password is "password").
# Navigate to the assignment, and click "Other's work". You should be able to see the review response that student7340 was working on. Click on view.
# Verify that the information is the same as it entered by student7340.
# Click back and then click edit on the review response. Verify that the proper information is prefilled here too. Make a change to one of the response boxes.
# Logout and login as student7340. Navigate back to the review response and click "View".
# Verify that the changes made by student7341 are present in the response.

 
'''Students cannot edit the response at the same time: '''
''Prerequisites: Same as the above test.''
# Repeat steps 1-11 (inclusive) from the above test. 
# Open another browser and navigate to Expertiza. Then, login as student7341. 
# Navigate to the assignment and click "Edit". Verify that you are redirected and unable to edit the review response since student7340 is already editing it. 
# Try clicking "View". Verify that you are unable to view the review response here either.

CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

2019-12-06T21:15:46Z

Smyoder: /* How to implement */

== Introduction - Purpose & Problem ==
Currently, reviews of other student’s work can only be performed by individual students in Expertiza, not by groups of students. Since doing reviews together could help students learn more than by doing them alone, it has been requested that reviews must now have the option to be done by teams instead of individual participants. Therefore, there should be an option when creating assignments that allows the creator to select whether the assignment will use team reviewers or individual reviewers. For simplification, we were allowed to assume that the teams that worked on an assignment together would review together. Each participant should be able to make individual changes to the review (while logged in from their account), but these changes should apply to the team’s collective review. This creates an issue where teammates could accidentally overwrite each other’s work if they edit the review at once. Therefore, it has been decided that the review should be locked while one edits it so that only one participant can edit it at once. Locking the review presents its own challenges.

== Proposed Solution ==
* Modification to Response Map Classes
** A field should be added to ResponseMap which indicates whether responses are done by teams or by individuals.
* Modification to Assignment Class
** A field indicating if the assignment is to be done with team or individuals. This is necessary because part of the suggested requirements is to add a drop down on the review strategy section of the assignment.
* Locking Solution
** Research needs to be done as to whether a rails mechanism already exists to facilitate a lock on page edits
** A solution can be implemented from scratch by storing a flag in the database on the review’s table entry. This would require an additional migration.
**The ability to have a lock on a review requires the implementation of some kind of auto-unlock feature. If a user never unlocks a review, his/her teammates still need to be able to modify the review.
*** We should be able to use the “updated at” field to check if the lock has been held for too long and needs to be released.

== More on Locks ==
The locking solution we added works as a general locking solution. It adds a new table in the database called locks which create a mapping between a user and a resource. This database change does not force a lock on the resource. Just because there exists a lock between some resource and some user, does not mean that other users cannot edit that resource. The actual prevention of edits, be it redirecting or preventing access to controller methods, is the responsibility of you, the programmer. This class just provides an easy interface to facilitate that behavior.

=== Database Changes ===
Locks created the following changes:
* locks
** timeout_period
** created_at
** updated_at
** user_id
** lockable_id
** lockable_type

=== Code Changes ===
[[File:E1973_lock_uml.png]]

=== How to implement ===
Whichever model needs to be able to be locked must include this line:
include Lockable
See app/models/response.rb

To check to see if a resource is locked, use
resource = Lock.get_lock(resource, user, timeout_period)
If the resource is nil, it has been locked. If it's not nil, the given user owns the lock over the current resource.
See app/controllers/response_controller.rb

To unlock a resource after it is done being used, use
Lock.release_lock(resource)
See app/controllers/response_controller.rb

To check to see if a lock exists between a user and a resource, use
Lock.lock_between?(resource, user)
See app/views

== Changes to Code ==
* review_response_map.rb (migration required)
** Field - reviewer_is_team: boolean
* review_mapping_controller.rb - update the following methods to use AssignmentTeam as well as AssignmentParticipant as the reviewer
** automatic_review_mapping()
** add_calibration()
** assign_reviewer_dynamically()
** get_reviewer()
* assignment.rb (migration required)
** Field - has_team_reviews: boolean
* assignment_controller.rb
** update new() and create() methods to handle new field has_team_reviews
* assignment ui files - add check box for has_team_reviews

== Changes Represented in UML ==
[[File:E1973_Uml_1.png]]

== UI Changes ==
=== Assignment Review Strategy ===
==== Before ====
[[File:E1973_Editing_before.png]]

==== After ====
[[File:E1973_Editing_after.png]]

=== Assign Reviewers ===
==== Before ====
[[File:E1973_Participants_before.png]]

==== After ====
[[File:E1973_Participants_after.png]]

== Test Plan ==
=== Rspec ===
Our primary purpose for rspec testing will involve ensuring that we haven't broken any existing functionality.
Since our new functionality doesn't involve any model/view/controller additions, our tests will be appended to existing rspec tests inside of:

* assignments_controller_spec.rb
* response_controller_spec.rb
* review_mapping_controller_spec.rb

The new functionality we need to test should primarily ensure that:

* Students on the same team can see each other's review responses
* No two students can edit a review at the same time
* Reviews submitted by teams are treated identically to reviews submitted by individuals

=== UI Testing ===

Our UI tests aim to capture the following core pieces of functionality: 

'''Students on the same team can view/edit the same response: '''

''Prerequisites: instructor6, student7339, student7340, and student7341 exist in the system. This test assumes student7340 and 7341 are on a team. ''
# Login as instructor6 with password "password".
# Navigate to Manage -> Assignments and click to add a new assignment.
# Fill in the neccessary fields for rubrics by setting Review to "Peer Review Rubric Example" and Author Feedback to "Area of Focus". Under Review Strategy, check the box "Are Reviewers Teams?". Finally, under Due Dates, set number of rounds to 1. Set due dates such that all are in the future. Make sure to give the assignment a unique name you will remember.
# Click back to return to the manage assignments page. Then, click add participants on the assignment you have created. Add student7339 and student7340 to the assignment with the role as participant.
# Logout and log in as student7339 (password is "password").
# Click on the assignment you created as instructor, and select "Your work". Upload a random link, such as "google.com". Click submit.
# Repeat steps 5 through 7, except with student7340 (password is "password").
# Logout and login as instructor6. Navigate to Manage -> Assignment and edit the assignment you created previously.
# Set the assignment's submission1 date to yesterday and submit. This will allow other students to update the assignment.
# Logout and login as student7340.
# Now navigate to the assignment, and click "Other's work". Select "Request new review". Click "Begin" on the review.
# Fill in dummy values for the review, and click save review.
# Logout and login as student7341 (password is "password").
# Navigate to the assignment, and click "Other's work". You should be able to see the review response that student7340 was working on. Click on view.
# Verify that the information is the same as it entered by student7340.
# Click back and then click edit on the review response. Verify that the proper information is prefilled here too. Make a change to one of the response boxes.
# Logout and login as student7340. Navigate back to the review response and click "View".
# Verify that the changes made by student7341 are present in the response.

 
'''Students cannot edit the response at the same time: '''
''Prerequisites: Same as the above test.''
# Repeat steps 1-11 (inclusive) from the above test. 
# Open another browser and navigate to Expertiza. Then, login as student7341. 
# Navigate to the assignment and click "Edit". Verify that you are redirected and unable to edit the review response since student7340 is already editing it. 
# Try clicking "View". Verify that you are unable to view the review response here either.

File:E1973 lock uml.png

2019-12-06T21:03:46Z

Smyoder: uploaded a new version of "File:E1973 lock uml.png"

CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

2019-12-06T21:02:32Z

Smyoder: /* More on Locks */

== Introduction - Purpose & Problem ==
Currently, reviews of other student’s work can only be performed by individual students in Expertiza, not by groups of students. Since doing reviews together could help students learn more than by doing them alone, it has been requested that reviews must now have the option to be done by teams instead of individual participants. Therefore, there should be an option when creating assignments that allows the creator to select whether the assignment will use team reviewers or individual reviewers. For simplification, we were allowed to assume that the teams that worked on an assignment together would review together. Each participant should be able to make individual changes to the review (while logged in from their account), but these changes should apply to the team’s collective review. This creates an issue where teammates could accidentally overwrite each other’s work if they edit the review at once. Therefore, it has been decided that the review should be locked while one edits it so that only one participant can edit it at once. Locking the review presents its own challenges.

== Proposed Solution ==
* Modification to Response Map Classes
** A field should be added to ResponseMap which indicates whether responses are done by teams or by individuals.
* Modification to Assignment Class
** A field indicating if the assignment is to be done with team or individuals. This is necessary because part of the suggested requirements is to add a drop down on the review strategy section of the assignment.
* Locking Solution
** Research needs to be done as to whether a rails mechanism already exists to facilitate a lock on page edits
** A solution can be implemented from scratch by storing a flag in the database on the review’s table entry. This would require an additional migration.
**The ability to have a lock on a review requires the implementation of some kind of auto-unlock feature. If a user never unlocks a review, his/her teammates still need to be able to modify the review.
*** We should be able to use the “updated at” field to check if the lock has been held for too long and needs to be released.

== More on Locks ==
The locking solution we added works as a general locking solution. It adds a new table in the database called locks which create a mapping between a user and a resource. This database change does not force a lock on the resource. Just because there exists a lock between some resource and some user, does not mean that other users cannot edit that resource. The actual prevention of edits, be it redirecting or preventing access to controller methods, is the responsibility of you, the programmer. This class just provides an easy interface to facilitate that behavior.

=== Database Changes ===
Locks created the following changes:
* locks
** timeout_period
** created_at
** updated_at
** user_id
** lockable_id
** lockable_type

=== Code Changes ===
[[File:E1973_lock_uml.png]]

=== How to implement ===
Whichever model needs to be able to be locked must include this line:
include Lockable
See app/models/response.rb

To check to see if a resource is locked, use
resource = Lock.get_lock(resource, user, timeout_period)
If the resource is nil, it has been locked. If it's not nil, the given user owns the lock over the current resource.
See

To unlock a resource after it is done being used, use
Lock.release_lock(resource)

To check to see if a lock exists between a user and a resource, use
Lock.lock_between?(resource, user)

== Changes to Code ==
* review_response_map.rb (migration required)
** Field - reviewer_is_team: boolean
* review_mapping_controller.rb - update the following methods to use AssignmentTeam as well as AssignmentParticipant as the reviewer
** automatic_review_mapping()
** add_calibration()
** assign_reviewer_dynamically()
** get_reviewer()
* assignment.rb (migration required)
** Field - has_team_reviews: boolean
* assignment_controller.rb
** update new() and create() methods to handle new field has_team_reviews
* assignment ui files - add check box for has_team_reviews

== Changes Represented in UML ==
[[File:E1973_Uml_1.png]]

== UI Changes ==
=== Assignment Review Strategy ===
==== Before ====
[[File:E1973_Editing_before.png]]

==== After ====
[[File:E1973_Editing_after.png]]

=== Assign Reviewers ===
==== Before ====
[[File:E1973_Participants_before.png]]

==== After ====
[[File:E1973_Participants_after.png]]

== Test Plan ==
=== Rspec ===
Our primary purpose for rspec testing will involve ensuring that we haven't broken any existing functionality.
Since our new functionality doesn't involve any model/view/controller additions, our tests will be appended to existing rspec tests inside of:

* assignments_controller_spec.rb
* response_controller_spec.rb
* review_mapping_controller_spec.rb

The new functionality we need to test should primarily ensure that:

* Students on the same team can see each other's review responses
* No two students can edit a review at the same time
* Reviews submitted by teams are treated identically to reviews submitted by individuals

=== UI Testing ===

Our UI tests aim to capture the following core pieces of functionality: 

'''Students on the same team can view/edit the same response: '''

''Prerequisites: instructor6, student7339, student7340, and student7341 exist in the system. This test assumes student7340 and 7341 are on a team. ''
# Login as instructor6 with password "password".
# Navigate to Manage -> Assignments and click to add a new assignment.
# Fill in the neccessary fields for rubrics by setting Review to "Peer Review Rubric Example" and Author Feedback to "Area of Focus". Under Review Strategy, check the box "Are Reviewers Teams?". Finally, under Due Dates, set number of rounds to 1. Set due dates such that all are in the future. Make sure to give the assignment a unique name you will remember.
# Click back to return to the manage assignments page. Then, click add participants on the assignment you have created. Add student7339 and student7340 to the assignment with the role as participant.
# Logout and log in as student7339 (password is "password").
# Click on the assignment you created as instructor, and select "Your work". Upload a random link, such as "google.com". Click submit.
# Repeat steps 5 through 7, except with student7340 (password is "password").
# Logout and login as instructor6. Navigate to Manage -> Assignment and edit the assignment you created previously.
# Set the assignment's submission1 date to yesterday and submit. This will allow other students to update the assignment.
# Logout and login as student7340.
# Now navigate to the assignment, and click "Other's work". Select "Request new review". Click "Begin" on the review.
# Fill in dummy values for the review, and click save review.
# Logout and login as student7341 (password is "password").
# Navigate to the assignment, and click "Other's work". You should be able to see the review response that student7340 was working on. Click on view.
# Verify that the information is the same as it entered by student7340.
# Click back and then click edit on the review response. Verify that the proper information is prefilled here too. Make a change to one of the response boxes.
# Logout and login as student7340. Navigate back to the review response and click "View".
# Verify that the changes made by student7341 are present in the response.

 
'''Students cannot edit the response at the same time: '''
''Prerequisites: Same as the above test.''
# Repeat steps 1-11 (inclusive) from the above test. 
# Open another browser and navigate to Expertiza. Then, login as student7341. 
# Navigate to the assignment and click "Edit". Verify that you are redirected and unable to edit the review response since student7340 is already editing it. 
# Try clicking "View". Verify that you are unable to view the review response here either.

CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

2019-12-06T20:49:40Z

Smyoder: /* More on Locks */

== Introduction - Purpose & Problem ==
Currently, reviews of other student’s work can only be performed by individual students in Expertiza, not by groups of students. Since doing reviews together could help students learn more than by doing them alone, it has been requested that reviews must now have the option to be done by teams instead of individual participants. Therefore, there should be an option when creating assignments that allows the creator to select whether the assignment will use team reviewers or individual reviewers. For simplification, we were allowed to assume that the teams that worked on an assignment together would review together. Each participant should be able to make individual changes to the review (while logged in from their account), but these changes should apply to the team’s collective review. This creates an issue where teammates could accidentally overwrite each other’s work if they edit the review at once. Therefore, it has been decided that the review should be locked while one edits it so that only one participant can edit it at once. Locking the review presents its own challenges.

== Proposed Solution ==
* Modification to Response Map Classes
** A field should be added to ResponseMap which indicates whether responses are done by teams or by individuals.
* Modification to Assignment Class
** A field indicating if the assignment is to be done with team or individuals. This is necessary because part of the suggested requirements is to add a drop down on the review strategy section of the assignment.
* Locking Solution
** Research needs to be done as to whether a rails mechanism already exists to facilitate a lock on page edits
** A solution can be implemented from scratch by storing a flag in the database on the review’s table entry. This would require an additional migration.
**The ability to have a lock on a review requires the implementation of some kind of auto-unlock feature. If a user never unlocks a review, his/her teammates still need to be able to modify the review.
*** We should be able to use the “updated at” field to check if the lock has been held for too long and needs to be released.

== More on Locks ==
The locking solution we added works as a general locking solution. It adds a new table in the database called locks which create a mapping between a user and a resource. This database change does not force a lock on the resource. Just because there exists a lock between some resource and some user, does not mean that other users cannot edit that resource. The actual prevention of edits, be it redirecting or preventing access to controller methods, is the responsibility of you, the programmer. This class just provides an easy interface to facilitate that behavior.

=== Database Changes ===
Locks created the following changes:
* locks
** timeout_period
** created_at
** updated_at
** user_id
** lockable_id
** lockable_type

=== Code Changes ===
[[File:E1973_lock_uml.png]]

=== How to implement ===
Whichever model needs to be able to be locked must include this line:
include Lockable

== Changes to Code ==
* review_response_map.rb (migration required)
** Field - reviewer_is_team: boolean
* review_mapping_controller.rb - update the following methods to use AssignmentTeam as well as AssignmentParticipant as the reviewer
** automatic_review_mapping()
** add_calibration()
** assign_reviewer_dynamically()
** get_reviewer()
* assignment.rb (migration required)
** Field - has_team_reviews: boolean
* assignment_controller.rb
** update new() and create() methods to handle new field has_team_reviews
* assignment ui files - add check box for has_team_reviews

== Changes Represented in UML ==
[[File:E1973_Uml_1.png]]

== UI Changes ==
=== Assignment Review Strategy ===
==== Before ====
[[File:E1973_Editing_before.png]]

==== After ====
[[File:E1973_Editing_after.png]]

=== Assign Reviewers ===
==== Before ====
[[File:E1973_Participants_before.png]]

==== After ====
[[File:E1973_Participants_after.png]]

== Test Plan ==
=== Rspec ===
Our primary purpose for rspec testing will involve ensuring that we haven't broken any existing functionality.
Since our new functionality doesn't involve any model/view/controller additions, our tests will be appended to existing rspec tests inside of:

* assignments_controller_spec.rb
* response_controller_spec.rb
* review_mapping_controller_spec.rb

The new functionality we need to test should primarily ensure that:

* Students on the same team can see each other's review responses
* No two students can edit a review at the same time
* Reviews submitted by teams are treated identically to reviews submitted by individuals

=== UI Testing ===

Our UI tests aim to capture the following core pieces of functionality: 

'''Students on the same team can view/edit the same response: '''

''Prerequisites: instructor6, student7339, student7340, and student7341 exist in the system. This test assumes student7340 and 7341 are on a team. ''
# Login as instructor6 with password "password".
# Navigate to Manage -> Assignments and click to add a new assignment.
# Fill in the neccessary fields for rubrics by setting Review to "Peer Review Rubric Example" and Author Feedback to "Area of Focus". Under Review Strategy, check the box "Are Reviewers Teams?". Finally, under Due Dates, set number of rounds to 1. Set due dates such that all are in the future. Make sure to give the assignment a unique name you will remember.
# Click back to return to the manage assignments page. Then, click add participants on the assignment you have created. Add student7339 and student7340 to the assignment with the role as participant.
# Logout and log in as student7339 (password is "password").
# Click on the assignment you created as instructor, and select "Your work". Upload a random link, such as "google.com". Click submit.
# Repeat steps 5 through 7, except with student7340 (password is "password").
# Logout and login as instructor6. Navigate to Manage -> Assignment and edit the assignment you created previously.
# Set the assignment's submission1 date to yesterday and submit. This will allow other students to update the assignment.
# Logout and login as student7340.
# Now navigate to the assignment, and click "Other's work". Select "Request new review". Click "Begin" on the review.
# Fill in dummy values for the review, and click save review.
# Logout and login as student7341 (password is "password").
# Navigate to the assignment, and click "Other's work". You should be able to see the review response that student7340 was working on. Click on view.
# Verify that the information is the same as it entered by student7340.
# Click back and then click edit on the review response. Verify that the proper information is prefilled here too. Make a change to one of the response boxes.
# Logout and login as student7340. Navigate back to the review response and click "View".
# Verify that the changes made by student7341 are present in the response.

 
'''Students cannot edit the response at the same time: '''
''Prerequisites: Same as the above test.''
# Repeat steps 1-11 (inclusive) from the above test. 
# Open another browser and navigate to Expertiza. Then, login as student7341. 
# Navigate to the assignment and click "Edit". Verify that you are redirected and unable to edit the review response since student7340 is already editing it. 
# Try clicking "View". Verify that you are unable to view the review response here either.

CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

2019-12-06T20:44:19Z

Smyoder: /* Code Changes */

== Introduction - Purpose & Problem ==
Currently, reviews of other student’s work can only be performed by individual students in Expertiza, not by groups of students. Since doing reviews together could help students learn more than by doing them alone, it has been requested that reviews must now have the option to be done by teams instead of individual participants. Therefore, there should be an option when creating assignments that allows the creator to select whether the assignment will use team reviewers or individual reviewers. For simplification, we were allowed to assume that the teams that worked on an assignment together would review together. Each participant should be able to make individual changes to the review (while logged in from their account), but these changes should apply to the team’s collective review. This creates an issue where teammates could accidentally overwrite each other’s work if they edit the review at once. Therefore, it has been decided that the review should be locked while one edits it so that only one participant can edit it at once. Locking the review presents its own challenges.

== Proposed Solution ==
* Modification to Response Map Classes
** A field should be added to ResponseMap which indicates whether responses are done by teams or by individuals.
* Modification to Assignment Class
** A field indicating if the assignment is to be done with team or individuals. This is necessary because part of the suggested requirements is to add a drop down on the review strategy section of the assignment.
* Locking Solution
** Research needs to be done as to whether a rails mechanism already exists to facilitate a lock on page edits
** A solution can be implemented from scratch by storing a flag in the database on the review’s table entry. This would require an additional migration.
**The ability to have a lock on a review requires the implementation of some kind of auto-unlock feature. If a user never unlocks a review, his/her teammates still need to be able to modify the review.
*** We should be able to use the “updated at” field to check if the lock has been held for too long and needs to be released.

== More on Locks ==
The locking solution we added works as a general locking solution. It adds a new table in the database called locks which create a mapping between a user and a resource. This database change does not force a lock on the resource. Just because there exists a lock between some resource and some user, does not mean that other users cannot edit that resource. The actual prevention of edits, be it redirecting or preventing access to controller methods, is the responsibility of you, the programmer. This class just provides an easy interface to facilitate that behavior.

=== Database Changes ===
Locks created the following changes:
* locks
** timeout_period
** created_at
** updated_at
** user_id
** lockable_id
** lockable_type

=== Code Changes ===
[[File:E1973_lock_uml.png]]

== Changes to Code ==
* review_response_map.rb (migration required)
** Field - reviewer_is_team: boolean
* review_mapping_controller.rb - update the following methods to use AssignmentTeam as well as AssignmentParticipant as the reviewer
** automatic_review_mapping()
** add_calibration()
** assign_reviewer_dynamically()
** get_reviewer()
* assignment.rb (migration required)
** Field - has_team_reviews: boolean
* assignment_controller.rb
** update new() and create() methods to handle new field has_team_reviews
* assignment ui files - add check box for has_team_reviews

== Changes Represented in UML ==
[[File:E1973_Uml_1.png]]

== UI Changes ==
=== Assignment Review Strategy ===
==== Before ====
[[File:E1973_Editing_before.png]]

==== After ====
[[File:E1973_Editing_after.png]]

=== Assign Reviewers ===
==== Before ====
[[File:E1973_Participants_before.png]]

==== After ====
[[File:E1973_Participants_after.png]]

== Test Plan ==
=== Rspec ===
Our primary purpose for rspec testing will involve ensuring that we haven't broken any existing functionality.
Since our new functionality doesn't involve any model/view/controller additions, our tests will be appended to existing rspec tests inside of:

* assignments_controller_spec.rb
* response_controller_spec.rb
* review_mapping_controller_spec.rb

The new functionality we need to test should primarily ensure that:

* Students on the same team can see each other's review responses
* No two students can edit a review at the same time
* Reviews submitted by teams are treated identically to reviews submitted by individuals

=== UI Testing ===

Our UI tests aim to capture the following core pieces of functionality: 

'''Students on the same team can view/edit the same response: '''

''Prerequisites: instructor6, student7339, student7340, and student7341 exist in the system. This test assumes student7340 and 7341 are on a team. ''
# Login as instructor6 with password "password".
# Navigate to Manage -> Assignments and click to add a new assignment.
# Fill in the neccessary fields for rubrics by setting Review to "Peer Review Rubric Example" and Author Feedback to "Area of Focus". Under Review Strategy, check the box "Are Reviewers Teams?". Finally, under Due Dates, set number of rounds to 1. Set due dates such that all are in the future. Make sure to give the assignment a unique name you will remember.
# Click back to return to the manage assignments page. Then, click add participants on the assignment you have created. Add student7339 and student7340 to the assignment with the role as participant.
# Logout and log in as student7339 (password is "password").
# Click on the assignment you created as instructor, and select "Your work". Upload a random link, such as "google.com". Click submit.
# Repeat steps 5 through 7, except with student7340 (password is "password").
# Logout and login as instructor6. Navigate to Manage -> Assignment and edit the assignment you created previously.
# Set the assignment's submission1 date to yesterday and submit. This will allow other students to update the assignment.
# Logout and login as student7340.
# Now navigate to the assignment, and click "Other's work". Select "Request new review". Click "Begin" on the review.
# Fill in dummy values for the review, and click save review.
# Logout and login as student7341 (password is "password").
# Navigate to the assignment, and click "Other's work". You should be able to see the review response that student7340 was working on. Click on view.
# Verify that the information is the same as it entered by student7340.
# Click back and then click edit on the review response. Verify that the proper information is prefilled here too. Make a change to one of the response boxes.
# Logout and login as student7340. Navigate back to the review response and click "View".
# Verify that the changes made by student7341 are present in the response.

 
'''Students cannot edit the response at the same time: '''
''Prerequisites: Same as the above test.''
# Repeat steps 1-11 (inclusive) from the above test. 
# Open another browser and navigate to Expertiza. Then, login as student7341. 
# Navigate to the assignment and click "Edit". Verify that you are redirected and unable to edit the review response since student7340 is already editing it. 
# Try clicking "View". Verify that you are unable to view the review response here either.

File:E1973 lock uml.png

2019-12-06T20:43:32Z

Smyoder:

CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

2019-12-06T20:34:36Z

Smyoder: /* More on Locks */

== Introduction - Purpose & Problem ==
Currently, reviews of other student’s work can only be performed by individual students in Expertiza, not by groups of students. Since doing reviews together could help students learn more than by doing them alone, it has been requested that reviews must now have the option to be done by teams instead of individual participants. Therefore, there should be an option when creating assignments that allows the creator to select whether the assignment will use team reviewers or individual reviewers. For simplification, we were allowed to assume that the teams that worked on an assignment together would review together. Each participant should be able to make individual changes to the review (while logged in from their account), but these changes should apply to the team’s collective review. This creates an issue where teammates could accidentally overwrite each other’s work if they edit the review at once. Therefore, it has been decided that the review should be locked while one edits it so that only one participant can edit it at once. Locking the review presents its own challenges.

== Proposed Solution ==
* Modification to Response Map Classes
** A field should be added to ResponseMap which indicates whether responses are done by teams or by individuals.
* Modification to Assignment Class
** A field indicating if the assignment is to be done with team or individuals. This is necessary because part of the suggested requirements is to add a drop down on the review strategy section of the assignment.
* Locking Solution
** Research needs to be done as to whether a rails mechanism already exists to facilitate a lock on page edits
** A solution can be implemented from scratch by storing a flag in the database on the review’s table entry. This would require an additional migration.
**The ability to have a lock on a review requires the implementation of some kind of auto-unlock feature. If a user never unlocks a review, his/her teammates still need to be able to modify the review.
*** We should be able to use the “updated at” field to check if the lock has been held for too long and needs to be released.

== More on Locks ==
The locking solution we added works as a general locking solution. It adds a new table in the database called locks which create a mapping between a user and a resource. This database change does not force a lock on the resource. Just because there exists a lock between some resource and some user, does not mean that other users cannot edit that resource. The actual prevention of edits, be it redirecting or preventing access to controller methods, is the responsibility of you, the programmer. This class just provides an easy interface to facilitate that behavior.

=== Database Changes ===
Locks created the following changes:
* locks
** timeout_period
** created_at
** updated_at
** user_id
** lockable_id
** lockable_type

=== Code Changes ===

== Changes to Code ==
* review_response_map.rb (migration required)
** Field - reviewer_is_team: boolean
* review_mapping_controller.rb - update the following methods to use AssignmentTeam as well as AssignmentParticipant as the reviewer
** automatic_review_mapping()
** add_calibration()
** assign_reviewer_dynamically()
** get_reviewer()
* assignment.rb (migration required)
** Field - has_team_reviews: boolean
* assignment_controller.rb
** update new() and create() methods to handle new field has_team_reviews
* assignment ui files - add check box for has_team_reviews

== Changes Represented in UML ==
[[File:E1973_Uml_1.png]]

== UI Changes ==
=== Assignment Review Strategy ===
==== Before ====
[[File:E1973_Editing_before.png]]

==== After ====
[[File:E1973_Editing_after.png]]

=== Assign Reviewers ===
==== Before ====
[[File:E1973_Participants_before.png]]

==== After ====
[[File:E1973_Participants_after.png]]

== Test Plan ==
=== Rspec ===
Our primary purpose for rspec testing will involve ensuring that we haven't broken any existing functionality.
Since our new functionality doesn't involve any model/view/controller additions, our tests will be appended to existing rspec tests inside of:

* assignments_controller_spec.rb
* response_controller_spec.rb
* review_mapping_controller_spec.rb

The new functionality we need to test should primarily ensure that:

* Students on the same team can see each other's review responses
* No two students can edit a review at the same time
* Reviews submitted by teams are treated identically to reviews submitted by individuals

=== UI Testing ===

Our UI tests aim to capture the following core pieces of functionality: 

'''Students on the same team can view/edit the same response: '''

''Prerequisites: instructor6, student7339, student7340, and student7341 exist in the system. This test assumes student7340 and 7341 are on a team. ''
# Login as instructor6 with password "password".
# Navigate to Manage -> Assignments and click to add a new assignment.
# Fill in the neccessary fields for rubrics by setting Review to "Peer Review Rubric Example" and Author Feedback to "Area of Focus". Under Review Strategy, check the box "Are Reviewers Teams?". Finally, under Due Dates, set number of rounds to 1. Set due dates such that all are in the future. Make sure to give the assignment a unique name you will remember.
# Click back to return to the manage assignments page. Then, click add participants on the assignment you have created. Add student7339 and student7340 to the assignment with the role as participant.
# Logout and log in as student7339 (password is "password").
# Click on the assignment you created as instructor, and select "Your work". Upload a random link, such as "google.com". Click submit.
# Repeat steps 5 through 7, except with student7340 (password is "password").
# Logout and login as instructor6. Navigate to Manage -> Assignment and edit the assignment you created previously.
# Set the assignment's submission1 date to yesterday and submit. This will allow other students to update the assignment.
# Logout and login as student7340.
# Now navigate to the assignment, and click "Other's work". Select "Request new review". Click "Begin" on the review.
# Fill in dummy values for the review, and click save review.
# Logout and login as student7341 (password is "password").
# Navigate to the assignment, and click "Other's work". You should be able to see the review response that student7340 was working on. Click on view.
# Verify that the information is the same as it entered by student7340.
# Click back and then click edit on the review response. Verify that the proper information is prefilled here too. Make a change to one of the response boxes.
# Logout and login as student7340. Navigate back to the review response and click "View".
# Verify that the changes made by student7341 are present in the response.

 
'''Students cannot edit the response at the same time: '''
''Prerequisites: Same as the above test.''
# Repeat steps 1-11 (inclusive) from the above test. 
# Open another browser and navigate to Expertiza. Then, login as student7341. 
# Navigate to the assignment and click "Edit". Verify that you are redirected and unable to edit the review response since student7340 is already editing it. 
# Try clicking "View". Verify that you are unable to view the review response here either.

CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

2019-12-06T20:27:12Z

Smyoder: /* More on Locks */

== Introduction - Purpose & Problem ==
Currently, reviews of other student’s work can only be performed by individual students in Expertiza, not by groups of students. Since doing reviews together could help students learn more than by doing them alone, it has been requested that reviews must now have the option to be done by teams instead of individual participants. Therefore, there should be an option when creating assignments that allows the creator to select whether the assignment will use team reviewers or individual reviewers. For simplification, we were allowed to assume that the teams that worked on an assignment together would review together. Each participant should be able to make individual changes to the review (while logged in from their account), but these changes should apply to the team’s collective review. This creates an issue where teammates could accidentally overwrite each other’s work if they edit the review at once. Therefore, it has been decided that the review should be locked while one edits it so that only one participant can edit it at once. Locking the review presents its own challenges.

== Proposed Solution ==
* Modification to Response Map Classes
** A field should be added to ResponseMap which indicates whether responses are done by teams or by individuals.
* Modification to Assignment Class
** A field indicating if the assignment is to be done with team or individuals. This is necessary because part of the suggested requirements is to add a drop down on the review strategy section of the assignment.
* Locking Solution
** Research needs to be done as to whether a rails mechanism already exists to facilitate a lock on page edits
** A solution can be implemented from scratch by storing a flag in the database on the review’s table entry. This would require an additional migration.
**The ability to have a lock on a review requires the implementation of some kind of auto-unlock feature. If a user never unlocks a review, his/her teammates still need to be able to modify the review.
*** We should be able to use the “updated at” field to check if the lock has been held for too long and needs to be released.

== More on Locks ==
The locking solution we added works as a general locking solution. It adds a new table in the database called locks which create a mapping between a user and a resource. This database change does not force a lock on the resource. Just because there exists a lock between some resource and some user, does not mean that other users cannot edit that resource. The actual prevention of edits, be it redirecting or preventing access to controller methods, is the responsibility of you, the programmer. This class just provides an easy interface to facilitate that behavior.

=== Database Changes ===
Locks created the following changes:
* locks
** timeout_period
** created_at
** updated_at
** user_id
** lockable_id
** lockable_type

== Changes to Code ==
* review_response_map.rb (migration required)
** Field - reviewer_is_team: boolean
* review_mapping_controller.rb - update the following methods to use AssignmentTeam as well as AssignmentParticipant as the reviewer
** automatic_review_mapping()
** add_calibration()
** assign_reviewer_dynamically()
** get_reviewer()
* assignment.rb (migration required)
** Field - has_team_reviews: boolean
* assignment_controller.rb
** update new() and create() methods to handle new field has_team_reviews
* assignment ui files - add check box for has_team_reviews

== Changes Represented in UML ==
[[File:E1973_Uml_1.png]]

== UI Changes ==
=== Assignment Review Strategy ===
==== Before ====
[[File:E1973_Editing_before.png]]

==== After ====
[[File:E1973_Editing_after.png]]

=== Assign Reviewers ===
==== Before ====
[[File:E1973_Participants_before.png]]

==== After ====
[[File:E1973_Participants_after.png]]

== Test Plan ==
=== Rspec ===
Our primary purpose for rspec testing will involve ensuring that we haven't broken any existing functionality.
Since our new functionality doesn't involve any model/view/controller additions, our tests will be appended to existing rspec tests inside of:

* assignments_controller_spec.rb
* response_controller_spec.rb
* review_mapping_controller_spec.rb

The new functionality we need to test should primarily ensure that:

* Students on the same team can see each other's review responses
* No two students can edit a review at the same time
* Reviews submitted by teams are treated identically to reviews submitted by individuals

=== UI Testing ===

Our UI tests aim to capture the following core pieces of functionality: 

'''Students on the same team can view/edit the same response: '''

''Prerequisites: instructor6, student7339, student7340, and student7341 exist in the system. This test assumes student7340 and 7341 are on a team. ''
# Login as instructor6 with password "password".
# Navigate to Manage -> Assignments and click to add a new assignment.
# Fill in the neccessary fields for rubrics by setting Review to "Peer Review Rubric Example" and Author Feedback to "Area of Focus". Under Review Strategy, check the box "Are Reviewers Teams?". Finally, under Due Dates, set number of rounds to 1. Set due dates such that all are in the future. Make sure to give the assignment a unique name you will remember.
# Click back to return to the manage assignments page. Then, click add participants on the assignment you have created. Add student7339 and student7340 to the assignment with the role as participant.
# Logout and log in as student7339 (password is "password").
# Click on the assignment you created as instructor, and select "Your work". Upload a random link, such as "google.com". Click submit.
# Repeat steps 5 through 7, except with student7340 (password is "password").
# Logout and login as instructor6. Navigate to Manage -> Assignment and edit the assignment you created previously.
# Set the assignment's submission1 date to yesterday and submit. This will allow other students to update the assignment.
# Logout and login as student7340.
# Now navigate to the assignment, and click "Other's work". Select "Request new review". Click "Begin" on the review.
# Fill in dummy values for the review, and click save review.
# Logout and login as student7341 (password is "password").
# Navigate to the assignment, and click "Other's work". You should be able to see the review response that student7340 was working on. Click on view.
# Verify that the information is the same as it entered by student7340.
# Click back and then click edit on the review response. Verify that the proper information is prefilled here too. Make a change to one of the response boxes.
# Logout and login as student7340. Navigate back to the review response and click "View".
# Verify that the changes made by student7341 are present in the response.

 
'''Students cannot edit the response at the same time: '''
''Prerequisites: Same as the above test.''
# Repeat steps 1-11 (inclusive) from the above test. 
# Open another browser and navigate to Expertiza. Then, login as student7341. 
# Navigate to the assignment and click "Edit". Verify that you are redirected and unable to edit the review response since student7340 is already editing it. 
# Try clicking "View". Verify that you are unable to view the review response here either.

CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

2019-12-06T20:18:59Z

Smyoder:

CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

2019-11-15T19:07:16Z

Smyoder: /* Rspec */

CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

2019-11-15T18:54:32Z

Smyoder:

CSC/ECE 517 Fall 2019

2019-11-14T00:03:33Z

Smyoder:

* [[CSC/ECE 517 Fall 2019 - Project E1947. Refactor quiz_questionnaire_controller.rb]]
* [[CSC/ECE 517 Fall 2019 - Project E1965. Review report should link to the usual view for reviews]]
* [[CSC/ECE 517 Fall 2019 - Project E1943. Refactor sign up sheet controller.rb]]
* [[CSC/ECE 517 Fall 2019 - E1972. OSS project J. Skellington: Accessing Assignment Rubrics]]
* [[CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing]]
* [[CSC/ECE 517 Fall 2019 - E1961. Email notification to reviewers and instructors]]
* [[CSC/ECE 517 Fall 2019 - E1971. OSS project Finklestein: Instructors & Institutions]]
* [[CSC/ECE 517 Fall 2019 - E1953. Tagging report for student]]
* [[CSC/ECE 517 Fall 2019 - E1955.Write unit tests for student_task.rb]]
* [[CSC/ECE 517 Fall 2019 - E1954. Auto-generate submission directory names based on assignment names]]
* [[CSC/ECE 517 Fall 2019 - E1958. Two issues related to assignment management]]
* [[CSC/ECE 517 Fall 2019 - E1948. Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Fall 2019 - E1959. Intelligent copying of assignments without topics]]
* [[CSC/ECE 517 Fall 2019 - E1968. Fixes for adding members to teams]]
* [[CSC/ECE 517 Fall 2019 - E1969. Fixes for reviews not being available]]
* [[CSC/ECE 517 Fall 2019 - E1951. Remove multiple topics at a time]]
* [[CSC/ECE 517 Fall 2019 - E1957. Time travel Not Allowed..!!! Restrict TAs’ ability to change their own grade + limit file-size upload]]
* [[CSC/ECE 517 Fall 2019 - E1963. Changing assignment participant role]]
* [[CSC/ECE 517 Fall 2019 - E1941. Issues related to topic deadlines]]
* [[CSC/ECE 517 Fall 2019 - E1966. Tabbed_reviews partial file refactor for displaying the alternate view of reviews]]
* [[CSC/ECE 517 Fall 2019 - E1962. Email notification upon account creation]]
* [[CSC/ECE 517 Fall 2019 - E1967. Fix glitches in author feedback]]
* [[CSC/ECE 517 Fall 2019 - E1960. Create new late policy successfully and fixing "Back" link]]
* [[CSC/ECE 517 Fall 2019 - E1939. OSS Project Juniper: Bookmark enhancements]]
* [[CSC/ECE 517 Fall 2019 - M1950. Support Asynchronous Web Assembly Compilation]]
* [[CSC/ECE 517 Fall 2019 - E1938. OSS project Duke Blue: Fix import glitches]]
* [[CSC/ECE 517 Fall 2019 - E1985. Let course staff and students do reviews]]
* [[CSC/ECE 517 Fall 2019 - M1951. Implement missing OffscreenCanvas APIs]]
* [[CSC/ECE 517 Fall 2019 - E1940. Improving email notification]]
* [[CSC/ECE 517 Fall 2019 - E1956. There is no shortcut to get free review points: Review Assignment Bug]]
* [[CSC/ECE 517 Fall 2019 - E1942. Refactor stage deadlines in assignment.rb]]
* [[CSC/ECE 517 Fall 2019 - M1952. Missing DOM features project]]
* [[CSC/ECE 517 Fall 2019 - E1945. Refactor users_controller.rb]]
* [[CSC/ECE 517 Fall 2019 - E1964. Export review scores for projects]]
* [[CSC/ECE 517 Fall 2019 - E1949. Write Unit Tests for Importing assignment participants and import glitches]]
* [[CSC/ECE 517 Fall 2019 - E1944. Refactor review mapping controller]]
* [[CSC/ECE 517 Fall 2019 - E1946. Refactor Questionnaire controller]]
* [[CSC/ECE 517 Fall 2019 - E1982. Regulate changing of rubrics while projects are in progress]]
* [[CSC/ECE 517 Fall 2019 - E1989. Track the time students look at other submissions]]
* [[CSC/ECE 517 Fall 2019 - E1990. Integrate suggestion detection algorithm]]
* [[CSC/ECE 517 Fall 2019 - E1995. Tests for email functionality]]
* [[CSC/ECE 517 Fall 2019 - E1993 Track Time Between Successive Tag Assignments]]
* [[CSC/ECE 517 Fall 2019 - E1979. Completion/Progress view]]
* [[CSC/ECE 517 Fall 2019 - E1980. Sort instructor reports by name, ID, score, etc.]]
* [[CSC/ECE 517 Fall 2019 - E1983. Refactor E1858, Github metrics integration view]]
* [[CSC/ECE 517 Fall 2019 - E1984. Improve self-review Link peer review & self-review to derive grades]]
* [[CSC/ECE 517 Fall 2019 - E1994. Mentor management for assignments without topics]]
* [[CSC/ECE 517 Fall 2019 - E1997. Issues related to meta-reviewing]]
* [[CSC/ECE 517 Fall 2019 - E1981. Student-generated questions added to rubric]]
* [[CSC/ECE 517 Fall 2019 - E1996. Enhancements to review grader]]
* [[CSC/ECE 517 Fall 2019 - E1987. Improving search facility in Expertiza]]
* [[CSC/ECE 517 Fall 2019 - E1978. Fix issues related to deadlines and late policies]]
* [[CSC/ECE 517 Fall 2019 - E1991. Improvements to anonymized view]]
* [[CSC/ECE 517 Fall 2019 - E1998. Weights in grade calculation]]
* [[CSC/ECE 517 Fall 2019 - E1986. Allow reviewers to bid on what to review]]
* [[CSC/ECE 517 Fall 2019 -E1974 Allow users to create an account and submit work to an ”assignment” Design]]
* [[CSC/ECE 517 Fall 2019 -E1988 Allow reviewer to say review can be shown to class as an example]]
* [[CSC/ECE 517 Fall 2019 - E1975. Generalize Review Versioning]]
* [[CSC/ECE 517 Fall 2019 - E1976. Issues Related to Assignment Creation]]
* [[CSC/ECE 517 Fall 2019 - E1991. Improvements to anonymized view]]
* [[CSC/ECE 517 Fall 2019 - E1992. Add cake type to rubrics design]]

CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

2019-11-14T00:01:26Z

Smyoder: /* Changes Represented in UML */

File:E1973 Participants after.png

2019-11-14T00:01:19Z

Smyoder:

File:E1973 Participants before.png

2019-11-14T00:00:51Z

Smyoder:

File:E1973 Editing after.png

2019-11-13T23:59:50Z

Smyoder:

File:E1973 Editing before.png

2019-11-13T23:59:19Z

Smyoder:

CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

2019-11-13T23:55:09Z

Smyoder: /* Changes to Code */

File:E1973 Uml 1.png

2019-11-13T23:54:52Z

Smyoder:

CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

2019-11-13T23:53:41Z

Smyoder: /* Proposed Solution */

CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

2019-11-13T23:52:34Z

Smyoder: /* Proposed Solution */

CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

2019-11-13T23:51:26Z

Smyoder: /* Proposed Solution */

CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

2019-11-13T23:50:54Z

Smyoder: /* Introduction - Purpose & Problem */

CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

2019-11-13T23:49:28Z

Smyoder: /* Introduction - Purpose & Problem */

CSC/ECE 517 Fall 2019 - Project E1973. Team Based Reviewing

2019-11-13T23:49:12Z

Smyoder: Created page with "== Introduction - Purpose & Problem =="

== Introduction - Purpose & Problem ==

CSC/ECE 517 Fall 2019 - E1953. Tagging report for student

2019-11-07T04:47:22Z

Smyoder: /* Issue 1: Show tagging count for review page */

CSC/ECE 517 Fall 2019 - E1953. Tagging report for student

==Introduction==
===About Expertiza ===
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

===Problem Statement===
The following tasks were accomplished in this project:

* If tagging is enabled, number of total tags per round is shown on student's score page
* Implemented feature which shows number of tags student have entered
* Implemented feature to show number of tags entered and total number of tags in Assignment page.
* Implemented feature to show tagging counts dynamically when student change tagging type in score page
* Added RSPEC testcases for testing changes done for tagging

===About Tagging===
Expertiza has a feature of peer review where other teams can provide feedback on student's work. There is also another feature of "Tags", where a student can answer if the feedback provided were helpful or not. Tags can vary from assignment to assignment but the main motive of it is to provide information on whether the feedback provides helpful information for student's assignment. The picture below shows an example of tags.

[[File:Example-tags.png]]

===Motivation===
For a particular assignment, there may be a lot of questions and hence multiple feedback. Students might miss a few tags and they might go unanswered. This feature will provide students to keep track of answered tags and show them how many tags have they answered out of total tags on the page.

==Design==
For counting, we are primarily concerned with two numbers: the number of possible tags for an assignment and the number of completed tags for an assignment. The latter is easy to calculate as it's directly stored as AnswerTags. The former is more difficult: possible tags are stored as TagPromptDeployments which do not have a 1:1 correspondence to the number of prompts the user sees on their page.

[[File:E1953_UML.png]]

The green classes are used to count the number of tags done, the red classes are used to count the number of tags possible, and the yellow classes are used to calculate both counts. All classes help to narrow the scope to a specific user and assignment.

==Implementation==

=== Task 1 : Count answered tags in an assignment on Assignment Homepage ===

==== Description ====
On clicking of particular Assignment, student can see his/her teams, work, scores, etc. There is no feature which allows student to show how many of the review tags has he/she answered on this page. This task implements this feature where student can see answered tags with respect to total tags in Assignment page.

==== Code Implemented ====
'''app/controllers/student_task_controller.rb'''
- The following code counts the number of Tags present in an assignment and total number of answered tags in that particular assignment.
<pre>
@completed_tags = 0
@total_tags = 0
vmlist.each do |vm|
vm.list_of_rows.each do |r|
r.score_row.each do |row|
vm_prompts = row.vm_prompts.select {|prompt| prompt.tag_dep.tag_prompt.control_type.downcase != "checkbox"}
@total_tags += vm_prompts.count
vm_prompts.each do |vm_prompt|
answer_tag = AnswerTag.where(tag_prompt_deployment_id: vm_prompt.tag_dep, user_id: @participant.user_id, answer: vm_prompt.answer).first
if !answer_tag.nil? and answer_tag.value != "0"
@completed_tags += 1
end
end
end
end
end
</pre>

=== Task 2 : Count answered tags in an assignment per rounds on Summary Report Page ===

==== Description ====
On clicking of particular Assignment>Your Scores> student can see his/her score. Student can also see all the reviews per rounds in particular assignment. This new feature will allow student to see number of answered tags per round with respect to number of total tags present in particular round

==== Code Implemented ====
'''app/controllers/grades_controller.rb'''
- The following code counts the number of Tags present in a round and total number of answered tags in that particular round.
<pre>
@vmlist.each do |vm|
if vm.round == @round
vm.list_of_rows.each do |r|
r.score_row.each do |row|
vm_prompts = row.vm_prompts.select {|prompt| prompt.tag_dep.tag_prompt.control_type.downcase != "checkbox"}
if vm_prompts.count > 0
@total_tags += vm_prompts.count
vm_prompts.each do |vm_prompt|
answer_tag = AnswerTag.where(tag_prompt_deployment_id: vm_prompt.tag_dep, user_id: @participant.user_id, answer: vm_prompt.answer).first
if !answer_tag.nil? and answer_tag.value != "0"
@completed_tags += 1
end
end
end
end
end
end
end
@total_tags_array.append(@total_tags)
@completed_tags_array.append(@completed_tags)
</pre>

=== Task 3 : Per round tag counts should be automatically updated as soon as tags are changed ===

==== Description ====
If a user changes their tags, the page formerly needed to be refreshed in order to display the correct counts. This functionality ensures that the tag counts always accurately reflect the results on the page.

==== Code Implemented ====
'''app/assets/javascripts/answer_tags.js'''
- The following code correctly increments/decrements the tag count on the page based on the user's action.
<pre>
update_tag_count = function(tag_prompt, round_number) {
//Get the previous value of this tag prompt from an HTML attribute
var old_value = tag_prompt.getAttribute('data-prev_value')
//This is the new value of the tag prompt
var new_value = tag_prompt.value
//Store the new value back into the HTML attribute
tag_prompt.setAttribute('data-prev_value', new_value)
//This is the current tag count for the round this tag is in
var current_count = parseInt(document.getElementById('tag_counts_' + (round_number)).innerHTML);
if(old_value != "0" && new_value == "0") {
//The user has reset the value of this tag. Decrement the tag count
document.getElementById('tag_counts_' + round_number).innerHTML = current_count - 1;
} else if(old_value == "0" && new_value != "0"){
//The user has set the value of this tag to something meaningful. Increment the count
document.getElementById('tag_counts_' + round_number).innerHTML = current_count + 1;
}
}
</pre>

==Process==
[[File:E1953_FlowChart2.png]]

==Test Plan==

=== RSpec Tests ===
Please find below RSpec Test cases for this feature

===Issue 1: Show tagging count for Assignment Homepage===
====spec/controllers/student_task_controller_spec.rb====
Follow the below steps to Verify the fix for this issue:

'''Test Case 1'''
<pre>
it "reports zero completed tags correctly" do
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment1, user_id: 1, answer: answer2).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment2, user_id: 1, answer: answer2).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment3, user_id: 1, answer: answer2).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment4, user_id: 1, answer: answer2).and_return([])

allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment1, user_id: 1, answer: answer1).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment2, user_id: 1, answer: answer1).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment3, user_id: 1, answer: answer1).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment4, user_id: 1, answer: answer1).and_return([])
params = {id: 1}
get :view, params
expect(controller.instance_variable_get(:@participant)).to eq(participant)
expect(assigns(:completed_tags)).to eq(0)
expect(assigns(:total_tags)).to eq(6)
end
</pre>

'''Test Case 2'''
<pre>
it "reports some completed tags correctly" do
answer_tags = [AnswerTag.new(value: 0), AnswerTag.new(value: 1), AnswerTag.new(value: -1), AnswerTag.new(value: 1),
AnswerTag.new(value: 1), AnswerTag.new(value: 1), AnswerTag.new(value: -1), AnswerTag.new(value: 0),]

allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment1, user_id: 1, answer: answer2).and_return([answer_tags[0]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment2, user_id: 1, answer: answer2).and_return([answer_tags[1]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment3, user_id: 1, answer: answer2).and_return([answer_tags[2]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment4, user_id: 1, answer: answer2).and_return([answer_tags[3]])

allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment1, user_id: 1, answer: answer1).and_return([answer_tags[4]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment2, user_id: 1, answer: answer1).and_return([answer_tags[5]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment3, user_id: 1, answer: answer1).and_return([answer_tags[6]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment4, user_id: 1, answer: answer1).and_return([answer_tags[7]])
params = {id: 1}
get :view, params
expect(controller.instance_variable_get(:@participant)).to eq(participant)
expect(assigns(:completed_tags)).to eq(5)
expect(assigns(:total_tags)).to eq(6)
end
</pre>

===Issue 2: Show tagging count for review page===
====spec/controllers/grades_controller_spec.rb====
Follow the below steps to Verify the fix for this issue:

'''Test Case 1'''
<pre>
it "reports zero completed tags correctly" do
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment1, user_id: 1, answer: answer2).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment2, user_id: 1, answer: answer2).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment3, user_id: 1, answer: answer2).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment4, user_id: 1, answer: answer2).and_return([])

allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment1, user_id: 1, answer: answer1).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment2, user_id: 1, answer: answer1).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment3, user_id: 1, answer: answer1).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment4, user_id: 1, answer: answer1).and_return([])
params = {id: 1}
get :view_team, params
expect(controller.instance_variable_get(:@participant)).to eq(participant)
expect(assigns(:completed_tags)).to eq(0)
expect(assigns(:total_tags)).to eq(6)
end
</pre>

'''Test Case 2'''
<pre>
it "reports some completed tags correctly" do
answer_tags = [AnswerTag.new(value: 0), AnswerTag.new(value: 1), AnswerTag.new(value: -1), AnswerTag.new(value: 1),
AnswerTag.new(value: 1), AnswerTag.new(value: 1), AnswerTag.new(value: -1), AnswerTag.new(value: 0),]

allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment1, user_id: 1, answer: answer2).and_return([answer_tags[0]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment2, user_id: 1, answer: answer2).and_return([answer_tags[1]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment3, user_id: 1, answer: answer2).and_return([answer_tags[2]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment4, user_id: 1, answer: answer2).and_return([answer_tags[3]])

allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment1, user_id: 1, answer: answer1).and_return([answer_tags[4]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment2, user_id: 1, answer: answer1).and_return([answer_tags[5]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment3, user_id: 1, answer: answer1).and_return([answer_tags[6]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment4, user_id: 1, answer: answer1).and_return([answer_tags[7]])
params = {id: 1}
get :view_team, params
expect(controller.instance_variable_get(:@participant)).to eq(participant)
expect(assigns(:completed_tags)).to eq(5)
expect(assigns(:total_tags)).to eq(6)
end
</pre>

=== Regression Tests ===
Since new changes were added to existing function, we ran the existing tests to ensure none of them were failing.

=== Manual Tests ===
We needed to check if the feature implemented were resulting the expected behavior. To test this we followed following steps:-

1. Login as a student

2. Select Assignment for Assignment Home Page

'''Test Case 1'''

This page should show number of tags completed and total tags present including all the rounds in that particular assignment. ✓

'''Test Case 2'''

On selecting Your Scores on Student Task page, Each round should show Review Tagged Column. ✓

'''Test Case 3'''

Review Tagged Column should consist of tags completed and total tags count for that particular round. ✓

'''Test Case 4'''

Review Tagged Column should not consist of tags completed in all rounds and total tags count. ✓

'''Test Case 5'''

Review Tagged Column should dynamically increase or decrease tag count when user change their tagging. ✓

==Deployed Example==
Below are instructions for navigating through expertiza to see the review tags in action.

'''1.''' Go to http://152.46.18.192:8080/ and log in as {username: student7552 password: password}.

'''2.''' After you log in if you are not at the assignments landing page (152.46.18.192:8080//student_task/list) click on Assignments to navigate there.

'''3.''' Click on "Final project (and design doc)" from the list of assignments in the table at the bottom of the page.

'''4.''' Behold the tag counter next to the bullet labeled "Your scores". It reads (You have tagged the available tags completed / total available reviews).

[[File:Assignment-page-tags.png]]

'''5'''. Further, click on "Your scores". On the next page that shows up, click on a row in the table to see the tags. Notice in the last column of the header of the table is a cell containing the available tags completed / total available tags.

[[FIle:Per-round-tags.png‎ ]]

'''6.''' After clicking on a row to reveal tags drag the blue square towards 'No,' 'Yes,' or the middle. Observe that the tags left / total tags has updated.

'''7.''' To observe the new per round tagging capabilities log out and then log in as {username: student8115 password: password}.

'''8.''' Select the first Program 2 from the list of assignments. In the next page click on "Your scores" as in step 4 above. Scroll down and behold tagging statistics for each round in the last column of the table headers.

[[FIle:Per-round-tagging2.png‎ ]]

==Teammates==
Mentor -Akanksha Mohan

* Sameer Adhikari (sadhika2)
* Spencer Yoder (smyoder)
* Mark Trawick (mtrawic)

==References==
# [https://github.com/expertiza/expertiza Github Repository for Expertiza]
# [http://wiki.expertiza.ncsu.edu/index.php/Documentation_on_Database_Tables Expertiza Documentation on Database Tables]
# [https://guides.rubyonrails.org/api_app.html Rails Guide Documentation]

CSC/ECE 517 Fall 2019 - E1953. Tagging report for student

2019-11-07T04:46:55Z

Smyoder: /* Test Plan */

CSC/ECE 517 Fall 2019 - E1953. Tagging report for student

==Introduction==
===About Expertiza ===
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

===Problem Statement===
The following tasks were accomplished in this project:

* If tagging is enabled, number of total tags per round is shown on student's score page
* Implemented feature which shows number of tags student have entered
* Implemented feature to show number of tags entered and total number of tags in Assignment page.
* Implemented feature to show tagging counts dynamically when student change tagging type in score page
* Added RSPEC testcases for testing changes done for tagging

===About Tagging===
Expertiza has a feature of peer review where other teams can provide feedback on student's work. There is also another feature of "Tags", where a student can answer if the feedback provided were helpful or not. Tags can vary from assignment to assignment but the main motive of it is to provide information on whether the feedback provides helpful information for student's assignment. The picture below shows an example of tags.

[[File:Example-tags.png]]

===Motivation===
For a particular assignment, there may be a lot of questions and hence multiple feedback. Students might miss a few tags and they might go unanswered. This feature will provide students to keep track of answered tags and show them how many tags have they answered out of total tags on the page.

==Design==
For counting, we are primarily concerned with two numbers: the number of possible tags for an assignment and the number of completed tags for an assignment. The latter is easy to calculate as it's directly stored as AnswerTags. The former is more difficult: possible tags are stored as TagPromptDeployments which do not have a 1:1 correspondence to the number of prompts the user sees on their page.

[[File:E1953_UML.png]]

The green classes are used to count the number of tags done, the red classes are used to count the number of tags possible, and the yellow classes are used to calculate both counts. All classes help to narrow the scope to a specific user and assignment.

==Implementation==

=== Task 1 : Count answered tags in an assignment on Assignment Homepage ===

==== Description ====
On clicking of particular Assignment, student can see his/her teams, work, scores, etc. There is no feature which allows student to show how many of the review tags has he/she answered on this page. This task implements this feature where student can see answered tags with respect to total tags in Assignment page.

==== Code Implemented ====
'''app/controllers/student_task_controller.rb'''
- The following code counts the number of Tags present in an assignment and total number of answered tags in that particular assignment.
<pre>
@completed_tags = 0
@total_tags = 0
vmlist.each do |vm|
vm.list_of_rows.each do |r|
r.score_row.each do |row|
vm_prompts = row.vm_prompts.select {|prompt| prompt.tag_dep.tag_prompt.control_type.downcase != "checkbox"}
@total_tags += vm_prompts.count
vm_prompts.each do |vm_prompt|
answer_tag = AnswerTag.where(tag_prompt_deployment_id: vm_prompt.tag_dep, user_id: @participant.user_id, answer: vm_prompt.answer).first
if !answer_tag.nil? and answer_tag.value != "0"
@completed_tags += 1
end
end
end
end
end
</pre>

=== Task 2 : Count answered tags in an assignment per rounds on Summary Report Page ===

==== Description ====
On clicking of particular Assignment>Your Scores> student can see his/her score. Student can also see all the reviews per rounds in particular assignment. This new feature will allow student to see number of answered tags per round with respect to number of total tags present in particular round

==== Code Implemented ====
'''app/controllers/grades_controller.rb'''
- The following code counts the number of Tags present in a round and total number of answered tags in that particular round.
<pre>
@vmlist.each do |vm|
if vm.round == @round
vm.list_of_rows.each do |r|
r.score_row.each do |row|
vm_prompts = row.vm_prompts.select {|prompt| prompt.tag_dep.tag_prompt.control_type.downcase != "checkbox"}
if vm_prompts.count > 0
@total_tags += vm_prompts.count
vm_prompts.each do |vm_prompt|
answer_tag = AnswerTag.where(tag_prompt_deployment_id: vm_prompt.tag_dep, user_id: @participant.user_id, answer: vm_prompt.answer).first
if !answer_tag.nil? and answer_tag.value != "0"
@completed_tags += 1
end
end
end
end
end
end
end
@total_tags_array.append(@total_tags)
@completed_tags_array.append(@completed_tags)
</pre>

=== Task 3 : Per round tag counts should be automatically updated as soon as tags are changed ===

==== Description ====
If a user changes their tags, the page formerly needed to be refreshed in order to display the correct counts. This functionality ensures that the tag counts always accurately reflect the results on the page.

==== Code Implemented ====
'''app/assets/javascripts/answer_tags.js'''
- The following code correctly increments/decrements the tag count on the page based on the user's action.
<pre>
update_tag_count = function(tag_prompt, round_number) {
//Get the previous value of this tag prompt from an HTML attribute
var old_value = tag_prompt.getAttribute('data-prev_value')
//This is the new value of the tag prompt
var new_value = tag_prompt.value
//Store the new value back into the HTML attribute
tag_prompt.setAttribute('data-prev_value', new_value)
//This is the current tag count for the round this tag is in
var current_count = parseInt(document.getElementById('tag_counts_' + (round_number)).innerHTML);
if(old_value != "0" && new_value == "0") {
//The user has reset the value of this tag. Decrement the tag count
document.getElementById('tag_counts_' + round_number).innerHTML = current_count - 1;
} else if(old_value == "0" && new_value != "0"){
//The user has set the value of this tag to something meaningful. Increment the count
document.getElementById('tag_counts_' + round_number).innerHTML = current_count + 1;
}
}
</pre>

==Process==
[[File:E1953_FlowChart2.png]]

==Test Plan==

=== RSpec Tests ===
Please find below RSpec Test cases for this feature

===Issue 1: Show tagging count for Assignment Homepage===
====spec/controllers/student_task_controller_spec.rb====
Follow the below steps to Verify the fix for this issue:

'''Test Case 1'''
<pre>
it "reports zero completed tags correctly" do
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment1, user_id: 1, answer: answer2).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment2, user_id: 1, answer: answer2).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment3, user_id: 1, answer: answer2).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment4, user_id: 1, answer: answer2).and_return([])

allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment1, user_id: 1, answer: answer1).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment2, user_id: 1, answer: answer1).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment3, user_id: 1, answer: answer1).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment4, user_id: 1, answer: answer1).and_return([])
params = {id: 1}
get :view, params
expect(controller.instance_variable_get(:@participant)).to eq(participant)
expect(assigns(:completed_tags)).to eq(0)
expect(assigns(:total_tags)).to eq(6)
end
</pre>

'''Test Case 2'''
<pre>
it "reports some completed tags correctly" do
answer_tags = [AnswerTag.new(value: 0), AnswerTag.new(value: 1), AnswerTag.new(value: -1), AnswerTag.new(value: 1),
AnswerTag.new(value: 1), AnswerTag.new(value: 1), AnswerTag.new(value: -1), AnswerTag.new(value: 0),]

allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment1, user_id: 1, answer: answer2).and_return([answer_tags[0]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment2, user_id: 1, answer: answer2).and_return([answer_tags[1]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment3, user_id: 1, answer: answer2).and_return([answer_tags[2]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment4, user_id: 1, answer: answer2).and_return([answer_tags[3]])

allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment1, user_id: 1, answer: answer1).and_return([answer_tags[4]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment2, user_id: 1, answer: answer1).and_return([answer_tags[5]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment3, user_id: 1, answer: answer1).and_return([answer_tags[6]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment4, user_id: 1, answer: answer1).and_return([answer_tags[7]])
params = {id: 1}
get :view, params
expect(controller.instance_variable_get(:@participant)).to eq(participant)
expect(assigns(:completed_tags)).to eq(5)
expect(assigns(:total_tags)).to eq(6)
end
</pre>

===Issue 1: Show tagging count for review page===
====spec/controllers/grades_controller_spec.rb====
Follow the below steps to Verify the fix for this issue:

'''Test Case 1'''
<pre>
it "reports zero completed tags correctly" do
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment1, user_id: 1, answer: answer2).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment2, user_id: 1, answer: answer2).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment3, user_id: 1, answer: answer2).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment4, user_id: 1, answer: answer2).and_return([])

allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment1, user_id: 1, answer: answer1).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment2, user_id: 1, answer: answer1).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment3, user_id: 1, answer: answer1).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment4, user_id: 1, answer: answer1).and_return([])
params = {id: 1}
get :view_team, params
expect(controller.instance_variable_get(:@participant)).to eq(participant)
expect(assigns(:completed_tags)).to eq(0)
expect(assigns(:total_tags)).to eq(6)
end
</pre>

'''Test Case 2'''
<pre>
it "reports some completed tags correctly" do
answer_tags = [AnswerTag.new(value: 0), AnswerTag.new(value: 1), AnswerTag.new(value: -1), AnswerTag.new(value: 1),
AnswerTag.new(value: 1), AnswerTag.new(value: 1), AnswerTag.new(value: -1), AnswerTag.new(value: 0),]

allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment1, user_id: 1, answer: answer2).and_return([answer_tags[0]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment2, user_id: 1, answer: answer2).and_return([answer_tags[1]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment3, user_id: 1, answer: answer2).and_return([answer_tags[2]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment4, user_id: 1, answer: answer2).and_return([answer_tags[3]])

allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment1, user_id: 1, answer: answer1).and_return([answer_tags[4]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment2, user_id: 1, answer: answer1).and_return([answer_tags[5]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment3, user_id: 1, answer: answer1).and_return([answer_tags[6]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment4, user_id: 1, answer: answer1).and_return([answer_tags[7]])
params = {id: 1}
get :view_team, params
expect(controller.instance_variable_get(:@participant)).to eq(participant)
expect(assigns(:completed_tags)).to eq(5)
expect(assigns(:total_tags)).to eq(6)
end
</pre>

=== Regression Tests ===
Since new changes were added to existing function, we ran the existing tests to ensure none of them were failing.

=== Manual Tests ===
We needed to check if the feature implemented were resulting the expected behavior. To test this we followed following steps:-

1. Login as a student

2. Select Assignment for Assignment Home Page

'''Test Case 1'''

This page should show number of tags completed and total tags present including all the rounds in that particular assignment. ✓

'''Test Case 2'''

On selecting Your Scores on Student Task page, Each round should show Review Tagged Column. ✓

'''Test Case 3'''

Review Tagged Column should consist of tags completed and total tags count for that particular round. ✓

'''Test Case 4'''

Review Tagged Column should not consist of tags completed in all rounds and total tags count. ✓

'''Test Case 5'''

Review Tagged Column should dynamically increase or decrease tag count when user change their tagging. ✓

==Deployed Example==
Below are instructions for navigating through expertiza to see the review tags in action.

'''1.''' Go to http://152.46.18.192:8080/ and log in as {username: student7552 password: password}.

'''2.''' After you log in if you are not at the assignments landing page (152.46.18.192:8080//student_task/list) click on Assignments to navigate there.

'''3.''' Click on "Final project (and design doc)" from the list of assignments in the table at the bottom of the page.

'''4.''' Behold the tag counter next to the bullet labeled "Your scores". It reads (You have tagged the available tags completed / total available reviews).

[[File:Assignment-page-tags.png]]

'''5'''. Further, click on "Your scores". On the next page that shows up, click on a row in the table to see the tags. Notice in the last column of the header of the table is a cell containing the available tags completed / total available tags.

[[FIle:Per-round-tags.png‎ ]]

'''6.''' After clicking on a row to reveal tags drag the blue square towards 'No,' 'Yes,' or the middle. Observe that the tags left / total tags has updated.

'''7.''' To observe the new per round tagging capabilities log out and then log in as {username: student8115 password: password}.

'''8.''' Select the first Program 2 from the list of assignments. In the next page click on "Your scores" as in step 4 above. Scroll down and behold tagging statistics for each round in the last column of the table headers.

[[FIle:Per-round-tagging2.png‎ ]]

==Teammates==
Mentor -Akanksha Mohan

* Sameer Adhikari (sadhika2)
* Spencer Yoder (smyoder)
* Mark Trawick (mtrawic)

==References==
# [https://github.com/expertiza/expertiza Github Repository for Expertiza]
# [http://wiki.expertiza.ncsu.edu/index.php/Documentation_on_Database_Tables Expertiza Documentation on Database Tables]
# [https://guides.rubyonrails.org/api_app.html Rails Guide Documentation]

CSC/ECE 517 Fall 2019 - E1953. Tagging report for student

2019-11-07T03:52:49Z

Smyoder: /* Test Plan */

CSC/ECE 517 Fall 2019 - E1953. Tagging report for student

==Introduction==
===About Expertiza ===
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

===Problem Statement===
The following tasks were accomplished in this project:

* If tagging is enabled, number of total tags per round is shown on student's score page
* Implemented feature which shows number of tags student have entered
* Implemented feature to show number of tags entered and total number of tags in Assignment page.
* Implemented feature to show tagging counts dynamically when student change tagging type in score page
* Added RSPEC testcases for testing changes done for tagging

===About Tagging===
Expertiza has a feature of peer review where other teams can provide feedback on student's work. There is also another feature of "Tags", where a student can answer if the feedback provided were helpful or not. Tags can vary from assignment to assignment but the main motive of it is to provide information on whether the feedback provides helpful information for student's assignment. The picture below shows an example of tags.

[[File:Example-tags.png]]

===Motivation===
For a particular assignment, there may be a lot of questions and hence multiple feedback. Students might miss a few tags and they might go unanswered. This feature will provide students to keep track of answered tags and show them how many tags have they answered out of total tags on the page.

==Design==
For counting, we are primarily concerned with two numbers: the number of possible tags for an assignment and the number of completed tags for an assignment. The latter is easy to calculate as it's directly stored as AnswerTags. The former is more difficult: possible tags are stored as TagPromptDeployments which do not have a 1:1 correspondence to the number of prompts the user sees on their page.

[[File:E1953_UML.png]]

The green classes are used to count the number of tags done, the red classes are used to count the number of tags possible, and the yellow classes are used to calculate both counts. All classes help to narrow the scope to a specific user and assignment.

==Implementation==

=== Task 1 : Count answered tags in an assignment on Assignment Homepage ===

==== Description ====
On clicking of particular Assignment, student can see his/her teams, work, scores, etc. There is no feature which allows student to show how many of the review tags has he/she answered on this page. This task implements this feature where student can see answered tags with respect to total tags in Assignment page.

==== Code Implemented ====
'''app/controllers/student_task_controller.rb'''
- The following code counts the number of Tags present in an assignment and total number of answered tags in that particular assignment.
<pre>
@completed_tags = 0
@total_tags = 0
vmlist.each do |vm|
vm.list_of_rows.each do |r|
r.score_row.each do |row|
vm_prompts = row.vm_prompts.select {|prompt| prompt.tag_dep.tag_prompt.control_type.downcase != "checkbox"}
@total_tags += vm_prompts.count
vm_prompts.each do |vm_prompt|
answer_tag = AnswerTag.where(tag_prompt_deployment_id: vm_prompt.tag_dep, user_id: @participant.user_id, answer: vm_prompt.answer).first
if !answer_tag.nil? and answer_tag.value != "0"
@completed_tags += 1
end
end
end
end
end
</pre>

=== Task 2 : Count answered tags in an assignment per rounds on Summary Report Page ===

==== Description ====
On clicking of particular Assignment>Your Scores> student can see his/her score. Student can also see all the reviews per rounds in particular assignment. This new feature will allow student to see number of answered tags per round with respect to number of total tags present in particular round

==== Code Implemented ====
'''app/controllers/grades_controller.rb'''
- The following code counts the number of Tags present in a round and total number of answered tags in that particular round.
<pre>
@vmlist.each do |vm|
if vm.round == @round
vm.list_of_rows.each do |r|
r.score_row.each do |row|
vm_prompts = row.vm_prompts.select {|prompt| prompt.tag_dep.tag_prompt.control_type.downcase != "checkbox"}
if vm_prompts.count > 0
@total_tags += vm_prompts.count
vm_prompts.each do |vm_prompt|
answer_tag = AnswerTag.where(tag_prompt_deployment_id: vm_prompt.tag_dep, user_id: @participant.user_id, answer: vm_prompt.answer).first
if !answer_tag.nil? and answer_tag.value != "0"
@completed_tags += 1
end
end
end
end
end
end
end
@total_tags_array.append(@total_tags)
@completed_tags_array.append(@completed_tags)
</pre>

=== Task 3 : Per round tag counts should be automatically updated as soon as tags are changed ===

==== Description ====
If a user changes their tags, the page formerly needed to be refreshed in order to display the correct counts. This functionality ensures that the tag counts always accurately reflect the results on the page.

==== Code Implemented ====
'''app/assets/javascripts/answer_tags.js'''
- The following code correctly increments/decrements the tag count on the page based on the user's action.
<pre>
update_tag_count = function(tag_prompt, round_number) {
//Get the previous value of this tag prompt from an HTML attribute
var old_value = tag_prompt.getAttribute('data-prev_value')
//This is the new value of the tag prompt
var new_value = tag_prompt.value
//Store the new value back into the HTML attribute
tag_prompt.setAttribute('data-prev_value', new_value)
//This is the current tag count for the round this tag is in
var current_count = parseInt(document.getElementById('tag_counts_' + (round_number)).innerHTML);
if(old_value != "0" && new_value == "0") {
//The user has reset the value of this tag. Decrement the tag count
document.getElementById('tag_counts_' + round_number).innerHTML = current_count - 1;
} else if(old_value == "0" && new_value != "0"){
//The user has set the value of this tag to something meaningful. Increment the count
document.getElementById('tag_counts_' + round_number).innerHTML = current_count + 1;
}
}
</pre>

==Process==
[[File:E1953_FlowChart2.png]]

==Test Plan==

=== RSpec Tests ===
Please find below RSpec Test cases for this feature

===Issue 1: Show tagging count for Assignment Homepage===
Follow the below steps to Verify the fix for this issue:

'''Test Case 1'''
<pre>
it "reports zero completed tags correctly" do
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment1, user_id: 1, answer: answer2).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment2, user_id: 1, answer: answer2).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment3, user_id: 1, answer: answer2).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment4, user_id: 1, answer: answer2).and_return([])

allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment1, user_id: 1, answer: answer1).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment2, user_id: 1, answer: answer1).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment3, user_id: 1, answer: answer1).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment4, user_id: 1, answer: answer1).and_return([])
params = {id: 1}
get :view, params
expect(controller.instance_variable_get(:@participant)).to eq(participant)
expect(assigns(:completed_tags)).to eq(0)
expect(assigns(:total_tags)).to eq(6)
end
</pre>

'''Test Case 2'''
<pre>
it "reports some completed tags correctly" do
answer_tags = [AnswerTag.new(value: 0), AnswerTag.new(value: 1), AnswerTag.new(value: -1), AnswerTag.new(value: 1),
AnswerTag.new(value: 1), AnswerTag.new(value: 1), AnswerTag.new(value: -1), AnswerTag.new(value: 0),]

allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment1, user_id: 1, answer: answer2).and_return([answer_tags[0]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment2, user_id: 1, answer: answer2).and_return([answer_tags[1]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment3, user_id: 1, answer: answer2).and_return([answer_tags[2]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment4, user_id: 1, answer: answer2).and_return([answer_tags[3]])

allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment1, user_id: 1, answer: answer1).and_return([answer_tags[4]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment2, user_id: 1, answer: answer1).and_return([answer_tags[5]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment3, user_id: 1, answer: answer1).and_return([answer_tags[6]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment4, user_id: 1, answer: answer1).and_return([answer_tags[7]])
params = {id: 1}
get :view, params
expect(controller.instance_variable_get(:@participant)).to eq(participant)
expect(assigns(:completed_tags)).to eq(5)
expect(assigns(:total_tags)).to eq(6)
end
</pre>

=== Regression Tests ===
Since new changes were added to existing function, we ran the existing tests to ensure none of them were failing.

=== Manual Tests ===
We needed to check if the feature implemented were resulting the expected behavior. To test this we followed following steps:-

1. Login as a student

2. Select Assignment for Assignment Home Page

'''Test Case 1'''

This page should show number of tags completed and total tags present including all the rounds in that particular assignment. ✓

'''Test Case 2'''

On selecting Your Scores on Student Task page, Each round should show Review Tagged Column. ✓

'''Test Case 3'''

Review Tagged Column should consist of tags completed and total tags count for that particular round. ✓

'''Test Case 4'''

Review Tagged Column should not consist of tags completed in all rounds and total tags count. ✓

'''Test Case 5'''

Review Tagged Column should dynamically increase or decrease tag count when user change their tagging. ✓

==Deployed Example==
Below are instructions for navigating through expertiza to see the review tags in action.

'''1.''' Go to http://152.46.18.192:8080/ and log in as {username: student7552 password: password}.

'''2.''' After you log in if you are not at the assignments landing page (152.46.18.192:8080//student_task/list) click on Assignments to navigate there.

'''3.''' Click on "Final project (and design doc)" from the list of assignments in the table at the bottom of the page.

'''4.''' Behold the tag counter next to the bullet labeled "Your scores". It reads (You have tagged the available tags completed / total available reviews).

[[File:Assignment-page-tags.png]]

'''5'''. Further, click on "Your scores". On the next page that shows up, click on a row in the table to see the tags. Notice in the last column of the header of the table is a cell containing the available tags completed / total available tags.

[[FIle:Per-round-tags.png‎ ]]

'''6.''' After clicking on a row to reveal tags drag the blue square towards 'No,' 'Yes,' or the middle. Observe that the tags left / total tags has updated.

'''7.''' To observe the new per round tagging capabilities log out and then log in as {username: student8115 password: password}.

'''8.''' Select the first Program 2 from the list of assignments. In the next page click on "Your scores" as in step 4 above. Scroll down and behold tagging statistics for each round in the last column of the table headers.

[[FIle:Per-round-tagging2.png‎ ]]

==Teammates==
Mentor -Akanksha Mohan

* Sameer Adhikari (sadhika2)
* Spencer Yoder (smyoder)
* Mark Trawick (mtrawic)

==References==
# [https://github.com/expertiza/expertiza Github Repository for Expertiza]
# [http://wiki.expertiza.ncsu.edu/index.php/Documentation_on_Database_Tables Expertiza Documentation on Database Tables]
# [https://guides.rubyonrails.org/api_app.html Rails Guide Documentation]

CSC/ECE 517 Fall 2019 - E1953. Tagging report for student

2019-11-07T03:52:23Z

Smyoder: /* Test Plan */

CSC/ECE 517 Fall 2019 - E1953. Tagging report for student

==Introduction==
===About Expertiza ===
[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

===Problem Statement===
The following tasks were accomplished in this project:

* If tagging is enabled, number of total tags per round is shown on student's score page
* Implemented feature which shows number of tags student have entered
* Implemented feature to show number of tags entered and total number of tags in Assignment page.
* Implemented feature to show tagging counts dynamically when student change tagging type in score page
* Added RSPEC testcases for testing changes done for tagging

===About Tagging===
Expertiza has a feature of peer review where other teams can provide feedback on student's work. There is also another feature of "Tags", where a student can answer if the feedback provided were helpful or not. Tags can vary from assignment to assignment but the main motive of it is to provide information on whether the feedback provides helpful information for student's assignment. The picture below shows an example of tags.

[[File:Example-tags.png]]

===Motivation===
For a particular assignment, there may be a lot of questions and hence multiple feedback. Students might miss a few tags and they might go unanswered. This feature will provide students to keep track of answered tags and show them how many tags have they answered out of total tags on the page.

==Design==
For counting, we are primarily concerned with two numbers: the number of possible tags for an assignment and the number of completed tags for an assignment. The latter is easy to calculate as it's directly stored as AnswerTags. The former is more difficult: possible tags are stored as TagPromptDeployments which do not have a 1:1 correspondence to the number of prompts the user sees on their page.

[[File:E1953_UML.png]]

The green classes are used to count the number of tags done, the red classes are used to count the number of tags possible, and the yellow classes are used to calculate both counts. All classes help to narrow the scope to a specific user and assignment.

==Implementation==

=== Task 1 : Count answered tags in an assignment on Assignment Homepage ===

==== Description ====
On clicking of particular Assignment, student can see his/her teams, work, scores, etc. There is no feature which allows student to show how many of the review tags has he/she answered on this page. This task implements this feature where student can see answered tags with respect to total tags in Assignment page.

==== Code Implemented ====
'''app/controllers/student_task_controller.rb'''
- The following code counts the number of Tags present in an assignment and total number of answered tags in that particular assignment.
<pre>
@completed_tags = 0
@total_tags = 0
vmlist.each do |vm|
vm.list_of_rows.each do |r|
r.score_row.each do |row|
vm_prompts = row.vm_prompts.select {|prompt| prompt.tag_dep.tag_prompt.control_type.downcase != "checkbox"}
@total_tags += vm_prompts.count
vm_prompts.each do |vm_prompt|
answer_tag = AnswerTag.where(tag_prompt_deployment_id: vm_prompt.tag_dep, user_id: @participant.user_id, answer: vm_prompt.answer).first
if !answer_tag.nil? and answer_tag.value != "0"
@completed_tags += 1
end
end
end
end
end
</pre>

=== Task 2 : Count answered tags in an assignment per rounds on Summary Report Page ===

==== Description ====
On clicking of particular Assignment>Your Scores> student can see his/her score. Student can also see all the reviews per rounds in particular assignment. This new feature will allow student to see number of answered tags per round with respect to number of total tags present in particular round

==== Code Implemented ====
'''app/controllers/grades_controller.rb'''
- The following code counts the number of Tags present in a round and total number of answered tags in that particular round.
<pre>
@vmlist.each do |vm|
if vm.round == @round
vm.list_of_rows.each do |r|
r.score_row.each do |row|
vm_prompts = row.vm_prompts.select {|prompt| prompt.tag_dep.tag_prompt.control_type.downcase != "checkbox"}
if vm_prompts.count > 0
@total_tags += vm_prompts.count
vm_prompts.each do |vm_prompt|
answer_tag = AnswerTag.where(tag_prompt_deployment_id: vm_prompt.tag_dep, user_id: @participant.user_id, answer: vm_prompt.answer).first
if !answer_tag.nil? and answer_tag.value != "0"
@completed_tags += 1
end
end
end
end
end
end
end
@total_tags_array.append(@total_tags)
@completed_tags_array.append(@completed_tags)
</pre>

=== Task 3 : Per round tag counts should be automatically updated as soon as tags are changed ===

==== Description ====
If a user changes their tags, the page formerly needed to be refreshed in order to display the correct counts. This functionality ensures that the tag counts always accurately reflect the results on the page.

==== Code Implemented ====
'''app/assets/javascripts/answer_tags.js'''
- The following code correctly increments/decrements the tag count on the page based on the user's action.
<pre>
update_tag_count = function(tag_prompt, round_number) {
//Get the previous value of this tag prompt from an HTML attribute
var old_value = tag_prompt.getAttribute('data-prev_value')
//This is the new value of the tag prompt
var new_value = tag_prompt.value
//Store the new value back into the HTML attribute
tag_prompt.setAttribute('data-prev_value', new_value)
//This is the current tag count for the round this tag is in
var current_count = parseInt(document.getElementById('tag_counts_' + (round_number)).innerHTML);
if(old_value != "0" && new_value == "0") {
//The user has reset the value of this tag. Decrement the tag count
document.getElementById('tag_counts_' + round_number).innerHTML = current_count - 1;
} else if(old_value == "0" && new_value != "0"){
//The user has set the value of this tag to something meaningful. Increment the count
document.getElementById('tag_counts_' + round_number).innerHTML = current_count + 1;
}
}
</pre>

==Process==
[[File:E1953_FlowChart2.png]]

==Test Plan==

=== RSpec Tests ===
Please find below RSpec Test cases for this feature

===Issue 1: Show tagging count for Assignment Homepage===
Follow the below steps to Verify the fix for this issue:

'''Test Case 1'''
<pre>
it "reports zero completed tags correctly" do
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment1, user_id: 1, answer: answer2).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment2, user_id: 1, answer: answer2).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment3, user_id: 1, answer: answer2).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment4, user_id: 1, answer: answer2).and_return([])

allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment1, user_id: 1, answer: answer1).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment2, user_id: 1, answer: answer1).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment3, user_id: 1, answer: answer1).and_return([])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment4, user_id: 1, answer: answer1).and_return([])
params = {id: 1}
get :view, params
expect(controller.instance_variable_get(:@participant)).to eq(participant)
expect(assigns(:completed_tags)).to eq(0)
expect(assigns(:total_tags)).to eq(6)
end
</pre>

'''Test Case 2'''
it "reports some completed tags correctly" do
answer_tags = [AnswerTag.new(value: 0), AnswerTag.new(value: 1), AnswerTag.new(value: -1), AnswerTag.new(value: 1),
AnswerTag.new(value: 1), AnswerTag.new(value: 1), AnswerTag.new(value: -1), AnswerTag.new(value: 0),]

allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment1, user_id: 1, answer: answer2).and_return([answer_tags[0]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment2, user_id: 1, answer: answer2).and_return([answer_tags[1]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment3, user_id: 1, answer: answer2).and_return([answer_tags[2]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment4, user_id: 1, answer: answer2).and_return([answer_tags[3]])

allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment1, user_id: 1, answer: answer1).and_return([answer_tags[4]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment2, user_id: 1, answer: answer1).and_return([answer_tags[5]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment3, user_id: 1, answer: answer1).and_return([answer_tags[6]])
allow(AnswerTag).to receive(:where).with(tag_prompt_deployment_id: deployment4, user_id: 1, answer: answer1).and_return([answer_tags[7]])
params = {id: 1}
get :view, params
expect(controller.instance_variable_get(:@participant)).to eq(participant)
expect(assigns(:completed_tags)).to eq(5)
expect(assigns(:total_tags)).to eq(6)
end

=== Regression Tests ===
Since new changes were added to existing function, we ran the existing tests to ensure none of them were failing.

=== Manual Tests ===
We needed to check if the feature implemented were resulting the expected behavior. To test this we followed following steps:-

1. Login as a student

2. Select Assignment for Assignment Home Page

'''Test Case 1'''

This page should show number of tags completed and total tags present including all the rounds in that particular assignment. ✓

'''Test Case 2'''

On selecting Your Scores on Student Task page, Each round should show Review Tagged Column. ✓

'''Test Case 3'''

Review Tagged Column should consist of tags completed and total tags count for that particular round. ✓

'''Test Case 4'''

Review Tagged Column should not consist of tags completed in all rounds and total tags count. ✓

'''Test Case 5'''

Review Tagged Column should dynamically increase or decrease tag count when user change their tagging. ✓

==Deployed Example==
Below are instructions for navigating through expertiza to see the review tags in action.

'''1.''' Go to http://152.46.18.192:8080/ and log in as {username: student7552 password: password}.

'''2.''' After you log in if you are not at the assignments landing page (152.46.18.192:8080//student_task/list) click on Assignments to navigate there.

'''3.''' Click on "Final project (and design doc)" from the list of assignments in the table at the bottom of the page.

'''4.''' Behold the tag counter next to the bullet labeled "Your scores". It reads (You have tagged the available tags completed / total available reviews).

[[File:Assignment-page-tags.png]]

'''5'''. Further, click on "Your scores". On the next page that shows up, click on a row in the table to see the tags. Notice in the last column of the header of the table is a cell containing the available tags completed / total available tags.

[[FIle:Per-round-tags.png‎ ]]

'''6.''' After clicking on a row to reveal tags drag the blue square towards 'No,' 'Yes,' or the middle. Observe that the tags left / total tags has updated.

'''7.''' To observe the new per round tagging capabilities log out and then log in as {username: student8115 password: password}.

'''8.''' Select the first Program 2 from the list of assignments. In the next page click on "Your scores" as in step 4 above. Scroll down and behold tagging statistics for each round in the last column of the table headers.

[[FIle:Per-round-tagging2.png‎ ]]

==Teammates==
Mentor -Akanksha Mohan

* Sameer Adhikari (sadhika2)
* Spencer Yoder (smyoder)
* Mark Trawick (mtrawic)

==References==
# [https://github.com/expertiza/expertiza Github Repository for Expertiza]
# [http://wiki.expertiza.ncsu.edu/index.php/Documentation_on_Database_Tables Expertiza Documentation on Database Tables]
# [https://guides.rubyonrails.org/api_app.html Rails Guide Documentation]

CSC/ECE 517 Fall 2019 - E1953. Tagging report for student

2019-11-06T21:25:02Z

Smyoder: /* Deployed Example */

CSC/ECE 517 Fall 2019 - E1953. Tagging report for student

2019-11-06T21:23:30Z

Smyoder: /* Implementation */

CSC/ECE 517 Fall 2019 - E1953. Tagging report for student

2019-10-29T01:52:22Z

Smyoder: /* Design */

File:E1953 UML.png

2019-10-29T01:51:55Z

Smyoder: uploaded a new version of "File:E1953 UML.png": A smaller version was uploaded since editing in the page causes the image to not be displayed

This shows the design for project E1953, which involves counting review tags for users. The green classes are used to count the number of tags done by a user whereas the red classes are used to count the number of tags remaining. The yellow classes are used for both.

CSC/ECE 517 Fall 2019 - E1953. Tagging report for student

2019-10-29T01:47:31Z

Smyoder: /* Design */

CSC/ECE 517 Fall 2019 - E1953. Tagging report for student

2019-10-29T01:46:17Z

Smyoder: /* Design */

File:E1953 UML.png

2019-10-29T01:41:17Z

Smyoder: This shows the design for project E1953, which involves counting review tags for users. The green classes are used to count the number of tags done by a user whereas the red classes are used to count the number of tags remaining. The yellow classes are us