CSC/ECE 517 Spring 2019 - Project E1924. Regulate changing of rubrics while projects are in progress
Here is a link to the [| video], which the team emailed to the instructor.
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 who had started reviewing with the old rubric are not notified of the change. Only the rest of the students who had not started a review will be presented with the updated rubric.
The goal of this project is two-fold:
1. If a rubric is replaced, or the items/questions are changed, then all the responses to that rubric need to be redone.
2. The system should then email the previously done reviews to the reviewer and delete the response object and all associated answer objects.
However, if the change does not involve an addition/deletion of questions, it is termed as a minor change. If the change is deemed as a minor change, the refactoring should not make any changes to the current implementation
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. As of status quo, 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
Data Flow Diagram
The main function of the code is to change the rubric questionnaire. There are three main functions to change the rubric of a questionnaire: add, remove or edit questions. Editing a question is considered a minor change as it does not change the general format(i.e. number of questions or their types) of the rubric. The two major changes are highlighted, they are adding or removing a question.
In case of a minor change the question in the database is simply updated, no other action/notification is required.
In case of a major change, the reviews given for that question need to be deleted in case the question has been removed and the consequent changes need to be relayed to the appropriate databases. Moreover, the reviewers, whose reviews have been removed, need to be informed about the changes made and be asked to update the reviews via email. The email-ids for these users have to be queried from the Users database.
Proposed Solution
The solution is divided into 2 phases viz. Identification of edit and Notification.
Identification of edit
The primary metric for identification of a major change is when the ids of questions associated to a questionnaire change. 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. As per the definition of a major change, it is obvious that there is no change in the question ids(records/objects) associated with the questionnaire. Hence this would be a minor change.
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 because it entails a change in the objects associated with the questionnaire. The params passed to the controller also includes a tag/identifier if a new question was added. We are using this tag to identify there was a new question added and hence major change.
In the diagram shown above, the "Save teammate review questionnaire" would result in a minor change. Clicking on the highlighted add and remove would result in a change of the questions and is therefore a major change.
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 respond to 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.
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 use the tags in the params. The view has been coded such that it adds a tag called ":add_new_questions" whenever there is a post method to add a new question. We have used this tag to identify a major change and redirected to necessary helper methods. This is indicated in the image below:
Similarly, we have identified when a question is deleted and redirected again to helper methods.
The next step, is to look iterate through answers database and group the answers for the edited questionnaire per user/reviewer. The below UML diagram would assist in understanding the flow of information and the relation between the models.
Please note that FK stands for foreign key in the above diagram.
Using the question ids returned from view, we obtained the response id from the answer database. We tracked this response id through the response, response_map and user models to arrive at the user id. This has been achieved using the code shown below:
Once we have identified the answers, user mail id and other associated information, this has to be mailed to the user and then the records deleted. This has been achieved using the code shown below:
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.
Currently, we have added two tests:
- To verify whether a new question has been added or not and check whether the corresponding answers in the questionnaire have been appropriately deleted.
- To verify whether a question has been deleted or not and check whether the corresponding answers in the questionnaire have been appropriately deleted.
Team members
1. Aishwarya Tirumala
2. Nilay Kapadia
3. Nitin Nataraj Kuncham
4. Suraj Siddharudh