Expertiza_Wiki - User contributions [en]

File:UML diagram.png

2019-05-01T05:11:11Z

Nkuncha:

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

2019-05-01T05:10:40Z

Nkuncha:

''' 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 [https://github.com/expertiza/expertiza/blob/master/README.md 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===

[[File:UseCase_rubric.png|Use Case Diagram]]

===Data Flow Diagram===

[[File:dfd_4.png]]

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.
[[File:edit_questionnaire_page.png|Edit questionnaire page]]
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:

[[File:new_question_added.jpg|identification of major change]]

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.

[[File:UML_diagram.png|UML diagram showing the relationship between necessary 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:

[[File:reviewer_answer_mapping.jpg|grouping of answers per reviewer]]

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:

[[File:mailer_function.jpg|Mailer function and deleting of associated records]]

=='''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:
# 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
# If there is a new question added - assert if the email was sent

=='''Team members'''==
1. Aishwarya Tirumala 
2. Nilay Kapadia 
3. Nitin Nataraj Kuncham 
4. Suraj Siddharudh 

=='''References'''==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://www.rubyguides.com/2018/07/rspec-tutorial/ rpec tutorial]
#[https://www.stackoverflow.com/ Stackoverflow]

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

2019-05-01T05:10:02Z

Nkuncha: added UML diagram

''' 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 [https://github.com/expertiza/expertiza/blob/master/README.md 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===

[[File:UseCase_rubric.png|Use Case Diagram]]

===Data Flow Diagram===

[[File:dfd_4.png]]

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.
[[File:edit_questionnaire_page.png|Edit questionnaire page]]
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:

[[File:new_question_added.jpg|identification of major change]]

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.

[[File:UML.png|UML diagram showing the relationship between necessary 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:

[[File:reviewer_answer_mapping.jpg|grouping of answers per reviewer]]

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:

[[File:mailer_function.jpg|Mailer function and deleting of associated records]]

=='''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:
# 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
# If there is a new question added - assert if the email was sent

=='''Team members'''==
1. Aishwarya Tirumala 
2. Nilay Kapadia 
3. Nitin Nataraj Kuncham 
4. Suraj Siddharudh 

=='''References'''==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://www.rubyguides.com/2018/07/rspec-tutorial/ rpec tutorial]
#[https://www.stackoverflow.com/ Stackoverflow]

File:Mailer function.jpg

2019-05-01T04:54:03Z

Nkuncha:

File:Reviewer answer mapping.jpg

2019-05-01T04:52:59Z

Nkuncha:

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

2019-05-01T04:52:44Z

Nkuncha:

''' 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 [https://github.com/expertiza/expertiza/blob/master/README.md 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===

[[File:UseCase_rubric.png|Use Case Diagram]]

===Data Flow Diagram===

[[File:dfd_4.png]]

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.
[[File:edit_questionnaire_page.png|Edit questionnaire page]]
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:
[[File:new_question_added.jpg|identification of major change]]

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. This has been achieved using the code shown below:
[[File:reviewer_answer_mapping.jpg|grouping of answers per reviewer]]

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:
[[File:mailer_function.jpg|Mailer function and deleting of associated records]]

=='''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:
# 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
# If there is a new question added - assert if the email was sent

=='''Team members'''==
1. Aishwarya Tirumala 
2. Nilay Kapadia 
3. Nitin Nataraj Kuncham 
4. Suraj Siddharudh 

=='''References'''==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://www.rubyguides.com/2018/07/rspec-tutorial/ rpec tutorial]
#[https://www.stackoverflow.com/ Stackoverflow]

File:New question added.jpg

2019-05-01T04:51:51Z

Nkuncha:

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

2019-05-01T04:51:30Z

Nkuncha: code changes updated

''' 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 [https://github.com/expertiza/expertiza/blob/master/README.md 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===

[[File:UseCase_rubric.png|Use Case Diagram]]

===Data Flow Diagram===

[[File:dfd_4.png]]

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.
[[File:edit_questionnaire_page.png|Edit questionnaire page]]
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:
[[File:new_question_added.jpg|identification of major change]]
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. This has been achieved using the code shown below:
[[File:reviewer_answer_mapping.jpg|grouping of answers per reviewer]]

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:
[[File:mailer_function.jpg|Mailer function and deleting of associated records]]

=='''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:
# 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
# If there is a new question added - assert if the email was sent

=='''Team members'''==
1. Aishwarya Tirumala 
2. Nilay Kapadia 
3. Nitin Nataraj Kuncham 
4. Suraj Siddharudh 

=='''References'''==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://www.rubyguides.com/2018/07/rspec-tutorial/ rpec tutorial]
#[https://www.stackoverflow.com/ Stackoverflow]

File:Edit questionnaire page.png

2019-05-01T02:26:46Z

Nkuncha:

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

2019-05-01T02:26:14Z

Nkuncha: added image of edit questionnaire UI

''' 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. 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 [https://github.com/expertiza/expertiza/blob/master/README.md 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===

[[File:UseCase_rubric.png|Use Case Diagram]]

===Data Flow Diagram===

[[File:dfd_4.png]]

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===

[[File:edit_questionnaire_page.png|Edit questionnaire page]]
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 are using this tag to identify there was a new question added and hence 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 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.

[[File:code2.png|Code]]

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.

[[File:code1.png|Code]]

=='''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:
# 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
# If there is a new question added - assert if the email was sent

=='''Team members'''==
1. Aishwarya Tirumala 
2. Nilay Kapadia 
3. Nitin Nataraj Kuncham 
4. Suraj Siddharudh 

=='''References'''==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://www.rubyguides.com/2018/07/rspec-tutorial/ rpec tutorial]
#[https://www.stackoverflow.com/ Stackoverflow]

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

2019-04-12T21:12:03Z

Nkuncha: added team members and references

''' 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. 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 [https://github.com/expertiza/expertiza/blob/master/README.md 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===

[[File:UseCase_rubric.png|Use Case Diagram]]

===Data Flow Diagram===

[[File:dfd_4.png]]

=='''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.

[[File:code2.png|Code]]

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.

[[File:code1.png|Code]]

=='''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:
# 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
# If there is a new question added - assert if the email was sent

=='''Team members'''==
1. Aishwarya Tirumala 
2. Nilay Kapadia 
3. Nitin Nataraj Kuncham 
4. Suraj Siddharudh 

=='''References'''==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://www.rubyguides.com/2018/07/rspec-tutorial/ rpec tutorial]
#[https://www.stackoverflow.com/ Stackoverflow]

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

2019-04-08T15:13:52Z

Nkuncha: added test plan and proposed solution (2a

CSC/ECE 517 Spring 2019 - Project E1903. Create quiz questionnaires controller.rb

2019-04-03T00:03:14Z

Nkuncha: video

== Problem Statement ==

1. The questionnaires_controller.rb has multiple methods to handle quizzes. Some of these methods cater only to quizzes. The controller has to be refactored into 2 controllers by moving the functions related to quizzes and the dependencies into a new controller called quiz_questionnaire_controller.rb.

2. Some methods in the questionnaires_controller.rb are long or have hardcoded parameters. These methods have to be refactored into shorter functions rid of hardcoded parameters.

==Changes made to current Implementation==

1. Creation of new controller 
A new controller called quiz_questionnaire_controller.rb was created using scaffold. The methods in the questionnaire control pertaining to quizzes were moved to the new controller. Certain methods such as create_questionnaire which are to be needed in both classes were refactored as explained in later sections. 
The routes.rb file was edited to reflect the new routes to the new controller's actions as shown in image below.
[[File:New_routes_file.png]] 
The views for the controller were not created or moved from questionnaires controller. Instead, every action in the quiz_questionnaire controller renders a view from the old controller itself. However, the links and redirect was edited multiple controllers and views (as stated in affected files), so that the action in the right controller was called.

to be filled

3. Refactoring current controller 
'''Problem''': Due to multiple refactoring over the years, there are few redundant methods in questionnaire_controller.rb. Additionally, a few of the methods like update_quiz, create contain the redundant piece of code and multiple switch statements.

''Refactoring of create_questionnaire method'': 
The create_questionnaire method from questionnaire_controller.rb is used to create a questionnaire based on the type of questionnaire. The implementation corresponding to the quiz is irrelevant in the context of questionnaire_controller.rb. Newly created quiz_questionnaire_controller.rb undertakes the task of creating a questionnaire of type Quiz and the original method handles the creation of all other types of questionnaires. The control was delegated based on the type of questionnaire and the corresponding method is called. 
Refactored create_questionnaire method 
[[File:create_questionnaire.png]] 
Refactored create_quiz_questionnaire method 
[[File:create_quiz_questionnaire.png]]

''Refactoring of create method'': 
The create method is used to create a questionnaire in the questionnaire_controller.rb. Based on the type of questionnaire, the name in the view is changed. Assignment of display type is done using a switch case that takes up 11 lines of code and each case adds "%" to the camel cased value.
Solution: The implementation was changed to check if the display type matches with the available type and when matched, uses Regex, split and join methods to evaluate the same in a single line.

[[File:Refactor Create Method.png]]

''Refactoring of update_quiz method'': 
The update_quiz method is used to update the quiz when the user edits the existing quiz. Iterating over the set of questions, the attributes are updated based on the type of question (viz. Multiple Choice, Radio, True/False). The implementation for two of these types can be changed and can be used as private methods.
[[File:Private_methods.png]]

''Refactoring of save_choices method'': 
The save_choices method contains a lot of redundant hard coded data that is not accessed/used in the application. These hardcoded variables were removed and the relevant code is refactored to work seamlessly.

4. Creation of new route for quiz_questionnaire_controller and updated the affected links in views 
Created a new route quiz_questionnaire for quiz_questionnaire_controller in "routes.rb" and moved the custom created "get/post" routes for quizzes from questionnaires route to it.
<pre>
resources :quiz_questionnaire, only: %i[new create edit update] do
collection do
get :new_quiz
post :create_quiz_questionnaire
get :edit_quiz
post :update_quiz
end
end
</pre>
Then changed the controller name and route in all the following views which are accessing quiz_questionnaire_controller while keeping the application flow intact -

/app/views/questionnaire/view.html.erb 
<pre>
<% if @questionnaire.type == "QuizQuestionnaire" %>
<%= link_to 'Edit', :controller => :quiz_questionnaire, :action => :edit_quiz, :id =>
@questionnaire.id, :pid => @participant.id %>|
</pre>

/app/views/questionnaire/new_quiz.erb 
<pre>
<%= form_tag :controller => 'quiz_questionnaire', :action => 'create_quiz_questionnaire',
:pid => @participant_id, :aid => @assignment_id do %>
<% $disp_flag = 1 %>
<%= render :partial => 'quiz_questionnaire' %>
<% $disp_flag = 0 %>

<%= render :partial => 'new_question_template' %>

 
<%= submit_tag "Create Quiz", :name=>"save" %>
<% end %>
</pre>

/app/views/questionnaire/edit.html.erb 
<pre>
<%= form_tag({:controller=>'quiz_questionnaire', :action=>'update_quiz', :id=>@questionnaire.id, :pid => params[:pid]}, :multipart => true) do %>
</pre>
/app/views/submitted_content/_main.html.erb 
<pre>
<% if !t_id.nil? && questionnaire = QuizQuestionnaire.where(["instructor_id = ?", t_id]).first %>
<%= link_to 'View quiz', :controller => :quiz_questionnaire, :action => :view_quiz, :id => questionnaire.id, :pid => participant.id %>
 
<% if !questionnaire.taken_by_anyone?%>
<%= link_to 'Edit quiz', :controller => :quiz_questionnaire, :action => :edit_quiz, :id => questionnaire.id, :pid => participant.id %>
<% end %>
 

<% else %>
 
<%= link_to 'Create a quiz', :controller => :quiz_questionnaire, :action => :new_quiz, :model => "QuizQuestionnaire", :private => 0, :aid => @assignment.id, :pid => participant.id %>
 
<% end %>
</pre>

==Files affected==

The following files were created or refactored
1. /app/controllers/questionnaires_controller.rb 
2. /app/controllers/quiz_questionnaire_controller.rb 
3. /app/views/questionnaire/view.html.erb 
4. /app/views/questionnaire/new_quiz.erb 
5. /app/views/questionnaire/edit.html.erb 
6. /app/views/submitted_content/_main.html.erb 
7. /config/routes.rb 
8. /spec/controllers/questionnaires_controller_spec.rb 
9. /spec/controllers/quiz_questionnaire_controller_spec.rb

==Test Plan==

The refactoring of code was done in a manner as to not affect the functionality or the code flow. Therefore, the test plan has not been modified from the original spec file apart from moving quiz_questionnaire relevant tests from questionnaire spec file to quiz_questionnaire spec file. The code is not hosted as there are no new functionalities created. As with other refactor projects, a video of using the UI is attached in the submission.

==Team members==
1. Abhishek Arya (aarya@ncsu.edu) 
2. Nitin Nataraj Kuncham (nkuncha@ncsu.edu) 
3. Suraj Siddharudh (ssiddha@ncsu.edu) 

==References==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://www.rubyguides.com/2018/07/rspec-tutorial/ rpec tutorial]
#[https://www.stackoverflow.com/ Stackoverflow]

CSC/ECE 517 Spring 2019 - Project E1903. Create quiz questionnaires controller.rb

2019-03-31T15:49:07Z

Nkuncha: Added test plan

== Problem Statement ==

1. The questionnaires_controller.rb has multiple methods to handle quizzes. Some of these methods cater only to quizzes. The controller has to be refactored into 2 controllers by moving the functions related to quizzes and the dependencies into a new controller called quiz_questionnaire_controller.rb.

2. Some methods in the questionnaires_controller.rb are long or have hardcoded parameters. These methods have to be refactored into shorter functions rid of hardcoded parameters.

==Changes made to current Implementation==

1. Creation of new controller 
A new controller called quiz_questionnaire_controller.rb was created using scaffold. The methods in the questionnaire control pertaining to quizzes were moved to the new controller. Certain methods such as create_questionnaire which are to be needed in both classes were refactored as explained in later sections. 
The routes.rb file was edited to reflect the new routes to the new controller's actions as shown in image below.
[[File:New_routes_file.png]] 
The views for the controller were not created or moved from questionnaires controller. Instead, every action in the quiz_questionnaire controller renders a view from the old controller itself. However, the links and redirect was edited multiple controllers and views (as stated in affected files), so that the action in the right controller was called.

to be filled

3. Refactoring current controller 
'''Problem''': Due to multiple refactoring over the years, there are few redundant methods in questionnaire_controller.rb. Additionally, a few of the methods like update_quiz, create contain the redundant piece of code and multiple switch statements.

''Refactoring of create_questionnaire method'': 
The create_questionnaire method from questionnaire_controller.rb is used to create a questionnaire based on the type of questionnaire. The implementation corresponding to the quiz is irrelevant in the context of questionnaire_controller.rb. Newly created quiz_questionnaire_controller.rb undertakes the task of creating a questionnaire of type Quiz and the original method handles the creation of all other types of questionnaires. The control was delegated based on the type of questionnaire and the corresponding method is called. 
Refactored create_questionnaire method 
[[File:create_questionnaire.png]] 
Refactored create_quiz_questionnaire method 
[[File:create_quiz_questionnaire.png]]

''Refactoring of create method'': 
The create method is used to create a questionnaire in the questionnaire_controller.rb. Based on the type of questionnaire, the name in the view is changed. Assignment of display type is done using a switch case that takes up 11 lines of code and each case adds "%" to the camel cased value.
Solution: The implementation was changed to check if the display type matches with the available type and when matched, uses Regex, split and join methods to evaluate the same in a single line.

[[File:Refactor Create Method.png]]

''Refactoring of update_quiz method'': 
The update_quiz method is used to update the quiz when the user edits the existing quiz. Iterating over the set of questions, the attributes are updated based on the type of question (viz. Multiple Choice, Radio, True/False). The implementation for two of these types can be changed and can be used as private methods.
[[File:Private_methods.png]]

''Refactoring of save_choices method'': 
The save_choices method contains a lot of redundant hard coded data that is not accessed/used in the application. These hardcoded variables were removed and the relevant code is refactored to work seamlessly.

4. Creation of new route for quiz_questionnaire_controller and updated the affected links in views 
Created a new route quiz_questionnaire for quiz_questionnaire_controller in "routes.rb" and moved the custom created "get/post" routes for quizzes from questionnaires route to it.
<pre>
resources :quiz_questionnaire, only: %i[new create edit update] do
collection do
get :new_quiz
post :create_quiz_questionnaire
get :edit_quiz
post :update_quiz
end
end
</pre>
Then changed the controller name and route in all the following views which are accessing quiz_questionnaire_controller while keeping the application flow intact -

/app/views/questionnaire/view.html.erb 
<pre>
<% if @questionnaire.type == "QuizQuestionnaire" %>
<%= link_to 'Edit', :controller => :quiz_questionnaire, :action => :edit_quiz, :id =>
@questionnaire.id, :pid => @participant.id %>|
</pre>

/app/views/questionnaire/new_quiz.erb 
<pre>
<%= form_tag :controller => 'quiz_questionnaire', :action => 'create_quiz_questionnaire',
:pid => @participant_id, :aid => @assignment_id do %>
<% $disp_flag = 1 %>
<%= render :partial => 'quiz_questionnaire' %>
<% $disp_flag = 0 %>

<%= render :partial => 'new_question_template' %>

 
<%= submit_tag "Create Quiz", :name=>"save" %>
<% end %>
</pre>

/app/views/questionnaire/edit.html.erb 
<pre>
<%= form_tag({:controller=>'quiz_questionnaire', :action=>'update_quiz', :id=>@questionnaire.id, :pid => params[:pid]}, :multipart => true) do %>
</pre>
/app/views/submitted_content/_main.html.erb 
<pre>
<% if !t_id.nil? && questionnaire = QuizQuestionnaire.where(["instructor_id = ?", t_id]).first %>
<%= link_to 'View quiz', :controller => :quiz_questionnaire, :action => :view_quiz, :id => questionnaire.id, :pid => participant.id %>
 
<% if !questionnaire.taken_by_anyone?%>
<%= link_to 'Edit quiz', :controller => :quiz_questionnaire, :action => :edit_quiz, :id => questionnaire.id, :pid => participant.id %>
<% end %>
 

<% else %>
 
<%= link_to 'Create a quiz', :controller => :quiz_questionnaire, :action => :new_quiz, :model => "QuizQuestionnaire", :private => 0, :aid => @assignment.id, :pid => participant.id %>
 
<% end %>
</pre>

==Files affected==

The following files were created or refactored
1. /app/controllers/questionnaires_controller.rb 
2. /app/controllers/quiz_questionnaire_controller.rb 
3. /app/views/questionnaire/view.html.erb 
4. /app/views/questionnaire/new_quiz.erb 
5. /app/views/questionnaire/edit.html.erb 
6. /app/views/submitted_content/_main.html.erb 
7. /config/routes.rb 
8. /spec/controllers/questionnaires_controller_spec.rb 
9. /spec/controllers/quiz_questionnaire_controller_spec.rb

==Test Plan==

The refactoring of code was done in a manner as to not affect the functionality or the code flow. Therefore, the test plan has not been modified from the original spec file apart from moving quiz_questionnaire relevant tests from questionnaire spec file to quiz_questionnaire spec file.

==Team members==
1. Abhishek Arya (aarya@ncsu.edu) 
2. Nitin Nataraj Kuncham (nkuncha@ncsu.edu) 
3. Suraj Siddharudh (ssiddha@ncsu.edu) 

==References==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://www.rubyguides.com/2018/07/rspec-tutorial/ rpec tutorial]
#[https://www.stackoverflow.com/ Stackoverflow]

File:New routes file.png

2019-03-28T17:29:27Z

Nkuncha:

CSC/ECE 517 Spring 2019 - Project E1903. Create quiz questionnaires controller.rb

2019-03-26T01:43:23Z

Nkuncha: Added creation of new controller

== Problem Statement ==

1. The questionnaires_controller.rb has multiple methods to handle quizzes. Some of these methods cater only to quizzes. The controller has to be refactored into 2 controllers by moving the functions related to quizzes and the dependencies into a new controller called quiz_questionnaire_controller.rb.

2. Some methods in the questionnaires_controller.rb are long or have hardcoded parameters. These methods have to be refactored into shorter functions rid of hardcoded parameters.

==Changes made to current Implementation==

1. Creation of new controller 
A new controller called quiz_questionnaire_controller.rb was created using scaffold. The methods in the questionnaire control pertaining to quizzes were moved to the new controller. Certain methods such as create_questionnaire which are to be needed in both classes were refactored as explained in later sections. 
The routes.rb file was edited to reflect the new routes to the new controller's actions as shown in image below.
[[File:New_routes_file.png]] 
The views for the controller were not created or moved from questionnaires controller. Instead, every action in the quiz_questionnaire controller renders a view from the old controller itself. However, the links and redirect was edited multiple controllers and views (as stated in affected files), so that the action in the right controller was called.

to be filled

2. Creation of Rspec file for new controller 
to be filled

3. Refactoring current controller 
'''Problem''': Due to multiple refactoring over the years, there are few redundant methods in questionnaire_controller.rb. Additionally, a few of the methods like update_quiz, create contain the redundant piece of code and multiple switch statements.

''Refactoring of create_questionnaire method'': 
The create_questionnaire method from questionnaire_controller.rb is used to create a questionnaire based on the type of questionnaire. The implementation corresponding to the quiz is irrelevant in the context of questionnaire_controller.rb. Newly created quiz_questionnaire_controller.rb undertakes the task of creating a questionnaire of type Quiz and the original method handles the creation of all other types of questionnaires. The control was delegated based on the type of questionnaire and the corresponding method is called. 
Refactored create_questionnaire method 
[[File:create_questionnaire.png]] 
Refactored create_quiz_questionnaire method 
[[File:create_quiz_questionnaire.png]]

''Refactoring of create method'': 
The create method is used to create a questionnaire in the questionnaire_controller.rb. Based on the type of questionnaire, the name in the view is changed. Assignment of display type is done using a switch case that takes up 11 lines of code and each case adds "%" to the camel cased value.
Solution: The implementation was changed to check if the display type matches with the available type and when matched, uses Regex, split and join methods to evaluate the same in a single line.

[[File:Refactor Create Method.png]]

''Refactoring of update_quiz method'': 
The update_quiz method is used to update the quiz when the user edits the existing quiz. Iterating over the set of questions, the attributes are updated based on the type of question (viz. Multiple Choice, Radio, True/False). The implementation for two of these types can be changed and can be used as private methods.
[[File:Private_methods.png]]

''Refactoring of save_choices method'': 
The save_choices method contains a lot of redundant hard coded data that is not accessed/used in the application. These hardcoded variables were removed and the relevant code is refactored to work seamlessly.

4. Creation of new route for quiz_questionnaire_controller and updated the affected links in views 
Created a new route quiz_questionnaire for quiz_questionnaire_controller in "routes.rb" and moved the custom created "get/post" routes for quizzes from questionnaires route to it.
<pre>
resources :quiz_questionnaire, only: %i[new create edit update] do
collection do
get :new_quiz
post :create_quiz_questionnaire
get :edit_quiz
post :update_quiz
end
end
</pre>
Then changed the controller name and route in all the following views which are accessing quiz_questionnaire_controller while keeping the application flow intact -

/app/views/questionnaire/view.html.erb 
<pre>
<% if @questionnaire.type == "QuizQuestionnaire" %>
<%= link_to 'Edit', :controller => :quiz_questionnaire, :action => :edit_quiz, :id =>
@questionnaire.id, :pid => @participant.id %>|
</pre>

/app/views/questionnaire/new_quiz.erb 
<pre>
<%= form_tag :controller => 'quiz_questionnaire', :action => 'create_quiz_questionnaire',
:pid => @participant_id, :aid => @assignment_id do %>
<% $disp_flag = 1 %>
<%= render :partial => 'quiz_questionnaire' %>
<% $disp_flag = 0 %>

<%= render :partial => 'new_question_template' %>

 
<%= submit_tag "Create Quiz", :name=>"save" %>
<% end %>
</pre>

/app/views/questionnaire/edit.html.erb 
<pre>
<%= form_tag({:controller=>'quiz_questionnaire', :action=>'update_quiz', :id=>@questionnaire.id, :pid => params[:pid]}, :multipart => true) do %>
</pre>
/app/views/submitted_content/_main.html.erb 
<pre>
<% if !t_id.nil? && questionnaire = QuizQuestionnaire.where(["instructor_id = ?", t_id]).first %>
<%= link_to 'View quiz', :controller => :quiz_questionnaire, :action => :view_quiz, :id => questionnaire.id, :pid => participant.id %>
 
<% if !questionnaire.taken_by_anyone?%>
<%= link_to 'Edit quiz', :controller => :quiz_questionnaire, :action => :edit_quiz, :id => questionnaire.id, :pid => participant.id %>
<% end %>
 

<% else %>
 
<%= link_to 'Create a quiz', :controller => :quiz_questionnaire, :action => :new_quiz, :model => "QuizQuestionnaire", :private => 0, :aid => @assignment.id, :pid => participant.id %>
 
<% end %>
</pre>

==Files affected==

The following files were created or refactored
1. /app/controllers/questionnaires_controller.rb 
2. /app/controllers/quiz_questionnaire_controller.rb 
3. /app/views/questionnaire/view.html.erb 
4. /app/views/questionnaire/new_quiz.erb 
5. /app/views/questionnaire/edit.html.erb 
6. /app/views/submitted_content/_main.html.erb 
7. /config/routes.rb 
8. /spec/controllers/questionnaires_controller_spec.rb 
9. /spec/controllers/quiz_questionnaire_controller_spec.rb

==Team members==
1. Abhishek Arya (aarya@ncsu.edu) 
2. Nitin Nataraj Kuncham (nkuncha@ncsu.edu) 
3. Suraj Siddharudh (ssiddha@ncsu.edu) 

==References==
#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://www.rubyguides.com/2018/07/rspec-tutorial/ rpec tutorial]
#[https://www.stackoverflow.com/ Stackoverflow]

File:New routes file.PNG

2019-03-26T01:37:52Z

Nkuncha: new routes.rb for to include routes for new controller

new routes.rb for to include routes for new controller

CSC/ECE 517 Spring 2019 - Project E1903. Create quiz questionnaires controller.rb

2019-03-25T18:42:52Z

Nkuncha: filled problem statement, files affected, team members and references