E1867 allow reviewer to say review can be shown to class as an example: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 123: Line 123:
           %h3{:class=>'col-md-10'} "Reviewed by #{User.find(@reviewer_id).fullname} (Round #{round})"
           %h3{:class=>'col-md-10'} "Reviewed by #{User.find(@reviewer_id).fullname} (Round #{round})"
           %div{:class=>'col-md-2'}
           %div{:class=>'col-md-2'}
             %button{:class=>'col-md-12 mark-unmark-sample-button '+instance_variable_get('@mark_as_sample_'+round.to_s), :data=>{'visibility':2, 'response_id':instance_variable_get('@response_id_round_' + round.to_s),'round':round} } Mark as Sample
             %button{:class=>'col-md-12 mark-unmark-sample-button '+instance_variable_get('@mark_as_sample_'+round.to_s),
             %button{:class=>'col-md-12 mark-unmark-sample-button '+instance_variable_get('@remove_as_sample_'+round.to_s), :data=>{'visibility':3, 'response_id':instance_variable_get('@response_id_round_' + round.to_s),'round':round} } Remove as Sample
:data=>{'visibility':2, 'response_id':instance_variable_get('@response_id_round_' + round.to_s),'round':round} } Mark as Sample
             %button{:class=>'col-md-12 mark-unmark-sample-button '+instance_variable_get('@remove_as_sample_'+round.to_s),
:data=>{'visibility':3, 'response_id':instance_variable_get('@response_id_round_' + round.to_s),'round':round} } Remove as Sample
             %span{:class=>"hide col-md-12 mark-unmark-sample-result", :id=>"mark_unmark_fail_"+round.to_s}
             %span{:class=>"hide col-md-12 mark-unmark-sample-result", :id=>"mark_unmark_fail_"+round.to_s}
             %span{:class=>"hide col-md-12 mark-unmark-sample-result success", :id=>"mark_unmark_success_"+round.to_s}
             %span{:class=>"hide col-md-12 mark-unmark-sample-result success", :id=>"mark_unmark_success_"+round.to_s}
</pre>
</pre>
Clicking on “Mark as Sample” or “Unmark as Sample” changes the visibility of the response to 2 or 3 respectively. Like case 1 mentioned above, this is another situation where the visibility needs to be updated when there is a page event.
Both these cases are event based, and require to make a HTTP request from the browser and handle the response while staying on the same page. Therefore, according to standard practice, an AJAX request must be initiated on click of the button or checkbox. The request needs two parameters - response id, and updated value of visibility. User-identifying data is sent by default in HTTP header cookies (as in any usual HTTP request).
To handle these requests, we have created a sample_reviews controller with a method update_visibility. Within the method, we first check whether the request parameters are valid, and then proceed to check whether the current user (identified by session id) should be allowed to edit the response object to the visibility value passed in the request.
We have validated requests in this manner since HTTP is stateless and requests can easily be cloned (a browser need not be the only client making requests). For example, one could simply copy the request as a cURL, change the session id in the HTTP header to a student’s session, and pass alternative values of visibility (say 2, meaning, approved as sample) in the request. Such requests should be identified as unauthorized requests, while requests which want to update visibility to a value that’s not allowed need to be rejected as bad requests.





Revision as of 14:04, 6 December 2018

Problem Statement

The objective of this project is to:

  1. Add a feature for students to make their reviews 'public', that is, allow other students to view them.
  2. Add a feature for TA to select a subset of 'public' reviews, and make those reviews visible as sample reviews of the particular assignment.
  3. Add a feature for Instructor to select a subset of 'public' reviews and make those reviews visible as sample reviews of any of his/her assignments in the course.
  4. Create a view where the student can see a list of sample reviews of the assignment and have a detailed view of each.
  5. Allow the student to toggle the visibility of a review he/she has submitted.

Approach & Design

  1. Consent to make the review public - add a checkbox and an oncheck event handlers (JS) that sets a new field 'visibility' to public of Response object.
  2. Change the schema of Responses table (add the new column) and write db migrations.
  3. Create new table, model, view, controller for "similar_assignments" and validate CRUD operations that access the table.
  4. Add HTML (checkbox) to uncheck the consent such that the reviews becomes private again.
  5. On the "popup/team_users_popup" page (where instructor/TA can view all reviews), we give a checkbox against every review with public visibility to allow instructors/TAs to select one or more reviews as sample reviews to be available for students.
  6. Once the instructor selects and submits some reviews as sample reviews, we give a popup containing a list of assignments with a checkbox against each of them and a submit button at the end to allow instructors to make sample reviews available for multiple assignments in one go. We perform validation checks also.
  7. On submit of the popup, we update the similar_assignments table.
  8. At the top of student_reviews/list page, we give an option for the student to preview all the available sample reviews.
  9. Create the MVC setup for this new page to list all the sample reviews. Students will be able to click on one particular review and preview it.


DB Design

Currently, the Expertiza database design does not maintain any link between different assignments. An assignment of the current semester is completely independent of any other assignment of any other course having similar or exact objectives. For example, in a course C, the assignment named A1 in a semester Sx has no association to the same assignment given in an earlier semester Sy.

Since our task involves using reviews from the past as samples for the present, we should create this association as a new table. Further, reviews may not be the only intention to associate assignments with each other, as future requirements might require associating them on other criteria too. Thus, we find it appropriate to name the table as "similar_assignments".

The table structure is defined here.

This table can be visualized as a directed graph where vertices represent assignments. An edge (u,v) with a label L means u is similar to v for the intent of association, L.

Consider a row (id = x, assignment_id = Ak, is_similar_for = An, association_intent = "review"). This means, given the intent of association as "review", assignment Ak was chosen as a similar assignment for assignment An. That is, while marking some review for An as a sample, the instructor opted to have reviews of Ak as samples for An as well.

Implementation Details

UML - Use Case Diagram


Power Users: Instructors, TAs, Admins and Super Admins


More details about each point mentioned in the approach section will be updated after the implementation.

Test Plan

As a Power User (TA/Instructor/Admin/Super Admin)

  1. Log in
  2. Click on Manage->Assignments
  3. Displays list of Assignments
  4. Click View Report/Review for a particular assignment.
  5. Displays a list of reviews submitted by students.
  6. Click on any review in "team reviewed" column for a particular student.
  7. Displays the summary of reviews submitted by that student, with a "Make as sample" button on the right of every review.
  8. Click on "Make as sample" for the intended reviews, which opens a popup that displays a list of all assignments that are a part of the instructor's courses.
  9. From this list select all assignments for which the review has to be shown as a sample.
  10. Click on 'Submit' after selection (this closes the popup).
  11. Navigate to view reviews of that particular assignment and click on "Sample Reviews".
  12. A new page is opened that lists out all the sample reviews of the assignment.


As a Student

  1. Log in.
  2. Click on Assignments
  3. List of assignments is displayed.
  4. Click on any assignment for which the review has to be submitted.
  5. Assignment task page is displayed.
  6. Click on "Other's work" to open the reviews summary page (at /student_review).
  7. Below the heading "Reviews for ...", click on the "Show sample reviews" link.
  8. This opens a page where the student can view all sample reviews for that assignment.
  9. Use the browser's back button to go back to Assignment review page.
  10. Chose to review any of the teams' assignments that are displayed.
  11. Select a team for review and fill in the review.
  12. Before submitting the review, select the check box that says "I agree to share this review anonymously as an example to the entire class".
  13. After clicking on the submit button, the review submitted has been made public.

Implementation

We have added a new column in the ‘responses’ table (in the database), namely, ‘visibility’. Visibility can have 4 values as listed below:

We have maintained these constants in a new file at helpers/response_constants.rb.
module ResponseConstants
	def _private
		0
	end

	def in_review
		1
	end

	def approved_as_sample
		2
	end

	def rejected_as_sample
		3
	end
end


In the existing implementation of reviews, when a student starts a review (but hasn’t filled any text or ratings yet), a response gets created in the database. This response has a default visibility of 0.

We have provided a checkbox (a HTML input node with attribute ‘type’ as ‘checkbox’) for the student to consent for his / her review to be used as an example, with values 0 and 1 for unchecked and checked respectively. This value is used to update the response object as part of the form submission.

However, a student might want to remove their consent, or give their consent, for a review that is already submitted. So, in the page where student views his / her own response (link here), we have added the same HTML textbox in filename. On checking or unchecking the checkbox, the visibility field in the corresponding response object in the database needs to be updated. Consider this as case 1.

Now when a power user looks at a review (at url, which is an HTML rendering of a ResponseMap containing Responses), he / she must be able to approve and reject responses which students have consented (offered) to be made visible to all. This is done by providing a button “Mark as Sample” or “Unmark as Sample”. Responses without consent need not have any button.

These HTML changes appear in views/popup/team_users_popup.html.haml

if instance_variable_get('@sample_button_'+round.to_s)
        %div{:class=>'col-md-12 mark-delete-sample '+'round'+round.to_s}
          %h3{:class=>'col-md-10'} "Reviewed by #{User.find(@reviewer_id).fullname} (Round #{round})"
          %div{:class=>'col-md-2'}
            %button{:class=>'col-md-12 mark-unmark-sample-button '+instance_variable_get('@mark_as_sample_'+round.to_s),
 :data=>{'visibility':2, 'response_id':instance_variable_get('@response_id_round_' + round.to_s),'round':round} } Mark as Sample
            %button{:class=>'col-md-12 mark-unmark-sample-button '+instance_variable_get('@remove_as_sample_'+round.to_s),
 :data=>{'visibility':3, 'response_id':instance_variable_get('@response_id_round_' + round.to_s),'round':round} } Remove as Sample
            %span{:class=>"hide col-md-12 mark-unmark-sample-result", :id=>"mark_unmark_fail_"+round.to_s}
            %span{:class=>"hide col-md-12 mark-unmark-sample-result success", :id=>"mark_unmark_success_"+round.to_s}


Clicking on “Mark as Sample” or “Unmark as Sample” changes the visibility of the response to 2 or 3 respectively. Like case 1 mentioned above, this is another situation where the visibility needs to be updated when there is a page event.

Both these cases are event based, and require to make a HTTP request from the browser and handle the response while staying on the same page. Therefore, according to standard practice, an AJAX request must be initiated on click of the button or checkbox. The request needs two parameters - response id, and updated value of visibility. User-identifying data is sent by default in HTTP header cookies (as in any usual HTTP request).

To handle these requests, we have created a sample_reviews controller with a method update_visibility. Within the method, we first check whether the request parameters are valid, and then proceed to check whether the current user (identified by session id) should be allowed to edit the response object to the visibility value passed in the request.

We have validated requests in this manner since HTTP is stateless and requests can easily be cloned (a browser need not be the only client making requests). For example, one could simply copy the request as a cURL, change the session id in the HTTP header to a student’s session, and pass alternative values of visibility (say 2, meaning, approved as sample) in the request. Such requests should be identified as unauthorized requests, while requests which want to update visibility to a value that’s not allowed need to be rejected as bad requests.


Additional Links and References

  1. Link to the Git Pull Request
  2. Expertiza on GitHub
  3. GitHub Project Repository Fork
  4. The Live Expertiza Website

Team

Amogh Agnihotri Subbanna
Chinmai Kaidabettu Srinivas
Siddu Madhure Jayanna
Suhas Naramballi Gururaja