CSC/ECE 517 Spring 2019 - Project E1924. Regulate changing of rubrics while projects are in progress

Regulate changing of rubrics while projects are in progress

Expertiza is a web application through which students can submit and peer-review learning objects (articles, code, web sites, etc). It consists of multiple features, one such feature is the ability to setup an assignment by an instructor. While setting up an assignment, the instructor would be asked to choose different kinds of rubrics. Any of these rubrics can later be edited or changed to a different rubric. A problem arises when an assignment is underway (students have already started reviewing) and a rubric is edited or changed. Some students started reviewing with the old rubric and the rest of the students who had not started a review will be presented with the updated rubric. This usually happens when an assignment is copied from a previous year and the rubrics are not updated to match the current topic. It could be at a later point that the instructor/TA realizes this and changes it. The goal of this project is two-fold: One, If a rubric is replaced, or the items/questions are changed, then all the reviews that have been done need to be redone and two, the system should then email the previously done reviews to the reviewer and delete the response object and all associated answer objects.

Setting up and Building the Project

Follow the Guidelines mentioned in the read me page of the project's Wiki Page for building the Project in a Local Environment.

Project Description

Current Scenario

Currently, when an instructor updates a questionnaire rubric of an ongoing assignment, the reviews are not reset and moreover, no notifications are sent to reviewers to update them of the changes made. Moreover, the instructor, post making changes, would have to individually inform each reviewer of the changes made and ask them to change the reviews accordingly.

Expected Solution

The project aims to resolve the two main issue arising from the problems mentioned above:

• If a rubric is replaced, or the items/questions are changed, then all the reviews that have been done need to be redone
• The system should then email the previously done reviews to the reviewer and delete the response object and all associated answer objects.

Further descriptions about how the project will be implemented and what files will be changed are mentioned in subsequent sections.

Design Diagrams

Use case Diagram

Proposed Solution

The solution is divided into 2 phases viz. Identification of edit and Notification.

Identification of edit

When a rubric is submitted after an edit, the update method is called. The current rubric is made such that the question type (Radio/Checkbox/True or False) is not editable, however, the wording of the question can be edited. The questions can be deleted and/or added. We term an edit as major edit if the change involves addition or deletion of a question and a minor edit corresponds to editing any existing questions. The params passed to the controller also includes a tag/identifier if a new question was added. We plan on using this identifier along with the number of questions to identify it the changes made were major or minor.

E-mail Notification

Once this solution finds that the rubric has major edits and there exists some user who has started the response (corresponding records exist), email notification module is initiated. In this phase, these records are pulled from the ActiveRecord and sent to the user through email. Once the email is sent successfully, records are deleted from the DB.

At this stage, the user has all the details already added by them and when they click on "Review", the questions now correspond to the new rubric. This lets the user to edit on the new rubric without losing data for any question. One of the motives behind sending these responses as email is that the first few questions in the review may be similar across rubrics and the user may re-use the same responses when prompted with the new rubric.

Proposed Code Changes

Firstly, we need to check if there has been a change in the questionnaire, i.e if any question has been added or deleted. For this we pull out the records from the active database of the questions and compare it with the number of question entries in the view. We get the number of questions from the code snippet as shown below from questionnare_controller.rb.

Now, we come across two cases. In the first scenario, If there is a change in the number of questions we do the necessary changes. We delete all the response objects and answers and mail the changes to the user.

In the second scenario, If there is no change in the number of questions then there can be two possible cases. Either there really has been no change in the questions and we leave it as it is. Else, there has been equal number of additions and deletions and to detect this we check if the parameter add_new_questions is present. If it is, then there has been an update and we again do the required changes as discussed above. We check this through the code snippet below of the update method in questionnare_controller.rb.

Test Plan

The current rspec file describes various contexts for testing such as adding new questions if attributes weren't correctly entered etc. As stated in the earlier sections, the update method of the questionnaire controller would be edited to identify major changes and trigger emails and deletions of records of responses. A context corresponding to this in the spec file for questionnaire controller under the describe block for update would be added.

At this moment we are thinking of at least 2 new test cases, both these cases correspond to editing a rubric:

1. If there is no new question added and the question id's match with the ones in the record - validate the existence of the record
2. If there is a new question added - assert if the email was sent